Need help?
<- Back

Comments (67)

  • abanana
    > 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-offThe 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".
  • LASR
    Whatever one might think of Windows and Microsoft, the idea that you can still run apps that are 30+ years old is incredible.
  • hypercube33
    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.
  • Dwedit
    Why show a screenshot of a different game (SimCity 2000) when discussing SimCity?
  • adwf
    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.
  • manoDev
    This is a great example of how implementation becomes the specification.
  • RajT88
  • sedatk
    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.
  • Blikkentrekker
    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?
  • ForOldHack
    I wouldn't be surprised by windows components that use this. Wish I could run 16-bit apps tho.
  • 150g2
    And yet scamming people with direct X.
  • jeffbee
    This is why memory allocators should be linked into applications and should not be considered operating system components.
  • hyperhello
    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?
  • thighbaugh
    What else could be expected of Redmond's finest?
  • xp84
    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.