7 ms·

Windows API is Successful Cross-Platform API (2024)

107 points by phendrenad2 6mo ago

YPPH 6mo ago
There's something deeply satisfying about compiling a Win32 desktop application and knowing that single binary will run unmodified on essentially every Windows machine from XP onward, and look nearly identical doing it. High-DPI is the one real caveat, but even that's manageable with a manifest. I'm not sure any other platform-native API comes close to that combination of reach and consistency. Running them on other operating systems is really just a bonus.
- dbacar 6mo ago
  I am not sure if this holds, I have witnessed apps that dont work in newer versions of Windows.
  - bigfatkitten 6mo ago
    They exist but they’re in the minority. Compare this with the Linux world, where userspace compatibility between one major distro release and the next, 12 months apart is very much a roll of the dice.
    - MathMonkeyMan 6mo ago
      This is true. To be fair, if you use only the Linux syscall interface, then a program that you compiled on x86 in the 90s will probably still run anywhere today. Linus is adamant about this. But if you want to use... anything else, then it's unlikely to work at all unless you are very specific about your target. There isn't one company deciding that glibc or mesa or whatever is binary backward compatible on every kernel for every platform forever. Microsoft is, somewhat, one such company. That's why System32\*.dll have such stable interfaces -- it's their job to translate whatever late 90s system/graphics facilities some boomer dreamed up into whatever the current Windows hodgepodge of system services support. It's no wonder Microsoft is trying to drop support for hardware like crazy. This implicit compatibility isn't true for all Windows programs, though. Consider Visual Studio. Couldn't compile my console program on my computer and run it on my dad's computer. He had to first install the "Redistributable," which for him and most people might as well be a rootkit and a super scary virus program bad guy.
      - delta_p_delta_x 6mo ago
        > To be fair, if you use only the Linux syscall interface, then a program that you compiled on x86 in the 90s will probably still run anywhere today. Linus is adamant about this. This is frankly the opposite of how it should've been. Who cares that the kernel ABI doesn't change from release to release? As an end-user, I couldn't care less. Even as a developer I care very little indeed, because I'm not writing drivers. I'm almost never programming directly against the kernel's interface but rather using my language's standard library, which is already an abstraction over the kernel interface. Platform vendors (this includes distro maintainers) should recompile and re-package libraries for each new ABI in each OS release, done. End-users won't ever notice, they can run their applications portably because the user-mode library ABIs haven't changed... Which is what Win32 has done, and what glibc has consistently failed to do.
        markus_zhang 6mo ago
        I think Windows also discourages people to use their syscall directly. It could change from version to version so they should use the API.
        king_geedorah 6mo ago
        The funny thing about the glibc situation is that glibc really doesn’t provide improvements to any of the kernel interfaces or really any comfort stuff for developers. If anything the fact that it is bound by the C standards makes it worse than using the kernel API directly besides that for whatever reason the kernel headers seem to lack a fair number of definitions. That could just be a me problem though.
    - duped 6mo ago
      The biggest problem with user space compatibility on Linux are binaries compiled and run on older releases, not future ones.
gregman1 6mo ago
(2024) Interesting provocative article, I bet it will be praised on some Microsoft sponsored conference. Wine and Proton are not tributes to Win32's portability. They are symptoms of a desktop market that Microsoft locked hard enough that the rest of us had to reverse engineer our way out. Market damage, not collaboration. The ecosystem was not won on technical merit. OEM per-processor licensing, embrace-extend-extinguish against Java and the web, document format lock-in, and a long pattern of obstructing standardization attempts that would constrain Windows (PWI in 1994, ECMA-234 in 1995, OpenDocument later) while pushing their own through when it extended reach. No CS curriculum holds up Win32 as exemplary API design. No system copied it. A successful API earns adoption. Win32 enforced it.
- drdaeman 6mo ago
  All true, but simultaneously, if you look at it not in the “how did we get here” but “what’s out there today” light, it’s an option that can run on a lot of platforms. Not by some particular merit but because history happened this way - but that’s not a problem with the technology itself.
  - bruce511 6mo ago
    I concur. The article defines "success" in the Windows context as being "available everywhere". It does not address how it got to that point. And sure, you might not like Microsoft, and you may not like how it became successful (using the above definition) but the fact that it is available everywhere is not in dispute. Of course most successful things have murky pasts. We don't necessarily agree with how it got there, but there it is. That is, at least in the technical sense irrelevant. You may prefer LP's or CD's, but streaming is now the successful way to get your music. That doesn't mean it's the only way though, and of course you are free to not use Windows programs, or play games via Steam etc. That is your choice.
