> 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.
> 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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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 :)
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.
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.
> 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.
From an article on this[0]:
> 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...
[delayed]
I have read some similar things about macOS having app-specific fixes for popular apps.
It might have been this article: https://news.ycombinator.com/item?id=34034413
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.
One may even speculate the author got some, or a lot of ... "help", if it's even a real author.
Nothing wrong with getting help from AI as long as you’re applying good and qualified judgment on what parts of its help is decent.
Your comment also do not bring anything interesting to discussion.
good thing the comment wasn't swarmed in ads
I prefer ads over snarky dismissive hot air of someone ego.
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?
I believe they identified it by the name of the executable. IIRC, we did exactly what your second sentence says.
If you look at the compatibility tool you'll see multiple checks not only executable name match. It can check version headers and other signatures.
Whatever one might think of Windows and Microsoft, the idea that you can still run apps that are 30+ years old is incredible.
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.
Did you have to procure a physical library of random devices for that kind of work?
My kid's a big fan of original StarCraft, which is now going on 28 years old.
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..."
Also Windows has a huge community of people who will help you.
With Linux you're stuck trying to decipher the ramblings of neckbeards.
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.
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.
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.
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.
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.
Why show a screenshot of a different game (SimCity 2000) when discussing SimCity?
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.
Because this article is an AI slop rehashing for SEO.
Alternate theory:
https://web.archive.org/web/20130226221212/http://windows95t...
It actually seems like Windows 11 shipping with Windows 3.1's memory manager that was kept in Windows 95 memory manager as a compatibility option.
This is a great example of how implementation becomes the specification.
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.
Which is more attractive?
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.
I wouldn't be surprised by windows components that use this. Wish I could run 16-bit apps tho.
> Wish I could run 16-bit apps tho.
https://github.com/otya128/winevdm
https://github.com/leecher1337/ntvdmx64
And yet scamming people with direct X.
This is why memory allocators should be linked into applications and should not be considered operating system components.
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.
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.
Userland system DLLs need to allocate memory too.
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.
And when you are running more than one application at the same time how is that supposed to work?
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
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?
There was such a tool, called Purify.
https://web.stanford.edu/class/cs343/resources/purify.pdf
[delayed]
This is what sanitizers do.
I know compilers have advanced, but I was wondering about a runtime debug check.
A sanitizer is that runtime debug check. The compiler just inserts those checks.
Okay. Then I have to assume that they didn't do it for SimCity! Thanks.
Sanitizers come with a lot of overhead, and the tech wasn't readily available in SimCity's day, certainly not for Windows 95.
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 :)
What else could be expected of Redmond's finest?
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.
A hidden z80 emulator...
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.