Thanks for this patch. I patched the win98 folder from ISO with patcher9x and installed Windows 98SE in VMware Workstation 16.2.3 on the AMD Ryzen 9 3900.

Windows 98SE runs much faster after the VMware Tools are installed. Stability so far is fine. I have just installed the hotfixes from Security9_enu_15.iso

Nice work! I was having this issue under qemu+whpx with an 11 gen intel CPU. I could work around it but this is a better fix

Re: Qemu + whpx accel + win98 guest DLL corruption

Thanks for all responses – I’m happy to hear that it works and that here are users who still running Windows 9X virtual machines 😀

I recently tried to port patch to Windows Me – but there is little problem: I can’t catch any situation, where this code is executed – so if you discover some situation (caused by application or more likely by driver) where WinMe will show strange errors in system DLLs, please write it to me. (In VMM/FlushMappedCacheBlock on WinMe is much less space to inject some code, so patch will need longer jump/call to somewhere where space is, and I’ll need to test it.)

It is also possible, that Windows Me has too many bugs, that this one did not fit install CD and WinMe isn't affected by this 😁

Thanks for the patch. It seems to work well. Earlier I was not able to install Win98 on Virtualbox. I also tried this new Windows 9x Virtualbox display driver: http://www.os2museum.com/wp/windows-9x-video-minidriver-hd/

JH64 wrote on 2022-06-01, 22:38:

I've created a patch for Windows 98 to run on the newest CPU (AMD Zen 2+, 10 nm Intel, ...).

I am bit curious about "10nm Intel", which I am guessing means Alder Lake only. I was not aware that it was broken there too. Is there online any complaining about it ?

Also, for those who own an AMD Zen 2 o 3 .... are there any other problems left when virtualizing Windows 9x ? I may need to buy one in a couple years...

Update: the patch is now working for Windows Me too, see updated 1st post

@janih: thanks for the tip - any new driver for Win 9x for virtual GPU is welcome!

@javispedro1: there is also Tiger Lake (10nm too) where is "this problem" present - I haven't any 12th gen Intel to test, but I assume if there was this improvement in 11th generation, there will be also in 12th generation. There is also speed improvement - if you have special instruction to update TLB, you don't need checking generic write to test if there was change; and with some "small" compatibility issues - people don't care about much newer system then Windows 98/Me... I didn't see any online complaining with Windows 98 + 12th gen. Intel, but personally I didn't see any for 11th gen. too before I saw this bug on my own laptop! There is also "CPU speed bug" in 95/98 FE (first edition), but 98 SE/Me looks OK to me* - but if anyone find some, report it please 😀

*OK, there are another like 48 bit LBA - if you attach larger virtual drive, memory limitation (both RAM and GPU) etc., but if you correctly sets VM they probably won't bother you.

Great Work!

Add a working Ryzen 5 3600 in VMware to the list (using the boot floppy method on a German Win98 SE).

Note: the command line options mention "WMM32.WXD", "WMM.VXD" & "WMM32.VXD" - is that a typo or do these files exist during installation?

Hello 1541, thanks to report your CPU - I added it to CPU list.

To your note: Its typo, only exists VMM32.VXD and VMM.VXD files (sorry for it). I already fix it in source on GIT and in next release it'll be corrected in program on readme/help (hope soon).

Well done!

Works great in VMware Workstation 16.2.3 on my Ryzen 5950X 😀

JH64 wrote on 2022-06-01, 22:38:

I've created a patch for Windows 98 to run on the newest CPU (AMD Zen 2+, 10 nm Intel, ...).

Hello. Will support for updates Q242161 (VMM.VXD 4.10.1999 for win98) and Q288430 (VMM.VXD 4.10.2226 for win98se) be included?

Hello computerfan9000, glad to see the desktop AMD ZEN 3 CPUs works too!

Hello BolenB, thank you for pointing out Windows 98 updates which updating vmm.vxd. But difference in patched function (FlushMappedCacheBlock) is only 2 extra instructions. So, I'll add support to next release (maybe at weekend or next week).

@JH64,
You can find Q288430 (VMM.VXD 4.10.2226 for win98se) here:

https://web.archive.org/web/20070101033443/ht … -q288430-en.zip

Works great on my 12th gen mobile Intel (i7-12700H) -- finally have 9x in VMware again! Nice stuff dude!

