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.
Speaking of portability, As a developer who has shipped software on Windows for over a decade, and then some on Linux. Targeting Windows is insanely easy, because of the ABI. You compile once and you have an extremely high chance that it just works on every Windows version. Not perfect, but better than any other platform ever made. Heck I've used software from CDROMS where the binary was compiled 20 years ago and it still works today without any modification.
With Linux, you have to target specific distros, do something insane like a giant bundle of everything, or static linking or some other craziness, or open up your source code and let someone else take the headache. Oh and I almost forgot.. install scripts that detect distros, install dependencies. And god help you if you need to ship a kernel module.
>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.
Windows has broad hardware compatibility, a stable enough application platform (see above), aggressive backward compatibility, a large developer ecosystem, and distribution through OEMs. Those are technical merits, even if they are not the only merits.
Early Java was horrid for everybody except the architecture astronauts who could cram ten GoF design patterns into a hello world program. It only got traction because a different wannabe monopolist, Sun Microsystems, spent heavily to get it pushed into CS curriculums. Fortunately, the one-two punch of Linux and Intel killed Sun or we might all be cursing them today instead of Microsoft.
None of your opinion on Java changes the fact that Microsoft used it's monopoly to execute an embrace, extend, extinguish strategy on Java. It is well documented since they lost an anti-trust court case on it [1].
Sun was actually a decent company once upon a time. Their problem was that Microsoft excluded them from the market and starved them for money for so long that their hardware stopped being competitive, so that by the time Java made it so you could run some software on it, nobody wanted their hardware regardless.
It was only after they went bankrupt and got bought by Oracle that things like OpenSolaris getting killed off and Java lawsuits started happening.
It went the other way around. Object-oriented programming came out of academia, before Sun adopted it into Java. They adopted it full-force, making programmers jump through all of its hoops whether they wanted to or not, unlike C++ and Python where for most programs, the only hint of the language being object oriented is the syntax.
Proton represents Valve's failure to make Linux gaming attractive to game studios.
Not even those that have Android/Linux NDK builds, bother with porting to GNU/Linux.
Besides blaming Microsoft, look inside into the endless reboots of audio stack, GNOME vs KDE vs XFCE vs Sway vs whatever is cool in Linux Desktops this month, X Windows vs Wayland,...
I was a believer, until 2010, then went back into Windows 7. If it wasn't for gaming and .NET, I would probably be on macOS instead.
Taking care of Linux deployments is part of my job, so I know pretty well how it goes today, don't need the have you tried standard Linux forum replies.
> Proton represents Valve's failure to make Linux gaming attractive to game studios.
> Not even those that have Android/Linux NDK builds, bother with porting to GNU/Linux.
It is a huge hassle to make a new build to a new platform. You double build system, release management, and testing. Compared to just one plat. Games are complicated, and testing all the dynamic behaviour is also complicated.
Making just a Win32 build really saves resources.
Also Win32 has been a stable api for a long time. Linux apis tend to change, and old games don't get re-built. The win32 build is therefore also provably a lot more long lived, compered to anything you build on linux.
Thats also important because of the Dont Kill Games effort and so on.
The point is not that Win32 is exemplary. The point is that it's compatible. More compatible, in some cases, than native apps for non-Windows platforms. A Win32 binary that runs in Wine is likely to work on more Linux distros than a native Linux binary, due to decisions made by glibc and distro maintainers over the years.
Uh, no, a Win32 binary will run in Wine because of the concerted effort of thousands of talented developers for more than a decade, painstakingly reimplemting Win32 into a a compatibility layer for it to run on Linux.
There has been little to no interest in doing the reverse, at least until WSL, which is just containers anyways. (WSfU barely counts as an "attempt.")
I would hardly consider anything relying on a compatibility shim "compatible." Especially since Wine is not a perfect shim!
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.
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.
winapi introduced event based programming to the masses and took it to the next level. You could argue that they weren't the first, but blanket singling it out as bad design makes no sense.
This control flow has been taught everywhere and is the basis of node's async loop (node waits on io, winapi waits on kb/mouse/timers) so "no system copied it" is complete ignorance. It is the first thing I think of when I'm designing an async flow.
> Wine and Proton are not tributes to Win32's portability.
I emphatically disagree. It is a hilarious and catastrophic failure of Linux userspace that the best API for running games on Linux is Win32. This has absolutely nothing to do with what Microsoft locking down the desktop market. It has 100% literally everything to do with Linux userspace being a clusterfuck of terrible design.
Linux adopted Win32 because it actually worked. They didn't have to. They could have simply invented a better API that didn't suck. But that's quite hard.
So yeah. I emphatically, but respectfully, disagree with your entire thesis.
It's Linux's failure that one of the world's biggest corporations outspent it on marketing by orders of magnitude? You can sell crap like hotcakes with enough money and advertising minds. Yours isn't really an argument for Linux APIs being any worse or better quality.
> Linux adopted Win32 because it actually worked.
WINE would have been invented one way or another because enough people would have wanted to run Windows programs on Linux in a world where Linux had dominant market share. For Pete's sake, there are Commodore 64 emulators for Linux in a world where that system has been dead for decades. It has nothing to do with what "works" or not. WINE and Proton are developed as actively as they are today because Microslop has been able to market so effectively to convince average joes and businesss leaders to buy their crappy OS. This has nothing to do with the quality of APIs.
> They could have simply invented a better API that didn't suck.
Is there ever a situation where this statement isn't true? Everything built in software can be seen as sucking, and all software could have been written better the first time around.
> It is a hilarious and catastrophic failure of Linux userspace that the best API for running games on Linux is Win32
Studios don't target Linux, they target Windows and sometimes Mac.
Imagine if Flappy Bird targeted only iPhone, because there were only 50,000,000 Android users in the world (hardly worth supporting). Then Android creates an iPhone runtime on Android so people can play Flappy Bird on it, and you conclude "iPhone actually worked, this is evidence that Android is a hilarious and catastrophic failure."
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.
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.
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.
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)
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?
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.
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.
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
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
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
> something that comes from consensus from a big, top-down standardisation body usually fails.
So IETF is the "big, top-down standardisation body" producing "bloated, inefficient and largely unused standards" here?
Wouldn't be the first time someone characterized it as such.
> The internet is an example of the implementation of a top-down approach when a scientist submits a paper for an RFC and iterates on it until it's de-facto protocol of the internet.
Yeah, he must be talking about the IETF. Very consensus-driven, most participants funded by vendors, difficult to iterate after RFC approval.
> While their nimbler competition is being adopted, iterated, and expanded. In the internet protocol use cases, OSI Model is now essentially just a theory taught in networking training, certification, and classes. In the real world, the internet is TCP/IP, and it's TCP IP that runs on computers, phones, and other devices.
Now I'm confused. TCP/IP are literally defined by IETF RFCs.
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.
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.
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.
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.
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.
(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.
Speaking of portability, As a developer who has shipped software on Windows for over a decade, and then some on Linux. Targeting Windows is insanely easy, because of the ABI. You compile once and you have an extremely high chance that it just works on every Windows version. Not perfect, but better than any other platform ever made. Heck I've used software from CDROMS where the binary was compiled 20 years ago and it still works today without any modification.
With Linux, you have to target specific distros, do something insane like a giant bundle of everything, or static linking or some other craziness, or open up your source code and let someone else take the headache. Oh and I almost forgot.. install scripts that detect distros, install dependencies. And god help you if you need to ship a kernel module.
>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.
Windows has broad hardware compatibility, a stable enough application platform (see above), aggressive backward compatibility, a large developer ecosystem, and distribution through OEMs. Those are technical merits, even if they are not the only merits.
> "...embrace-extend-extinguish against Java..."
Early Java was horrid for everybody except the architecture astronauts who could cram ten GoF design patterns into a hello world program. It only got traction because a different wannabe monopolist, Sun Microsystems, spent heavily to get it pushed into CS curriculums. Fortunately, the one-two punch of Linux and Intel killed Sun or we might all be cursing them today instead of Microsoft.
None of your opinion on Java changes the fact that Microsoft used it's monopoly to execute an embrace, extend, extinguish strategy on Java. It is well documented since they lost an anti-trust court case on it [1].
[1] https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor....
3 replies →
Sun was actually a decent company once upon a time. Their problem was that Microsoft excluded them from the market and starved them for money for so long that their hardware stopped being competitive, so that by the time Java made it so you could run some software on it, nobody wanted their hardware regardless.
It was only after they went bankrupt and got bought by Oracle that things like OpenSolaris getting killed off and Java lawsuits started happening.
4 replies →
It went the other way around. Object-oriented programming came out of academia, before Sun adopted it into Java. They adopted it full-force, making programmers jump through all of its hoops whether they wanted to or not, unlike C++ and Python where for most programs, the only hint of the language being object oriented is the syntax.
Proton represents Valve's failure to make Linux gaming attractive to game studios.
Not even those that have Android/Linux NDK builds, bother with porting to GNU/Linux.
Besides blaming Microsoft, look inside into the endless reboots of audio stack, GNOME vs KDE vs XFCE vs Sway vs whatever is cool in Linux Desktops this month, X Windows vs Wayland,...
I was a believer, until 2010, then went back into Windows 7. If it wasn't for gaming and .NET, I would probably be on macOS instead.
Taking care of Linux deployments is part of my job, so I know pretty well how it goes today, don't need the have you tried standard Linux forum replies.
> Proton represents Valve's failure to make Linux gaming attractive to game studios.
> Not even those that have Android/Linux NDK builds, bother with porting to GNU/Linux.
It is a huge hassle to make a new build to a new platform. You double build system, release management, and testing. Compared to just one plat. Games are complicated, and testing all the dynamic behaviour is also complicated.
Making just a Win32 build really saves resources.
Also Win32 has been a stable api for a long time. Linux apis tend to change, and old games don't get re-built. The win32 build is therefore also provably a lot more long lived, compered to anything you build on linux.
Thats also important because of the Dont Kill Games effort and so on.
3 replies →
The point is not that Win32 is exemplary. The point is that it's compatible. More compatible, in some cases, than native apps for non-Windows platforms. A Win32 binary that runs in Wine is likely to work on more Linux distros than a native Linux binary, due to decisions made by glibc and distro maintainers over the years.
Uh, no, a Win32 binary will run in Wine because of the concerted effort of thousands of talented developers for more than a decade, painstakingly reimplemting Win32 into a a compatibility layer for it to run on Linux.
There has been little to no interest in doing the reverse, at least until WSL, which is just containers anyways. (WSfU barely counts as an "attempt.")
I would hardly consider anything relying on a compatibility shim "compatible." Especially since Wine is not a perfect shim!
4 replies →
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.
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.
winapi introduced event based programming to the masses and took it to the next level. You could argue that they weren't the first, but blanket singling it out as bad design makes no sense.
This control flow has been taught everywhere and is the basis of node's async loop (node waits on io, winapi waits on kb/mouse/timers) so "no system copied it" is complete ignorance. It is the first thing I think of when I'm designing an async flow.
> Wine and Proton are not tributes to Win32's portability.
I emphatically disagree. It is a hilarious and catastrophic failure of Linux userspace that the best API for running games on Linux is Win32. This has absolutely nothing to do with what Microsoft locking down the desktop market. It has 100% literally everything to do with Linux userspace being a clusterfuck of terrible design.
Linux adopted Win32 because it actually worked. They didn't have to. They could have simply invented a better API that didn't suck. But that's quite hard.
So yeah. I emphatically, but respectfully, disagree with your entire thesis.
It's Linux's failure that one of the world's biggest corporations outspent it on marketing by orders of magnitude? You can sell crap like hotcakes with enough money and advertising minds. Yours isn't really an argument for Linux APIs being any worse or better quality.
> Linux adopted Win32 because it actually worked.
WINE would have been invented one way or another because enough people would have wanted to run Windows programs on Linux in a world where Linux had dominant market share. For Pete's sake, there are Commodore 64 emulators for Linux in a world where that system has been dead for decades. It has nothing to do with what "works" or not. WINE and Proton are developed as actively as they are today because Microslop has been able to market so effectively to convince average joes and businesss leaders to buy their crappy OS. This has nothing to do with the quality of APIs.
> They could have simply invented a better API that didn't suck.
Is there ever a situation where this statement isn't true? Everything built in software can be seen as sucking, and all software could have been written better the first time around.
3 replies →
> Linux adopted Win32 because it actually worked.
Completely untrue - Linux "adopted" Win32 because the majority of video games are written for Windows (and thus Win32).
They could not have invented a better API because the entire reason Proton exists is because developers don't build native Linux games.
1 reply →
> It is a hilarious and catastrophic failure of Linux userspace that the best API for running games on Linux is Win32
Studios don't target Linux, they target Windows and sometimes Mac.
Imagine if Flappy Bird targeted only iPhone, because there were only 50,000,000 Android users in the world (hardly worth supporting). Then Android creates an iPhone runtime on Android so people can play Flappy Bird on it, and you conclude "iPhone actually worked, this is evidence that Android is a hilarious and catastrophic failure."
8 replies →
> The ecosystem was not won on technical merit.
This is always the case.
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.
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.
I am not sure if this holds, I have witnessed apps that dont work in newer versions of Windows.
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.
1 reply →
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)
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?
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.
>> 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.
It is successful because it succeeded. Not because how it succeeded with right, great or ideal. People in this thread keep confusing these two points.
I think it is NOT a gigantic success.
It's an OK success.
A gigantic success would mean there's no friction at all running Windows apps on other platforms.
Even with all that development work it is a LONG way from easy to run Windows apps on Linux.
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.
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
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
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
> In the real world, the internet is TCP/IP
I guess he missed http3, which now makes up 35% of web traffic.
> something that comes from consensus from a big, top-down standardisation body usually fails.
So IETF is the "big, top-down standardisation body" producing "bloated, inefficient and largely unused standards" here?
Wouldn't be the first time someone characterized it as such.
> The internet is an example of the implementation of a top-down approach when a scientist submits a paper for an RFC and iterates on it until it's de-facto protocol of the internet.
Yeah, he must be talking about the IETF. Very consensus-driven, most participants funded by vendors, difficult to iterate after RFC approval.
> While their nimbler competition is being adopted, iterated, and expanded. In the internet protocol use cases, OSI Model is now essentially just a theory taught in networking training, certification, and classes. In the real world, the internet is TCP/IP, and it's TCP IP that runs on computers, phones, and other devices.
Now I'm confused. TCP/IP are literally defined by IETF RFCs.
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.
So what exactly does he mean then?
2 replies →
http3 operates on a different OSI layer
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.
1 reply →
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.
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.
JavaFX is surprisingly decent. Nobody cares bc the web ate everything.
What's even sadder is that was built and Sun fought against it because they were worried that devs would only compile for Win32.
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.
That’s like praising English as common language around the world but ignoring why that is the case.
It's been a joke for years that "Win32 is the most stable API on Linux".
It's not that the train wasn't successful.
kinda