> 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.
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.
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.
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
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.
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.
With Linux you're stuck trying to decipher the ramblings of neckbeards.
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.
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?
Clearly this can't be enforced, but I've always found it bad practice to allocate memory inside a library.
https://github.com/otya128/winevdm
https://github.com/leecher1337/ntvdmx64
https://web.stanford.edu/class/cs343/resources/purify.pdf