WPF and the CLR

A while back, someone asked me whether Windows Presentation Foundation calls any private APIs in the CLR.  The answer is no, we don't use any CLR APIs you couldn't call yourself.  Although the question motivated me to ask around about what features in the CLR were motivated by WPF (sometimes we were the only motivation, sometimes we were just one motivation among many, you'd really need to ask the CLR folks why they did any particular feature).  It ended up being almost entirely around performance, deployment, and security.

The performance work was mostly around the things that benefit client applications more than server applications, especially working set.  Rico blogged recently about some of the 2005 perf improvements, particularly around decreasing private pages/increasing shared pages.  The various ngen improvements and security speedups have helped WPF significantly, and AddMemoryPressure is perfect for how to deal with a managed Image that holds onto unmanaged image data.

The second area is deployment, where the CLR added the InPlaceHostingManager api.  This enables WPF's web browser applications, which extend click-once technology by letting you run that application in the browser.  (The "InPlace" refers to the interface loading an application into the same process -- in the browser, WPF has one small app domain that acts as a loader for the main application's app domain)

In the security realm, the big advance was transparent assemblies.  Ultimately this is about managing a large development project -- we have hundreds of people working on WPF, if we had to trust every last one of them to write absolutely perfect security code, we'd be out of luck.  Instead, we've marked a small number of classes as being security-critical, and only those classes are allowed to make security asserts, which elevates privilege above the caller's permissions.  All the remaining classes are transparent -- they aren't allowed to assert, and run with the permission of their caller, even though they are part of a trusted dll.  (Which is not to say they can't cause any security problems, just that we don't need to watch them like a hawk the same way we need to watch security-critical classes)  I've heard this technique referred to as creating a secure kernel, and transparent assemblies have been a critical part in that methodology.