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 2025-09-26, 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 2025-09-26, 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 2025-09-26, 19:06:

jakethompson1 wrote on 2025-09-26, 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 2025-09-26, 20:08:

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".

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

Indeed, that's why I like DOS 6.2x so much. It has those small things that make life easier. ^^

Btw, if memory serves, in the DOS 3.x days it was already possible to use Control-C to interrupt processing of start-up files (or batch files in general).
But it required BREAK=ON in config.sys, I vaguely remember.

Jo22 wrote on Yesterday, 07:41:

Btw, if memory serves, in the DOS 3.x days it was already possible to use Control-C to interrupt processing of start-up files (or batch files in general).
But it required BREAK=ON in config.sys, I vaguely remember.

BREAK=ON and the handling of Ctrl-C is an interesting topic in itself. The basic idea of Ctrl-C is obviously to cancel the current task (i.e. DOS program), but to do it at a point in time that is "safe" (for some definition of safe). DOS doesn't use any interrupt-driven mechanism to detect Ctrl-C, but at "some convenient time", it asks the BIOS whether the first character in the keybaord buffer is Ctrl-C. This means Ctrl-C will have no effect if there are unhandled keypresses before in the BIOS keyboard buffer. That's actually where Ctrl-Brk comes in handy: If you push Ctrl-Brk, the BIOS keyboard interrupt handler clears all unconsumed input and triggers Int 1B, which is intended to be hooked by the operating system. Either the BIOS by itself or the DOS Int 1B handler (if there is one) will then place a Ctrl-C event into the keyboard buffer, so it will be seen by DOS at the next "convenient time". The setting BREAK influences what time DOS considers a convenient time to cancel a program. By default (BREAK OFF), programs may only be cancelled when the try to read data from the keyboard or (IIRC) print to the screen (using DOS functions). This ensures you can't interrupt a program while it is updating a file (unless it prints progress messages), so file integrity is kind-of guaranteed even if someone presses Ctrl-C.

On the other hand, this means, you can not cancel long-running file operations, which may be inconvenient. That's why DOS offers the more aggressive choice (BREAK ON) to not only cancel during console I/O, but also during file I/O.

Whenever a program executed from a batch file is cancelled using Ctrl-C (or Ctrl-Brk, which uses the same canellation path in the end), COMMAND.COM (responsible for handling batch files) will ask the user whether the batch file should continue executing the next command after the cancelled program, or whether the batch execution should be terminated. This is what you are referring to. To make use of this feature to prevent a "bad" startup process from locking up your system, you would need to Issue Ctrl-Brk (or Ctrl-C) before the last convenient point in time before the "bad operation". A tool like CTCM prints a banner message before trying to configure plug-and-play cards, so it could actually work (even with BREAK OFF, if I remember correctly that BREAK OFF still allows breaking on screen output) - if CTCM.EXE were called from AUTOEXEC.BAT to configure PnP cards. Actually, it isn't, instead, it is loaded from CONFIG.SYS for this purpose, and the BREAK mechanism doesn't apply while loading device drivers, I think. At least, as COMMAND.COM isn't involved in parsing CONFIG.SYS, you will not get a message like "terminate batch file (Y/N)" if you interrupt a previous process.