Windows 95 Went the Extra Mile To Ensure Compatibility of SimCity, Other Games (arstechnica.com) 77
An anonymous reader quotes a report from Ars Technica: It's still possible to learn a lot of interesting things about old operating systems. Sometimes, those things are already documented (on a blog post) that miraculously still exist. One such quirk showed up recently when someone noticed how Microsoft made sure that SimCity and other popular apps worked on Windows 95. A recent tweet by @Kalyoshika highlights an excerpt from a blog post by Fog Creek Software co-founder, Stack Overflow co-creator, and longtime software blogger Joel Spolsky. The larger post is about chicken-and-egg OS/software appeal and demand. The part that caught the eye of a Hardcore Gaming 101 podcast co-host is how the Windows 3.1 version of SimCity worked on the Windows 95 system. Windows 95 merged MS-DOS and Windows apps, upgraded APIs from 16 to 32-bit, and was hyper-marketed. A popular app like SimCity, which sold more than 5 million copies, needed to work without a hitch.
Spolsky's post summarizes how SimCity became Windows 95-ready, as he heard it, without input from Maxis or user workarounds: "Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here's the amazing part: 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."
Spolsky (in 2000) considers this a credit to Microsoft and an example of how to break the chicken-and-egg problem: "provide a backwards compatibility mode which either delivers a truckload of chickens, or a truckload of eggs, depending on how you look at it, and sit back and rake in the bucks." Windows developers may have deserved some sit-back time, seeing the extent of the tweaks they often have to make for individual games and apps in Windows 95. Further in @Kalyoshika's replies, you can find another example, pulled from the Compatibility Administrator in Windows' Assessment and Deployment Kit (ADK). A screenshot from @code_and_beer shows how Windows NT, upon detecting files typically installed with Final Fantasy VII, will implement a fittingly titled compatibility fix: "Win95VersionLie." Simply telling the game that it's on Windows 95 seems to fix a major issue with its operation, along with a few other emulation and virtualization tweaks. "Mike Perry, former creative director at Sim empire Maxis (and later EA), noted later that there was, technically, a 32-bit Windows 95 version of Sim City available, as shown by the 'Deluxe Edition' bundle of the game," adds Ars. "He also states that Ross worked for Microsoft after leaving Maxis, which would further explain why Microsoft was so keen to ensure people could keep building parks in the perfect grid position to improve resident happiness."
Spolsky's post summarizes how SimCity became Windows 95-ready, as he heard it, without input from Maxis or user workarounds: "Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here's the amazing part: 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."
Spolsky (in 2000) considers this a credit to Microsoft and an example of how to break the chicken-and-egg problem: "provide a backwards compatibility mode which either delivers a truckload of chickens, or a truckload of eggs, depending on how you look at it, and sit back and rake in the bucks." Windows developers may have deserved some sit-back time, seeing the extent of the tweaks they often have to make for individual games and apps in Windows 95. Further in @Kalyoshika's replies, you can find another example, pulled from the Compatibility Administrator in Windows' Assessment and Deployment Kit (ADK). A screenshot from @code_and_beer shows how Windows NT, upon detecting files typically installed with Final Fantasy VII, will implement a fittingly titled compatibility fix: "Win95VersionLie." Simply telling the game that it's on Windows 95 seems to fix a major issue with its operation, along with a few other emulation and virtualization tweaks. "Mike Perry, former creative director at Sim empire Maxis (and later EA), noted later that there was, technically, a 32-bit Windows 95 version of Sim City available, as shown by the 'Deluxe Edition' bundle of the game," adds Ars. "He also states that Ross worked for Microsoft after leaving Maxis, which would further explain why Microsoft was so keen to ensure people could keep building parks in the perfect grid position to improve resident happiness."
Re: (Score:3)
It's worth bringing up because backwards compatibility is important.
Re: (Score:3)
Yup. That was one of the reasons why Windows was so popular in commercial environments, MS bent over backwards to make sure that anything important would still run no matter how badly misbehaved it was. The amount of shimming that used to be present in Windows to allow badly-written apps to keep running is frightening.
Of course that was years ago, before Windows became so entrenched that MS realised it could just shit on customers and they'd have to keep using Windows no matter what.
Re: (Score:2)
It also makes things quite hard on writers of compatibility layers, such as WINE.
Re: (Score:2)
Yeah, but the people fixing the problem aren't the people who created it. you Could argue they should have patched the game instead of doing special casing in the OS, but there are potential legal issues there.
Re: (Score:2)
Yes, it was the same company. But people leave, and Microsoft is not really known for having top flight programmers.
Re: (Score:3)
you Could argue they should have patched the game instead of doing special casing in the OS, but there are potential legal issues there.
When Windows 95 came out, the internet as we know it didn't exist. Games came on floppy discs and there was no menu option to check for updates. Also, the playing field wasn't very big so Microsoft just had to make sure that Windows 95 was compatible with killer apps and popular games. Maxis DID fix the issue when they released the 32 bit version of Sim City.
And also (Score:4, Insightful)
Went out of their way to make sure other software didn't work.
Re: (Score:3)
DOS ain't done 'till Lotus won't run.
Re: (Score:2)
Re: (Score:2)
Microsoft didn't have many games at the time. It was mostly just flight sim and some card games for a long time... less than two dozen titles total (i.e. not counting versions of flight sim) before Windows '95.
Re: (Score:2)
*Microsoft* had games. Almost all games required DOS. It was *Windows* that didn't have games.
Re: (Score:3)
*Microsoft* had games. Almost all games required DOS. It was *Windows* that didn't have games.
No, I was talking about DOS and Windows titles combined, and counting stuff like BASIC games that came with DOS. Microsoft themselves had barely published any games before Windows. It was a PITA to do well, and Microsoft was too busy making a shitty OS to make a good game.
Re: (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
If you're going to try to show me up, do it right [wikipedia.org]. Now count the number of titles, and then compare to what I said...
Re:And also (Score:5, Interesting)
DOS ain't done 'till Lotus won't run.
I consider this an unproven and frankly crazy conspiracy theory.
First of all, DOS is not that large (by modern standards) and if there was any secret stuff in there that would have sabotaged Lotus 1-2-3, someone would have found it by now. Someone in the FreeDOS [freedos.org] community, reverse-engineering what DOS does to make sure FreeDOS is compatible, would have said "huh, that's weird, what's this for?"
Second of all, I spent a few years working at Microsoft and I never saw any evidence there of any secret stuff to help me do my job or to prevent other companies from being able to do their job.
Now, obviously, I wasn't on a first-name basis with Bill Gates or any of the other top guys, so you can choose to believe that there was a cabal and I wasn't in it. But IMHO Occam's Razor tells me that the simplest answer is that there was no conspiracy.
At the time I worked for Microsoft it was a popular topic in news discussions. Someone described the separation between Microsoft "systems" people and Microsoft "apps" people as a Chinese Wall [wikipedia.org]. I remember discussion of the fact that Microsoft Word ran much better on Macintosh than any other word processor of the day, and someone on the Word team sarcastically remarked "I guess there's no Chinese Wall between Apple's Mac OS team and the Microsoft Word team."
Another reason I regard this as a conspiracy theory is that I am 100% certain that another conspiracy theory is false. There is a theory that Microsoft never believed in OS/2 and planned for it to fail, and tricked IBM into believing in OS/2. I was there at the relevant time. I had two desktops, one running DOS/Windows and one running OS/2. The Microsoft Library used OS/2 computers for their catalog system. I went to internal lectures on the bright future of OS/2.
But everyone was shocked when Windows 3.0 was released and the customers bought it. And then Microsoft made the decision: our customers are voting with their wallets for Windows, let's listen to the customers.
Note that current versions of Windows run on the "Windows NT" code base, and that is an OS kernel with a Windows-flavored userland running on it. In the early days there was also an OS/2 flavored userland running on it. But after the "divorce" where IBM and Microsoft parted ways, Microsoft bet heavily on Windows and no longer maintained the OS/2 compatibility in NT; and of course IBM poured resources into OS/2.
IMHO the biggest mistake that IBM made was insisting on OS/2 being incompatible with Windows. Microsoft had a compatibility layer (similar to WINE) but it was complicated because there were so many differences. Because the differences were so severe, most companies didn't bother to write apps for both Windows and OS/2. If it had been easier to support both, OS/2 would have been more successful.
The real reason why Microsoft prospered and Lotus failed was that it was a pain to support both Windows and OS/2. Lotus put all its chips on OS/2 and that was the wrong bet. Microsoft covered all the bets, supporting Mac, Windows, and OS/2. The "Windows" bets paid off big for Microsoft and the rest is history.
Re:And also (Score:5, Interesting)
IMHO the biggest mistake that IBM made was insisting on OS/2 being incompatible with Windows. Microsoft had a compatibility layer (similar to WINE) but it was complicated because there were so many differences. Because the differences were so severe, most companies didn't bother to write apps for both Windows and OS/2. If it had been easier to support both, OS/2 would have been more successful.
Having worked with both OS/2 (1.3EE and 2.0) as well as Windows (3.x) at the time, I thought that OS/2 2.0's "better DOS than DOS and better Windows than Windows" functionality is what ultimately doomed it. Writing for Windows guaranteed that your application would run equally well on both platforms, negating the need to write a separate OS/2 version. OS/2 was an amazing operating system, but the bespoke software just wasn't there for it. By the time MS introduced NT (and later 95), there was just not much of a business case for going with IBM unless you needed the mainframe support that Communications Manager/2 provided.
Re: (Score:2)
IMHO the biggest mistake that IBM made was insisting on OS/2 being incompatible with Windows. Microsoft had a compatibility layer (similar to WINE) but it was complicated because there were so many differences. Because the differences were so severe, most companies didn't bother to write apps for both Windows and OS/2. If it had been easier to support both, OS/2 would have been more successful.
Having worked with both OS/2 (1.3EE and 2.0) as well as Windows (3.x) at the time, I thought that OS/2 2.0's "better DOS than DOS and better Windows than Windows" functionality is what ultimately doomed it. Writing for Windows guaranteed that your application would run equally well on both platforms, negating the need to write a separate OS/2 version. OS/2 was an amazing operating system, but the bespoke software just wasn't there for it. By the time MS introduced NT (and later 95), there was just not much of a business case for going with IBM unless you needed the mainframe support that Communications Manager/2 provided.
I have to second this as also worked with both OS/2 and Win 3.x in business environments. One huge advantage that OS/2 had was reliable multi-tasking which blew away what Windows was able to do at the time.
Re: (Score:3)
In 1998, the desktop application that I worked on finally migrated from 16-bit to 32-bit Windows. Windows 95 had been out for three years, and Windows NT even longer. One customer called in a panic because they ran OS/2, and it's Windows compatibility was 16-bit only. She asked what are your other clients who use OS/2 doing to make this work. I said "I'm not sure that we have any other clients using OS/2."
Re:And also (Score:4, Insightful)
Writing for Windows guaranteed that your application would run equally well on both platforms, negating the need to write a separate OS/2 version.
But my point is that it was needlessly difficult to make a separate OS/2 version. You shouldn't have had to work hard to build a native OS/2 app.
I never learned all the details, but one specific example is easy to remember: Windows and OS/2 used totally different graphics coordinate systems. IIRC Windows started counting pixels from the lower left corner, and OS/2 started counting pixels from the upper-left corner. IBM thought their way had some sort of technical merit (I think it was compatible with some now-forgotten product they used to sell).
It meant that WLO ("Windows Libraries for OS/2", the WINE-like compatibility layer) was heavyweight and slowed an app down. And only Microsoft had WLO anyway, they never released it as a developer tool for anyone else to use.
IIRC the Excel team had refactored Excel and were able to build lean native versions for Mac, Windows, and OS/2. But Word for OS/2 Presentation Manager was just Word for Windows, compiled with WLO. (Microsoft had had a project to rewrite Word to be refactored like Excel, and it didn't go well and they decided there wasn't sufficient benefit to make it worth the effort.)
Linux isn't the same as other UNIX versions, but it's overall very close. If you wanted to write an app to sell on multiple flavors of UNIX, it wouldn't take a heavyweight WINE-like library, just a few compatibility shims and a recompile. OS/2 should have been like that for Windows.
Because OS/2 could run Windows apps, and it was a real pain to make an app you could build on both Windows and OS/2, almost nobody bothered to support OS/2. That's what I consider IBM's biggest mistake with OS/2.
Re: (Score:2)
DOS ain't done 'till Lotus won't run.
I consider this an unproven and frankly crazy conspiracy theory.
Slashdot ran an entire story on this quote: https://slashdot.org/story/05/... [slashdot.org]
Re:And also (Score:4, Interesting)
I remember reading somewhere that the issues Lotus had were due to making use of undocumented DOS APIs that changed, and BIOS calls that didn't work as expected when DOS made changes to the state of the system.
The Lotus people were convinced that the secret APIs were there to make Microsoft products perform better, and also to deal better with the awkward way memory worked under DOS. The encountered similar problems with other operating systems, like DOS Plus and DR DOS.
Re: (Score:3)
The Lotus people were convinced that the secret APIs were there to make Microsoft products perform better,
Microsoft applications including parts of Office have on occasion used APIs on Windows which were not documented, and the documented APIs literally were just wrappers around other functions which had timer loops added to them to slow them down. What we don't know for sure is whether that was done just because Windows sucks, or maliciously. To wit, maybe Office apps using those undocumented APIs added delays internally, based on knowing when they are or aren't necessary. But given that they're simple timers,
Re:And also (Score:5, Interesting)
Interesting, are the delay loops documented anywhere?
I remember people complained that Explorer add-ons from non-Microsoft sources were slower. Turns out the reason was that Explorer was testing their APIs, calling the function to see if it would crash, and if it did calling the API again with compatibility hacks enabled. The reason the context menu took seconds to open is because the add-ons were crashing and being reloaded a few times until they worked.
Re: (Score:2)
this might be a good starting point [alphr.com] for keywords and such
Re: (Score:2)
Thanks. I'm always a bit sceptical of things said in court like that. 800 hidden APIs? At the time Windows didn't have 800 APIs total. Maybe they meant 800 hidden functions, but even then, how many were private OS functions that were never meant for userland, and how many were just hidden to give Microsoft apps an edge?
Re: (Score:2)
Show me the disassembled delay loops. The burden of proof is on you, you made the claim. Don't tell me to find it myself, that's not my job here!
I don't work for you, coward. I posted a link to help with searching for them. We discussed them here on Slashdot previously. If you weren't here, that's not my problem.
Re: (Score:2)
Andrew Schulman disagreed in 1993. I believed him then and I believe him now.
https://en.wikipedia.org/wiki/... [wikipedia.org]
I was a Dr Dobbs subscriber back then, so I read the original article on paper. Wikipedia's link is to the Wayback Machine.
Re: (Score:2)
DOS ain't done 'till Lotus won't run.
That myth was debunked long ago [slashdot.org], back in 2005. In any case the job of the operating system is to run programs so if a program won't run and you can't modify the program then modifying the OS makes sense.
Re: (Score:2)
DOS ain't done 'till Lotus won't run.
I ran Lotus 123 on DOS 'back in the day' and didn't have any problems...
Re: (Score:1)
And yes, I realize
Not just Microsoft, but GPU Vendors also (Score:5, Interesting)
The largest part of GPU driver installs over the years has been bug fixes and/or improvements for specific games.
I can speak of a specific example of a GPU driver bug-fix, because I am the coder responsible for such a bug in Microsoft's Age of Empires (1997)
During the game's development in 1996 and 1997, we did not yet have 3D cards with 2D functionality (the stand alone Voodoo 1 card existed). Instead we were using 2D cards with 512K to 2MB of VRAM, capable of generating frame buffers up to 1280x1024 with 8-bit indexed color. These were VESA era cards, many of which used bank switching of 64K windows into the onboard VRAM.
Microsoft's DirectDraw API did for Windows 95 what UniVBE basically did for DOS games of the era - presented VRAM as a linear frame buffer that worked on (most) all video cards, and did any bank-switching needed behind the scenes by trapping the CPU fault when you wrote to a VRAM address that wasn't currently mapped to the card, and switching the address remapping and GPU VRAM bank transparently before resuming your code.
Using the DirectDraw API you had to issue a Lock() command to get access to the VRAM, and then Unlock() it when you were done copying pixels to it, so that it could do things like present the current frame, or next frame if you were double buffering, or execute a blit, which may or may not involve support hardware on the video card. The Unlock command would invalidate the mapped memory region to the GPU.
In one spot in the code of Age of Empires, I forgot to call Unlock(). On all the 2D cards in 1997.. it didn't matter. You could still write to the video card buffer and it was ok. Once we started getting GPUs with 3D and more VRAM like the nVidia GeForce 256 and ATI Radeon 9600, which also meant newer version of Direct3D (DriectX), etc, the code in Age of Empires would crash the game.
Both nVidia and ATI put code in their drivers to specifically detect that that game, and fix the problem so that the game ran, despite being a "bad citizen" and not calling Unlock(). This was keyed, at least in part, off the .exe filename. If you renamed empires.exe to expires1.exe (or anything else), the game would crash as soon as you attempted to start a game.
Re: (Score:3)
I didn't realise how far back this went. For anyone who has ever read a GPU driver release note (which is likely nobody) it would come as no surprise that they implement workarounds for specific games. Just having a quick look at Release 517.48 and you see they have game / software specific fixes for:
- [DirectX 12] Microsoft Flight Simulator may display texture corruption after extended gameplay [3762763]
- [Jurassic World Evolution 2] Game may display shadow flickering [3682201]
- [Fusion 360] Addresses perf
Re: (Score:2)
I didn't realise how far back this went. For anyone who has ever read a GPU driver release note (which is likely nobody) it would come as no surprise that they implement workarounds for specific games. Just having a quick look at Release 517.48 and you see they have game / software specific fixes for:
- [DirectX 12] Microsoft Flight Simulator may display texture corruption after extended gameplay [3762763]
- [Jurassic World Evolution 2] Game may display shadow flickering [3682201]
- [Fusion 360] Addresses performance issues when using variable refresh rate monitors [3724711]
- [Adobe Photoshop] Resolves random crashes in DirectML.dll [3749935]
- [Adobe Illustrator] Using Reduce Noise with Ray Tracing appears pixelated [3709309]
How much of the above is due to the software not working properly and how much is actually a bug in the driver code?
I would rather that the driver makers name and shame software makers so that they don't have to keep on maintaining bug fixes/workarounds for various software on an ongoing basis. That will just bloat the drivers over time with workarounds for 100s or even 1000s of applications being tracked over the years.
Re: (Score:2)
Re: (Score:2)
How much of the above is due to the software not working properly and how much is actually a bug in the driver code?
Given how NVIDIA / AMD actually has engineers assisting in the optimisation for individual games with individual studios and their engines I'm willing to say that the issue isn't so much the driver as much as it is the complexity of what is being done. The closer to hardware and more optimised you are, the more likely it is you identify some edge case which isn't as much a "bug" in the driver as much as it wasn't a consideration in the first place.
Re: (Score:2)
This is why Intel's new GPUs are having severe quality issues. They have made a decision to only support DX12 games, and if anything older works then it's just luck. But even DX12 stuff has issues because they don't have years of hot fixes for all those bugs.
Re: (Score:2)
They should just implement Vulkan (I'd hope and even assume they do already, it would be ridiculous not to) and use DXVK to provide compatibility [reddit.com] with older DirectX versions. DXVK could always use more contributions anyway :)
let me get this straight... (Score:3)
Microsoft added special cases to change its OS behavior (to an arguably incorrect behavior) to accommodate application bugs? No wonder Windows 95 and later are so full of so much bad (and vulnerable!) code... Isn't supporting an application that reads memory after it's freed adding an explicitly exploitable vulnerability?
Re: (Score:2)
No wonder Windows 95 and later are so full of so much bad (and vulnerable!) code... Isn't supporting an application that reads memory after it's freed adding an explicitly exploitable vulnerability?
Only if you are that application. And I've yet to hear of an exploit pretending to be another application just to make use of a bug that said application was worked around in the OS.
Re: (Score:2)
Isn't supporting an application that reads memory after it's freed adding an explicitly exploitable vulnerability?
The workaround is to not free that memory right away.
Re: (Score:2)
It was a very different time. Windows 95 didn't even install the TCP/IP stack by default, it was an optional extra. As was Internet Explorer 1.0.
The filesystem was FAT32, which didn't have any support for users or security. Viruses could just overwrite system files with nothing to stop them. There really wasn't any need for exploits because there was no security - every app ran as root, no privileges to escalate.
To be fair, most desktop computers of the day were the same. They either ran DOS/Windows 3.11, M
Re: (Score:2)
I used MuFS on my Amiga, you permissionless clod! I had filesystem permissions. What I didn't have was a MMU, alas. Users who had them could use them, but I wasn't one of them.
What's the use of filesystem permissions if you don't have an MMU, you ask? None really, but it was amusing.
Re: (Score:2)
I did have an MMU in my Amiga back in the day. It was useful for things like Enforcer, but Enforcer itself was somewhat limited in terms of how much security it could provide.
AmigaOS itself had a basic issue that made security tricky. The standard way that data was passed between tasks was to allocate some memory and then tell the other task to read it. I'm not sure how they solved it in Amiga OS 4, I've never used it.
No surprise there (Score:3)
No way I'm finding a story with Slashdot's basic search function but when the Windows XP partial (not the recent 2020 case, but the one well over a decade ago) source code leak happened, analysis showed a significant amount of application specific code in Windows for compatibility reasons. This was discussed a lot here at the time but I can't for the life of me find the story.
Wait, what? A Use-After-Free? (Score:2)
Did he just say he freaking left a use-after-free bug, and Microsoft coddled it?
Re: (Score:2)
All a Matter of Priorities : ) (Score:2)
Reverse MS Bug... (Score:2, Interesting)
Back in the 90s, I worked QA for a what was briefly a powerhouse edutainment (yeah, that word) software company.
I found a memory leak bug in one of our games that turned out to be a Windows 95 memory leak. I don't recall if the devs created a work around, or if MS eventually fixed it. I almost feel like MS fixed it, but I was just more happy I found a bug in Win95 than anything, so I never really remembered the details.
Re: (Score:2)
but I was just more happy I found a bug in Win95 than anything
That's kind of a cool feeling, isn't it? I found a bug in Visual C++ many years ago where the generated assembly code was not correct, and reported it to MS. I never heard back about it, but the next version didn't exhibit the problem. :-)
'95 still DOS under the hood (Score:2)
Re: (Score:3)
In Windows 95 and 98 alike, DOS either is or isn't used after Windows is loaded based on whether you are in 16 bit mode or not, which is controlled by whether you have or haven't loaded any device drivers in DOS before starting Windows. In normal operation there are no BIOS calls being made, and DOS is mostly removed from memory. There is no significant difference between Windows 95 and 98 in this regard.
maybe not the only reason (Score:5, Insightful)
"...That's the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95."
That, and the fact that it fit on a few floppies and had no copy protection or even serial check that mattered.
That one purchased copy ended up on 35 other systems ENSURED that win95 crushed os2, the only extant alternative (that was actually better).
Microsoft is the dominant ecosystem because of piracy, not in spite of it.
Re: (Score:2)
That one purchased copy ended up on 35 other systems ENSURED that win95 crushed os2, the only extant alternative (that was actually better).
OS/2 was better, although it had inexplicable mouse button config out of the box for no apparent reason other than to make the system behave slightly differently from literally everything else. You could trivially change it, but... why?
But OS/2 was also expensive, and while I don't remember there being anything like copy protection I do remember that if you wanted to run software that actually existed, you basically had to install Windows inside of it... and not only did OS/2 have substantially higher syste
Re: (Score:2)
I know it's a MS site so I'd believe it too, but I'd swear I sneaker-netted that with a hardcase box for my 1.44m floppies and that didn't hold more than 10.
But yeah, 13 is more than I remember but still not much compared to OS2. Even Monkey Island was like...6 3.5" disks?
Data Point: This is a needle in a needlestack (Score:5, Interesting)
A very small part of my work as a Microsoft DSE is helping customers get their old applications running on new versions of Windows. Our Windows ADK contains the Application Compatibility toolkit that gives you visibility into the thousands of applications like SimCity that have appcompat shims built into the OS still to this day.
Interesting trivia: The most common appcompat shim is, by a very wide margin, lying to the application about what version of Windows it's running on. So many apps check for version == instead of >=. It's a little sad. I'm not complaining though; Those are easy wins and I enjoy being able knocking them out. ;)
Re: (Score:3)
~15 years later: "We just shipped Windows 8, so the next version... oh shit..."
Re: (Score:2)
Windows 8 was version 6.2, so they had plenty of runway.
They made Windows 10 version 10.0 anyway. They also made Windows 11 version 10.0
Re: (Score:2)
The most common appcompat shim is, by a very wide margin, lying to the application about what version of Windows it's running on.
That makes me wonder how much of the success of changing to different windows compatibility modes is just the version reported to applications.
Re: (Score:2)
It's a lot. The modes built-in to the program compatibility assistant include several other fixes, but VersionLie is a big one. In my experience, at least 25%. There was a great blog post that documented them but it's 404'd.
Future me is going to kick myself for not saving that off to a pdf. :(
Re: (Score:2)
There was a great blog post that documented them but it's 404'd. :(
Future me is going to kick myself for not saving that off to a pdf.
Pardon if you have, but have you tried the internet archive yet? I am often surprised by how good it is these days.
I heard they did the same for Doom (Score:2)
Diablo (Score:2)
The only reason that anyone I knew moved to 95 was it was a requirement for Diablo . . . who knew?
Re: (Score:2)
The first time change after Windows 95 came out happened during a LAN party in the garage of the geek house I was living in at the time. I forget whether we were playing Descent or Doom at the time (we played both games that evening) but I do remember all the Windows 95 systems simultaneously announcing they were rebooting to cope with the time change. Hilarity ensued.
There used to be another blog post about this... (Score:1)
... I can't find it now. If someone can pull it up that would be smashing.
Apparently (and approximately), there was a program that was using an error code returned from a DOS system call as a file handle (may have been 1, standard output), but it worked because the error code was 1. In Windows NT, a different error code was returned, so NT detected that this program was running and returned error code 1.
Patching for crappy coding practices (Score:2)
Jesus H. Microsoft hacked their code to support a product with shitty programming practices?! Makes you wonder what else is effed up in the OS. How about this: Microsoft intentionally didn't patch security holes so Norton, McAfee, et al would still be in business.