> No way you could run Linux binaries or MacOS classic binaries from '98
The key problem for desktop Linux is that nobody knows exactly how to build binaries that will run on any reasonable Linux desktop system today, so it's hard to keep that non-existent reasonable subset of ABI stable for an extended period.
That said, you CAN do this. The kernel itself does present a mostly pretty stable ABI to userland applications, so you can grab a Debian chroot from 1998 and be on your way. Debian even still serves repositories for everything on archive.debian.org, and Dockerhub has OCI images you can `docker run` for Debian from 1999, under the debian/eol repo. You can `docker run` and `apt-get install` 25+ year old binaries on modern Linux!
What would be sweet is if we could build and ship compatibility tools that make these old binaries work mostly transparently. Today, double clicking a binary on Linux won't do anything particularly sophisticated, and there are no compatibility options. But actually, it would be totally doable to write a variety of useful compatibility shims without doing anything horribly grotesque. The DT_INTERP and DT_NEEDED fields of binaries would often give sufficient information for how you might get such a binary to run. It's not like it would be that useful, but I would personally be very pleased if you could just double click e.g. some old Kylix application and have it just run, perhaps after downloading some (shims for?) old libraries. You could extend this to transparently running CPU emulators too, not unlike the tricks people do with binfmt_misc, just possibly with more batteries included (and a bit less transparency.)
Another really great feature would be useful error messages when executing an application fails. Today if the DT_INTERP is missing, it looks like the binary itself can't be found since it returns the same errno, and you won't see linker errors if you execute a file in a GUI file explorer. What a great improvement it would be if all of that could be fixed, and there is no technical reason it can't be.
Of course, frustratingly, for more reasons than just this, the more likely thing to happen is that nobody bothers since containers are the future anyways, and Win32 instead becomes cemented as the true stable ABI of Linux. Which, in my opinion, is a bummer. We could always have two stable ABIs of Linux...
I'm happy for WSL2 users that are getting what they want, but I don't even particularly care about the things WSL2 brings to Windows, what keeps me from using Windows is just Microsoft.
I have been thinking about the parallels to OS/2, though, and I really do wonder if it's going to go that way. Much like debates about which economic systems are actually viable, there's no real reason to believe aping someone else's ABI can't work other than that it didn't in the 90s. But boy, the game sure has changed a lot, and I'm not so sure it will play out that way anymore. While Valve has been shipping the Windows ABI on Linux commercially, the way they've been doing so is definitely a bit different than how it was done in the past. So far it seems like they're actually succeeding, and the question is somewhat more of how much they can succeed with it.
Valve has been lucky that UWP did not caught among Windows and XBox (ERA runtime) developers, however Microsoft might still pull a move in Win32 that isn't so easy to reverse engineer in Proton, and somehow make it part of DirectX.
There is the whole ongoing discussion about a possible existence of XBox OS, that other OEMs selling handhelds would rather have than SteamOS.
And then there is the whole question, which will be beyond my lifetime, about what comes after Valve, when its founding members are no longer around.
> Valve has been lucky that UWP did not caught among Windows and XBox (ERA runtime) developers, however Microsoft might still pull a move in Win32 that isn't so easy to reverse engineer in Proton, and somehow make it part of DirectX.
I wouldn't necessarily call it luck. I mean, UWP didn't fail in a vacuum. They played a part in its failure, and frankly they did so in part because Microsoft doesn't care about what developers or gamers need or want anymore, they just care about getting the end game they most prefer.
They're definitely running out of time though: with Proton and Steam Deck, there is real life value in sticking to the subset that works on Steam Deck, and right now that value is increasing over time, with another handheld on the horizon.
> There is the whole ongoing discussion about a possible existence of XBox OS, that other OEMs selling handhelds would rather have than SteamOS.
Meanwhile, though, while people theorize about a potential licensable Xbox OS that might exist some day, SteamOS has been shipping on Steam Decks and will be shipping on Lenovo handhelds soon. The rumor mill on the Valve side of things suggests that they will open SteamOS up for users to run on ordinary computers soon, and there might be a return of Steam boxes and the Steam controller.
Do vendors want to ship Xbox OS more than Steam OS? That, IMO, remains to be seen and depends heavily on Microsoft's strategy. Valve almost definitely gives vendors much more free reign over what will ship on their devices and how. Xbox is a household name which would be attractive, but it could bomb if they fail to meaningfully deliver the "Xbox experience"; Microsoft has been running with the narrative that everything is an Xbox, which, sure, sounds great, but game streaming is not going to be competitive with handhelds that can actually play games locally for now.
> And then there is the whole question, which will be beyond my lifetime, about what comes after Valve, when its founding members are no longer around.
Well, someone will have to keep investing in Linux handhelds to keep it alive in some form, but it doesn't have to be Valve. The work they're putting in is largely there for anyone to take advantage of and continue later in their absence, even moreso than Android in many regards.
Yep. All of this considered, Valve should really care about a better native developer experience before the time window disappears. I'm not so sure their current approaches are good enough; they do have a "Steam runtime" but it doesn't provide much isolation from the host system which may stymie some of the benefits.
Still, they seem to be successfully shipping desktop Linux to users more or less successfully, which is extremely impressive and strange. A lot of Steam Deck users are learning to deal with Flatpaks and AppImages. My feelings on those modes of app distribution notwithstanding, no doubt continual improvement in those ecosystems will help ensure that not everything they do will only serve to benefit Steam and emulated Windows apps.
But I definitely understand what's going on here. They know well they can't stop investing in Windows emulation yet. A marketing point against SteamOS has been the fact that it can't play your whole Steam library, and while it can play a lot more than I ever expected, it's true. They need to keep working on answering the challenges for existing games and their anti-cheat solutions.
The key problem for desktop Linux is that nobody knows exactly how to build binaries that will run on any reasonable Linux desktop system today, so it's hard to keep that non-existent reasonable subset of ABI stable for an extended period.
That said, you CAN do this. The kernel itself does present a mostly pretty stable ABI to userland applications, so you can grab a Debian chroot from 1998 and be on your way. Debian even still serves repositories for everything on archive.debian.org, and Dockerhub has OCI images you can `docker run` for Debian from 1999, under the debian/eol repo. You can `docker run` and `apt-get install` 25+ year old binaries on modern Linux!
What would be sweet is if we could build and ship compatibility tools that make these old binaries work mostly transparently. Today, double clicking a binary on Linux won't do anything particularly sophisticated, and there are no compatibility options. But actually, it would be totally doable to write a variety of useful compatibility shims without doing anything horribly grotesque. The DT_INTERP and DT_NEEDED fields of binaries would often give sufficient information for how you might get such a binary to run. It's not like it would be that useful, but I would personally be very pleased if you could just double click e.g. some old Kylix application and have it just run, perhaps after downloading some (shims for?) old libraries. You could extend this to transparently running CPU emulators too, not unlike the tricks people do with binfmt_misc, just possibly with more batteries included (and a bit less transparency.)
Another really great feature would be useful error messages when executing an application fails. Today if the DT_INTERP is missing, it looks like the binary itself can't be found since it returns the same errno, and you won't see linker errors if you execute a file in a GUI file explorer. What a great improvement it would be if all of that could be fixed, and there is no technical reason it can't be.
Of course, frustratingly, for more reasons than just this, the more likely thing to happen is that nobody bothers since containers are the future anyways, and Win32 instead becomes cemented as the true stable ABI of Linux. Which, in my opinion, is a bummer. We could always have two stable ABIs of Linux...