One of the core tenets of the entire .NET architecture (compared to the native Win32 world) was security. At the very beginning, it was often claimed you could mathematically prove that a managed application was types safe, you could use Code Access Security to determine if an application had specific permission to execute any code deemed potentially unsafe. Also the goal (4 or 5 years ago) was to rapidly phase out COM (declared an obsolete legacy technology right after .NET was launched) and native code in favor of an all managed ecosystem.

Fast forward to the last few weeks. First, one of the most heralded new features of Silverlight 4 is its COM binding capability. This goes against the security mantra (even if this will be possible only for applications installed locally), the entire idea of portability (how could a Mono app on Linux talk via COM to Office is a mystery), and the notion that COM is obsolete. One of the core issues is Microsoft Office interaction. If Microsoft cannot push Office as an element of its development ecosystem.

Second, one of the cornerstones of .NET security, Code Access Security, is "retired" as Tim Anderson clearly tells in his blog. Even if powerful, the model was too complex for most programmers to comply with and system administrators to enable. This certainly doesn't compromise the security of .NET applications in any way, as I doubt it was really used.

Now if we put these two unrelated announcements together, the morale is quite obvious (at least to me and many other die-heats native Win32 developers): Native COM and Win32 code is here to stay and using it properly doesn't compromise security. This is not surprising, given the amount of new native (COM and Win32) features in Windows Vista and (even more) Windows 7. There is nothing new in recent operating systems you cannot use in a native application.

Connecting the dots, however, I'm tempted to push this a little forward. Contrary to what Microsoft envisioned or hoped or simply told us, the Windows ecosystem is not moving towards a .NET centric solution, but .NET is only a powerful and sophisticated execution and development environment on top of Windows . Which is what Delphi and the VCL are, even if at a much smaller extened due to the highly different R&D budget behind it. I know this is debatable, happy to hear about your point of view.