"Windows Server 2003 ships with .Net 1.1 but doesn't actually run any of its OS code within it"
I don't really know what this means. I assume this guy is saying that Windows 2003 Server doesn't run .NET code natively, but what exactly is that distinction? Does Windows run VB code natively? VB requires vbrun*.dll. So does that mean it doesn't run the code "within it"?
In Windows 9x/2000, .NET code is run via a modifacation to the PE (portable executable) file header. When you double click a .NET exe, Windows sees this additional entry in the PE header, and redirects the execution to the .NET COM server. (That's right, .NET is actually a COM server.)
In Windows XP/2003+, .NET code is now a first class PE citizen, as the header has been changed to include .NET executables in the list of inherently supported types. Of course, when it's run, it still gets forwarded to a COM server.
In Windows 2003, the .NET runtimes are loaded at startup by the OS. Just as the WinAPI runtimes (well, supporting DLLs) are loaded. So the only difference between .NET on Win2k3 and, say, a C++ application on Win2k3, is the fact that the .NET code is run by a COM server.
I guess this guy could also be talking about the fact that the Win2k3 server isn't 100% .NET yet. Microsoft has long hinted that a future version of Windows will be 100% .NET in the sense that it will only run .NET applications, and that the only available APIs are the .NET framework libraries. This, of course, has many advantages. But it would also make people just like this guy scream bloody murder because his VB app doesn't work anymore.
We're several years off before Windows "is" .NET, and to complain that it isn't .NET yet is silly, because we don't want it to be .NET yet.
|