WIN32 API and Windows CE

The Win32 API is the core programming interface for Windows CE. In the early 1990s, Microsoft announced that its two core strategic technologies were Win32 and the Component Object Model (COM). The Win32 API is supported on all Windows operating systems, including 16-bit systems (Microsoft Windows 95, Windows 98, and Windows Millennium Edition) and 32-bit systems (Microsoft Windows NT, Windows 2000, and Windows XP). Windows CE was the first Microsoft operating system to use the Win32 API for both device drivers and applications. Sixteen-bit Windows systems use the Virtual (VxD) drivers at their lowest layer, and 32-bit Windows systems have a proprietary kernel-mode API that is decidedly not Win32. Therefore, Windows CE is more deeply connected to Win32 than any other Microsoft operating system. Win32 has been referred to as the "assembly language of Windows," because it is a very low-level API with very primitive functions. Just as multiple machine language instructions are needed to accomplish even the simplest task, multiple Win32 function calls are often needed to do real work. This is, however, the API that all other APIs and development tools ultimately rely on to get things done. In the context of the .NET Framework, Win32 code is referred to as "unmanaged code." This is because the Common Language Runtime does not manage the memory, or guarantee the security and type-safety, of Win32 code. .NET code, by contrast, is called "managed code" because all these features and more are provided by the .NET runtime. Understanding the distinction between managed and unmanaged code is key to understanding the difference between these two APIs.

WIN32 API History

Before I present some of my WIN32 modules, I'll start explaining the WIN32 API by introducing you to its history as it can be found at Wikipedia.

The Windows API has always exposed a large part of the underlying structure of the various Windows systems for which it has been built to the programmer. This has had the advantage of giving Windows programmers a great deal of flexibility and power over their applications. However, it also has given Windows applications a great deal of responsibility in handling various low-level, sometimes tedious, operations that are associated with a graphical user interface.

Charles Petzold, writer of well-read Windows API books, has said: "The original hello-world program in the Windows 1.0 SDK was a bit of a scandal. HELLO.C was about 150 lines long, and the HELLO.RC resource script had another 20 or so more lines. (...) Veteran C programmers often curled up in horror or laughter when encountering the Windows hello-world program." A Hello world program is a frequently used programming example, usually designed to show the easiest possible application on a system that can actually do something (i.e. print a line that says "Hello World").

Over the years, various changes and additions were made to the Windows Operating System, and the Windows API changed and grew to reflect this. The Windows API for Windows 1.0 supported fewer than 450 function calls, where in modern versions of the Windows API there are thousands. However, in general, the interface remained fairly consistent, and an old Windows 1.0 application will still look familiar to a programmer who is used to the modern Windows API.

A large emphasis has been put by Microsoft on maintaining software backwards compatibility. To achieve this, Microsoft sometimes even went as far as supporting software that was using the API in an undocumented or even (programmatically) illegal way. Raymond Chen, a Microsoft developer who works on the Windows API, has said: "I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure."

One of the largest changes the Windows API underwent was the transition from Win16 (shipped in Windows 3.1 and older) to Win32 (Windows NT and Windows 95 and up). While Win32 was originally introduced with Windows NT 3.1 and Win32s allowed usage of a Win32 subset before Windows 95, it was not until Windows 95 that many applications began being ported to Win32. To ease the transition, in Windows 95, both for external developers and for Microsoft itself, a complex scheme of API thunks was used that could allow 32 bit code to call into 16 bit code and (in limited cases) vice-versa. So-called flat thunks allowed 32 bit code to call into 16 bit libraries, and the scheme was used extensively inside Windows 95 to avoid porting the whole OS to Win32 itself in one chunk. In Windows NT, the OS was pure 32-bit (except the parts for compatibility with 16-bit applications) and the only thunk available was generic thunks which only thunks from Win16 to Win32 and worked in Windows 95 too. The Platform SDK shipped with a compiler that could produce the code necessary for these thunks.