.NET vs Win32 - Really?

Sunday, February 22, 2004 04:39 AM

One of the things people keep telling me about .NET is that Microsoft had announced that Win32 will only be supported as an emulation layer in the next version of Windows ("Longhorn"), so we should all migrate our existing applications to .NET. Unless they're friends, or people I really don't want to hear from ever again, I can't really laugh at their face, so I have to give some reasonable answers. Here are some:

1. It's just not true. As of today, Microsoft deosn't plan to reimplement Win32, Win64, or any other native API as a managed API. On the other hand, Microsoft does plan to provide new managed APIs that will not necessarily be available to unmanaged applications. (Take a look at this message posted to Borland's newsgroups).

2. Even if it was true, it won't break my code. If ever there was a software company that invested heavily in backward compatibility, it's Miocrosoft. Just take a look at the amount of code in Windows 95 to detect specific application and change the operating system's behavior for them. In fact, Windows 95 reports its version number to applications as 3.95 (and not 4.0), just to work around a common bug that incorrectly tested for Windows 3.1. There's just no way Microsoft would break the Win32 API.

3. Win32 is already an emulation layer. Most Windows programmers aren't even aware of this fact, but Win32 isn't really the native API in the NT family of operating systems (Windows NT, Windows 2000, Windows XP, and Windows 2003). NT uses a modified microkernel architecture, and Win32 is implemented as a subsystem that provides applications and services with the Win32 API, which it then translates into "native" system calls. If you look at the list of processes in the Task Manager, you'll find several interesting processes, such as smss.exe, the Session Manager Subsystem, which creates NT's user-mode environment and loads other subsystems. The Win32 sybsystem is implemented by csrss.exe (Client/Server Runtime Subsystem), and several DLLs, such as KERNEL32.DLL, USER32.DLL, and GDI32.DLL. NT's real API (sometimes known as the native API) is accessible through NTDLL.DLL, which doesn't really implement it, but triggers software exception to switch the code into kernel mode.

In fact, Win32 is just one of several subsystems supported by NT. NT's designers built the system as a sort of operating system musuem, and included several other subsystems, such as OS/2 and POSIX (how many POSIX applications do you have on your system, by the way?). The bottom line is that Win32 has always been an emulation layer, and I don't see that changing. And unless Microsoft want to commit suicide, they won't break it.