Oh, this was very well timed, thank you. Not because I'm installing Windows 98 (over my dead body) but because I'm trying to get a little operating system I wrote in the early 90's to work in Qemu or VirtualBox. And the article contained a nice hint about the emulation hardware.
It is interesting how what worked flawlessly on the hardware of the time is almost impossible to get to work on these emulators, the fidelity is quite low. But bit by bit I'm making progress in figuring out where the differences are and how to work around them. I've got a basic self-hosted development system working now with all of the data in a ram disk. The floppy, keyboard and VGA screen all work, now I need to figure out why the harddrive controller keeps disappearing.
Oh well, the night is young ;)
Thank you for posting this! It really moved the needle in what already was a super long debug session.
It's true that qemu doesn't aim for fidelity. (Despite the name, qemu isn't exactly an emulator!) The development efforts upstream are almost all about getting modern OSes to work well, and quite often the OS is aware that it's running on qemu and adjusts itself - most notably with the installation of virtio drivers, but also in smaller ways. The Linux kernel has over 1000 references to QEMU in its source code.
Also if you look at qemu's device emulation, that's usually "done" when it can run modern operating systems. Qemu doesn't try hard to emulate the entire IDE or SCSI command set in every detail, or every aspect of old hardware.
Another thing is that qemu is not cycle-accurate at all. Instruction and device timings will be wildly different from real hardware, especially if using TCG.
Yes, so I noticed... but: good to put all those old skills to use again. I'm having a lot of fun just struggling, if that makes any sense. And there is progress, I just booted the whole thing for the first time from 'floppy' (an image). The harddrive device driver is still giving me pain but I'm pretty sure I'm very close to making it work. The CHS emulation seems to be broken beyond repair so I'll just move the whole thing to LBA can call it a day.
My development system is a ramdisk right now and that feels a bit scary.
That suggests also that QEmu isn’t the right software when fiddling with raw x86 assembly to write an OS (qemu is the recommendation of oswiki though).
So what is? One would need software supporting debugging. VirtualBox supports that I think, but I don’t know if that works if it runs on top of Hyper-V - which is enabled by default in Windows due to some security features (and I don’t want to disable that anyway).
> That suggests also that QEmu isn’t the right software when fiddling with raw x86 assembly to write an OS (qemu is the recommendation of oswiki though).
It is the right software. It's not even debatable: qemu is the one most used for OS development by an order of magnitude difference or more.
The differences between the different "hardware of the time" are larger than between any of the emulators you mention. This is not consoles where the hardware is exactly the same over and over. PC hardware is mostly poor clones of poor clones of the original under-specified hardware and even software emulators of such clones whose only thought of compatibility amongst each other is "does Windows boot already?" (and most specially in the 98 era) . Go and ask Linux...
In fact, (having worked for quite a while in supporting decades old enterprise software) my experience with most PC virtualizers and emulators is that they're ridiculously accepting of errors that will most definitely trigger random behavior in (at least some) real hardware.
It won't be a great experience, but for MIDI, wouldn't Microsoft GS Wavetable Synth suffice? Doesn't that come with Windows 98? If it's trying to use the nonexistent Ad Lib support, you can probably tell it to use GS Wavetable Synth instead in the MIDI settings?
One really big advantage of DOSBox is that it has Ad Lib emulation. DOSBox is kinda weird and broken when it comes to trying to run Win9x though. It's good when it works at least.
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.
How does Windows 98 work with the fingertouch interface of the iPad? There were some very expensive touchscreen Windows tablets back in the late 90s but they all used a stylus and generally the responsiveness was very slow
In one video I've seen UTM used mouse emulation without absolute positioning: it treated the screen surface as a giant trackpoint nub and you could move away from the current location with variable speed. A native on-screen keyboard is also available.
Why would it handle any differently than a trackpad?
Most non-multitouch touchscreen devices emulate a mouse if there is not a more specific driver available. Trackpads were widely available on laptops at the time and you could jump to any point on the screen with those.
You can click but don't expect any gestures to work.
Anybody got a qcow image laying around with Windows 98 working in virt-manager? I've managed to get a 98lite install "working", but it's got some issues. The sound with AC97 is hit or miss and sb16 doesn't seem to be an option in virt-manager.
Oh, this was very well timed, thank you. Not because I'm installing Windows 98 (over my dead body) but because I'm trying to get a little operating system I wrote in the early 90's to work in Qemu or VirtualBox. And the article contained a nice hint about the emulation hardware.
It is interesting how what worked flawlessly on the hardware of the time is almost impossible to get to work on these emulators, the fidelity is quite low. But bit by bit I'm making progress in figuring out where the differences are and how to work around them. I've got a basic self-hosted development system working now with all of the data in a ram disk. The floppy, keyboard and VGA screen all work, now I need to figure out why the harddrive controller keeps disappearing.
Oh well, the night is young ;)
Thank you for posting this! It really moved the needle in what already was a super long debug session.
It's true that qemu doesn't aim for fidelity. (Despite the name, qemu isn't exactly an emulator!) The development efforts upstream are almost all about getting modern OSes to work well, and quite often the OS is aware that it's running on qemu and adjusts itself - most notably with the installation of virtio drivers, but also in smaller ways. The Linux kernel has over 1000 references to QEMU in its source code.
Also if you look at qemu's device emulation, that's usually "done" when it can run modern operating systems. Qemu doesn't try hard to emulate the entire IDE or SCSI command set in every detail, or every aspect of old hardware.
Another thing is that qemu is not cycle-accurate at all. Instruction and device timings will be wildly different from real hardware, especially if using TCG.
Yes, so I noticed... but: good to put all those old skills to use again. I'm having a lot of fun just struggling, if that makes any sense. And there is progress, I just booted the whole thing for the first time from 'floppy' (an image). The harddrive device driver is still giving me pain but I'm pretty sure I'm very close to making it work. The CHS emulation seems to be broken beyond repair so I'll just move the whole thing to LBA can call it a day.
My development system is a ramdisk right now and that feels a bit scary.
That suggests also that QEmu isn’t the right software when fiddling with raw x86 assembly to write an OS (qemu is the recommendation of oswiki though).
So what is? One would need software supporting debugging. VirtualBox supports that I think, but I don’t know if that works if it runs on top of Hyper-V - which is enabled by default in Windows due to some security features (and I don’t want to disable that anyway).
> That suggests also that QEmu isn’t the right software when fiddling with raw x86 assembly to write an OS (qemu is the recommendation of oswiki though).
It is the right software. It's not even debatable: qemu is the one most used for OS development by an order of magnitude difference or more.
If you need to emulate (and not virtualize) have a try at pcem.
It's a marvelous piece of engineering which is slower than others, but that's the price to pay for accuracy.
ok, I will definitely do that. Thank you for the pointer.
The differences between the different "hardware of the time" are larger than between any of the emulators you mention. This is not consoles where the hardware is exactly the same over and over. PC hardware is mostly poor clones of poor clones of the original under-specified hardware and even software emulators of such clones whose only thought of compatibility amongst each other is "does Windows boot already?" (and most specially in the 98 era) . Go and ask Linux...
In fact, (having worked for quite a while in supporting decades old enterprise software) my experience with most PC virtualizers and emulators is that they're ridiculously accepting of errors that will most definitely trigger random behavior in (at least some) real hardware.
There is a superior emulator: x86box
If you want to try Windows 95 in UTM, I've done it for you.
https://archive.org/details/windows-95-for-utm
It won't be a great experience, but for MIDI, wouldn't Microsoft GS Wavetable Synth suffice? Doesn't that come with Windows 98? If it's trying to use the nonexistent Ad Lib support, you can probably tell it to use GS Wavetable Synth instead in the MIDI settings?
The problem would be games/software that moves to DOS mode and tries to use SB16 MIDI then
If you don’t need to run on iPad, Windows 98 works great on DOSBox, including audio and CD.
One really big advantage of DOSBox is that it has Ad Lib emulation. DOSBox is kinda weird and broken when it comes to trying to run Win9x though. It's good when it works at least.
I used this install guide[1]. It went pretty smoothly if I recall.
[1] https://dosbox-x.com/wiki/#Guide:Installing-Windows-98
iDOS3 is a great DOSBox iPad app. Not sure if it’s available in the US due to all of the Apple shenanigans.
Install Rain 2.0 too, or a similar libre licensed tool.
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.
How does Windows 98 work with the fingertouch interface of the iPad? There were some very expensive touchscreen Windows tablets back in the late 90s but they all used a stylus and generally the responsiveness was very slow
In one video I've seen UTM used mouse emulation without absolute positioning: it treated the screen surface as a giant trackpoint nub and you could move away from the current location with variable speed. A native on-screen keyboard is also available.
For absolute positioning a USB input device is emulated, so this might not work in Windows 98 without a suitable driver: https://docs.getutm.app/preferences/ios/#cursor
Win98 does work with absolute USB mouse input. VirtualBox uses it by default.
Why would it handle any differently than a trackpad?
Most non-multitouch touchscreen devices emulate a mouse if there is not a more specific driver available. Trackpads were widely available on laptops at the time and you could jump to any point on the screen with those.
You can click but don't expect any gestures to work.
Anybody got a qcow image laying around with Windows 98 working in virt-manager? I've managed to get a 98lite install "working", but it's got some issues. The sound with AC97 is hit or miss and sb16 doesn't seem to be an option in virt-manager.
Very surprised that softgpu wasn't mentioned at all: https://github.com/JHRobotics/softgpu/
I liked win 98 back in time I will try to install this on an old pc I have