Microsoft Windows Api

The Microsoft Windows API, properly spelled Win32, is what programmers use when programming Windows directly (i.e., not through a toolkit or high level language) to display windows on the screen, communicate with the file system, etc.

There are several implementations of the Win32 API:

• WindowsNt, WindowsTwoThousand, WindowsXp, WindowsServerTwoThousandThree
• WindowsNinetyFive, WindowsNinetyEight, WindowsMe
• WinCe, PocketPc, WindowsMobile
• WineProject?

Earlier versions of Windows used a 16-bit API.

There is some debate about exactly what functions constitute the Win32 API. This is not helped by the fact that Microsoft continuously adds new functions to the API.

Complexity

To give you an idea of how complex it is... the Windows API won't even give you the time of day -- unless you #include <windows.h>, create a SYSTEMTIME structure, and call GetSystemTime with its address as a parameter. But it will give you UTC time. To convert it to local time, you have to create a TIME_ZONE_INFORMATION structure, then call GetTimeZoneInformation, passing the address of the structure as a parameter. This function will return TIME_ZONE_ID_STANDARD if it succeeds and you're on standard time, or TIME_ZONE_ID_DAYLIGHT if it succeeds and you're on daylight savings time, or TIME_ZONE_ID_UNKNOWN under certain circumstances (this is not an error but a warning), or TIME_ZONE_ID_INVALID in case of error. If there is an error, call GetLastError for extended error information.

If it succeeds, then you must create another SYSTEMTIME structure and call SystemTimeToTzSpecificLocalTime, which requires a pointer to the TIME_ZONE_INFORMATION, a pointer to the SYSTEMTIME input, and a pointer to the SYSTEMTIME output. The SYSTEMTIME structure contains eight WORD data fields: wYear, wMonth, wDayOfWeek, wDay, wHour, wMinute, wSecond, and wMilliseconds.

At least it's thorough.

Or, you could just have called GetLocalTime() instead of GetSystemTime() in the first place! -- MikeSmith

I love the opening argument!

Windows:

 SYSTEMTIME time;
 GetLocalTime(&time);

done

posix:

 *crickets*

I'm convinced!

Because of the complexity, many programmers prefer to use a higher-level abstraction where possible. For basic file input/output, most languages provide bindings that hide a significant amount of the complexity. The MicrosoftDotNet BaseClassLibrary? is basically an object-oriented wrapper around the Win32 API.

Comparisons to PosixStandard

Note that in WindowsNt and its derived operating systems, Win32 is not a native layer above the kernel. The WindowsNt kernel natively exposes the NT API, which is significantly different from Win32. Win32, POSIX, and some other APIs are installed as "subsystems" above the native NT API. This is in contrast to most Unix operating systems, where the kernel exposes a POSIX API that is consumed directly by user programs.

Part of the problem with the Win32 API, as illustrated above, is the low-level nature inherent in all procedural APIs. However, some things are really easy to achieve with the Win32 API compared to POSIX.

For example, the concept of "waitable object" is very elegant and allows a thread to wait for multiple resources -- files, IO streams, mutexes, semaphores, timers, etc. etc. Compare this to POSIX where you must select or poll for I/O events on file descriptors, set up signal handlers for timers, and then handle pthread synchronisation objects and SysV IPC objects with entirely different APIs. Getting all those different APIs to work correctly together can get pretty hairy.

Development resources

All programmers who do any serious Windows programming in C or C++ should download the MicrosoftPlatformSdk? (software development kit) documentation, which includes header files and HTML-help documentation for all the Windows API functions. Even if you use MicrosoftDotNet or another high-level abstraction, it is recommended, because most Win32 abstractions are LeakyAbstractions.

---

CategoryMicrosoft, CategoryOperatingSystem