This PDC 2005 session was a great introduction to the top-level application framework used by WPF. We learned about the Application class. We learned about the various ways to store application settings. We learned about the various supported “user experience models,” and about the navigation-based model in particular.

I didn’t realize that WPF would have special support for “structured navigation” – that’s when you navigate to a page or series of pages that has a “finish” button at the end that brings you back to the page where you started the trail, akin to a traditional application that launches a wizard dialog, but all in the main frame of the application. I still don’t quite understand the programming model, but it didn’t look too complicated.

The session also talked about running WPF applications from a Web browser. The same application model is used for both Windows and Web apps, though there are special challenges for Web apps, especially as regards code access security.

The Microsoft Visual Studio Express Editions are absolutely free! Installed!

• Visual C++ 2005 Express
• Visual C# 2005 Express
• Visual Web Developer 2005 Express
• SQL Server 2005 Express

This PDC 2005 session was about WinFS, the object-oriented storage system that Microsoft has been working on for years. It is certainly interesting, but still basically the same technology that they were talking about two years ago. It’s also hard to get excited about a technology that they’re not planning to ship until after Windows Vista ships in late 2006…

I love writing extensible applications, so I was very interested in attending this PDC session. The obvious approach to writing managed add-ins is to simply load any assemblies that are registered as add-ins, use reflection to look for specially-marked types in each assembly, create instances of those types, and communicate with those instances. This session talked about potential problems with that approach and discussed solutions.

One problem is that old add-ins won’t work with new versions of the application (and vice-versa) because of strong naming. This problem is solved by using non-versioned, stable interfaces for any communication between the application and the add-in.

If the add-in assembly is loaded directly, the assembly can’t be unloaded if the add-in is unloaded. This can be solved by loading the assembly into its own app domain, or even in its own process. Also, the add-in must run under the same security as the application unless it is loaded into its own app domain or process. Another potential problem is that the add-in must use the same version of the CLR and the .NET Framework, but the only way around that is to load the add-in into a separate process.

Of course, loading an add-in into its own app domain has its own problems. Objects that are passed between the application and the add-in must be serializable or marshal-by-ref, which can be more work, and decreases performance. Loading an add-in into its own process provides even worse performance, and communication between the two becomes even more difficult.

The speakers thus recommended loading add-in assemblies into their own app domains, and spent the rest of the session explaining the add-in model used by the new System.AddIn namespace. Unfortunately, I was pretty lost for most of the presentation; it can’t be as complicated as it seemed…

In any case, I’ll still consider the direct approach for loading add-ins if I ever need them for a desktop application. Leaving an add-in assembly loaded even after the add-in is unloaded is not a significant problem for short-lived client apps. Giving add-ins full trust seems a bit dangerous, but if you trust an add-in developer enough to run their installer, it’s not a stretch that you need to trust their add-in as well.

(Ah, “performant.” I used that word the other day while talking to my boss, and he wondered if I had made it up. It’s not actually a word, and most people talking about it on the Internet don’t seem to like it very much, but it works for me. I knew immediately what it was getting at – “having high performance,” basically. I wonder how long it will take to make it into the dictionary…)

Rico Mariani’s session was mostly about performance improvements to the .NET Framework 2.0. He talked about improvements to “ngen,” which should be good news for the startup time of client applications. He talked about “generic” collections – and warned against creating too many collection types that store less than 500 value type items. He talked about how “foreach” should now always be the optimal way to enumerate a collection. Garbage collection is faster, and it’s okay to call GC.Collect after the user does something that causes “mass extinction” of objects. Throwing exceptions is faster – though still discouraged for normal flow control. Security is faster, particularly for “full trust” applications. Reflection is faster – good news for users of custom attributes. Profiling is better. Delegates are faster. String hashing is faster. Et cetera. Basically, to “write performant managed code,” use the latest .NET Framework.

Brent Rector’s session was not what I had hoped it would be. I thought I was going to learn about the APIs, but the session was about some of the SDK tools. The session seemed pretty random; here are some of the interesting bits:

• The XSD tool will help you build an XML schema from a .NET class or an existing XML document, and it will build a .NET class from an XML schema.
• The SGEN tool will build XML serializer code so that it doesn’t have to happen via reflection at runtime.
• The Fusion Log Viewer can be used to see where your .NET assemblies are coming from, but the tool is ugly and finicky.
• The new Windows shell (code-named Monad) looks very cool, but I wonder if I’ll ever take the time to learn it. If you spend a lot of time writing batch files and one-off scripts, you should really appreciate its power.
• Perforator is a tool that can help diagnose WPF (Avalon) performance (frame rates, etc.).

I attended two Birds of a Feather sessions, which are informal sessions where the (generally small) audience is expected to participate in the discussion.

I started at Keith Brown’s “Writing Secure Code” session, but it ended up focusing on server security, which really isn’t relevant to what I do. So I switched to John Moody’s “Help! I Have to Manage Programmers!”, which was packed to the gills. Clearly this topic resonated with people, and there were lots of strong opinions in the audience. Much of the discussion was about task estimation. One interesting idea was to allow experienced programmers to estimate longer tasks, but require newer programmers to estimate shorter tasks.

For the next session, I returned to Keith Brown for “Writing Partially Trusted Code,” which was much more interesting to me than his first session, as it stayed more focused on client applications. I actually learned some things about .NET code access security, the most important of which was about assembly-level security attributes. Even though FxCop wants me to declare security attributes on my assemblies, the experts at the session insisted that it is often best to simply ignore that rule. That’s great, because I still don’t understand how I would use them.

This session by Joe Duffy had more practical advice about programming with concurrency. Some highlights:

