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.

  • 11
    Because 32bit applications are different from 64bit applications?
    – Oded
    Aug 29, 2017 at 12:03
  • 55
    Win32 is the name of the Windows API, similar to the role of POSIX on Unix/Linux systems. The name may have originated from 32-bit processors, but that should be seen as a historic artefact.
    – amon
    Aug 29, 2017 at 12:12
  • 4
    Why is bin traditionally used to indicate a directory with binary executables? It's just a convention. win32 is just shorthand for a program running on windows with 32 bits. If you prefer to call it flimflam, you're welcome to do so, though it may not be very clear in your project.
    – Neil
    Aug 29, 2017 at 12:31
  • 38
    Lots of misinformation in the comments here... Win32 has not implied 32-bit code since the early 90s, when it drew a distinction between 16-bit Windows 3 and 32-bit later versions. The modern 64-bit versions of Windows implement a native 64-bit API, and it is called "Win32". It keeps the same name because it is compatible with the 32-bit API, but it's a native 64-bit implementation, and it would make perfect sense for a 64-bit library to call itself "Win32". "Win64" would actually mean the Itanium architecture, not x86-64/AMD64. Aug 29, 2017 at 16:44
  • 6
    @Oded: win32 is a holdover from when Windows transitioned from 16 to 32 bit. Aug 29, 2017 at 21:00

2 Answers 2


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.

  • 5
    Also, the Win32 API is/was supported on other Operating Systems, e.g. OS/2, ReactOS, and then there's Wine, which is also an implementation of the Win32 API. Aug 29, 2017 at 12:28
  • 6
    @UnmannedPlayer, Well, Win32 is the name of the platform being targeted. Win32 is Windows as we know it. As the above quote explains the proper name nowadays is “Windows API”, but it describes the same thing.
    – amon
    Aug 29, 2017 at 12:48
  • 9
    "To port the application to 64-bit Windows, just recompile the code."... riiiiiiiiiiiiiiiiiiiiiight. Aug 29, 2017 at 20:51
  • 7
    @DanielKamilKozar This is less crazy than it sounds – it's the same API. Sure, that might have been the marketing dept. speaking. But with a bit of discipline and sufficient testing, it is not fundamentally difficult to write portable code. The important difference is that in Win32, int, long, and pointer types are 32 bit large. That assumption no longer holds under Win64 which breaks code that tried to be clever. But once the code has been made portable, the difference between Win32 and Win64 ends up being little more than a compiler option.
    – amon
    Aug 29, 2017 at 21:01
  • 4
    @amon: Unfortunately, Microsoft decided for some bizarre reason to make 32-bit and 64-bit apps use different areas of the registry, making it needlessly difficult for a group of related applications to share settings unless all are 32 bit or all are 64 bit. Yeah, there are workarounds, but none so easy as simply using the same storage.
    – supercat
    Aug 29, 2017 at 22:41

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.


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.

  • 3
    The new windows API is called WinRT. It has a lot in common with Win32 but also a lot different - just like Win32 did with Win16(?). Aug 30, 2017 at 0:13
  • 12
    @immibis WinRT is the runtime that microsoft probably wanted to be the "new" one. It's the runtime for windows store apps, running on Windows 8+, Windows RT and Windows Phone 8+. You know, for those apps nobody likes. Aug 30, 2017 at 10:47
  • Thank you both for adding the WinRT API to this answer. I guess I fall into the group of people that are not fond of the Win 8+ non-desktop apps. But it does appear that Microsoft has renamed Win32 as "Windows API": msdn.microsoft.com/en-us/library/windows/desktop/… I answered the question in the context of why you see "win32" references in existing software etc. Aug 30, 2017 at 14:37
  • A few downvotes the past month without comments to suggest how this answer can be improved. The accepted answer basically answer the question "why is it called win32" by saying "because it is named win32". I stand behind my answer because the main point is that back in the day when 16-bit was still the majority, people who bought 32-bit capable computers didn't want to see or hear "16" anywhere in your hardware or software architecture. So the API was named accordingly, probably not thinking about this decade when 32-bit became the new 16-bit. Dec 4, 2018 at 17:56
  • That's incorrect, becouse 64-bit applications also are using win32 API, but 64-bit variation. Just weird naming. Aug 23, 2021 at 12:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.