I prefer qemu for its performance. But there may be better alternatives.

There were tools for Windows 95 or 98 you could run in the background that issued an HLT instruction if the system is idle. Try searching for "rain" or "waterfall" if you experience that qemu uses 100% of a core while the guest is idle.

Windows 98 does support ACPI and HLT. At least when installing in VirtualBox, setup must be run manually through DOS with special parameter as support is not recognized by default.

I think it's: setup /P J

If I'm not misremembering. Not sure about performance, but I thought not using HLT just wastes power.

What is "before XP"? Windows NT has always used HLT.

If Windows 98 uses APM or uses no power managment at all, then the CPU load might be high.
Re: Windows 98SE install problem

Anyway, there had been third-party solutions for Windows 3.x/9x and DOS.
For Windows 3.1x there's WQGHLT (by Weiqi Gao), for Windows 98 there's amnhltm, Raine etc. For DOS, there's DOSIdle.

MS-DOS 6.22 also has power.exe, which uses energy savings.
In principle, power saving support exist since 386SXL. Some NEC CPUs had it, too.

Thanks for all replies, now I know that it is possible to enable HLT support even before XP.

Here are instructions to enable HLT in windows 2000.

Making Windows 2000 issue the HLT instruction when idling requires modifying the OS's idle loop behavior. Here's how you can approach this:

Background:
The HLT instruction halts the CPU until an interrupt occurs, reducing power consumption.
Windows 2000's idle loop is handled by the kernel (ntoskrnl.exe).
By default, Windows 2000 may use a busy-wait loop or HLT depending on HAL (Hardware Abstraction Layer) and power management settings.
Methods to Enable HLT:
1. Registry Tweak (Preferred Method)
Windows 2000 has a registry setting that can force the use of HLT:

Open regedit.exe.
Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
Create or modify a DWORD value named Hiberboot and set it to 1.

According to Raymond Chen, a Microsoft Employee, Windows 95 didn't use HLT because of some incompatible hardware, see the posts on his blog "The Old New Thing" titled Hardware backwards compatibility and Why didn’t Windows 95 simply special-case the laptops that locked up when it executed the HLT instruction?.

English Wikipedia claims that Windows NT already used HLT: https://en.wikipedia.org/wiki/HLT_(x86_instruction): In Windows NT, for example, this instruction is run in the "System Idle Process".

spoony1971 wrote on Today, 00:34:

Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
Create or modify a DWORD value named Hiberboot and set it to 1.

The registry patching instruction you quote is an AI hallucination. The setting quoted there is not connected the the HLT instruction at all, but instead that setting is related to the "fast boot" feature introduced with Windows Vista or Windows 7, which replaces the traditional "shut down" and "boot up" procedures by "suspend (the OS after killing all user tasks) to disk" and "resume the OS from disk and then start up fresh user tasks". ("Hibernation" instead of "boot", thus the name).

Linux 2.0/2.2 also have a test of whether HLT works, and the source code blames it on "Problems on some 486Dx4's and old 386's" -- could the association with laptops actually be a 486DX4 erratum?
One comment on the second Old New Thing blog post suggests that OS/2 hit this issue first.

jakethompson1 wrote on Today, 18:42:

Linux 2.0/2.2 also have a test of whether HLT works,

"test" is a pretty strong name for that routine. Yeah, IIRC the message printed at that point is actually "Testing wheter the HLT instructions works: OK", but what actually happens is that HLT is issued repeatedly for a couple of times (possibly 4 times), and the one that is actually to handle test failures is not the kernel, but the user, who had a system that crashed at that point (without "OK" being printed to the screen). The user than had to start corrective action by adding "no-hlt" to the kernel command line. In that case, the kernel wouldn't use HLT, and obviously, it also wouldn't perform the test whether the machine crashes on a series of HLT instructions.

mkarcher wrote on Today, 19:06:

jakethompson1 wrote on Today, 18:42:

Linux 2.0/2.2 also have a test of whether HLT works,

"test" is a pretty strong name for that routine. Yeah, IIRC the message printed at that point is actually "Testing wheter the HLT instructions works: OK", but what actually happens is that HLT is issued repeatedly for a couple of times (possibly 4 times), and the one that is actually to handle test failures is not the kernel, but the user, who had a system that crashed at that point (without "OK" being printed to the screen). The user than had to start corrective action by adding "no-hlt" to the kernel command line. In that case, the kernel wouldn't use HLT, and obviously, it also wouldn't perform the test whether the machine crashes on a series of HLT instructions.

Fair, but par for the course for the time anyway. Like the Windows 95 setup ISA hardware probe, which as someone in the blog comments pointed out, could have also been used as an opportunity to check whether HLT works.

jakethompson1 wrote on 26 minutes ago:

Fair, but par for the course for the time anyway. Like the Windows 95 setup ISA hardware probe, which as someone in the blog comments pointed out, could have also been used as an opportunity to check whether HLT works.

The Windows 95 ISA probe is actually doing the stuff correctly (albeit quite slow, as a consequence, due to all the synchronized hard disk writes). I agree, HLT testing could have been added to it.

I just experienced the counter-example with the Creative Plug&Play manager. I installed a SB32 PnP into a 486 system with an Adaptec 1542C SCSI controller for the boot drive, in its default configuration. The Plug and Play manager setup utitlity then had a screen similar to the Windows 95 message like "your system might crash now, if it does, please reboot and try again" or something like that. And the system did crash indeed, so I rebooted (using the reset button). Actually, I wasn't that surprised and was quite confident I already knew what was happening. After pressing reset, DOS executed config.sys which already had DEVICE=C:\CTCM\CTCM.SYS added to it, which printed a message like "5 out of 5 Creative Plug & Play devices configured", and then DOS was complaining about COUNTRY.SYS missing and CONFIG.SYS being corrupt, then the system locked up. The computer responded to Ctrl-Alt-Del (yeah, I did try this instead of the reset button knowing very well what was about to happen), but the Adaptec POST now failed ("BIOS NOT intended for this host adapter! BIOS not installed!"). Pressing reset again got me to DOS failing to boot. Luckily, it was DOS 6, so I could use F5/F8/Shift to circumvent CONFIG.SYS and run the Plug & Play Creative Configuration utility to declare that Port 330h is in use by the SCSI controller, but the experience was everything but "just reboot and continue".