From when I first got into graphics, I immediately dismissed DirectX because of platform locks. I wish that more developers had this same stance of refusing all options with abusive practices like platform exclusivity.
Games industry is built on platform locks and exclusives since the Atari 2600.
I don't touch consoles. They're cesspits of abusive practices: computers that can't do general purpose computing, shit like xbox demanding a monthly fee to have networking capabilities, and, of course, the fact that you need permission from the console's manufacturer to make games for them.
Steam deck is an exception. They do consoles how it should be done.
(I will touch such technologies when being paid to do so, after expressing my concerns about them if applicable)
Just wait until all the PC handelds start shipping the better Windows version, like it happened with netbooks.
It already does. When Elden Ring released, it suffered from terrible performance problems, which were worked around in VKD3D (DX12 for Wine) in the first week of release.
I've heard people complaining about Elden Ring performance on Windows for months afterwards.
The point is the historical lesson of building castles on other companies kingdoms, not the technical achievement.
On the non-GUI front it had a better command processor, CMD.EXE, which is a precursor to the Windows NT one. It had an actually decent scripting language (REXX). It had a better filesystem (HPFS).
It was also incredibly good at running DOS games of the era, while comfortably multitasking in the background, including serial port and network usage. You could be downloading something while fragging some demons in Doom. You could also pause the game at any time and switch back to the desktop, then go back and resume.
The thing that was different between OS/2 and Linux + WINE is the engineering approach. IBM had a license to use actual DOS and Windows code, at least until they cancelled the JDA (Joint Development Agreement) contract with Microsoft in 1990. Even after they cancelled, they still had rights to everything from before, which included Windows 3.0.
In order to avoid having to pay Microsoft a royalty on the Windows portions of OS/2, which they had to pass along in the retail price, they even released a variant of OS/2 version 2.1 called "OS/2 for Windows" which took your existing Windows 3.x, the one that you almost certainly already paid for as part of your computer, and binary patched it to work under OS/2. There was some grousing when Windows 3.11 came out and broke it, but IBM issued a patch.
So, in essence, they were able to market OS/2 less like a replacement OS, and more like a utility program you added on to your existing system to make it behave better. Kind of like hey, you just dropped $2000-$3000 or more on a new system, what'a another $129 to make it really sing.
And because it leveraged the fact that you already paid for Windows when you bought the computer, compatibility was top-notch: it was actually running real Windows.
In my opinion as a user at the time, what killed it was the move to Win32 software which OS/2 couldn't run but Windows 95 could. Once computers started regularly coming with enough RAM to run Windows NT 4, the nice things about OS/2 just weren't enough to justify the inability to run basically every new software package.
I've done a fair amount of research into this and I think it was technically within reach. IBM's marketing "a better DOS than DOS, a better Windows than Windows" was true until Windows 95 came out, and it would have continued to be true if they had simply offered Win95-OS/2. Not being able to run the latest Windows (Win32) software meant that OS/2 was no longer a better Windows than Windows, it was just a different and increasingly dated-looking Windows.
IBM was too self-absorbed to do this. They were going to ditch both Microsoft and Intel and make PowerPC machines running OS/2. That didn't work out too well.
Imagine a world where OS/2 Warp 3 saw a BBS-distributed or Internet-distributed update to support Win95-OS/2 released within a week of Windows 95 going to retail. It was entirely possible in September of 1995 to do this, Warp Connect adding Internet support was done this way. The "Chicago" betas were widely available so this could have easily been co-developed.
The real lesson here is that building a better runtime actually can work, if you commit to maintaining feature parity. OS/2 faltered because IBM stopped developing the features their customers wanted, like the ability to run standard Win32 software, and instead developed the features IBM wanted, like the ability to run on a different CPU architecture.
iOS and Android do backwards incompatibility all the time. If you find a mobile app that hasn't been updated in 10 or 15 years, you won't be able to install it on a modern device. But, iOS and Android ship apps to billions of users, nobody complains about ABI stability and nobody uses a Win32 compatibility layer.
glibc already has decent UX in that it doesn't allow you to load an app built for a newer version on a host with an older version. Unfortunately, the message is not user friendly at all "could not load @@GLIBC_X.YZ@@foo()", instead of something more readable, but the restriction is, in itself, good.
The problem is that there is no system to trigger backwards incompatibility at any point, nor is there a simple way to target an older Glibc version without spinning up a docker container.
And glibc is a HELL of a codebase, I would NOT want to be responsible for implementing those features, so I understand why they're not there. But 'our Linux build for our game we are still selling and advertising as working on Linux is no longer compatible with new Linux distributions, so let's rebuild it' is a much easier decision for a developer, publisher, etc. to make than '"some" Linux users are reporting issues with our game, should we dedicate resources to investigating this?'
> the restriction is, in itself, good.
Why do you consider this a good restriction?
The restriction is only annoying because there is no way to trivially link against an older "minimum requirement" ABI.
? I feel like you might be falling into the trap of assuming that the compiler always targets the current running system, but you 100% should always always always be doing a Linux-to-Linux "cross" compile with a sysroot... you don't need a docker container: you just extract an old Linux distribution into a folder and tell your current/modern compiler to target it.
That sounds like more work than spinning up a Docker container though. I'm imagining
gcc --glibc-target=2.31> Personally I share Linus’ opinion (link to YouTube) that changing ABI is okay as long as no one has noticed, but once it gets noticed - then it’s a regression. Once it’s a thing people depend on, it becomes a feature.
Games depend on the entire stack (audio, HID, VR, Vulkan, desktop compositor choice, etc.) so are the most vulnerable to any minor change. And game developers, rightly so, have better things to do than to recompile if not re-port their game because Linux has decided that Pulseaudio is out, or X11 has been replaced with Wayland.
So yes, in practice, there are only two stable APIs/ABIs on Linux: the syscalls, and Proton.
Previous discussion:
throwaway2046•4mo ago