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.
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.
But isn't this exactly what shipping on Windows looks like? I've just checked my Windows partition and there are 43 instances of sqlite dll and 16 instances of Qt5Core.dll because every program that uses those libs needs to include them in their "giant bundle of everything".
But okay, I accept your point. However I'd like to point out that "the OS allows you do something in multiple ways" is different from "this is the only way to do it"
Oouch, I just got temporary headache just trying to read and comprehend the Windows mess that you mentioned here.
> A given branch of the Freedesktop runtime has a 2 year support period after which they are declared EOL.
This is what you do for Flatpack, Steam, or Docker. All these are popular options.
> Oh and I almost forgot.. install scripts that detect distros, install dependencies.
Most distros offer tooling to make packages for their package managers. With them you declare the dependencies you want and the package manager does the rest.
> And god help you if you need to ship a kernel module.
The right way to do it is to open source it and let the installer compile the software against the kernel headers. Sysdig and VirtualBox do that.
Yes, Flatpak is decent, but its a separate runtime with its own sandbox and perms that can sometimes make things more awkward for things like accessing host components installed outside of flatpak e.g. IDE running installed compilers, and compilers accessing project files inside the sandbox. But yes, its nice when it works.
Docker is the nuclear option. Fundamentally, I don't see Docker as a good and legitimate way to ship software (I already ranted about the giant bundle of everything approach!). I can also image my entire dev box as a VM and ship software that way too :P
For example in a typical C library, as long as you don't rename or remove any existing functions/exports (or change their signatures), you can continue to add new ones over time without breaking forwards compatibility (old binaries can link/call into the newer library and still work). This is also important for security reasons and not just application compatibility.
Usually projects will only make ABI-stable changes within minor versions, and leave the breaking changes to major versions where upgrading or recompiling the original application becomes necessary.
For C++ this is more complicated because it's all compiler-dependent (no language-defined ABI), and with classes you typically can't re-arrange anything (like class members) without breaking compatibility.
Even though z/OS is officially a Unix.
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!
you cant just go and download a precompiled blob from a website and run it everywhere, like you can with macOS and Windows.
glibc only targets one audience, one which can recompile its apps when needed.
What linux badly needs is a stable ABI for Userspace Apps, and Win32 is just that sadly.
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.
It was only after they went bankrupt and got bought by Oracle that things like OpenSolaris getting killed off and Java lawsuits started happening.
That is not what happened. Sun Microsystems had immense revenue and clout in the server and enterprise space because of the dotcom boom, so much so that their advertising declared "We're the dot in dotcom." Microsoft was trying to duke it out with them in the server space but Windows Server was just barely starting to become decent at that point so MS didn't get all that much traction.
When the dotcom bust hit, Sun went into a tailspin because of the glut of Sun server hardware from dead dotcoms at bargain basement prices. That eventually passed but by that time Linux + Intel was good enough to undercut both Sun and Microsoft in the server space. With no way to compete with free as in beer software, Sun was doomed.
[1] https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor....
The Java stuff wasn't even the craziest part. The whole thing from investigation to the appeal took the FTC and DOJ 11 years, where they were unable to kill of Microsoft's dominance of Internet Explorer through lawfare, but it only took Mozilla and later Google six years, nearly half that time, for an open-source web browsers to have more market share than Internet Explorer.
It turns out that a better product was all that was needed. It's too bad that the Mozilla Foundation has changed course and is now adamant that Firefox be as unusable as possible.
[EDIT] I'd actually say MS losing the J# lawsuit was a net positive since it gave Hejlsberg the opportunity to create C#.
"Win32 is the only stable Linux desktop API" has been a common observation in the Linux community for years. I'm not sure why you're acting like it's a Microsoft-sponsored smear
Microsoft may have indeed won first place via dirty anticompetitive tricks, but Linux/*nix would need a similarly stable API first in order to have won at all. And obviously plenty of companies and initiatives have tried (from Red Hat to Valve), and yet progress has still been glacial
Also nobody's saying it's a particularly good API, but it is stable. As "Worse is better" famously observed, the technical elegance of a standard has barely any effect on its adoption, versus more boring social and commercial factors
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.
> 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.
Valve basically failed to provide the business value for those studios.
I have several games from 10+ years ago from Humble Bundle. The Linux builds all have quirks (my gamepad won't work on any of them). The Windows builds work fine with Wine (the same gamepad works on all of them).
Plus, given the lack of a stable ABI, I can't really run the Linux builds natively either, because they dynamically link some library which doesn't match on my host. I need some special chroot or container (which Steam can manage). Requiring a container isn't any better than requiring Wine.
While Linux may be a pain to release software for, had anyone been interested enough, a solution could have been found. No one cared because Windows was the market and everything else was a rounding error.
Which game studios were targeting Solaris?
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.
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.
> 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.
No, It is Linux's severe failure that it lacked a singular, stable, and unified userspace GUI API.
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.
Correct. However you grossly misunderstand why why dev don't build native Linux games. The answer is that distributing proprietary software that works on "Linux" is an absolute unmitigated clusterfuck of pain, misery, and woe.
Cross-platfrom is very very easy. It's a solved problem. There are indie devs with custom engines that can easily ship for Windows, macOS, iPhone, Android, Playstation, Switch, and Xbox.
If Linux userspace had an ABI that wasn't garbage then adding "Linux" to that list would be very easy. The fact that devs don't and it is your primary clue.
I keep putting "Linux" in quotes because back in the day with r/LinuxGaming would spam Kickstarters begging for Linux support that's what they asked for. Of course there is no such thing as shipping for Linux. There is the Linux kernel and glibc and a kajillion different distros that are all unique and terrible in an myriad of different ways.
And it turns out that Linux is such a minefield clusterfuck that the actually best ABI is Win32. It'd be great if Linux designed a new ABI that was better. Seriously, that'd be awesome. But in the meantime Win32 it is!
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."
The calculus is very very very boring and simple. Game devs will support every single platform on the planet in which the cost to support that platform - both directly and long-term maintenance - is less than the increased revenue that platform provides.
It is not uncommon for indie games on custom engines to support Windows, Playstation, Switch, Switch 2, Xbox. And, depending on the game, iOS or Android. Sometimes macOS although that's increasingly rare.
Native Linux builds are pretty rare. Especially before Proton got pretty good with Steamdeck release.
Supporting Linux is a monumentally tremendous pain in the ass. Radically more than literally any other platform. It is hands-down the hardest and most painful to support natively. So painful that emulating Win32 is a clear win. Valve's runtime helps a lot. And supporting another path is just a waste of time.
Very sad!
In my experience even with games that have native Linux support running through proton seems to have less issues.
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.
This is always the case.
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.
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)
Win32 in a browser
How is that successful cross platform?
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.
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.
Will I ever target it? No, I'd rather you rip my bones and eyes out. But it's unarguably successful.
I guess he missed http3, which now makes up 35% of web traffic.
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.
Microsoft, Google, and Apple have invested millions to polish their GUI solutions because that’s where their revenue comes from.
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.
