Conflicts between Windows 9x versions and the "modern" hardware of each era run much deeper than we imagine. Even when manufacturers insisted their products were optimized for Redmond's operating systems, users faced cryptic and frustrating errors. These errors became more frequent as processors gained speed, and today these systems are very difficult to run, with or without a virtualizer. Michal Necasek from the OS/2 Museum decided to find out why...
If you search for images of old AMD K6-2 processors, you'll notice a peculiar detail: the Windows 95 logo appears etched onto the heat spreader. That's supposed to be a guarantee of compatibility, proof that these chips work flawlessly with Microsoft's operating system. Well, let's just say "guarantee" and "proof" are optimistic expressions. Windows Protection Errors were intermittent on a 350 MHz K6-2, and semi-permanent on faster models.
A heated dispute between AMD and Microsoft
The most absurd part is that Microsoft and AMD nearly went to war over it: Redmond wanted to charge 35 additional dollars for the "hotfix" (although the real goal was to get users to adopt Windows 98), and AMD responded by publishing its own patch, free of charge. Intel processors initially showed some resistance, but later suffered similar problems: Windows 9x versions crashed with processors that were "too fast".
https://old.neoteo.com/mover-el-cursor-en-windows-95-lo-hacia-mas-rapido/The OS/2 Museum investigation
And so we arrive at the OS/2 Museum portal, where Michal Necasek received a message from an acquaintance announcing that Windows 3.11 for Workgroups no longer worked on virtual machines. The first steps of his investigation revealed that one of the main factors triggering the error is the processor. A Core i7-2600 triggered it rarely, but with a Ryzen 7 3800X it became constant: Michal typed "win", the Windows logo appeared... and back to DOS.
The rest of the entry is worthy of Sherlock Holmes. Tracing the debug kernel of 3.11 WFW, he found a division by zero error somewhere in the network section. That "somewhere" turned out to be NDIS.386, with a specific problem: When reading the time with the Get_System_Time command followed by 1,048,576 iterations of LOOP, the maximum precision is one millisecond. If it's faster than that... the beginning and end could be the same, with a difference of zero, which cannot be divided. On a 100 MHz processor or slower this would never be problematic, but on a 350 MHz chip, pure chaos.
In the case of Windows 95, the issue arises again with NDIS.VXD, and similar logic appeared in IOS.VXD, ESDI_506.PDR, and SCSIPORT.PDR. Why did Intel chips seem immune? Essentially due to differences in LOOP execution speed: a 350 MHz K6-2 was six times faster than its Pentium II equivalent. As Santa Clara's chips gained speed, the error became more frequent (e.g., Pentium 4).
The fix that took years
The story continues with Microsoft... being Microsoft. The error was fixed in Windows 98 (first edition) storage drivers, but it remained in NDIS, and the same happened with the patch for Windows 95 OSR2. The NDIS hotfix arrived in 2001 (the year XP debuted) and only for Windows 98, however, the famous Second Edition fixed all these problems from the root.
https://old.neoteo.com/windows-98-online-y-en-tu-navegador/Conclusion
Michal closes his article with a very interesting conclusion: no evaluation would have been able to detect the bug when the code was written. "What happens if LOOP runs in less than a millisecond?" was not something the engineers of the era had high on their priority lists.
And there's also the risk of assuming. The market went from a 66 MHz Pentium to a 350 MHz K6-2 in just five years, dropping the LOOP from 100 milliseconds to less than three. Software developers assumed such a performance leap would not be possible, and hardware developers assumed that speeding up instruction execution is always good.
Access the article: Click here