• It is important to maintain invariants (“assumed conditions in your code”), even in the face of exceptions.
• Asynchronous exceptions like thread aborts can happen almost anywhere, which can make invariant maintenance difficult, but .NET prevents them from being thrown from certain sensitive areas, such as catch/finally blocks, static constructors, and native code.
• Generally speaking, when you write a class, you should make any static state thread-safe, but require your client to lock access to your class instances, since you can’t predict their concurrency needs.
• Always protect shared memory with locks. In .NET, locks do more than prevent concurrent access; they also guard the code against hardware instruction reordering, etc.
• In the future, parallel programming will be the only way to leverage the increasing speed of computers, as the speed of a single CPU is nearing its physical maximum.

This was a good session by Jan Gray on the fundamentals of using concurrency in software development. Why bother with concurrency? For one, hanging the application is as disruptive as a crash, so it is important to free up the user interface thread by delegating work to other threads. You can also improve the user experience by allowing the user to see the status of the work, examine partial results of the work so far, and cancel the work if necessary.

Another use of concurrency is to increase performance by spreading the work across multiple processors. Of course, measurement is the key here; before adding the complexity of concurrency, make sure that you’re already pegging the CPU, and make sure that your algorithms are already fully optimized.

This session provided a number of tips:

• Server applications are often already highly concurrent, since each client gets their own thread, and SQL can distribute a single database query among multiple processors.
• OpenMP exists for doing straightforward parallelism in client applications. (It is supported by Visual C++ 2005.) Otherwise, the classic tools are threads using shared memory protected by locks.
• The standard techniques for protecting shared memory from conflicts, in increasing order of difficulty, are confinement (sharing as little memory as possible), immutability (not allowing writes to the shared memory), and synchronization (locking access to the shared memory).
• There are three primary goals when writing concurrent code: safety (identifying and holding “invariants” in shared data), liveness (avoiding deadlocks – two threads waiting for a lock the other holds), and efficiency (making the code as parallel as possible, generally by waiting as little as possible).
• In most cases, the thread pool is best for doing work in parallel, since it may not have the overhead of creating a new thread. In .NET, use ThreadPool.QueueUserWorkItem or BackgroundWorker.
• In .NET, use the Monitor class for shared memory management. Two threads interacting via shared memory use Monitor.Enter and Monitor.Exit to protect the memory. If one thread needs to wait for the other, Monitor.Wait releases the lock until the other thread calls Monitor.Pulse and releases its lock.
• If necessary, consider other classes in the System.Threading namespace, such as WaitHandle, Auto/ManualResetEvent, Mutex, and Semaphore. Rarely consider the Interlocked methods, ReaderWriterLock, Thread.Interrupt, and asynchronous delegates.
• Lock all writable shared state over the entire invariant, using private lock objects (not the instance or type object).
• Avoid calling “third-party” code while you hold a lock, including overridable methods.
• Use asynchronous I/O, e.g. Stream.BeginRead in .NET.

My first session at PDC 2005 was “Getting Users to Fall in Love with Your Software” by Hillel Cooperman. This session wasn’t really about Microsoft technology, but about ways to ensure that your users have a positive emotional reaction to your software. Unfortunately, there were no easy answers given here. Basically, you need to understand your customers, watch them in usability studies, anonymously instrument their use of the software, etc. Software products should be friendly, forgiving, and rock-solid.

Of course, there are other factors at play here, particularly the cost in time and money of doing all of that research and subsequent development. When retrofitting an existing software package, you also need to consider the amount of retraining that will be necessary.

The application that they developed to demonstrate these principles is a photo album application called Microsoft Max. If you’re curious, and dare install the WinFX September CTP, go check it out.

Basically, this session was a good reminder that we need to spend all of the time and money we can afford to eliminate the many negative emotional reactions that our products create in our users and actively strive toward a positive experience. Like most aspects of software development, there’s never a point where you’ve reached perfection, but most software teams should be spending more time in this area than they are.

It was, of course, fun to watch Bill Gates give his keynote on Day One. The video segment was entertaining, though a bit lost on me – it was a spoof on Napoleon Dynamite, which I have not seen. Jim Allchin’s keynote was also good; it was fun to see Windows 1.0 running on an old IBM XT. He claimed that 475 million new PCs will ship in the two years after Windows Vista is released; I reckon I’ll be one of the buyers. The best part of the keynotes on Day One was the demos. We saw Windows Vista and Office “12” and Superfetch and “Atlas” and WPF and WCF and LINQ, etc. Great stuff.

The keynotes on Day Two were a bit less interesting. The first half wasn’t too bad; we saw demos of Windows Workflow Foundation and the new Expression products for designing the next generation of cool user interface. The second half was, unfortunately, one of the most boring demos I’ve ever sat through, being about two technologies I (still) know nothing about, InfoPath and SharePoint.

I had low expectations for the keynote on Day Three, but it turned out fine. It was all about the new features coming for Windows Server, including better debugging of Web applications, remote computing, the new console, and IIS improvements, particularly for ASP.NET applications.

The “trouble” with the PDC is that it’s about products that won’t ship for a year or two; I’m ready now!

Last week, I went to the Microsoft PDC with three coworkers and had a great time. They keep you much too busy to blog while you’re there, but that shouldn’t stop me from blogging it now that I’m back, right?

The conference really was excellent. For the most part, it was well-organized and well-executed. Even the name badge was great, complete with a pen and an easy-to-access mini-guide of the conference for helping you keep track of the agenda, find your next session, etc. Food and drink was available everywhere, at all times, including three square meals each day. Lots of software and “swag” was distributed by Microsoft and by various sponsors and advertisers. An evening of exclusive access to Universal Studios was simply the icing on the cake. The PDC isn’t cheap, so it’s hard to measure whether it is “worth it,” but it was, at minimum, a great experience. Hopefully I’m better prepared to face the future of Windows application development…