Context: Win98 doesn't do anything with CPUs that support the HLT instruction, so even when the emulated cpu could be idle it's using 100% of your cpu.
This is a nice clarification story why there was no HLT in the idle loop of Win95/98, but it doesn't really explain why there wasn't an option to enable HTL as an advanced feature by modifying the registry. This is especially true if the HTL-related freezes were mostly a laptop problem. There were many strange options to customize Win9X by altering values in the registry, but not this one.
Like most stories from Raymond there is quite a lot of exaggeration. I really cannot imagine any hardware that would "lock itself unrecoverably" after running a HLT, mostly because such hardware would have burn even harder if you disabled interrupts and entered a infinite loop, which would have been likely an almost once per year event for most users running random programs.
In addition, MS was quite happy to ship advanced but dangerous features to customers only hidden behind user-accessible plain checkboxes. One example that comes to mind is the "DMA" checkbox in the IDE controller settings page. Guaranteed to corrupt your data and render your system unbootable on certain hardware (likely a worse scenario than anything HLT could potentially do to you), and at most you get a warning box claiming this may happen when you enable the checkbox.
Most likely, MS knew it was trivial (due to the design of DOS-based 9x/ME) for a 3rd party to ship either a utility or even a BIOS addition to do HLT-on-idle (and in fact, most laptops would do so in their APM BIOSes), so the problem didn't appear to them to be significant at all (and, frankly, really wasn't a significant problem at all). Not so much for e.g. DMA which would require a new driver replacement.
I remember when experimenting with win98 emulation ~ 10, 15 years ago that this nearly made the vm useless. windows just sitting there busy waiting. I did find a patch that somehow added a HLT state to the kernel. If I remember correctly the patch or driver or whatever it was came off some sketchy Russian site. so probably safe, a labor of love from some brilliant low level programmer who just wanted w98 to emulate well. but I always worried about it.
...and when you install Rain (or similar tools like Waterfall or CPUIdle) on Windows 95/98, counterintuitively, the Task Manager will show permanent 100% CPU usage, even though the CPU is actually idling and running cooler.
For me, the fact that Windows 95/98 can't use the HLT instruction is a reason why I wouldn't use these legacy operating systems to run older software. Not that many programs ran on Win95/98 but not on Win2000. Perhaps except for DOS games, which are better served by DOSBox.
Context: Win98 doesn't do anything with CPUs that support the HLT instruction, so even when the emulated cpu could be idle it's using 100% of your cpu.
And the story of why HLT was backed out :) Microsoft had no trouble adding it -- even in Windows 95, but... https://devblogs.microsoft.com/oldnewthing/20030828-00/?p=42...
This is a nice clarification story why there was no HLT in the idle loop of Win95/98, but it doesn't really explain why there wasn't an option to enable HTL as an advanced feature by modifying the registry. This is especially true if the HTL-related freezes were mostly a laptop problem. There were many strange options to customize Win9X by altering values in the registry, but not this one.
I don't understand why you wouldn't have a hardware whitelist, and a way for new hardware to opt in.
Like most stories from Raymond there is quite a lot of exaggeration. I really cannot imagine any hardware that would "lock itself unrecoverably" after running a HLT, mostly because such hardware would have burn even harder if you disabled interrupts and entered a infinite loop, which would have been likely an almost once per year event for most users running random programs.
In addition, MS was quite happy to ship advanced but dangerous features to customers only hidden behind user-accessible plain checkboxes. One example that comes to mind is the "DMA" checkbox in the IDE controller settings page. Guaranteed to corrupt your data and render your system unbootable on certain hardware (likely a worse scenario than anything HLT could potentially do to you), and at most you get a warning box claiming this may happen when you enable the checkbox.
Most likely, MS knew it was trivial (due to the design of DOS-based 9x/ME) for a 3rd party to ship either a utility or even a BIOS addition to do HLT-on-idle (and in fact, most laptops would do so in their APM BIOSes), so the problem didn't appear to them to be significant at all (and, frankly, really wasn't a significant problem at all). Not so much for e.g. DMA which would require a new driver replacement.
I remember when experimenting with win98 emulation ~ 10, 15 years ago that this nearly made the vm useless. windows just sitting there busy waiting. I did find a patch that somehow added a HLT state to the kernel. If I remember correctly the patch or driver or whatever it was came off some sketchy Russian site. so probably safe, a labor of love from some brilliant low level programmer who just wanted w98 to emulate well. but I always worried about it.
No reason not to tяust some sketchy Soviet^WRussian web site comrade
...and when you install Rain (or similar tools like Waterfall or CPUIdle) on Windows 95/98, counterintuitively, the Task Manager will show permanent 100% CPU usage, even though the CPU is actually idling and running cooler.
For me, the fact that Windows 95/98 can't use the HLT instruction is a reason why I wouldn't use these legacy operating systems to run older software. Not that many programs ran on Win95/98 but not on Win2000. Perhaps except for DOS games, which are better served by DOSBox.