Question

If a software/library has some support for the Windows platform they almost always name their directories and variables as win32. This is most prevalent in C/C++ projects. Even the MinGW project's target triple uses win32. Is there a reason for this? Why not use a proper name like Windows or Microsoft Windows? Is there a legal snag around the naming choice?

This question is not about the API, but the naming convention in use. When a library supports other operating systems, they often use the proper names like linux, freebsd or whatever special support needed. But when it comes to Windows, it's often abbreviated as win32 which seems a bit odd compared to the rest.

Was it helpful?

Solution

Win32 is the customary name for the Windows API. This API specifies how applications can interface with the operating system. It is roughly comparable with the POSIX standard on Unix, but Win32 also covers GUIs and many other features.

The Win32 API is not limited to 32-bit Windows installations.

From the Windows Dev Center:

The Windows application programming interface (API) lets you develop desktop and server applications that run successfully on all versions of Windows while taking advantage of the features and capabilities unique to each version.

The Windows API can be used in all Windows-based desktop applications, and the same functions are generally supported on 32-bit and 64-bit Windows. Differences in the implementation of the programming elements depend on the capabilities of the underlying operating system. These differences are noted in the API documentation.

Note This was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.

You do not have to use the Win32 API to develop for Windows. Alternatives are the .NET classes or the Windows RT interface.

There technically is a Win64 variant. But it differs from Win32 mostly in the data model (the size of pointers). It is not a distinct set of APIs:

The Win64 API environment is almost the same as the Win32 API environment—unlike the major shift from Win16 to Win32. The Win32 and Win64 APIs are now combined and called the Windows API. Using the Windows API, you can compile the same source code to run natively on either 32-bit Windows or 64-bit Windows. To port the application to 64-bit Windows, just recompile the code.

The Windows header files are modified so that you can use them for both 32-bit and 64-bit code. (source)

Because Win64 is not substantially different you will almost never see projects targeting win64 on a source-code level, though newer projects might target winapi instead of the traditional win32. But for all practical purposes all these names refer to the same API.

OTHER TIPS

Because the Windows API is 30+ years old and has been around when PC's were 16-bit, then 32-bit came along, then Win32s, then win64. There is platform dependence in windows development, and you need your code to match the OS libraries (dll's) in architecture.

https://en.wikipedia.org/wiki/Windows_API#Versions

A windows application that is built against win32 will run on 32-bit architectures, and will run on 64-bit by virtue of the Windows operating system providing a win32 subsystem so that win32 apps run on a modern 64-bit windows OS.

While win32 builds are becoming less and less as time goes by, win32 probably won't fade completely out any time soon. When win32 builds do phase out, there will probably be a win128, and win64 will be come the new win32.

Licensed under: CC-BY-SA with attribution
scroll top