33

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.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
Unmanned Player
  • 551
  • 1
  • 5
  • 8
  • 11
    Because 32bit applications are different from 64bit applications? – Oded Aug 29 '17 at 12:03
  • I don't think so. Most projects do support 64 bit. For e.g., `libev`, `libevent`, etc. – Unmanned Player Aug 29 '17 at 12:06
  • 1
    And the binary that goes out... is either 64 bit or 32 bit... Or both.. guess how you would want to name the binaries? – Oded Aug 29 '17 at 12:08
  • In the end, its always going to be `libsomething.dll` or if the said project compiles on MSVC its `something.dll`. No? The name doesn't seem to represent the architecture in anyway. – Unmanned Player Aug 29 '17 at 12:11
  • 54
    Win32 is the name of the [Windows API](https://en.wikipedia.org/wiki/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 '17 at 12:12
  • 1
    You say use "Windows or Microsoft Windows". But there are 32bit and 64bit flavours of the OS. – Oded Aug 29 '17 at 12:13
  • With @Oded here. Calling a 64 bit library, `win32`, would be irresponsible. `win32` denotes (or should denote) that its a 32-bit Windows library. – David Arno Aug 29 '17 at 12:15
  • @Oded, its not me. Besides, these libraries I showed as examples don't have any distinction between 32/64 architectures. They work on most OS and architectures. Yet when it comes to name its Win32. I'm just wondering why people stick to historical reasons when we can achieve better clarity by naming the directory as `windows` instead that contains windows specific code. Is there a legal issue? – Unmanned Player Aug 29 '17 at 12:22
  • Nothing legal. It is done for clarity - that a 32bit Windows executable *can* run on Windows 64 windows doesn't mean that one *means* for it to run on that OS. Sometimes one chooses a specific flavour to run on purpose. If you can't distinguish between the two - how are you to select? – Oded Aug 29 '17 at 12:23
  • 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 '17 at 12:31
  • 1
    If a libraries name does not reflect the architecture, thats **is** actually the reason why the output directory needs to reflect it. – Doc Brown Aug 29 '17 at 15:13
  • 37
    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. – Cody Gray - on strike Aug 29 '17 at 16:44
  • 2
    Another part of the reason is that there's only that many native toolchains in the world. The software projects you mention inherit names of the build flavours from how GCC chose to call that compilation target when Windows support was developed. It calls 'linux' differently than 'freebsd' because those platforms differ in executable file format, ABI, and other details besides the shared(-ish) POSIX API; and it's this combination of traits of the target platform that defines a build variant. – millimoose Aug 29 '17 at 17:39
  • @CodyGray Got a source for that? Based the sources in Amon's answer, Microsoft makes no such claim that Win64 is exclusively for Itanium. – 8bittree Aug 29 '17 at 18:39
  • 6
    @Oded: win32 is a holdover from when Windows transitioned from 16 to 32 bit. – whatsisname Aug 29 '17 at 21:00
  • 2
    @Oded, the `win32` name is *much* older than 64-bit Windows. It dates from the Windows 3.1-Windows 95 transition, where Windows 3.1 programs were *16*-bit, while Win95-native programs were 32-bit. – Mark Aug 30 '17 at 03:28
  • 2
    It's like how people call the 32 bit architecture i386, the processor of more than 30 years old, even for linux. – user23013 Aug 30 '17 at 13:03
  • @Mark May want to make that more like early Windows NT, and differentiating the Windows NT (32-bit) API from the Windows (16-bit) API. Then as an in-between there was the reduced functionality Win32s API which allowed running some (in reality, very few) Win32 applications on 16-bit Windows. – user Aug 30 '17 at 13:38
  • Years ago we had a program called `checksum32` at work. When I asked why it was called that, given that it generated a 16-bit checksum I was told it was "the Win32 port of `checksum`". Someone ported it to python years later and still called it `checksum32` - these numbers become less and less meaningful with time – Rodney Aug 30 '17 at 15:58

2 Answers2

62

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.

Community
  • 1
amon
  • 132,749
  • 27
  • 279
  • 375
  • 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. – Jörg W Mittag Aug 29 '17 at 12:28
  • The question wasn't about using the API itself, but just the naming convention being used. Libraries that support different OS use their proper names, but when it comes to windows it's just win32 which seemed a bit odd. Hence the question. – Unmanned Player Aug 29 '17 at 12:40
  • 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 '17 at 12:48
  • @amon: Haha. When people can say 'bottom' to refer to roughly middle-back of their bodies, 'win32' to refer to a class of APIs seem like why not. :) – Unmanned Player Aug 29 '17 at 12:57
  • 9
    "To port the application to 64-bit Windows, just recompile the code."... riiiiiiiiiiiiiiiiiiiiiight. – Daniel Kamil Kozar Aug 29 '17 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 '17 at 21:01
  • @amon : While what you're saying is of course true, you can't realistically expect an application written around the early 00s to run without any issues on Win64 by just recompiling, which is what that phrase suggests. – Daniel Kamil Kozar Aug 29 '17 at 21:17
  • 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 '17 at 22:41
  • 3
    @supercat I believe the reason they didn't do it is "We tried that. It didn't work", as Raymond Chen would say. – user253751 Aug 30 '17 at 00:15
  • @immibis: Why would all registry keys have to be segregated? The only thing that would seem like it might need to be segregated would be the locations of 32/64-bit modules, and those could be handled by saying that if a 32-bit and 64-bit module both exist, they would have names that matched except for the extension.' – supercat Aug 31 '17 at 14:19
  • @supercat So what happens when a 32-bit application tries to load a 64-bit-only module? Or when a 64-bit application tries to load the 32-bit version of a module because it didn't update the extension after getting the path? – user253751 Aug 31 '17 at 23:59
  • A request by a 64-bit application to load a module whose name ends in ".DLL" would attempt to fetch the module with a name ending in ".DLL64" [or whatever the extension is]. Doing the name substitution there would be a little icky, but far less so than splitting off the entire registry tree. – supercat Sep 01 '17 at 00:18
30

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.

Thomas Carlisle
  • 1,293
  • 9
  • 11
  • 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(?). – user253751 Aug 30 '17 at 00: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. – Metallkiller Aug 30 '17 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": https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx I answered the question in the context of why you see "win32" references in existing software etc. – Thomas Carlisle Aug 30 '17 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. – Thomas Carlisle Dec 04 '18 at 17:56
  • That's incorrect, becouse 64-bit applications also are using win32 API, but 64-bit variation. Just weird naming. – Bogdan Mart Aug 23 '21 at 12:03