This shows that having a legal way to run outdated operating systems is always important to guarantee that old software runs exactly as intended. Online activation schemes make this problematic.
The solution seems to be installing and fully activating the operating system in the VM while it's still possible, then archiving the VM image. However, I don't know how reliable this method is, since the Windows OS may require reactivation if the hardware configuration changes significantly. Therefore, if the future VM host machine exposes slightly different hardware to the guest machine, the activation might be gone.
This particular example actually doesn’t show that. The misbehavior is caused by a bug in the original game, which was initially hidden only by pure chance, and was already fixed 20 years ago in updated releases of the game, and can be fixed in any version by adding the missing parameters in a plain-text asset (or running the existing patcher add-on).
I agree in the general case, but this particular case isn’t a good argument for it.
I would argue that this case also demonstrates the aforementioned problem. Apparently, an older version of the Windows OS was tolerant to this specific bug, and the game worked just fine. Future users might not be even aware that an updated release of the game fixed this bug, or they might not have access to the update.
You can't blame the user for the fact that the old software contains something that is, technically, an invalid use of the API, meaning the software shouldn't have worked, even in the past. The only way to reliably make the old software work as intended is to have an OS version from that time available.
Just to be precise, the bug isn’t about invalid use of an API. The software uses uninitialized values on the stack, which under older Windows versions happen to be preserved from earlier calls to the same application-level function, despite intermediate calls to other functions, which happen to also involve Windows API calls. In newer Windows versions, these latter functions happen to use more stack space, leading to the old values not being preserved on the stack anymore.
I won’t argue about your other point, as there are arguments either way. I just don’t think this particular example makes a good case, and I suspect that it wouldn’t have been made if the full workings of the bug had been properly understood.
Hopefully the "Stop Killing Games" movement will create some formal obligations around those activation schemes too since it's pretty much the same problem from a different angle.
Criticisms of his post aside.
Isn't it unfortunate, the absolute degree everything legacy is at least in some way tethered to windows. If only there had been an open alternative, it would allow huge communities to emerge keeping very old software/games working indefinitely. Not that linux was even remotely close to being usable even only twenty years ago. Relying on a giants benevolence is never going to work in the long run. Their contemporary direction is only a function of what side of the bed theyd like to turn on today.
How would an open operating system fix a bug caused by sloppy game developers? I don't think anyone would think "let's not optimize the (equivalent of) critical sections in our operating system so that we don't break GTA", unless you're suggesting providing 100s of different implementations of different parts of the operating system that people can choose from to run a specific game, which I don't think is viable either. Patching individual games is far easier and is actually viable, which is precisely what GOG (Good Old Games) successfully does on a significantly large scale.
If anything, what Microsoft was way, way better at was finding and working around these types of problems in the OS. Many developers have a more idealistic and less pragmatic approach instead of empathizing with their users: "it's the program's fault, why should we deal with it?"
My sister who was at the time a professor had just moved to a Mac. There was some major statistics app that broke on an OS Update. She contacted the stats company and they said that Apple broke them. She contacted Apple and they said the stats company was given notice and access to beta builds. She was just stuck for months with it not working - and eventually loved back to Windows. She says it’s ugly, but it works.
Though at least back then, they provided backward-compatibility modes for old software. You know, back when the expected service lifetime of your Mac was longer than that of your dog.
> Many developers have a more idealistic and less pragmatic approach instead of empathizing with their users: "it's the program's fault, why should we deal with it?"
In the retro-games emulation scene there exist quite some people who write binary patches for popular retro games to fix such bugs. Perhaps this approach (and the necessary skills for it) should become more popular outside the retro-games emulation scene.
> unless you're suggesting providing 100s of different implementations of different parts of the operating system that people can choose from to run a specific game
> it would allow huge communities to emerge keeping very old software/games working indefinitely
The Linux community already stumbles at this and needs Windows to help it out. "Win32 is the only stable ABI on Linux" has been said so many times it isn't a joke any more. Keep in mind that the OS being open doesn't make the games open. Wine is possible because of Win32's die-hard commitment to long-term binary compatibility. I'm not so sure we're in a bad situation here. The Linux userspace has never had this degree of backwards binary compatibility. The kernel doesn't break userspace but userspace breaks itself all the time.
Linux userspace gets lots of other benefits from this rapid-iteration approach that doesn't concern itself with literally decades of binary compatibility, but keeping old games running indefinitely isn't one of them.
> Not that linux was even remotely close to being usable even only twenty years ago.
Running Linux on regular consumer hardware in 2005 was not really any harder than it is today. In fact, many of the same problems still exist! GPU drivers and janky wifi and power-saving modes, same shit, different decade.
There's Steam Deck now, and Android, but those are still quite proprietary driven by single companies, so I'm not really sure they fit what you mean about an open alternative.
> Not that linux was even remotely close to being usable even only twenty years ago
I've been using Linux only as a desktop for 30 years, so that's a strange comment. For sure games and other software that was written to run on Windows exclusively, ran best on Windows (who could have predicted it!). But as a desktop, Linux has been usable for many decades.
It works for some domains, but, games ain't the only thing. There is a lot of business software and "technical" software (for controlling manufacturing machines or whatever), which runs on Windows only, as it is the "default" platform. And those applications are low quality special purposes software, nobody knows much about ...
> Isn't it unfortunate, the absolute degree everything legacy is at least in some way tethered to windows. If only there had been an open alternative, it would allow huge communities to emerge keeping very old software/games working indefinitely.
Every time I've tried it, from 2007 to now, it's been a buggy hunk of crap. I normally try not to disparage peoples software projects, but I really don't get ReactOS. I tried it again actually just a few weeks ago. It's barely usable. You'll have far fewer problems just using Wine with Linux.
That's the thing with these kinds of projects that aim to run vast libraries of preexisting software — they're crap for a long, long time, until suddenly there's enough compatibility that hey, it's actually usable. The time vs usability graph for them is very non-linear.
Wine was "garbage" for decades as well. For a long time, it wouldn't do a satisfactory job of running anything but simplest win32 apps.
Same for Ruffle, the open source flash player, but it got to that point much quicker because the API surface is orders of magnitude smaller.
> it would allow huge communities to emerge keeping very old software/games working indefinitely.
That's a completely backwards take though. Windows is practically the only platform in the world that cares about backwards compatibility. On Windows you can run a 20 year old executable and you've got pretty good chance it runs. With Linux operating systems you have no idea if something compiled on the last LTS release runs on the next one.
This is one of the few issues where having a private company control the entire stack and providing a stable ABI for decades is actually a benefit, to the point where your target if you want to build games on linux is...Win32 (https://blog.hiler.eu/win32-the-only-stable-abi/)
That can already be done with Proton for anyone who wants to. But few, if any, are going to step up for the more obscure games. Relying on the benevolence of volunteers is never going to work in the long run either.
> Windows is actually excellent at maintain backwards compatibility.
Rather: Windows is actually excellent at maintain backwards compatibility for binary programs.
There exist lots of other backwards-compatibility topics like
- being backwards-compatible in the user interface (in a business setting, ensuring that the business-critical applications still run is a problem of the IT, but if the user interface changes, people will complain. I just say "Windows 8" or "Office ribbons" (when they were introduced)). I would for example claim that very specifically for the shell interface, the GNU/Linux crowd cares a lot more about user-interface backwards compatibility than what Microsoft does.
- being backwards-compatible in the hardware requirements (i.e. "will it still run on an old computer"). I just want to mention the drama around Windows 11 because it doesn't run on still actively used hardware so that Microsoft cannot force the update on all Windows 10 users, but on the other hand wants to terminate the support for Windows 10.
> I would for example claim that very specifically for the shell interface, the GNU/Linux crowd cares a lot more about user-interface backwards compatibility than what Microsoft does.
Maybe if you ignore things like systemd radically changing how services and init systems work. Massive changes with Network Manager and firewalld compared to iptables. Gnome today looks pretty much nothing like it did when I first started using Linux. Now we install software through snaps and what not, or move from yum to dnf or other package managers.
Using Linux today feels very different than it did 20 years ago. I bet most scrips I wrote for Ubuntu over 20 years ago would fail to execute today on a fresh modern install.
> cmd.exe is only some mostly deprecated tool that was only used by power-users to do some specific tasks.
And bash isn't "some mostly deprecated tool that was only used by power-users"? Think people are mostly using bash for their interface on their steam decks and Android phones and what not? Do most people boot Ubuntu straight into text mode or immediately launch a DE? Grandma using lynx to browse Facebook?
Explorer is a desktop environment. Which, yes, the desktop environment landscape in Linux these days looks pretty different from what was around 20 or so years ago.
You're constantly moving the goal posts and comparing apples and oranges here. Originally saying GNU/Linux user interfaces, then shifted to only text shells, and then comparing those text shells to entire desktop environments while ignoring the forest of constantly changing desktop environments of Linux.
And even then, most of those bat scrips I wrote since XP that only use system tools and commands will largely all still run and do the same thing today. I can't say the same for the same time frame on most major Linux distros that have changed out large parts of their internal tooling.
Also, Windows containers are a thing (not that I’ve ever used them). Shouldn’t it be possible to containerize old games bundled with versions of win32 libraries that were stable when the game was released? Then the games could be run in perpetuity so long as the low-level interfaces needed by the container runtime is maintained.
Windows containers are definitely a thing, but I think the implementation is at the "how to draw an owl: draw two circles..." stage and needs a lot of "...now draw the rest of the owl" in terms of being usable to the general consumer audience where their eyes are likely to gloss over if you say "go and install docker desktop". Having a simple method to maintain old software as usable would be beneficial, but it's hard to see what organization would want to do work to make it happen.
Legacy compatibility is one of windows biggest strong points, neatly containing 'old windows' and providing the best experience for it would solve the puzzle of why users should stick with windows if MS did want to prune the core OS without giving users reasons to move away.
People say this but I really don't consider it to be as true as it once was. I can't even move my taskbar to the side in windows 11 without installing a third-party program to patch explorer.
It's just ridiculous. Windows 11 currently has this bug where the file explorer just freezes all the time. Everyone is experiencing it at work. I cannot believe how a core product gets away with this.
Every time I've investigated an issue like this, it was something outside of explorer. Most of the time some kind of plugin that I didn't want (PDF readers, Tortoise SVN/Git, document preview handlers, you name it), mapped network drives not responding, or file system corruption that went by seemingly unnoticed.
At some point I started Autoruns and just disabled every DLL that didn't come from Microsoft and that I didn't strictly need. It sped up Windows immensely, and I went back enabling maybe one or two of those DLLs at a later point because it broke functionality.
I could've saved weeks of my life if Microsoft had just added a little popup that says "7zip.dll is adding 24% extra time to opening right click menus, disable it Y/N" every time a badly programmed plugin slowed down my shell.
A tale as old as time. It always seemed wild to me File Explorer is allowed to have so much synchronously driven activity. Like sure, display a loading symbol in the content area if I open a network share that's not already mounted (or whatever else it may wait on)... but don't lock the whole darn window so closing it becomes unresponsive!
Process Monitor is invaluable for investigating cases like that - at least one can look at what Windows is actually doing at that moment of freezing:
>Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. It combines the features of two legacy Sysinternals utilities, Filemon and Regmon ...
It's usually because there's some non-local stuff on your sidebar that it's trying to load - either a pinned item or a recently opened / frequently opened thing that's on network storage.
It's stupid but Windows has choked on that situation for many years.
The issue isn’t multithreading. Of course they know that. It’s that they want the UI to show all menu items when you click it (otherwise you’ll say “sometimes PDF Reader is available and sometimes it’s not!!”
Windows doesn’t have performance requirements for most plugins/extensions. It would be great if they did, but it hasn’t been the culture of their ecosystem thus far.
You can add as much multi threading as you want, but if you need to wait until all threads are done, the entire window will stall to show you that context menu you requested.
Since I'm not seeing issues like this I'm assuming these are computers on an active directory... I remember XP having a few fun issues like this when a GPO refreshed links to a file that didn't exist and froze for a moment trying to resolve them.
I get this all the time without being on an active directory. It's nothing network related from what I can tell. The explorer tab just stops being interactable seemingly randomly. Closing and reopening the tab works around it.
It seems to be almost impossible to have a new explorer window open in your home folder. Instead you get a different Home with duplicates of what's already pinned and visible in the sidebar.
I havent experienced that one myself, but I have other problems with the win 11 explorer. Like how when using the keyboard to navigate the right click menu, you cant just navigate into a submenu, but have to navigatw up or down after navigating into it, then the other way, to select the topmost item. And thats one thing I encounter many times a day at work.
As a heavy Windows keyboard user I've found the level or disrespect for my muscle memory skyrocketed with Windows 10. (I'm frustrated daily with the "Sign out" and "Switch user" in the menu to close Explorer. That stupid choice to rename "Log off" turned a deterministic muscle memory operation into a "now I have to look at the screen" operation.)
And there's also the focus stealing exhibited by office applications. Like the 15 minute reminder of outlook for a teams meeting. That one gets me almost daily.
That can happen if you have a mapped network drive which isn't immediately responding or which is offline. If you hover over the drive in Explorer (even accidentally) it will immediately try to query the network location. This can cause massive delay.
This feels like a "if you don't like where you live just move to a bigger house in a better neighborhood" style response to work related software problems. I.e. many people don't get to choose to run whatever software they'd like to on their work machines, nor are they able to justify changing jobs over control of a bug in the file browser.
Ah, I get ya. To me, the hard to believe part is not how individual end users can't solve the problem/pressure Microsoft - it's how enterprise IT teams across the country pay massive licensing/support fees but core parts products like this have regular outstanding hanging bugs of the same family for extended periods over decades. You'd think there would have been enough pressure to make File Explorer more asynchronous by now, given Microsoft are talking about how they still tinker with the low level stuff from decades ago! I know even just mid sized individual companies I've work at have gotten custom patch requests/minor changes in before.
The tough part with (implied) multifaceted comments is nobody can just say things like that, they have to assume what meaning could still make sense to them (which is a dangerous game) or just not engage.
It's really stark when you compare it to something like a linux desktop running KDE or Gnome. Both pretty full featured desktops that were built for the computers I used as a kid.
While there's been a bit of polish, the two simply sip hardware requirements. So much so that you can put them on things like a raspberry pi 3 and still get a decent experience.
It's really funny to me as well. All this effort put into low level performance seems like picking up pennies in front of a steamroller. The operating system (and core business software such as Office) is overflowing with bloat that absolutely tanks the performance and responsiveness of the system. On a fresh boot I might as well go for a 15 minute coffee break lest I end up with multiple hung applications blocked on the UI thread.
It's so bad that Microsoft is actually going to start preloading Office on boot to speed up the application start times.
It was quite the shock to me recently when I had to use a Surface Laptop (the ARM one). Snapdragon X Elite & 32GB of RAM and took almost double the time to get to the desktop from a cold start compared to my M2 Air. Then even once everything was loaded, interacting with the system just did not feel responsive at all, the most egregious being file explorer and the right click menu.
And I have my own gripes with macOS feeling like it's slow due to the animations and me wanting to move faster than it can. Windows used to happily oblige, but now it's laggy.
Microsoft is too caught up in shoving Copilot everywhere to care though.
It's bad everywhere. Every time I've upgraded Ubuntu on my old laptop, performance gets worse and worse because more and more junk keeps getting added. Absolutely maddening.
Is it the desktop environment or background stuff that’s getting worse for you? If the former: FWIW I was pleasantly surprised when I switched back to Kubuntu. KDE’s surprisingly resource efficient these days, actually seems pretty close to XFCE.
NixOS looks super cool, but it also looks too much like actual work. As a FreeBSD main for two decades, I've played that game already and have the (sadly, now long dead) tinderbox and poudriere installations to prove it.
They gave the different sorts of locks different names. Locks usable across processes are mutexes, and locks only usable within a process are critical sections.
Different names can be a huge source of confusion. The C++ standard library uses `std::mutex` as a lightweight synchronization lock. But on Win32, `Mutex` refers to a heavy kind of lock that can be used across processes. Very different things despite both using the same word "mutex" in the name.
Here's another example of confusing terminology. In the C standard library, `fflush` just advances you to the next step, where your buffer goes out to the 'write file' system call, where your data sits in the disk cache to be written later on. Meanwhile, Win32's `FlushFileBuffers` actually forces everything out to the disk, acting much more like `fsync`. Yet again, very different things despite using the same word "flush" in the name.
The Mutex thing kind of makes sense. std::mutex came in at C++11, while Microsoft's CreateMutex call goes back to at least Windows 95. "Mutex" just means "a particular type of lock", it doesn't say anything about the implementation, nor about the performance. It'd be dangerous to assume the performance characteristics of C++'s std::mutex and Rust's std::sync::mutex are anything alike either.
fflush and FlushFileBuffers both just happen to have "flush" in the name. The fact someone decided that fflush doesn't actually flush the file buffer and added fsync to actually flush the buffers, does make for a very frustrating experience, but I find most of the POSIX API to be like that. See also: sync(void) vs fsync(int fd) vs syncfs(int fd).
Really, the oddity is that Microsoft thinks there's a significant difference between in-process communication and cross-process communication. They're all running on the same physical memory and the kernel can share access to that.
I mean you can put a critical section inside of shared memory, but the heavy mutex is used for situations where you need to actually name the mutex, then have another process open it by name. Example uses include preventing multiple instances of a single program from running. Not the kind of thing you'd use a std::mutex or critical section for.
To add to what others have said, additional characteristics of a Win32 critical section:
- It is purely an in-process lock, and originally the main way of arbitrating access to shared memory within a process.
- It is counted and can be recursively locked.
- It defaults to simple blocking, but can also be configured to do some amount of spin-waiting before blocking.
- CritSecs are registered in a global debug list that can be accessed by debuggers. WinDbg's !locks command can display all locked critical sections in a process and which threads have locked them.
Originally in Win32, there were only two types of lock, the critical section for in-process locking, and the mutex for cross-process or named locks. Vista added the slim reader/writer lock, which is a much lighter weight, pointer-sized lock that uses the more modern wait-on-address approach to locking.
A critical section is code that accesses mutable shared data in a non-atomic way (i.e. as several steps, the classic example is: fetch data into a register, process that data, store the result back into memory). A lock is a mechanism that protects such data by preventing other code (or other threads running the same code) from accessing that data until the critical section completes.
Locks come in several types. A developer picks one type depending on the use of the protected data; for example, exclusive, reader-writer, and others.
Locks are great at preventing data corruption and data loss, but come with issues. They can hurt performance, can cause "liveness" and other issues, and are usually "advisory" ("mandatory" locks which are enforced by the OS are rarely available) so developers must remember to protect data by using locks around every critical section.
Modern hardware includes support for many lock-free mechanisms that can greatly reduce the need for locks.
It's a kind of lock. Critsecs are faster and lighter weight than mutices (kinda like a futex), but cannot be shared between processes, only threads within a process. Mutices can be shared between processes but because of that they have to make syscalls every time they're locked or released.
I'm pretty sure you could construct it in many other modern languages that have some Latin influence as well… So why do you think "index" is a Latin word and "mutex" isn't then?
I don't think "index" is a Latin word? You're probably asking the wrong person, I am quite comfortable to say indexes, and indeed sheeps -- it's an English word I can just put the -S noise at the end to pluralize it and that'll be fine even if (as with ox) there is a special case rule that some people insist matters for this word or that one.
Likewise I'm comfortable with "Can't nobody prove nothing", which I think is a succinct way to express an opinion that would be rather awkward when expressed in the prestige dialects of English instead.
In embedded (not sure how applicable here?) you invoke a critical section to access a lock. You will have an interrupt handler. Inside that, you will invoke a critical section, which prevents other processes from interrupting it. Inside the CS, you an get a handle to a mutex that has shared state. The mutex is what I would call the "lock" in this convention.
It's just a lock. It's analogous to a pthread_mutex_t (which on Linux is a futex), where the operation in the uncontended case is a single atomic access to shared memory. The contended case needs to enter the kernel to suspend, or to make a decision about who to wake up, and that seems to be the subject of the blog post.
This is hands down the worst Old New Thing he ever wrote. He either is, or at least should be, ashamed of the poor engineering his colleagues are doing, and trying weakly to defend them.
Monkeying with critical sections is hard. Monkeying with them due to performance and memory optimization while maintaining correctness is incredibly hard. If they'd done a good job of it, no one would have noticed, and Raymond would have had a cool story to tell. Instead we got this.
What? They did in fact maintain correctness. GTA was emphatically in the wrong here and only accidentally worked for a long time because of some internals of the CriticalSection code that they didn't even know they were depending on. The changes to that code didn't modify correctness. The issue was that GTA was relying on undefined behavior. GTA didn't know they had a bug because the undefined behavior happened to be in their favor for a long time. But it's a minor miracle that it hadn't broken before this in a myriad of other ways.
Rockstar actually did fix this bug some years ago, but because some content was removed, people instead downgrade to an earlier version that still has the bug and rely on community patches.
But they did a good job of it? The change of behavior is San Andreas is due to an invalid memory access reading out of bounds into an area of the stack that was only coincidentally initialized by a previous iteration.
They didn't make any changes in correctness. The game itself is broken, and it's normal to undefined behavior from out of bounds accesses will change between OS versions, even just for security reasons. In fact, other versions of the game did fix this bug in a patch, it just didn't get picked because people go out of their way to downgrade the game in order to maintain some cut assets and features.
Where what regularly happens? Wrong code coincidentally works and then doesn't? Which other OSes bend over backwards to the degree that Windows does in order to keep incorrect code working?
Open-source Linux is great at updating old software.
Most other OSes (Android, MacOS, iOS, game consoles) rely on versioning, which makes it easier to provide compatibility layers or at least know when a piece of software just isn't supported anymore.
Personally I think Windows should have specialized VMs for old software, so they can be compatible forever even if they have bugs.
And yet Valve has to translate Windows APIs if they want to have games, because not even the studios targeting Android/Linux care about GNU/Linux, in spite NDK having the same audio and 3D APIs available as C and C++ libraries.
All because game developers prefer to target this OS full or warts than dealing with GNU/Linux fragmentation.
Windows is roughly 25% of the gaming market and I don't know why you're bringing up Linux. I haven't ever had a console unable to play a game built for it, just Windows.
If they’d done a good job, they wouldn’t have made a change that used a little more stack space and triggered an old bug where GTA used an uninitialized local variable? Huh?
So adding a local variable to any function in the system needs to be considered dangerous, and have a way to run an old version of that function that doesn’t have a new local variable? How could that possibly be practical?
If compatability is important, it should at least be considered. For 20 years, this particilar system function did not touch that part of the stack, and GTA used it. In real estate, after ten years, GTA would have a prescriptive easement under Washington State law. :P
It’s just not feasible, unless your plan is not to change anything at all.
When you have apps doing things like relying on values in uninitialized memory, literally any change anywhere can potentially break them.
A company like Microsoft that cares about compatibility will test third party apps to try to catch this sort of thing, but there’s only so much testing you can do. It’s not feasible to test games from two decades prior so throughly that you’d notice that one particular vehicle never spawns.
That wouldn’t be compatibility mode, that would be shipping an entire copy of an older OS version.
From a quick search, it looks like compatibility mode entails interposing a library between the app and the OS libraries, and the library emulates the behavior of an older OS. It’s not automated, each compatibility fix is crafted to work around a specific issue. In theory a fix could be made for this issue, but they’d have to find it and debug it first.
After a while that kool-aid, chilled to optimum temperature, on infinite tap, becomes an aqueous sanctuary, even the most staunch hold-outs cannot resist.
This shows that having a legal way to run outdated operating systems is always important to guarantee that old software runs exactly as intended. Online activation schemes make this problematic.
The solution seems to be installing and fully activating the operating system in the VM while it's still possible, then archiving the VM image. However, I don't know how reliable this method is, since the Windows OS may require reactivation if the hardware configuration changes significantly. Therefore, if the future VM host machine exposes slightly different hardware to the guest machine, the activation might be gone.
This particular example actually doesn’t show that. The misbehavior is caused by a bug in the original game, which was initially hidden only by pure chance, and was already fixed 20 years ago in updated releases of the game, and can be fixed in any version by adding the missing parameters in a plain-text asset (or running the existing patcher add-on).
I agree in the general case, but this particular case isn’t a good argument for it.
I would argue that this case also demonstrates the aforementioned problem. Apparently, an older version of the Windows OS was tolerant to this specific bug, and the game worked just fine. Future users might not be even aware that an updated release of the game fixed this bug, or they might not have access to the update.
You can't blame the user for the fact that the old software contains something that is, technically, an invalid use of the API, meaning the software shouldn't have worked, even in the past. The only way to reliably make the old software work as intended is to have an OS version from that time available.
Just to be precise, the bug isn’t about invalid use of an API. The software uses uninitialized values on the stack, which under older Windows versions happen to be preserved from earlier calls to the same application-level function, despite intermediate calls to other functions, which happen to also involve Windows API calls. In newer Windows versions, these latter functions happen to use more stack space, leading to the old values not being preserved on the stack anymore.
I won’t argue about your other point, as there are arguments either way. I just don’t think this particular example makes a good case, and I suspect that it wouldn’t have been made if the full workings of the bug had been properly understood.
Hopefully the "Stop Killing Games" movement will create some formal obligations around those activation schemes too since it's pretty much the same problem from a different angle.
Criticisms of his post aside. Isn't it unfortunate, the absolute degree everything legacy is at least in some way tethered to windows. If only there had been an open alternative, it would allow huge communities to emerge keeping very old software/games working indefinitely. Not that linux was even remotely close to being usable even only twenty years ago. Relying on a giants benevolence is never going to work in the long run. Their contemporary direction is only a function of what side of the bed theyd like to turn on today.
How would an open operating system fix a bug caused by sloppy game developers? I don't think anyone would think "let's not optimize the (equivalent of) critical sections in our operating system so that we don't break GTA", unless you're suggesting providing 100s of different implementations of different parts of the operating system that people can choose from to run a specific game, which I don't think is viable either. Patching individual games is far easier and is actually viable, which is precisely what GOG (Good Old Games) successfully does on a significantly large scale.
If anything, what Microsoft was way, way better at was finding and working around these types of problems in the OS. Many developers have a more idealistic and less pragmatic approach instead of empathizing with their users: "it's the program's fault, why should we deal with it?"
My sister who was at the time a professor had just moved to a Mac. There was some major statistics app that broke on an OS Update. She contacted the stats company and they said that Apple broke them. She contacted Apple and they said the stats company was given notice and access to beta builds. She was just stuck for months with it not working - and eventually loved back to Windows. She says it’s ugly, but it works.
Apple was always like that.
"Once upon a time, pointers on the Macintosh had 24 bits..."
https://news.ycombinator.com/item?id=44632615
Though at least back then, they provided backward-compatibility modes for old software. You know, back when the expected service lifetime of your Mac was longer than that of your dog.
> Many developers have a more idealistic and less pragmatic approach instead of empathizing with their users: "it's the program's fault, why should we deal with it?"
In the retro-games emulation scene there exist quite some people who write binary patches for popular retro games to fix such bugs. Perhaps this approach (and the necessary skills for it) should become more popular outside the retro-games emulation scene.
> unless you're suggesting providing 100s of different implementations of different parts of the operating system that people can choose from to run a specific game
You just invented "run in compatibility mode"
> it would allow huge communities to emerge keeping very old software/games working indefinitely
The Linux community already stumbles at this and needs Windows to help it out. "Win32 is the only stable ABI on Linux" has been said so many times it isn't a joke any more. Keep in mind that the OS being open doesn't make the games open. Wine is possible because of Win32's die-hard commitment to long-term binary compatibility. I'm not so sure we're in a bad situation here. The Linux userspace has never had this degree of backwards binary compatibility. The kernel doesn't break userspace but userspace breaks itself all the time.
Linux userspace gets lots of other benefits from this rapid-iteration approach that doesn't concern itself with literally decades of binary compatibility, but keeping old games running indefinitely isn't one of them.
> Not that linux was even remotely close to being usable even only twenty years ago.
Running Linux on regular consumer hardware in 2005 was not really any harder than it is today. In fact, many of the same problems still exist! GPU drivers and janky wifi and power-saving modes, same shit, different decade.
There's Steam Deck now, and Android, but those are still quite proprietary driven by single companies, so I'm not really sure they fit what you mean about an open alternative.
The open alternative is Wine, and for very old games Wine is already more compatible than newer versions of Windows itself
> Not that linux was even remotely close to being usable even only twenty years ago
I've been using Linux only as a desktop for 30 years, so that's a strange comment. For sure games and other software that was written to run on Windows exclusively, ran best on Windows (who could have predicted it!). But as a desktop, Linux has been usable for many decades.
It works for some domains, but, games ain't the only thing. There is a lot of business software and "technical" software (for controlling manufacturing machines or whatever), which runs on Windows only, as it is the "default" platform. And those applications are low quality special purposes software, nobody knows much about ...
> Isn't it unfortunate, the absolute degree everything legacy is at least in some way tethered to windows. If only there had been an open alternative, it would allow huge communities to emerge keeping very old software/games working indefinitely.
Have a look at ReactOS:
> https://reactos.org/
> https://en.wikipedia.org/wiki/ReactOS
ReactOS is a thing.
And it's garbage.
Every time I've tried it, from 2007 to now, it's been a buggy hunk of crap. I normally try not to disparage peoples software projects, but I really don't get ReactOS. I tried it again actually just a few weeks ago. It's barely usable. You'll have far fewer problems just using Wine with Linux.
It's been getting better lately.
That's the thing with these kinds of projects that aim to run vast libraries of preexisting software — they're crap for a long, long time, until suddenly there's enough compatibility that hey, it's actually usable. The time vs usability graph for them is very non-linear.
Wine was "garbage" for decades as well. For a long time, it wouldn't do a satisfactory job of running anything but simplest win32 apps.
Same for Ruffle, the open source flash player, but it got to that point much quicker because the API surface is orders of magnitude smaller.
> Every time I've tried it, from 2007 to now, it's been a buggy hunk of crap.
So, VERY much in keeping with Windows tradition, then!
> it would allow huge communities to emerge keeping very old software/games working indefinitely.
That's a completely backwards take though. Windows is practically the only platform in the world that cares about backwards compatibility. On Windows you can run a 20 year old executable and you've got pretty good chance it runs. With Linux operating systems you have no idea if something compiled on the last LTS release runs on the next one.
This is one of the few issues where having a private company control the entire stack and providing a stable ABI for decades is actually a benefit, to the point where your target if you want to build games on linux is...Win32 (https://blog.hiler.eu/win32-the-only-stable-abi/)
That can already be done with Proton for anyone who wants to. But few, if any, are going to step up for the more obscure games. Relying on the benevolence of volunteers is never going to work in the long run either.
> it would allow huge communities to emerge keeping very old software/games working indefinitely
Windows is actually excellent at maintain backwards compatibility. A program written 30 years ago probably still works today.
> Windows is actually excellent at maintain backwards compatibility.
Rather: Windows is actually excellent at maintain backwards compatibility for binary programs.
There exist lots of other backwards-compatibility topics like
- being backwards-compatible in the user interface (in a business setting, ensuring that the business-critical applications still run is a problem of the IT, but if the user interface changes, people will complain. I just say "Windows 8" or "Office ribbons" (when they were introduced)). I would for example claim that very specifically for the shell interface, the GNU/Linux crowd cares a lot more about user-interface backwards compatibility than what Microsoft does.
- being backwards-compatible in the hardware requirements (i.e. "will it still run on an old computer"). I just want to mention the drama around Windows 11 because it doesn't run on still actively used hardware so that Microsoft cannot force the update on all Windows 10 users, but on the other hand wants to terminate the support for Windows 10.
> I would for example claim that very specifically for the shell interface, the GNU/Linux crowd cares a lot more about user-interface backwards compatibility than what Microsoft does.
Maybe if you ignore things like systemd radically changing how services and init systems work. Massive changes with Network Manager and firewalld compared to iptables. Gnome today looks pretty much nothing like it did when I first started using Linux. Now we install software through snaps and what not, or move from yum to dnf or other package managers.
Using Linux today feels very different than it did 20 years ago. I bet most scrips I wrote for Ubuntu over 20 years ago would fail to execute today on a fresh modern install.
> Maybe if you ignore things like systemd radically changing how services and init systems work.
I am explicitly talking about the shell (Bash, ksh, zsh). Other parts of the GNU/Linux stack changed a lot.
Well then, can't one also say Windows hasn't changed much since XP, which was one of the last major times CMD.exe changed?
cmd.exe is only some mostly deprecated tool that was only used by power-users to do some specific tasks.
The Windows analogue of some UNIX shell is rather explorer.exe, and this is exactly what my Windows 8 example refers to.
> cmd.exe is only some mostly deprecated tool that was only used by power-users to do some specific tasks.
And bash isn't "some mostly deprecated tool that was only used by power-users"? Think people are mostly using bash for their interface on their steam decks and Android phones and what not? Do most people boot Ubuntu straight into text mode or immediately launch a DE? Grandma using lynx to browse Facebook?
Explorer is a desktop environment. Which, yes, the desktop environment landscape in Linux these days looks pretty different from what was around 20 or so years ago.
You're constantly moving the goal posts and comparing apples and oranges here. Originally saying GNU/Linux user interfaces, then shifted to only text shells, and then comparing those text shells to entire desktop environments while ignoring the forest of constantly changing desktop environments of Linux.
And even then, most of those bat scrips I wrote since XP that only use system tools and commands will largely all still run and do the same thing today. I can't say the same for the same time frame on most major Linux distros that have changed out large parts of their internal tooling.
Also, Windows containers are a thing (not that I’ve ever used them). Shouldn’t it be possible to containerize old games bundled with versions of win32 libraries that were stable when the game was released? Then the games could be run in perpetuity so long as the low-level interfaces needed by the container runtime is maintained.
Windows containers are definitely a thing, but I think the implementation is at the "how to draw an owl: draw two circles..." stage and needs a lot of "...now draw the rest of the owl" in terms of being usable to the general consumer audience where their eyes are likely to gloss over if you say "go and install docker desktop". Having a simple method to maintain old software as usable would be beneficial, but it's hard to see what organization would want to do work to make it happen.
Legacy compatibility is one of windows biggest strong points, neatly containing 'old windows' and providing the best experience for it would solve the puzzle of why users should stick with windows if MS did want to prune the core OS without giving users reasons to move away.
People say this but I really don't consider it to be as true as it once was. I can't even move my taskbar to the side in windows 11 without installing a third-party program to patch explorer.
Given how awful performance on my Windows desktop is, I am shocked that Microsoft is still investing in performance.
It's just ridiculous. Windows 11 currently has this bug where the file explorer just freezes all the time. Everyone is experiencing it at work. I cannot believe how a core product gets away with this.
Every time I've investigated an issue like this, it was something outside of explorer. Most of the time some kind of plugin that I didn't want (PDF readers, Tortoise SVN/Git, document preview handlers, you name it), mapped network drives not responding, or file system corruption that went by seemingly unnoticed.
At some point I started Autoruns and just disabled every DLL that didn't come from Microsoft and that I didn't strictly need. It sped up Windows immensely, and I went back enabling maybe one or two of those DLLs at a later point because it broke functionality.
I could've saved weeks of my life if Microsoft had just added a little popup that says "7zip.dll is adding 24% extra time to opening right click menus, disable it Y/N" every time a badly programmed plugin slowed down my shell.
Yup, back when I used windows, my solution to software rot was “just don’t install things that aren’t absolutely essential”
Same goes for OS X now — it seems every OS grows incomprehensible to the company that makes it
Which is sad, because one of the main functions of an OS should be to protect you from misbehaving applications
Linux is a bit better, but I think even the Debian GUI suffers from trying to be convenient/magic rather than predictable/robust
A tale as old as time. It always seemed wild to me File Explorer is allowed to have so much synchronously driven activity. Like sure, display a loading symbol in the content area if I open a network share that's not already mounted (or whatever else it may wait on)... but don't lock the whole darn window so closing it becomes unresponsive!
Process Monitor is invaluable for investigating cases like that - at least one can look at what Windows is actually doing at that moment of freezing:
>Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. It combines the features of two legacy Sysinternals utilities, Filemon and Regmon ...
https://learn.microsoft.com/en-us/sysinternals/downloads/pro...
It's usually because there's some non-local stuff on your sidebar that it's trying to load - either a pinned item or a recently opened / frequently opened thing that's on network storage.
It's stupid but Windows has choked on that situation for many years.
It seems they haven't heard of multi threading...
The issue isn’t multithreading. Of course they know that. It’s that they want the UI to show all menu items when you click it (otherwise you’ll say “sometimes PDF Reader is available and sometimes it’s not!!”
Windows doesn’t have performance requirements for most plugins/extensions. It would be great if they did, but it hasn’t been the culture of their ecosystem thus far.
You can add as much multi threading as you want, but if you need to wait until all threads are done, the entire window will stall to show you that context menu you requested.
Since I'm not seeing issues like this I'm assuming these are computers on an active directory... I remember XP having a few fun issues like this when a GPO refreshed links to a file that didn't exist and froze for a moment trying to resolve them.
I get this all the time without being on an active directory. It's nothing network related from what I can tell. The explorer tab just stops being interactable seemingly randomly. Closing and reopening the tab works around it.
The reskin of File Explorer in win11 was the most unnecessary thing. Someone's need to justify their job is bringing misery to the masses.
It seems to be almost impossible to have a new explorer window open in your home folder. Instead you get a different Home with duplicates of what's already pinned and visible in the sidebar.
I havent experienced that one myself, but I have other problems with the win 11 explorer. Like how when using the keyboard to navigate the right click menu, you cant just navigate into a submenu, but have to navigatw up or down after navigating into it, then the other way, to select the topmost item. And thats one thing I encounter many times a day at work.
As a heavy Windows keyboard user I've found the level or disrespect for my muscle memory skyrocketed with Windows 10. (I'm frustrated daily with the "Sign out" and "Switch user" in the menu to close Explorer. That stupid choice to rename "Log off" turned a deterministic muscle memory operation into a "now I have to look at the screen" operation.)
And there's also the focus stealing exhibited by office applications. Like the 15 minute reminder of outlook for a teams meeting. That one gets me almost daily.
Not that it makes it any less frustrating to you, but it's probably triggered by something relatively rare/obscure in your environment.
Probably all you can do is keep poking your IT support and hope it goes up the line until someone finds or creates the fix/workaround.
That can happen if you have a mapped network drive which isn't immediately responding or which is offline. If you hover over the drive in Explorer (even accidentally) it will immediately try to query the network location. This can cause massive delay.
Having worked in software for over a decade, I believe it.
Stop using it.
This feels like a "if you don't like where you live just move to a bigger house in a better neighborhood" style response to work related software problems. I.e. many people don't get to choose to run whatever software they'd like to on their work machines, nor are they able to justify changing jobs over control of a bug in the file browser.
Then maybe they actually can believe that Microsoft gets away with it. My comment was multifaceted :P
Ah, I get ya. To me, the hard to believe part is not how individual end users can't solve the problem/pressure Microsoft - it's how enterprise IT teams across the country pay massive licensing/support fees but core parts products like this have regular outstanding hanging bugs of the same family for extended periods over decades. You'd think there would have been enough pressure to make File Explorer more asynchronous by now, given Microsoft are talking about how they still tinker with the low level stuff from decades ago! I know even just mid sized individual companies I've work at have gotten custom patch requests/minor changes in before.
The tough part with (implied) multifaceted comments is nobody can just say things like that, they have to assume what meaning could still make sense to them (which is a dangerous game) or just not engage.
If you can convince corporate to ditch Microsoft and Azure, I'll buy you a beer.
It's really stark when you compare it to something like a linux desktop running KDE or Gnome. Both pretty full featured desktops that were built for the computers I used as a kid.
While there's been a bit of polish, the two simply sip hardware requirements. So much so that you can put them on things like a raspberry pi 3 and still get a decent experience.
It's really funny to me as well. All this effort put into low level performance seems like picking up pennies in front of a steamroller. The operating system (and core business software such as Office) is overflowing with bloat that absolutely tanks the performance and responsiveness of the system. On a fresh boot I might as well go for a 15 minute coffee break lest I end up with multiple hung applications blocked on the UI thread.
It's so bad that Microsoft is actually going to start preloading Office on boot to speed up the application start times.
It was quite the shock to me recently when I had to use a Surface Laptop (the ARM one). Snapdragon X Elite & 32GB of RAM and took almost double the time to get to the desktop from a cold start compared to my M2 Air. Then even once everything was loaded, interacting with the system just did not feel responsive at all, the most egregious being file explorer and the right click menu.
And I have my own gripes with macOS feeling like it's slow due to the animations and me wanting to move faster than it can. Windows used to happily oblige, but now it's laggy.
Microsoft is too caught up in shoving Copilot everywhere to care though.
> It's so bad that Microsoft is actually going to start preloading Office on boot to speed up the application start times.
Office has been preloading on startup since Windows 95.
It's bad everywhere. Every time I've upgraded Ubuntu on my old laptop, performance gets worse and worse because more and more junk keeps getting added. Absolutely maddening.
Is it the desktop environment or background stuff that’s getting worse for you? If the former: FWIW I was pleasantly surprised when I switched back to Kubuntu. KDE’s surprisingly resource efficient these days, actually seems pretty close to XFCE.
I'm not sure and don't have the patience to check.
I might go back to Debian. I'm only really using Ubuntu since that and RHEL are what we use at work.
my nixos with just xmonad works really well, I haven't noticed any degradation in the last 10 years of updates.
NixOS looks super cool, but it also looks too much like actual work. As a FreeBSD main for two decades, I've played that game already and have the (sadly, now long dead) tinderbox and poudriere installations to prove it.
The new M$ slop Explorer is horribly optimized and full of unnecessary IPC so no wonder it's so slow.
Raymond Chen has such a unique style that I know it's going to be him before even clicking on the link
hn discussion of the GTA bug that triggered this post:
https://news.ycombinator.com/item?id=43772311
How is a critical section different from a lock?
They gave the different sorts of locks different names. Locks usable across processes are mutexes, and locks only usable within a process are critical sections.
Different names can be a huge source of confusion. The C++ standard library uses `std::mutex` as a lightweight synchronization lock. But on Win32, `Mutex` refers to a heavy kind of lock that can be used across processes. Very different things despite both using the same word "mutex" in the name.
Here's another example of confusing terminology. In the C standard library, `fflush` just advances you to the next step, where your buffer goes out to the 'write file' system call, where your data sits in the disk cache to be written later on. Meanwhile, Win32's `FlushFileBuffers` actually forces everything out to the disk, acting much more like `fsync`. Yet again, very different things despite using the same word "flush" in the name.
The Mutex thing kind of makes sense. std::mutex came in at C++11, while Microsoft's CreateMutex call goes back to at least Windows 95. "Mutex" just means "a particular type of lock", it doesn't say anything about the implementation, nor about the performance. It'd be dangerous to assume the performance characteristics of C++'s std::mutex and Rust's std::sync::mutex are anything alike either.
fflush and FlushFileBuffers both just happen to have "flush" in the name. The fact someone decided that fflush doesn't actually flush the file buffer and added fsync to actually flush the buffers, does make for a very frustrating experience, but I find most of the POSIX API to be like that. See also: sync(void) vs fsync(int fd) vs syncfs(int fd).
fflush does flush the userspace buffer, if it should affect the kernel, it needs to be the syscall, which is called fsync.
Really, the oddity is that Microsoft thinks there's a significant difference between in-process communication and cross-process communication. They're all running on the same physical memory and the kernel can share access to that.
I mean you can put a critical section inside of shared memory, but the heavy mutex is used for situations where you need to actually name the mutex, then have another process open it by name. Example uses include preventing multiple instances of a single program from running. Not the kind of thing you'd use a std::mutex or critical section for.
To add to what others have said, additional characteristics of a Win32 critical section:
- It is purely an in-process lock, and originally the main way of arbitrating access to shared memory within a process.
- It is counted and can be recursively locked.
- It defaults to simple blocking, but can also be configured to do some amount of spin-waiting before blocking.
- CritSecs are registered in a global debug list that can be accessed by debuggers. WinDbg's !locks command can display all locked critical sections in a process and which threads have locked them.
Originally in Win32, there were only two types of lock, the critical section for in-process locking, and the mutex for cross-process or named locks. Vista added the slim reader/writer lock, which is a much lighter weight, pointer-sized lock that uses the more modern wait-on-address approach to locking.
A critical section is code that accesses mutable shared data in a non-atomic way (i.e. as several steps, the classic example is: fetch data into a register, process that data, store the result back into memory). A lock is a mechanism that protects such data by preventing other code (or other threads running the same code) from accessing that data until the critical section completes.
Locks come in several types. A developer picks one type depending on the use of the protected data; for example, exclusive, reader-writer, and others.
Locks are great at preventing data corruption and data loss, but come with issues. They can hurt performance, can cause "liveness" and other issues, and are usually "advisory" ("mandatory" locks which are enforced by the OS are rarely available) so developers must remember to protect data by using locks around every critical section.
Modern hardware includes support for many lock-free mechanisms that can greatly reduce the need for locks.
It's a kind of lock. Critsecs are faster and lighter weight than mutices (kinda like a futex), but cannot be shared between processes, only threads within a process. Mutices can be shared between processes but because of that they have to make syscalls every time they're locked or released.
Mutex isn't latin. The plural of mutex is mutexes.
It’s a running joke in the field to have exotic pluralizations. Mutex->mutices is one, box->boxen (by analogy to oxen) is also pretty common.
We need more casual light-heartedness in this line of work considering how much casual bullshit there is.
> there's two hard problems in computer science: we only have one joke and it's not funny.
https://news.ycombinator.com/item?id=42046226
> box->boxen (by analogy to oxen) is also pretty common.
Not to mention (from way back when) VAX -> VAXen.
Except it actually is Latin. Both "mutual" and "exclusive" are borrowings from Latin.
No, it's an English word. The fact it's related, distantly, to some words in Latin doesn't mean mutex is Latin.
I'm pretty sure you could construct it in many other modern languages that have some Latin influence as well… So why do you think "index" is a Latin word and "mutex" isn't then?
I don't think "index" is a Latin word? You're probably asking the wrong person, I am quite comfortable to say indexes, and indeed sheeps -- it's an English word I can just put the -S noise at the end to pluralize it and that'll be fine even if (as with ox) there is a special case rule that some people insist matters for this word or that one.
Likewise I'm comfortable with "Can't nobody prove nothing", which I think is a succinct way to express an opinion that would be rather awkward when expressed in the prestige dialects of English instead.
plural of mutex is indeed exmut (exclusive mutation) :)
In embedded (not sure how applicable here?) you invoke a critical section to access a lock. You will have an interrupt handler. Inside that, you will invoke a critical section, which prevents other processes from interrupting it. Inside the CS, you an get a handle to a mutex that has shared state. The mutex is what I would call the "lock" in this convention.
It's just a lock. It's analogous to a pthread_mutex_t (which on Linux is a futex), where the operation in the uncontended case is a single atomic access to shared memory. The contended case needs to enter the kernel to suspend, or to make a decision about who to wake up, and that seems to be the subject of the blog post.
Critical sections are very old, and bloated version of a mutex, but there isn't a good reason to use them today.
Today you can use SRWLock or WaitOnAddress on Windows(or std::shared_mutex for portable impl, but not std::mutex because reasons).
Task manager takes 5 seconds to open on Windows 11 now
This is hands down the worst Old New Thing he ever wrote. He either is, or at least should be, ashamed of the poor engineering his colleagues are doing, and trying weakly to defend them.
Monkeying with critical sections is hard. Monkeying with them due to performance and memory optimization while maintaining correctness is incredibly hard. If they'd done a good job of it, no one would have noticed, and Raymond would have had a cool story to tell. Instead we got this.
Sigh, Microsoft, what's happening over there?
Please read the original article that this is in response to. The poor engineering was on Rockstar's side.
What? They did in fact maintain correctness. GTA was emphatically in the wrong here and only accidentally worked for a long time because of some internals of the CriticalSection code that they didn't even know they were depending on. The changes to that code didn't modify correctness. The issue was that GTA was relying on undefined behavior. GTA didn't know they had a bug because the undefined behavior happened to be in their favor for a long time. But it's a minor miracle that it hadn't broken before this in a myriad of other ways.
Rockstar actually did fix this bug some years ago, but because some content was removed, people instead downgrade to an earlier version that still has the bug and rely on community patches.
But they did a good job of it? The change of behavior is San Andreas is due to an invalid memory access reading out of bounds into an area of the stack that was only coincidentally initialized by a previous iteration.
They didn't make any changes in correctness. The game itself is broken, and it's normal to undefined behavior from out of bounds accesses will change between OS versions, even just for security reasons. In fact, other versions of the game did fix this bug in a patch, it just didn't get picked because people go out of their way to downgrade the game in order to maintain some cut assets and features.
'No Way To Prevent This', says only OS where this regularly happens.
Where what regularly happens? Wrong code coincidentally works and then doesn't? Which other OSes bend over backwards to the degree that Windows does in order to keep incorrect code working?
Which other OSes prevent this consistently?
Open-source Linux is great at updating old software.
Most other OSes (Android, MacOS, iOS, game consoles) rely on versioning, which makes it easier to provide compatibility layers or at least know when a piece of software just isn't supported anymore.
Personally I think Windows should have specialized VMs for old software, so they can be compatible forever even if they have bugs.
So other OSes prevent this by not even trying to run old software? Yeah, not particularly helpful
Better to have a strategy for software compatibility and evolution vs Microsoft's strategy of doing nothing.
Pretty much every game console ever made still works with every game for that console, but when it's Windows you never know.
And yet Valve has to translate Windows APIs if they want to have games, because not even the studios targeting Android/Linux care about GNU/Linux, in spite NDK having the same audio and 3D APIs available as C and C++ libraries.
All because game developers prefer to target this OS full or warts than dealing with GNU/Linux fragmentation.
Windows is roughly 25% of the gaming market and I don't know why you're bringing up Linux. I haven't ever had a console unable to play a game built for it, just Windows.
Because HN is all about SteamDeck when complaining about Windows.
Never break user-space and all
If they’d done a good job, they wouldn’t have made a change that used a little more stack space and triggered an old bug where GTA used an uninitialized local variable? Huh?
Perhaps not, but setting the compatability mode should maybe get programs that worked before to work again.
Using extra stack space has got to be on a list of things likely to cause trouble.
So adding a local variable to any function in the system needs to be considered dangerous, and have a way to run an old version of that function that doesn’t have a new local variable? How could that possibly be practical?
If compatability is important, it should at least be considered. For 20 years, this particilar system function did not touch that part of the stack, and GTA used it. In real estate, after ten years, GTA would have a prescriptive easement under Washington State law. :P
It’s just not feasible, unless your plan is not to change anything at all.
When you have apps doing things like relying on values in uninitialized memory, literally any change anywhere can potentially break them.
A company like Microsoft that cares about compatibility will test third party apps to try to catch this sort of thing, but there’s only so much testing you can do. It’s not feasible to test games from two decades prior so throughly that you’d notice that one particular vehicle never spawns.
I don't mind that they didn't find this, it would have been hard to find it, given the situation.
But it's still kind of bogus that compatability mode doesn't make things compatible.
That wouldn’t be compatibility mode, that would be shipping an entire copy of an older OS version.
From a quick search, it looks like compatibility mode entails interposing a library between the app and the OS libraries, and the library emulates the behavior of an older OS. It’s not automated, each compatibility fix is crafted to work around a specific issue. In theory a fix could be made for this issue, but they’d have to find it and debug it first.
After a while that kool-aid, chilled to optimum temperature, on infinite tap, becomes an aqueous sanctuary, even the most staunch hold-outs cannot resist.