> The tradition goes back to SimCity, which only ran on Windows 95 because Microsoft wrote special code for it... Yes, Microsoft modified its OS just to cover up one game’s bug... The SimCity hack was a one-off
The stuff around SimCity in this article is poorly written. It seems the author has misunderstood it to have been a one-off special case. I looked back at Joel Spolsky's article, and he does make it quite clear that the SimCity example was just one of many: "it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95".
The article does later mention "Windows XP’s hidden database of app fixes" but doesn't appreciate that the concept really started with Windows 95, and in a big way, not "just to cover up one game’s bug".
Rough guess but this is all content farming of Raymond Chen posts at https://devblogs.microsoft.com/oldnewthing/ though I can't find a smoking gun. I definitely remember an article about Intuit doing something some dumb they had to keep an internal API around reporting the wrong value or something like that.
I used to work as a QA Engineer @ Transmeta testing software om out CPUs to ensure x86 compatibility. My manager this operated like this. She would constantly look for old software to acquire. One of her favorite activities was dumpster diving outside of startups that had failed to pick up old copies of software on CDs and floppy disks. I remember testing a lot of Diablo 2, Tomb Raider of various versions, Star Wars Episode I Racer, and Risk (for Windows 3.0).
I found a bug where our system would freeze after playing Tomb Raider 2 on a certain CPU/chipset combo. If I remember correctly, it turned out to be a unacceptable voltage drop somewhere in the south bridge.
> On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.
The article’s content is generally quite weak, could probably have been covered in an old school tweet with screenshots and nothing of value would have been lost.
The only positive thing I can say about it is that it doesn’t appear to be written by AI.
I don’t think this person truly understands what they’re writing about, they did a little research, made some screenshots and put enough words in the article so that it will show up in search engines.
It’s reminiscent to me of many articles on Windows error codes, almost all of them are basically generic, generally quite long with drivel, and steering you to install some “fix it” software. Any technical person coming across these just finds them annoying as they clearly gamed the search results with unhelpful content.
We know a lot of this from the Windows NT leaks, its a shame that clearly Windows was a drastically better maintained OS than today. In the NT leaks there were comments about things like adding support for things like Delphi to ensure it compiles.
I worked for this place that made a security auditing tool. The agent had to know which version of Windows it was running on. When Microsoft came out with a new version, the agent didn't know what it was running on, since it hadn't been updated to include that version. I forget what it did in response, but it didn't run right - maybe just terminated?
Microsoft discovered this in their testing, before they released the new Windows version. In response, they added our agent to a list of programs that Windows would lie to about the Windows version. If our program asked, we would be told the previous version.
Well, that was great, in that our program didn't terminate early (or whatever it did). But now, even after we updated our agent, it still wouldn't know whether it was running on the new version of Windows, and so would not audit it correctly!
This dance shows just how far Microsoft went with backward compatibility. We were not a top-1000-most-used program by any means, but they knew about us and tested us and fixed for us. (I mean, we didn't want it, in this case, but it was still impressive.)
How did they identify your software? Could you guys produce a sibling program whose job is to identify the windows version and notify the main program?
That was a very old, very tasteless gag from someone who didn't understand the situation.
MS has always bent over backwards to retain backwards compatibility, to the extent that it's genuinely a corporate weakness: it's slowed software releases, bulked them up with patches and tweaks and special-case exceptions, and prevented the company from keeping the OSes relatively reasonably-sized by dropping obsolete features.
Linux is starting to do this now, but only because the team's hand is being forced by LLM-bot vulnerability discovery. So it's dropping loads of old drivers -- but then, the kernel is mostly drivers, hundreds of thousands of them.
Apple is more proactive: it regularly says "this is the next to last version that does [function X] and the release after next will remove that.
I've been using OS X since 10.0, after 13 years using classic MacOS. Over that time, OS X has progressively dropped:
* The Blue Box VM for running Classic apps (removed in 10.5)
* Then the PowerPC version (removed in 10.6)
* Then Rosetta for running PowerPC apps (removed in 10.7)
* Then the AppleTalk network sharing protocol connections -- printers remained (I forget when)
* Then 32-bit app support (removed in 10.15)
I'm on macOS 15, on an 11YO iMac thanks to OCLP. Soon I'll be forced onto Tahoe simply because it's the last ever x86 version. The current beta of OCLP supports this. I will wait for the final release.
It periodically warns me that the AppleShare over TCP/IP is going away too. Won't directly affect me on an Intel Mac.
* Intel support is going in macOS 27
I am willing to bet Rosetta 2 and x86 binary support will go by macOS 28 or so.
It also dropped HFS writing, leaving only R/O HFS support. That may be gone now. Not tried in a few years but circa 10.13 it could happily mount a 30YO floppy disk in a USB diskette drive.
Since 10.14 it will only boot off APFS although HSF+ R/W support is fine.
I worked on device connectivity in Windows core OS division in the Longhorn/Vista push. I came from the Linux and SunOS world before that. It was simply crazy at the dedication and effort put in to make Windows backwards compatible with whatever old broken and poorly behaving USB and printer device. We would have no-named cheap web cams that didn't function to USB spec but "worked" in Windows 98 that needed to work in Vista while still implementing new secure driver models that broke all cheap device assumptions. It was a long hard trek to get all those devices working.
They basically had a cart populated with random-ass stuff they found in computer shops to the maximum of the USB spec supported wirh hubs. They inserted the hub and watched Windows crash until everything is fixed and worked, then they started yanking it when it was still discovering devices.
This was shocking to me as a gamer who loved Windows and had to use Mac. Rosetta helped for a while. Nowadays it feels like an intentional treadmill to purge any dev not willing to keep up.
> intentional treadmill to purge any dev not willing to keep up
It is. Both Apple and Google will push apps off their stores that have not been updated in "a while". Even if the app works fine and is perfectly finished.
Oh yeah, Mac and games don't mix for other reasons besides that too. Like Apple wants devs to use Metal, and devs don't want to use Metal. I occasionally play whatever few games happen to run on my Mac, and that's enough.
Game devs also don't bother making their games work for Mac (or Linux). I keep hearing that the engines support Metal and this is no problem, but then there are still no Mac games. Edit: Especially Valve, big game company that used to make Mac versions and seemingly gave up.
Yeah, it makes no sense. The standard is OpenGL, Vulkan, but Apple ditches it just to be different or something. At least some big game engines support it, e.g. OGRE, so if you do want cross-platform dev, it's possible.
Even the cross-platform stuff tends to not support Mac as well. Like CSGO had a Mac version like the other Source-engine games, but it never worked quite right on Mac. I had input lag and inconsistent framerates, and it's not that I cared about winning, but the game was painful to play like that. Game was perfect on the same machine running Windows via Boot Camp.
Also, there's Vulkan on Metal, but there's translation overhead, and I have no idea what other issues it causes. Dolphin emulator did some research on that.
Nope, OpenGL and Vulkan are not standards embraced by game developers other than famous folks like Carmack pushing for it, and even him has acknowledged DirectX being much better.
Game consoles don't do Khronos APIs for the most part, they are really only standard on GNU/Linux and Android, really.
Indeed DirectX is king, but OpenGL and Vulkan aren't nothing. There was a long period of time, maybe 2000-2016, when high-budget games being released for Mac wasn't so uncommon, or at least it was more common than today, and those often used OpenGL. Instead of Apple rallying around the only alternatives to DirectX, they made yet another way. I'm assuming Mac games are just not a priority for Apple, which is fine.
No? Mac and games mix great in 2026. I'd wager 90% of games released in the last 30 days on Steam run out of the box under Wine on Mac, or at worst - usually when a custom in-house engine is used, which is now rare - with minimal modifications that Claude will whip up for you. AAA blockbusters and eSports, sure, but all in all that's only a small percentage of games. And of course some of the highest quality AAA games like Baldur's Gate 3 or very popular indie games like Slay the Spire run natively on Mac.
WINE is hilariously a more reliable way to run software on Mac than just making the software natively for Mac. There is software that got released for Mac but you can only run the Windows version on Mac today. A big chunk of that is x86-32.
But I did mean this as part of games not mixing with Mac. You most likely have to run any game in an emulator, and it still maybe doesn't work or is much laggier. It's not just AAA games and cringesports, it's all sorts of popular games. Both AoE2 remakes for example. BeamNG works but not well. Anything with anticheat is a no (last two examples aren't this category btw). I've used WINE like 2008-2022, at some point decided nah, even though Codeweavers have done an amazing job.
Oh and I have no idea what happens when they start removing Rosetta 2 support. Supposedly they will prioritize making certain software work for it, but x86-32 Windows games running in Crossover?
All I can tell you is of the last 10 I tried, all games from the last 10 years, 8 run perfectly fine under Wine on Mac, and 2 of the older ones with a custom inhouse engine for only that game, run perfectly fine after telling an agent to make it work. This is not even using CrossOver, I'm talking free. These games are all from different developers.
I'm sure there are games that don't work but it's a minority of new Steam releases even if you exclude pure slop.
AFAIK, you can run Civ1 (and other 16-bit games & applications) on Windows 10/11 in 3 ways:
1. Run CivWin on WineVDM: WineVDM, also known as OTVDM (Old 16-bit Windows Virtual Machine), is a compatibility layer that allows users to run many legacy 16-bit Windows applications on modern 64-bit Windows systems.
CivWin is the Windows re-release of Civ1, that's recommended due to its high resolution support (e.g., you can play it in HD with cool mods) and some people like the final multiplayer CivNet release too.
Credit: @Blake00 on this thread:
https://forums.civfanatics.com/threads/using-winevdm-to-play...https://winevdm.com/does-winevdm-work-on-windows-11/
3. VirtualBox or VMWare (virtual machines solution) to install and run a copy of Windows 95/98.
Note that Microsoft removed support for 16-bit subsystems from 64-bit editions of Windows many years ago, beginning with Windows XP Professional x64 Edition.
it's not 1999 anymore, we've already moved past the golden era of stackoverflow and forums to support Linux & Windows questions into a new dawn of poorly sourced reddit bot comments.
No, you're almost completely screwed if you're at the point of looking for non-trivial Windows help online. But you're also way less likely to be in that situation with Windows vs with Linux.
I really want to believe you and that I've just missed the magic support forums but trying to find answers to problems on Windows is just a million forums of the same essentially "turn it off and on again" advice
Linux forums might be obtuse but at least they'll have actual technical details about the problem. Almost without fail any "fix" they propose
won't work on your system because it's for a different distro that was EoL 5 years ago but they'll at least give you something to work with.
I know what you're talking about. Microsoft is so large, that the smallest of gaps are enough for ecosystems to form around and provide people a living.
For example, people trawling the Microsoft Q&A forum for low hanging fruit to provide advice to and build out their little home computer repair business profile.
Yeah this completely matches my experience. Questions lacking essential details or followup, answers that are some kind of professional help who don't actually know anything.
I found all of the above to be lacking years ago tbh no matter what platform the advice was for. I'm really glad now that I can just go back and forth with even a free-tier chatbot for 2-3 messages to fix any fixable problem, or just have a cursor agent tinker with it interactively until it's fixed.
This spirit is clearly a part of MS's corporate DNA and honestly I think the world is far better off for it. No other platform owner would do this, not today at least. The most you could expect from say, Apple or Google, is that they do ship the betas. If you go all summer without fixing "your" "bug" (note: it could be that the new OS is the code that introduced the bug) it'll just crash on OS launch day and the platform owner would make no attempt to even test it for you.
Maybe there's a tiny exception with like, Apple for Adobe. They might place a phone call between executives to warn them to avoid angering the "pros" who use those apps, but I think it's more because their users internally who also use Adobe apps would notice in the course of testing the betas, than a practice of testing many apps with the intent to ensure they work correctly.
To me what this feels like is that Microsoft's culture to this day considers it would be a breach of trust to ship an OS update that, from your perspective breaks your programs that used to work fine. Compared to the approach everywhere else today that the platform owner simply dictates How Things Will Be Now.
Keeping buggy, hard to mantain and complex code in a operating system in name of compatibility is not something benign as you seem to think it is. Instead it is putting marketing ahead of security.
The world should not be made more vulnerable just because someone in Idaho would be pissed because if they can't run Photoshop 2.0 anymore in a newer version of an operating system.
This philosophy is why Windows on ARM is a shitshow and Mac on ARM is a mostly seamless user experience. Microsoft refuses to kick developers to get with the times, whereas Apple doesn’t hesitate to do so, and Windows developers have become all the more lazy for it. Microsoft could really do with regularly breaking private and legacy APIs, and imposing the cost of maintenance onto developers instead of themselves.
You can see my other comment, but short version is that I think it’s just content for the sake of content without the person actually really understanding the topic much more than most of their readers.
Someone was watching NT to Now on Youtube I see, and playing with the Application SHIM system. There are a lot of quirky things from NT still in Windows 11. I think that Clock.exe was finally removed a year or two ago from 1994.
Wouldn't be surprised if this sort of backwards compatibility is an absolute goldmine for AI assisted vulnerability searches. Would place bets on MS having to remove some significant fraction of all this in the coming years.
By the way, the compatibility posture is now theoretical. I recently pointed out that Black and White was on archive.org to a friend. It didn't work on their Windows 11.
(It did work under Wine with a few small tweaks that I can't remember)
This kind of neglect for backwards compatibility is honestly why quite a bit of free software is failing, and also why quite a bit is not that understands it.
Like the fiasco with Python3 and Wayland. It's so clear the developers just thought “Wow, people will just switch” not realizing how much people demand an absolute drop-in replacement and then maybe later you can think of slowly deprecating features to discourage new users from adopting them. Rust realizes this with editions. Yes, it's a big investment for them to continue to support it, but the alternative is that Python library maintainers now have to have this big investment themselves because they have to maintain like 6 different versions of the same library because Python doesn't understand the value of backwards compatibility. z/OS still supports 50s COBOL frameworks and for good reason. No one is going to rewrite that.
These developers when you talk about them really do not seem to understand that people aren't jumping to rewrite code or maintain different versions at the same time and very often even call them “lazy” for not doing it like they're not using their time for other things. Say you're a company, and you can pay a developer for his time:
1) Have him develop new features that make you more money.
2) Have him fix bugs that cost you money.
3) Have him rewrite existing code that will do nothing new, and will probably introduce new bugs again so you can later go to 2.
Nobody is going to tell you that Python 2->3 wasn't excruciatingly painful but it's hard to argue with the result. Sometimes you have to rip the bandaid off. Python 3 is by far the better language.
You're right the "commercial" timeline of Python would have supported Python 2 forever because big paying clients demand it but I think that would have led to a worse outcome for the OSS community.
> Nobody is going to tell you that Python 2->3 wasn't excruciatingly painful but it's hard to argue with the result. Sometimes you have to rip the bandaid off. Python 3 is by far the better language.
It's not “by far”, the weird part is that they broke backwards compatibility but also didn't fix some of the other issues and many of the fixes didn't need backwards compatibility to be broken and most of all, the way Python works would allow code written in multiple versions to interact and they should absolutely have allowed that and allow Python3 code to call Python2 modules.
> You're right the "commercial" timeline of Python would have supported Python 2 forever because big paying clients demand it but I think that would have led to a worse outcome for the OSS community.
The cost of switching was ridiculous and it still is. “venv” needing to exist is symptomatic of the bizarre ecosystem and developers being expected to maintain like 6 different versions of the same library at times and when they don't as user you are screwed.
With Rust, multiple editions can just compile together. Crates written in one edition can be called from code written in another edition.
Also, the optimism just highlighted how out of touch they were, that they thought people would actually just rewrite everything in 5 years is bizarre and suggests a fundamental lack of understanding to me. Same thing with Wayland and GPLv3 to me. This is so common in the FOSS world. People come with a new version and just expect that everyone will quickly switch because they consider their new version better, not realizing that A) even if others think it's better, they still won't “just switch” because that costs time and money and B), very often they don't even think it's better which they never bothered to even investigate before they got started. They just assumed that everyone will agree because the “I have no idea what Xfce is or does, sorry.” people are completely out of touch with the world to be honest and it's pretty clear they're often living in some very specific online bubble and don't understand the concerns of companies, users, and just everyone outside of their own little bubble.
Well, FOSS is free (also "like beer", i.e. unpaid), so I don't find it surprising that it doesn't follow commercial mindset priorities. People working for free are driven by other motives. While needs of commercial users would be considered and accommodated in many cases, they are not the only priority, as they would be for a commercial enterprise like Microsoft.
I think you are pointing out the conflict that can then arise, but that I don't think is avoidable: a company has relatively short-term aim of surviving until year-end (or quarter-end) and making money. FOSS contributors are hoping to create something worthwhile by whatever value system they adhere to (elegance, public recognition etc).
FOSS does not mean all people who maintain/contribute to it work for free. A lot of them are being paid to maintain/develop module that their company uses. Microsoft developers contribute to Linux kernel all the time
And I am sure they are acting in the interests of the paying entity. But the interests of the paying entity may not align with the interests of entities like XFCE.
> Well, FOSS is free (also "like beer", i.e. unpaid), so I don't find it surprising that it doesn't follow commercial mindset priorities. People working for free are driven by other motives. While needs of commercial users would be considered and accommodated in many cases, they are not the only priority, as they would be for a commercial enterprise like Microsoft.
“I have no idea what Xfce is or does, sorry.” and Python developers actually thinking that everyone would switch in five years isn't about motivations; it's just about a fundamental lack of understanding of what goes on outside of one's own little world of people who program for fun and love tinkering. This isn't priority but simple ignorance.
> Also, the optimism just highlighted how out of touch they were, that they thought people would actually just rewrite everything in 5 years is bizarre and suggests a fundamental lack of understanding to me. Same thing with Wayland and GPLv3 to me.
It is the fundamental difference in the developer's origin/experience in FOSS projects vs commercial software. However, there is an even bigger paradigm difference underneath. Academia survives on one-off projects and FOSS is often recruits students in universities who contribute as hobby, without contracts. The usual POSIX software is all about exposing things with minimal abstractions. It makes developing and iterating on software easier on the developer.
People who work in commercial software are forced into decade-long support contracts. So they develop skills in managing long-term backwards compatibility. This comes with the abstractions and software designs with more thought into their future.
You see that in Windows components that the engineers thought about how the computer systems will evolve and allocated some slack to extend the software: https://faultlore.com/blah/c-isnt-a-language/#case-study-min... . This kind of hindsight isn't something one can easily learn without being forced into the backwards compatibility and getting burned before or mentored. Some of the skills also means that you need to learn where to place the "narrow waist" of the API.
To illustrate the difference I'll actually compare Win32 vs X11/Wayland. Win32 is a much better abstraction and much better "narrow waist" point than X11 was. X11 was designed tightly around 80's hardware and people had to add hacks on top of hacks to actually make things like GPUs work. X11's network transparent architecture actually made implementing direct rendering harder. While Win32 already had some ideas that made into Wayland and it designed nice abstractions for allocating windows, direct rendering buffers and compositing. Win32 had baked in concepts like a window or a button or text rendering. So when the devices with HighDPI appeared or when new security boundaries needed the higher level abstractions of Win32 made it possible for Microsoft to make smaller API changes while the whole X11 started to collapse with 90s hardware and then was useless for 2010s.
> It is the fundamental difference in the developer's origin/experience in FOSS projects vs commercial software. However, there is an even bigger paradigm difference underneath. Academia survives on one-off projects and FOSS is often recruits students in universities who contribute as hobby, without contracts. The usual POSIX software is all about exposing things with minimal abstractions. It makes developing and iterating on software easier on the developer.
I think it's just the fundamental mentality of the kind of people it recruits and it wasn't always the case either. It felt like the old Unix guard of people who worked at Bell Labs were far better adjusted. If anything, this feels more like a social thing because you just encounter these kinds of people a lot outside of programming on say Reddit or 4chan, as in people who just completely seem to miss what goes on outside of their little bubble and I do feel certain types of FOSS have a higher chance of recruiting those people because they were the people who used to first submit patches for free on github and then rose the ranks. This does not in any way occur with say people being paid by Intel to write drivers for Linux. They seem to know perfectly well what goes on with the world because they weren't recruited through those channels that are just more likely to attract, shall we call it “terminally online” people as the kids call it nowadays?
> To illustrate the difference I'll actually compare Win32 vs X11/Wayland. Win32 is a much better abstraction and much better "narrow waist" point than X11 was. X11 was designed tightly around 80's hardware and people had to add hacks on top of hacks to actually make things like GPUs work. X11's network transparent architecture actually made implementing direct rendering harder. While Win32 already had some ideas that made into Wayland and it designed nice abstractions for allocating windows, direct rendering buffers and compositing. Win32 had baked in concepts like a window or a button or text rendering. So when the devices with HighDPI appeared or when new security boundaries needed the higher level abstractions of Win32 made it possible for Microsoft to make smaller API changes while the whole X11 started to collapse with 90s hardware and then was useless for 2010s.
Even ignoring the future though. It's just the understanding of the “now”. Things like initially libinput having no way to disable mouse acceleration and the developer at first resisting it until receiving a mountain of complaints and finally relenting because “Everyone would want mouse acceleration always on, right?”. Or just in general how these people seem to completely forget that desktop usage is largely just an afterthought for Linux and the main usages are phones, servers, small devices and supercomputers. To them Linux is really just a desktop kernel and they completely don't seem to realize that desktop usage of it is really super inconsequential in the larger scheme of things.
"Venv" type solutions are how Windows manages its backward compatibility, at least in 32-bit land as well. Look up WinSxS: it's basically a store of the old DLLs an old application needs, and the system determines which versions an app needs at app launch, and adds those to the DLL load path. Pretty much transparently.
If an OS update gives me a better allocator, I want every app to take advantage of it. Same idea with other libraries, if I update a library for reading zip files to make it go faster, or to fix a vulnerability, I want every application that uses that library to take advantage of it.
This is a debatable position. Linux distros usually do this, but a lot of modern applications ship with all their dependencies. I'd say the former is more efficient and generally better from a user perspective and the latter is more stable and is generally better from a developer/maintainer perspective. Open source encourages the former, proprietary software encourages the latter.
I think Windows has had a much better memory allocator for some time now but it's behind a registry flag? I think there were issues with some applications so it shipped but turned off by default.
That isn't how history has unfolded. What has actually happened is that operating systems ship with extremely bad allocators unsuitable for any application and due to some kind of emergent collective problem they are never improved.
How does the memory allocator statically linked into the application request a new memory allocation into it's address space (sbrk or VirtualAlloc etc.)? Allocating memory will in most cases involve calling into the kernel, it's kinda a core function of a kernel. It has to have some link externally to the programme, directly or indirectly.
The smallest amount of memory you can request from the OS is a page (typically 4K, sometimes 16K), and there’s a lot of additional stuff that goes on in malloc().
Whenever I write I library I don't allocate memory. If memory needs to be allocated, the program calling into the library allocates memory and passes a pointer (or reference I suppose) into the library call.
Clearly this can't be enforced, but I've always found it bad practice to allocate memory inside a library.
How to you manage the API when caller doesn't know the right size to allocate? I mean you could pass an allocator object (ala zig/C++ stdlib etc), though I'm not sure I like the extra arg on functions... I guess a quasi-global-variable approach (e.g. a "context" object, passed to all functions, which can hold an allocator, or equivalently implicit arguments in a functional language) would be one way to achieve that without the "noise" of explicit allocators passed everywhere.
You can also design a "dual-pass" API. Basically you have an API call to estimate or calculate the memory usage needed and then another parameter / API call to actually do the operation.
For example the WideCharToMultiByte [1] function of Win32 handles UTF-16 to UTF-8 conversion. If you pass your destination pointer as NULL, then it purely calculates the number of bytes you'll need in your buffer. Then the main program actually allocates the memory and calls it again with the populated destination pointer.
It's not really practical to do this outside of simple cases. For example, a modern userspace GPU driver must allocate lots of memory in hundreds if not thousands of places to implement a standard API and there's no way around that.
Yeah, until your OS memory allocator evolves with your kernel in ways that are not exposed to third party applications which allows it to be more efficient/introspectable/debuggable
It works fine. The processes get a fenced off piece of memory and are allowed to portion it out to themselves any way they prefer. Syscalls are designed to be mostly neutral about how the app wants to proceed.
On a system with an MMU, applications have their own address space that the allocator draws from; pages need to be centrally allocated, but individual allocations can be handled in userspace
Windows NT (NT - Windows 11) keeps applications in their own private memory space by design. Windows 1,2,3,95,98,Me didn't do this which is why it was more prone to blue screens.
In 20 years we'll have finally reached the logical conclusion to all of this that there shouldn't be separate os components you link against and your "OS" will just be manager of lightweight VMs.
Now you can just ship the user your machine and software can theoretically be immortal.
I don’t know much about CPU and memory back then, but did they not have some kind of memory access debugging mode where it would match every access against the alloc map, understanding that it could be very slow, but would find some of this kind of bug? Come to think of it, do we even have that today?
I was imagining more like some kind of primitive CPU mode that sends every single RAM request to a software exception. Something you would normally have turned off but available for truly heavy duty debugging.
That sounds pretty similar to what Valgrind does, basically runs your program in a VM with that kind of instrumentation. The details of how it works are way past the boundaries of my own knowledge though :)
The operating system could effect this by not providing any page tables to the CPU, so every memory reference faults and the OS has to handle them all.
are you implying the fact that they proactively threw in a custom heap manager for a game is supposed to be a bad thing? The fact that almost any 25+ year old executable runs on Windows to this day is fantastic, they're seemingly the only guys who take backwards compatibility seriously.
The stuff around SimCity in this article is poorly written. It seems the author has misunderstood it to have been a one-off special case. I looked back at Joel Spolsky's article, and he does make it quite clear that the SimCity example was just one of many: "it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95".
The article does later mention "Windows XP’s hidden database of app fixes" but doesn't appreciate that the concept really started with Windows 95, and in a big way, not "just to cover up one game’s bug".
> On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.
[0] https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...
The only positive thing I can say about it is that it doesn’t appear to be written by AI.
I don’t think this person truly understands what they’re writing about, they did a little research, made some screenshots and put enough words in the article so that it will show up in search engines.
It’s reminiscent to me of many articles on Windows error codes, almost all of them are basically generic, generally quite long with drivel, and steering you to install some “fix it” software. Any technical person coming across these just finds them annoying as they clearly gamed the search results with unhelpful content.
It might have been this article: https://news.ycombinator.com/item?id=34034413
Microsoft discovered this in their testing, before they released the new Windows version. In response, they added our agent to a list of programs that Windows would lie to about the Windows version. If our program asked, we would be told the previous version.
Well, that was great, in that our program didn't terminate early (or whatever it did). But now, even after we updated our agent, it still wouldn't know whether it was running on the new version of Windows, and so would not audit it correctly!
This dance shows just how far Microsoft went with backward compatibility. We were not a top-1000-most-used program by any means, but they knew about us and tested us and fixed for us. (I mean, we didn't want it, in this case, but it was still impressive.)
MS has always bent over backwards to retain backwards compatibility, to the extent that it's genuinely a corporate weakness: it's slowed software releases, bulked them up with patches and tweaks and special-case exceptions, and prevented the company from keeping the OSes relatively reasonably-sized by dropping obsolete features.
Linux is starting to do this now, but only because the team's hand is being forced by LLM-bot vulnerability discovery. So it's dropping loads of old drivers -- but then, the kernel is mostly drivers, hundreds of thousands of them.
Apple is more proactive: it regularly says "this is the next to last version that does [function X] and the release after next will remove that.
I've been using OS X since 10.0, after 13 years using classic MacOS. Over that time, OS X has progressively dropped:
* The Blue Box VM for running Classic apps (removed in 10.5)
* Then the PowerPC version (removed in 10.6)
* Then Rosetta for running PowerPC apps (removed in 10.7)
* Then the AppleTalk network sharing protocol connections -- printers remained (I forget when)
* Then 32-bit app support (removed in 10.15)
I'm on macOS 15, on an 11YO iMac thanks to OCLP. Soon I'll be forced onto Tahoe simply because it's the last ever x86 version. The current beta of OCLP supports this. I will wait for the final release.
It periodically warns me that the AppleShare over TCP/IP is going away too. Won't directly affect me on an Intel Mac.
* Intel support is going in macOS 27
I am willing to bet Rosetta 2 and x86 binary support will go by macOS 28 or so.
It also dropped HFS writing, leaving only R/O HFS support. That may be gone now. Not tried in a few years but circa 10.13 it could happily mount a 30YO floppy disk in a USB diskette drive.
Since 10.14 it will only boot off APFS although HSF+ R/W support is fine.
They basically had a cart populated with random-ass stuff they found in computer shops to the maximum of the USB spec supported wirh hubs. They inserted the hub and watched Windows crash until everything is fixed and worked, then they started yanking it when it was still discovering devices.
It is. Both Apple and Google will push apps off their stores that have not been updated in "a while". Even if the app works fine and is perfectly finished.
Gamedevs already have Metal support on their engines, they don't spend time with API wars like FOSS communities.
Just like, Khronos APIs are largely irrelevant in game consoles, and Windows.
Even on the Switch that does Vulkan and GL, NVN is the main API for those that want full control over the hardware.
And as note,
https://asomobile.net/en/blog/mobile-gaming-market-in-2026-t...
But like USB-C, at some point you should just embrace the industry standard.
Also, there's Vulkan on Metal, but there's translation overhead, and I have no idea what other issues it causes. Dolphin emulator did some research on that.
Game consoles don't do Khronos APIs for the most part, they are really only standard on GNU/Linux and Android, really.
But I did mean this as part of games not mixing with Mac. You most likely have to run any game in an emulator, and it still maybe doesn't work or is much laggier. It's not just AAA games and cringesports, it's all sorts of popular games. Both AoE2 remakes for example. BeamNG works but not well. Anything with anticheat is a no (last two examples aren't this category btw). I've used WINE like 2008-2022, at some point decided nah, even though Codeweavers have done an amazing job.
I'm sure there are games that don't work but it's a minority of new Steam releases even if you exclude pure slop.
I think you need an emulator to run Civ1, though. My kid was asking if we could try it and I'm like "I don't think I can find that on Steam..."
[0] https://archive.org/details/CIVILIZATION_201902
1. Run CivWin on WineVDM: WineVDM, also known as OTVDM (Old 16-bit Windows Virtual Machine), is a compatibility layer that allows users to run many legacy 16-bit Windows applications on modern 64-bit Windows systems. CivWin is the Windows re-release of Civ1, that's recommended due to its high resolution support (e.g., you can play it in HD with cool mods) and some people like the final multiplayer CivNet release too. Credit: @Blake00 on this thread: https://forums.civfanatics.com/threads/using-winevdm-to-play... https://winevdm.com/does-winevdm-work-on-windows-11/
2. DosBox (get the D-Fend Reloaded frontend/GUI, it contains DosBox): https://dfendreloaded.sourceforge.io/ https://www.dosbox.com/mown/index.php
3. VirtualBox or VMWare (virtual machines solution) to install and run a copy of Windows 95/98.
Note that Microsoft removed support for 16-bit subsystems from 64-bit editions of Windows many years ago, beginning with Windows XP Professional x64 Edition.
With Linux you're stuck trying to decipher the ramblings of neckbeards.
There is so much obscure windows crap that can be found in the old internet.
Linux forums might be obtuse but at least they'll have actual technical details about the problem. Almost without fail any "fix" they propose won't work on your system because it's for a different distro that was EoL 5 years ago but they'll at least give you something to work with.
For example, people trawling the Microsoft Q&A forum for low hanging fruit to provide advice to and build out their little home computer repair business profile.
https://learn.microsoft.com/en-us/answers/tags/824/windows-h...
Some of these answers are really dubious. Some of these questions are really dubious.
Maybe there's a tiny exception with like, Apple for Adobe. They might place a phone call between executives to warn them to avoid angering the "pros" who use those apps, but I think it's more because their users internally who also use Adobe apps would notice in the course of testing the betas, than a practice of testing many apps with the intent to ensure they work correctly.
To me what this feels like is that Microsoft's culture to this day considers it would be a breach of trust to ship an OS update that, from your perspective breaks your programs that used to work fine. Compared to the approach everywhere else today that the platform owner simply dictates How Things Will Be Now.
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...
The world should not be made more vulnerable just because someone in Idaho would be pissed because if they can't run Photoshop 2.0 anymore in a newer version of an operating system.
https://web.archive.org/web/20130226221212/http://windows95t...
(It did work under Wine with a few small tweaks that I can't remember)
https://github.com/otya128/winevdm
https://github.com/leecher1337/ntvdmx64
Like the fiasco with Python3 and Wayland. It's so clear the developers just thought “Wow, people will just switch” not realizing how much people demand an absolute drop-in replacement and then maybe later you can think of slowly deprecating features to discourage new users from adopting them. Rust realizes this with editions. Yes, it's a big investment for them to continue to support it, but the alternative is that Python library maintainers now have to have this big investment themselves because they have to maintain like 6 different versions of the same library because Python doesn't understand the value of backwards compatibility. z/OS still supports 50s COBOL frameworks and for good reason. No one is going to rewrite that.
These developers when you talk about them really do not seem to understand that people aren't jumping to rewrite code or maintain different versions at the same time and very often even call them “lazy” for not doing it like they're not using their time for other things. Say you're a company, and you can pay a developer for his time:
1) Have him develop new features that make you more money.
2) Have him fix bugs that cost you money.
3) Have him rewrite existing code that will do nothing new, and will probably introduce new bugs again so you can later go to 2.
Which is more attractive?
You're right the "commercial" timeline of Python would have supported Python 2 forever because big paying clients demand it but I think that would have led to a worse outcome for the OSS community.
It's not “by far”, the weird part is that they broke backwards compatibility but also didn't fix some of the other issues and many of the fixes didn't need backwards compatibility to be broken and most of all, the way Python works would allow code written in multiple versions to interact and they should absolutely have allowed that and allow Python3 code to call Python2 modules.
> You're right the "commercial" timeline of Python would have supported Python 2 forever because big paying clients demand it but I think that would have led to a worse outcome for the OSS community.
The cost of switching was ridiculous and it still is. “venv” needing to exist is symptomatic of the bizarre ecosystem and developers being expected to maintain like 6 different versions of the same library at times and when they don't as user you are screwed.
With Rust, multiple editions can just compile together. Crates written in one edition can be called from code written in another edition.
Also, the optimism just highlighted how out of touch they were, that they thought people would actually just rewrite everything in 5 years is bizarre and suggests a fundamental lack of understanding to me. Same thing with Wayland and GPLv3 to me. This is so common in the FOSS world. People come with a new version and just expect that everyone will quickly switch because they consider their new version better, not realizing that A) even if others think it's better, they still won't “just switch” because that costs time and money and B), very often they don't even think it's better which they never bothered to even investigate before they got started. They just assumed that everyone will agree because the “I have no idea what Xfce is or does, sorry.” people are completely out of touch with the world to be honest and it's pretty clear they're often living in some very specific online bubble and don't understand the concerns of companies, users, and just everyone outside of their own little bubble.
I think you are pointing out the conflict that can then arise, but that I don't think is avoidable: a company has relatively short-term aim of surviving until year-end (or quarter-end) and making money. FOSS contributors are hoping to create something worthwhile by whatever value system they adhere to (elegance, public recognition etc).
FOSS does not mean all people who maintain/contribute to it work for free. A lot of them are being paid to maintain/develop module that their company uses. Microsoft developers contribute to Linux kernel all the time
“I have no idea what Xfce is or does, sorry.” and Python developers actually thinking that everyone would switch in five years isn't about motivations; it's just about a fundamental lack of understanding of what goes on outside of one's own little world of people who program for fun and love tinkering. This isn't priority but simple ignorance.
It is the fundamental difference in the developer's origin/experience in FOSS projects vs commercial software. However, there is an even bigger paradigm difference underneath. Academia survives on one-off projects and FOSS is often recruits students in universities who contribute as hobby, without contracts. The usual POSIX software is all about exposing things with minimal abstractions. It makes developing and iterating on software easier on the developer.
People who work in commercial software are forced into decade-long support contracts. So they develop skills in managing long-term backwards compatibility. This comes with the abstractions and software designs with more thought into their future.
You see that in Windows components that the engineers thought about how the computer systems will evolve and allocated some slack to extend the software: https://faultlore.com/blah/c-isnt-a-language/#case-study-min... . This kind of hindsight isn't something one can easily learn without being forced into the backwards compatibility and getting burned before or mentored. Some of the skills also means that you need to learn where to place the "narrow waist" of the API.
To illustrate the difference I'll actually compare Win32 vs X11/Wayland. Win32 is a much better abstraction and much better "narrow waist" point than X11 was. X11 was designed tightly around 80's hardware and people had to add hacks on top of hacks to actually make things like GPUs work. X11's network transparent architecture actually made implementing direct rendering harder. While Win32 already had some ideas that made into Wayland and it designed nice abstractions for allocating windows, direct rendering buffers and compositing. Win32 had baked in concepts like a window or a button or text rendering. So when the devices with HighDPI appeared or when new security boundaries needed the higher level abstractions of Win32 made it possible for Microsoft to make smaller API changes while the whole X11 started to collapse with 90s hardware and then was useless for 2010s.
I think it's just the fundamental mentality of the kind of people it recruits and it wasn't always the case either. It felt like the old Unix guard of people who worked at Bell Labs were far better adjusted. If anything, this feels more like a social thing because you just encounter these kinds of people a lot outside of programming on say Reddit or 4chan, as in people who just completely seem to miss what goes on outside of their little bubble and I do feel certain types of FOSS have a higher chance of recruiting those people because they were the people who used to first submit patches for free on github and then rose the ranks. This does not in any way occur with say people being paid by Intel to write drivers for Linux. They seem to know perfectly well what goes on with the world because they weren't recruited through those channels that are just more likely to attract, shall we call it “terminally online” people as the kids call it nowadays?
> To illustrate the difference I'll actually compare Win32 vs X11/Wayland. Win32 is a much better abstraction and much better "narrow waist" point than X11 was. X11 was designed tightly around 80's hardware and people had to add hacks on top of hacks to actually make things like GPUs work. X11's network transparent architecture actually made implementing direct rendering harder. While Win32 already had some ideas that made into Wayland and it designed nice abstractions for allocating windows, direct rendering buffers and compositing. Win32 had baked in concepts like a window or a button or text rendering. So when the devices with HighDPI appeared or when new security boundaries needed the higher level abstractions of Win32 made it possible for Microsoft to make smaller API changes while the whole X11 started to collapse with 90s hardware and then was useless for 2010s.
Even ignoring the future though. It's just the understanding of the “now”. Things like initially libinput having no way to disable mouse acceleration and the developer at first resisting it until receiving a mountain of complaints and finally relenting because “Everyone would want mouse acceleration always on, right?”. Or just in general how these people seem to completely forget that desktop usage is largely just an afterthought for Linux and the main usages are phones, servers, small devices and supercomputers. To them Linux is really just a desktop kernel and they completely don't seem to realize that desktop usage of it is really super inconsequential in the larger scheme of things.
This is a debatable position. Linux distros usually do this, but a lot of modern applications ship with all their dependencies. I'd say the former is more efficient and generally better from a user perspective and the latter is more stable and is generally better from a developer/maintainer perspective. Open source encourages the former, proprietary software encourages the latter.
Read about it here: https://news.ycombinator.com/item?id=47858177
I've read that comment at time and saved it somewhere, then when I remembered there was something like that I searched for hours yet couldn't find it.
Clearly this can't be enforced, but I've always found it bad practice to allocate memory inside a library.
For example the WideCharToMultiByte [1] function of Win32 handles UTF-16 to UTF-8 conversion. If you pass your destination pointer as NULL, then it purely calculates the number of bytes you'll need in your buffer. Then the main program actually allocates the memory and calls it again with the populated destination pointer.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/stringap...
Now you can just ship the user your machine and software can theoretically be immortal.
You mean like Windows/386 through Windows Me? They were effectively a hypervisor for DOS VMs.
https://web.stanford.edu/class/cs343/resources/purify.pdf