I created new release 0.7.45 (https://github.com/JHRobotics/patcher9x/releases/tag/v0.7.45, or download in 1st post) where I included CPU speed bug fix. Original patch was by Rudolph R. Loew (https://www.betaarchive.com/forum/viewtopic.php?t=29224) and I do some improvements: I increased the number of cycles by 8 times (80 times more than the original code and in the case of NDIS.VXD, 100 times more than the original code). And I also included a simple "divide by zero" protection.

Why more cycles in test loop? I created small test (you can run it by 'patcher9x -cputest' or 'patch9x -cputest' from DOS). And here are results on old Ryzen 5 1400:

1### stats:
2LOOP V1: 0.311 ms (LOOP = 1000000)
3LOOP V2: 0.328 ms (LOOP = 1048576)
4LOOP V3: 3.053 ms (LOOP = 10000000)
5LOOP V4: 3.197 ms (LOOP = 10485760)
6LOOP V5: 24.494 ms (LOOP = 80000000)
7### conclusion:
8Status: patch is recomended, but FIX95CPU works with your CPU too
9Precision: benchmark ran from OS, results are not completely accurate
10CPU: AMD Ryzen 5 1400 Quad-Core Processor

LOOP V3: is length of loop after FIX95CPU patch and if this value be under 1 ms the driver will fail on "System protection error" - on division by zero. In my version is simple protection, but timing information after that is completely useless (driver probably won't work correctly). This problem is in 98 SE in NDIS.VXD where is short test (~1 M LOOPs = LOOP V2 test) and if time=0 it sets time=1 (ms) so for faster CPU probably this driver won't work. There are also NDIS.VXD updates but I still didn't look to them. I think in near future (maybe in current high-end CPU models now, but I haven't any yet) this will be problem. So I increased cycles in test and fix 98 SE's driver too.

There is also one disadvantage - on slow CPU will system boot longer (8 - 10 times) so this patch isn't usable on every HW configuration. My slowest 386-compatible PC (some Duron ~1340 MHz) has these results:

1### stats:
2LOOP V1: 2.358 ms (LOOP = 1000000)
3LOOP V2: 2.472 ms (LOOP = 1048576)
4LOOP V3: 23.538 ms (LOOP = 10000000)
5LOOP V4: 24.689 ms (LOOP = 10485760)
6LOOP V5: 188.293 ms (LOOP = 80000000)
7### conclusion:
8Status: patch is recomended, but FIX95CPU works with your CPU too
9Precision: benchmark ran from DOS, results are precize
10CPU: AMD Duron(tm)

So, this warning isn't for most after 2000's CPU relative but could by problem for some half virtualized - half emulated configurations.

I hope I haven't created any new bugs with this patch 😀 It's out of my possibility test all Windows 95 and Windows 98 beta/FE versions, but everything I have tested it works (including "Memphis" 4.10.1351). If you have something from 9x family that not working on modern CPUs in VM, please, tell me 😀

@1541: thx for link!

@moya: thx for report your CPU (it's the first reported 12gen Intel - I'm glad that works!)

@BolenB: support for Q242161 and Q288430 is included in this release (0.7.45)

PS: Intel CPUs have bit slower LOOP instruction (from 2nd gen to 11th gen about 1 000 000 LOOP ~ 1 ms), so this is this timing is probably more CPU AMD related.

I've been experimenting VM's on my build... insane but it's a dream that I kinda wanted to become a reality.

I'm having a problem with running Cygwin 1.5.25's setup where it keeps locking up when "Parsing ini file". This doesn't happen on actual hardware on a fast Core 2 Duo, but it does when I try to run it in a VMware virtual machine on my Ryzen 1800X. I tried this patch, but there was no improvement.

I don't know what the problem is, but it's reproducible. I found that if I kept resetting the system and re-running setup, it would VERY RARELY get past this problem and allow me to continue. It feels like some kind of timing issue, but may also be related to my Ryzen CPU; I can't know for sure. But I can confirm that I have never had this problem in either Windows 98 or ME on actual hardware with a fast CPU. One time I was able to push it past the problem, I got a weird dialog about a missing DLL, but the file name was corrupted.

Do you know if this is related?

I encountered this blue screen after installing this patch on one of my retro desktops. It mentions VMM, so I wanted to mention it, in case it's related. It occurred at random but then would trigger whenever I tried to interact with things on the desktop, like running a program or opening a shortcut. I had to reboot to make things sane again.

Hello Kahenraz,

About Cygwin: It’s look more like problem with file system/disk driver/DMA (esdi_506.pdr?), but why only on Ryzen? (VirtualBox + Intel is without this problem) – I have access to Ryzen 1600, so I’ll try to simulate it.

About BSOD: I have never tested on bare metal hardware, so it’s probably bug in patch, I’m sorry for it 🙁. Patcher creates file backup (C:\WINDOWS\SYSTEM\VMM32.BAK -> VMM32.VXD or C:\WINDOWS\SYSTEM\VMM32\VMM.BAK -> VMM.VXD) so if you copy/rename back you’ll recover system without reinstall.
I have an idea where the bug is, so tomorrow I’ll try install win98 on some old PC, then apply patch and I will try to find a solution. Originally TLB bug fix doesn’t make sense on an old computer but with combination with CPU speed patch it is use-case too.

Could you please post your CPU name in your retro computer? In case that is not bug in my code I’ll probably need some CPU blacklist to prevent install VMM patch on them.

It's a Core 2 Duo e6700. I've been troubleshooting out of memory issues and wanted to see if this patch would make a difference.

I'm having trouble troubleshooting this elsewhere since all of my modern computers are Ryzen, and I'm having problems virtualizing there.

I have more questions about my problem, but I need more data. And I do a lot of the heavy lifting with Cygwin, which is why I'm trying to get that installed in a VM.