- asdfaoeu 6mo ago
  If you listen to CS professors you'd believe that Haskell would be very successful despite having limited if none real world usage. The reality is that catering to your users is much more important than having idealistic system. In my experience even with games that have native Linux support running through proton seems to have less issues.
wewewedxfgdf 6mo ago
Hasn't it taken gargantuan multi decade efforts of hundreds of developers, multiple open source projects and the backing of major corporations to make it work at all, let alone well, on Linux? How is that successful cross platform?
- throwaway27448 6mo ago
  Cuz there's good software written against it. And it doesn't need to be recompiled. Will I ever target it? No, I'd rather you rip my bones and eyes out. But it's unarguably successful.
- bruce511 6mo ago
  >> How is that successful cross platform? Because hundreds of developers, multiple open source projects and the backing of major corporations made it happen, not because Microsoft wanted it but in spite of it. In this case the route to success was via marketing (isn't it always so?), via market share, via application dominance (attracting developers to develop for the platform), and via insane levels of backward's compatibility. It was successful not because of the code itself (end users don't care 2 figs about the elegance of the code) but because they optimized for the end user experience. Linux optimized for the experienced, technically adept user, who wanted to fiddle, customize and could write programs. Apple optimized for the "now", ignoring the past and regularly made existing programs obsolete and unrunnable. I wrote windows programs in 1995. They still run today. They have run on all versions of Windows since then, without even a recompile. Everything I have [1] just keeps running. And it turns out, that's something users really want. I get that we're all technical folk here. I get that we strive for technical excellence and elegance. I get that we operate in the "now", ignoring hardware and software from the past. But the market is different, and wants different things. If you want a successful business you need to understand the market, not just your own aesthetics. Microsoft understands that, and that's why the market (especially the business market) relies on them. [1] - Except games. Copy protection on some of my games means they don't run anymore - but to be fair those were hacks designed specifically to prevent the game running in the first place.
- wmf 6mo ago
  Hasn't it taken gargantuan multi decade efforts of hundreds of developers, multiple open source projects and the backing of major corporations to make [WINE] work at all, let alone well, on Linux? Arguably there has been equal or larger effort invested/wasted in cross-platform and cross-distro frameworks/APIs/packaging and yet the result still doesn't work. Partly that's due to duplication of effort; there's (mostly) one WINE competing with Qt/Gtk/whatever times Snap/Flatpak/AppImage/whatever.
tehologist 6mo ago
Considering you can use 500 kilobyte distro of tcc that can self compile to build win32 apps and those versions will very easily run on wine. I think it is a valid point and a strategy I have used for sometime. Since windows can't decide what you should use for developing Windows apps
tehologist 6mo ago
As an added bonus, since win32 is so old. AI is quite strong at generating code for it, I have even had success with qwen 3.5 1.5B parameters with win32 and opengl 1.1
deleted 6mo ago
[deleted]
stkdump 6mo ago
> In the real world, the internet is TCP/IP I guess he missed http3, which now makes up 35% of web traffic.
- ablob 6mo ago
  http3 operates on a different OSI layer
  - stkdump 6mo ago
    Yes, which the article claims is just a theory now, irrelevant for the real world. More crucially though, http3 doesn't use TCP because it is built on top of UDP.
    - magicalhippo 6mo ago
      It's like how people say "pass me the butter" despite there's just a tub of margarine on the table.
- wmf 6mo ago
  Technically the Internet runs on "the Internet Protocol Suite" but people just say "TCP/IP" for short. That doesn't mean to exclude UDP, SCTP, or whatever.
  - stkdump 6mo ago
    So what exactly does he mean then?
    - wmf 6mo ago
      He means the Internet runs on the Internet Protocol Suite and not the "superior" OSI Protocol Suite (that people under age 50 have never heard of because it failed).
      - p_l 6mo ago
whateveracct 6mo ago
kinda
dbacar 6mo ago
Sometimes I think that, if Java ditched the idea of JVM and followed what modern languages did today (write once, compile on every major platform), things would be different.
- wmf 6mo ago
  What's even sadder is that was built and Sun fought against it because they were worried that devs would only compile for Win32.
  - AnthonyMouse 6mo ago
    The trouble there is that Sun was right about that. Doing it that way works great for open source where anyone can recompile the software for a new target, but for proprietary software they would have given you a Windows blob and that's about it. Meanwhile the problems with Java were mostly not the JVM. Its current problem is, of course, Oracle.
- maxloh 6mo ago
  I don't think so. Oracle isn’t a consumer-facing company and doesn't really care about that sector. SWT and Swing will likely remain as ugly as they are for the next century, regardless of their popularity. Microsoft, Google, and Apple have invested millions to polish their GUI solutions because that’s where their revenue comes from.
  - MrBuddyCasino 6mo ago
    JavaFX is surprisingly decent. Nobody cares bc the web ate everything.
- speed_spread 6mo ago
  The JVM and the ecosystem it sustains are more important than Java itself. The main reason newer languages can run "everywhere" is because hardware has been commoditized and the number of server OSes has been reduced to two. The JVM was designed to flatten a much more diverse environment than what we have today. Whatever you produce that can run on the JVM will still be runnable in 30 years.
qakajjqj 6mo ago
It's not that the train wasn't successful.
liamgm 6mo ago
I think not only win32 but win32 + directx API, the most used API for gaming industry. Wine , Proton , Crossover, DXVK, VKD3D, D3DMetal , WineD3D, Apple game porting toolkit , SteamOS , Winlator/Gamehub etc android Wine variant , ReactOS , MinGW from that API
p_l 6mo ago
The true success of WinAPI, including originally with Windows, is that it provided stable ABI from version to version, and didn't lock you into any language. The Unix world was lazy about it because of the approach of recompiling across somewhat source compatible systems thanks to POSIX, so there was reasonably fast portability if you didn't go too far off the beaten path. But doing anything other than C (w/ Cfront maybe) and Fortran and Pascal was a problem, even without binary compat. Even from version to version (legacy of which we now have in glibc breaking binary compat all the time). Microsoft went hard on the idea that if you bought/build a program for Windows version X, it would run on version X+1. You didn't have to buy a special upgraded version. You could update easier. The same approach later drove introduction of things like PC System Design Guide and ACPI so you could just upgrade your computers instead of waiting for special OS upgrade just to boot (like it was common in other platforms, including Mac, VMS, and Unix workstation world). Design wise, GUI parts of WinAPI aren't all that different from working with X intrinsics etc libraries (i.e. the parts above raw xlib)
BrenBarn 6mo ago
It's been a joke for years that "Win32 is the most stable API on Linux".
croes 6mo ago
That’s like praising English as common language around the world but ignoring why that is the case.
tehologist 6mo ago
The win32 api is extremely well documented, still supported and very stable. With tons of working examples to do pretty much everything with.
tehologist 6mo ago
Whoa, I didn't know about this. Looks pretty new. Win32 in a browser https://github.com/lqs/retrotick https://github.com/lqs/retrotick
firebot 6mo ago
I believe most of the Internet (especially the modern web) is QUIC(UDP/IP)...
nxobject 6mo ago
If I ever get the time, I’d like to make Wine as good as possible for UI app distribution - native UI bindings and the ability to slim down and bundle the runtime. Alas!

107 points by phendrenad2 6mo ago

YPPH 6mo ago

There's something deeply satisfying about compiling a Win32 desktop application and knowing that single binary will run unmodified on essentially every Windows machine from XP onward, and look nearly identical doing it. High-DPI is the one real caveat, but even that's manageable with a manifest. I'm not sure any other platform-native API comes close to that combination of reach and consistency. Running them on other operating systems is really just a bonus.

dbacar 6mo ago
I am not sure if this holds, I have witnessed apps that dont work in newer versions of Windows.
- bigfatkitten 6mo ago
  They exist but they’re in the minority. Compare this with the Linux world, where userspace compatibility between one major distro release and the next, 12 months apart is very much a roll of the dice.
  - MathMonkeyMan 6mo ago
    This is true. To be fair, if you use only the Linux syscall interface, then a program that you compiled on x86 in the 90s will probably still run anywhere today. Linus is adamant about this. But if you want to use... anything else, then it's unlikely to work at all unless you are very specific about your target. There isn't one company deciding that glibc or mesa or whatever is binary backward compatible on every kernel for every platform forever. Microsoft is, somewhat, one such company. That's why System32\*.dll have such stable interfaces -- it's their job to translate whatever late 90s system/graphics facilities some boomer dreamed up into whatever the current Windows hodgepodge of system services support. It's no wonder Microsoft is trying to drop support for hardware like crazy. This implicit compatibility isn't true for all Windows programs, though. Consider Visual Studio. Couldn't compile my console program on my computer and run it on my dad's computer. He had to first install the "Redistributable," which for him and most people might as well be a rootkit and a super scary virus program bad guy.
    - delta_p_delta_x 6mo ago
      > To be fair, if you use only the Linux syscall interface, then a program that you compiled on x86 in the 90s will probably still run anywhere today. Linus is adamant about this. This is frankly the opposite of how it should've been. Who cares that the kernel ABI doesn't change from release to release? As an end-user, I couldn't care less. Even as a developer I care very little indeed, because I'm not writing drivers. I'm almost never programming directly against the kernel's interface but rather using my language's standard library, which is already an abstraction over the kernel interface. Platform vendors (this includes distro maintainers) should recompile and re-package libraries for each new ABI in each OS release, done. End-users won't ever notice, they can run their applications portably because the user-mode library ABIs haven't changed... Which is what Win32 has done, and what glibc has consistently failed to do.
      - markus_zhang 6mo ago
        I think Windows also discourages people to use their syscall directly. It could change from version to version so they should use the API.
      - king_geedorah 6mo ago
        The funny thing about the glibc situation is that glibc really doesn’t provide improvements to any of the kernel interfaces or really any comfort stuff for developers. If anything the fact that it is bound by the C standards makes it worse than using the kernel API directly besides that for whatever reason the kernel headers seem to lack a fair number of definitions. That could just be a me problem though.
  - duped 6mo ago
    The biggest problem with user space compatibility on Linux are binaries compiled and run on older releases, not future ones.

gregman1 6mo ago

(2024) Interesting provocative article, I bet it will be praised on some Microsoft sponsored conference. Wine and Proton are not tributes to Win32's portability. They are symptoms of a desktop market that Microsoft locked hard enough that the rest of us had to reverse engineer our way out. Market damage, not collaboration. The ecosystem was not won on technical merit. OEM per-processor licensing, embrace-extend-extinguish against Java and the web, document format lock-in, and a long pattern of obstructing standardization attempts that would constrain Windows (PWI in 1994, ECMA-234 in 1995, OpenDocument later) while pushing their own through when it extended reach. No CS curriculum holds up Win32 as exemplary API design. No system copied it. A successful API earns adoption. Win32 enforced it.

drdaeman 6mo ago
All true, but simultaneously, if you look at it not in the “how did we get here” but “what’s out there today” light, it’s an option that can run on a lot of platforms. Not by some particular merit but because history happened this way - but that’s not a problem with the technology itself.
- bruce511 6mo ago
  I concur. The article defines "success" in the Windows context as being "available everywhere". It does not address how it got to that point. And sure, you might not like Microsoft, and you may not like how it became successful (using the above definition) but the fact that it is available everywhere is not in dispute. Of course most successful things have murky pasts. We don't necessarily agree with how it got there, but there it is. That is, at least in the technical sense irrelevant. You may prefer LP's or CD's, but streaming is now the successful way to get your music. That doesn't mean it's the only way though, and of course you are free to not use Windows programs, or play games via Steam etc. That is your choice.
asdfaoeu 6mo ago
If you listen to CS professors you'd believe that Haskell would be very successful despite having limited if none real world usage. The reality is that catering to your users is much more important than having idealistic system. In my experience even with games that have native Linux support running through proton seems to have less issues.

wewewedxfgdf 6mo ago

Hasn't it taken gargantuan multi decade efforts of hundreds of developers, multiple open source projects and the backing of major corporations to make it work at all, let alone well, on Linux? How is that successful cross platform?

throwaway27448 6mo ago
Cuz there's good software written against it. And it doesn't need to be recompiled. Will I ever target it? No, I'd rather you rip my bones and eyes out. But it's unarguably successful.
bruce511 6mo ago
>> How is that successful cross platform? Because hundreds of developers, multiple open source projects and the backing of major corporations made it happen, not because Microsoft wanted it but in spite of it. In this case the route to success was via marketing (isn't it always so?), via market share, via application dominance (attracting developers to develop for the platform), and via insane levels of backward's compatibility. It was successful not because of the code itself (end users don't care 2 figs about the elegance of the code) but because they optimized for the end user experience. Linux optimized for the experienced, technically adept user, who wanted to fiddle, customize and could write programs. Apple optimized for the "now", ignoring the past and regularly made existing programs obsolete and unrunnable. I wrote windows programs in 1995. They still run today. They have run on all versions of Windows since then, without even a recompile. Everything I have [1] just keeps running. And it turns out, that's something users really want. I get that we're all technical folk here. I get that we strive for technical excellence and elegance. I get that we operate in the "now", ignoring hardware and software from the past. But the market is different, and wants different things. If you want a successful business you need to understand the market, not just your own aesthetics. Microsoft understands that, and that's why the market (especially the business market) relies on them. [1] - Except games. Copy protection on some of my games means they don't run anymore - but to be fair those were hacks designed specifically to prevent the game running in the first place.
wmf 6mo ago
Hasn't it taken gargantuan multi decade efforts of hundreds of developers, multiple open source projects and the backing of major corporations to make [WINE] work at all, let alone well, on Linux? Arguably there has been equal or larger effort invested/wasted in cross-platform and cross-distro frameworks/APIs/packaging and yet the result still doesn't work. Partly that's due to duplication of effort; there's (mostly) one WINE competing with Qt/Gtk/whatever times Snap/Flatpak/AppImage/whatever.

tehologist 6mo ago

Considering you can use 500 kilobyte distro of tcc that can self compile to build win32 apps and those versions will very easily run on wine. I think it is a valid point and a strategy I have used for sometime. Since windows can't decide what you should use for developing Windows apps

tehologist 6mo ago

As an added bonus, since win32 is so old. AI is quite strong at generating code for it, I have even had success with qwen 3.5 1.5B parameters with win32 and opengl 1.1

deleted 6mo ago

[deleted]

stkdump 6mo ago

> In the real world, the internet is TCP/IP I guess he missed http3, which now makes up 35% of web traffic.

ablob 6mo ago
http3 operates on a different OSI layer
- stkdump 6mo ago
  Yes, which the article claims is just a theory now, irrelevant for the real world. More crucially though, http3 doesn't use TCP because it is built on top of UDP.
  - magicalhippo 6mo ago
    It's like how people say "pass me the butter" despite there's just a tub of margarine on the table.
wmf 6mo ago
Technically the Internet runs on "the Internet Protocol Suite" but people just say "TCP/IP" for short. That doesn't mean to exclude UDP, SCTP, or whatever.
- stkdump 6mo ago
  So what exactly does he mean then?
  - wmf 6mo ago
    He means the Internet runs on the Internet Protocol Suite and not the "superior" OSI Protocol Suite (that people under age 50 have never heard of because it failed).
    - p_l 6mo ago

whateveracct 6mo ago

kinda

dbacar 6mo ago

Sometimes I think that, if Java ditched the idea of JVM and followed what modern languages did today (write once, compile on every major platform), things would be different.

wmf 6mo ago
What's even sadder is that was built and Sun fought against it because they were worried that devs would only compile for Win32.
- AnthonyMouse 6mo ago
  The trouble there is that Sun was right about that. Doing it that way works great for open source where anyone can recompile the software for a new target, but for proprietary software they would have given you a Windows blob and that's about it. Meanwhile the problems with Java were mostly not the JVM. Its current problem is, of course, Oracle.
maxloh 6mo ago
I don't think so. Oracle isn’t a consumer-facing company and doesn't really care about that sector. SWT and Swing will likely remain as ugly as they are for the next century, regardless of their popularity. Microsoft, Google, and Apple have invested millions to polish their GUI solutions because that’s where their revenue comes from.
- MrBuddyCasino 6mo ago
  JavaFX is surprisingly decent. Nobody cares bc the web ate everything.
speed_spread 6mo ago
The JVM and the ecosystem it sustains are more important than Java itself. The main reason newer languages can run "everywhere" is because hardware has been commoditized and the number of server OSes has been reduced to two. The JVM was designed to flatten a much more diverse environment than what we have today. Whatever you produce that can run on the JVM will still be runnable in 30 years.

qakajjqj 6mo ago

It's not that the train wasn't successful.

liamgm 6mo ago

I think not only win32 but win32 + directx API, the most used API for gaming industry. Wine , Proton , Crossover, DXVK, VKD3D, D3DMetal , WineD3D, Apple game porting toolkit , SteamOS , Winlator/Gamehub etc android Wine variant , ReactOS , MinGW from that API

p_l 6mo ago

The true success of WinAPI, including originally with Windows, is that it provided stable ABI from version to version, and didn't lock you into any language. The Unix world was lazy about it because of the approach of recompiling across somewhat source compatible systems thanks to POSIX, so there was reasonably fast portability if you didn't go too far off the beaten path. But doing anything other than C (w/ Cfront maybe) and Fortran and Pascal was a problem, even without binary compat. Even from version to version (legacy of which we now have in glibc breaking binary compat all the time). Microsoft went hard on the idea that if you bought/build a program for Windows version X, it would run on version X+1. You didn't have to buy a special upgraded version. You could update easier. The same approach later drove introduction of things like PC System Design Guide and ACPI so you could just upgrade your computers instead of waiting for special OS upgrade just to boot (like it was common in other platforms, including Mac, VMS, and Unix workstation world). Design wise, GUI parts of WinAPI aren't all that different from working with X intrinsics etc libraries (i.e. the parts above raw xlib)

BrenBarn 6mo ago

It's been a joke for years that "Win32 is the most stable API on Linux".

croes 6mo ago

That’s like praising English as common language around the world but ignoring why that is the case.

tehologist 6mo ago

The win32 api is extremely well documented, still supported and very stable. With tons of working examples to do pretty much everything with.

tehologist 6mo ago

Whoa, I didn't know about this. Looks pretty new. Win32 in a browser https://github.com/lqs/retrotick https://github.com/lqs/retrotick

firebot 6mo ago

I believe most of the Internet (especially the modern web) is QUIC(UDP/IP)...

nxobject 6mo ago

If I ever get the time, I’d like to make Wine as good as possible for UI app distribution - native UI bindings and the ability to slim down and bundle the runtime. Alas!