I have had the most success with Win95B, using the unofficial FIX95CPU patch, in Vmware Workstation 16.2. There are still some occasional dll errors however.

I am a Ryzen 1600 user and disabling 32-bit drivers helped. However as soon as I enabled it, it didn't work anymore.

I was messing around with other stuff but did some quick testing.

Zen 2, B450, AGESA ComboV1 1.0.0.6 A, Win7 SP1 x64 host

VMware Workstation 10.0.7, last one for WinXP
installs win98 fine and lets me click through file explorer without any errors
-changed USB settings to 1.1 mode in vmware to fix missing USB driver
-SBPCI_WebDrvsV5_12_01.exe, apci8m.ecw to C:\windows\system, directx_9c_redist.exe to get sound driver (http://www.compdigitec.com/labs/2010/02/27/so … s-98-on-vmware/)
-only remaining missing driver is a PCI System Peripheral (quick search in google says its the VMCI bus device)
-no issues drag-n-drop to/from host/guest after VMtools installed

VMware Workstation 15.5.6, last one for Win7
Gets same errors that are mentioned here. Cant even log in, have to use Safe mode, Disable 32 bit driver trick to be able to login, but still gets errors all over. Changing the ESDI_506.PDR mentioned had no affect. Using Workstation5.x hardware compatibility mode did get fewer errors, in that i was able to log in after a fresh install without the safe mode trick, but still tons of random errors.

Looks like VM10 uses binary translation by default for the processor virtualization engine setting. When changing it to use AMD-V, it gets the same errors as on VM15, which no longer has that option. Deprecated by VMware.

Yup, binary translation dropped after 12.5.9.
VMware-workstation-12.5.9-7535481

Also for those interested in the last Vmware ver that supported 32bit only processors then that's v7.1.6

For Virtualbox I want to say v6.0.24 may be worth trying if you really want to run 9x in Virtualbox. It also supports XPDM.
Supposedly 6.0.24 works on XP but you'll need to extract the MSI from the executable.

I've tested with Windows 10 also VMWare Workstation Player 12.5.9, and I had no sucess, then tried VMWare Workstation 10.x, and the installation worked smoothless. Unfortunately VMWare Workstation 10.x is not fully Windows 10 compatible, if you install the VMWare tools, and later on if you are using drag & drop from the host desktop to the guest desktop, a blue screen will appear for the host (reboot is necessary).
You can disable Drag & Drop, but Shared Folder does not work either (I guess due to the unwanted/forbidden SMB v1 settings for the host), you have to use a FTP client within Windows 98 to get files to the guest system (not very convenient), or you create ISO images e.g. with PowerISO always to get files to the guest.

But I've found also an interesting Youtube Video https://www.youtube.com/watch?v=8fV42wxht9Q which shows the usage of the current version of Workstation Player 16 (!), changing the Compatibility Settings to VMWare 5.x after the base installation was done. This is not really reproducible for me, because with Workstation Player 16, during the Windows 98 installation process, it crashes still.
But may be the compatibility settings for the (current used) VM can be set earlier and may be then it will work (at the moment I had no patience anymore to test it, because I tried it too often).
Did someone tried it, as shown in the YT video ?

You can also use the most recent version of VMware if you follow the solution here (VMM.VXD fix): Re: Patch for Windows 98/98 SE/Me to run on newest CPUs
Tested it myself and it works flawlessly.

in a 4 core AMD A10 cpu i had issues with sound running win 9x in virtualbox and vmware.
It seems to be multimedia pipe not optimal in regards to and these programmers seem to favor as a primary example when coding their virtual hosts. And 64bit cpu's.

AMD "A10" is a diffent CPU architecture (Excavator). This thread is focussed on the successor model "Ryzen" (Zen), as "VME" explicitly broke on the Ryzen models.

Hi, did someone try to install Win98 in VMWare 16, with enabled hyper-v in Windows 10/11? In such configuration VMM runs at user level instead of privileged level, and I was wondering if it changes anything in scope of running Windows 98.
I am currently at vmware 15.1 because reasons, so before I start messing with my system I thought I would ask if anyone tried that already.

Sorry for coming late to the party. Didn't know about this "CPU issues" when I bought my Ryzen 3900X about two years ago. So... I went for a fresh install on real hardware (X470/3900X/Voodoo3) and everything worked fine in the end, as I was expecting. As of today Windows 98SE is still running perfectly stable, I can play for hours, get online etc. I encountered the same random .dll errors when I was messing with 32bit disk drivers for my PCI to SATA addon card.

Since my Ryzen 390X can run natively Windows 3.11, 95, 98 etc I would blame the VM software, VM implementation in the CPU or the BIOS.

Strange enough - on this very machine, once I upgraded the BIOS for the 5000 series - Windows 3.1 would boot and load - but exists to DOS in a few seconds. I encountered the same problem with the old BIOS and it was also disk related. Thing are worse with Windows 95, 98, Me which all give now the famous VCACHE error. As soon as I revert to the old BIOS everything works fine again.

I believe that Ryzen 5xxx series are also compatible at CPU level but the problem might be the AGESA release by AMD.

AWARD, PHOENIX are still in the BIOS business?

^Hi. I'm just a layman, but.. This is about VMs, I think. V86 and other CPU features should still work in Legacy mode on Ryzen (native boot).
Virtualizing them in x64 Long mode+Compatibility mode et cetera is a bit of a different story.
It adds things like Ring level -1, hardware-assisted virtualization et cetera.
https://en.wikipedia.org/wiki/X86-64#Operating_modes

That's the thing that old Ryzen messed up, among other things, maybe:
http://www.rcollins.org/ddj/Jan98/Jan98.html
http://www.rcollins.org/articles/vme1/VME_Overview.html

https://en.wikipedia.org/wiki/Virtual_8 ... ions_(VME)

Those "fixed" Ryzen CPUs maybe just dropped VME from CPU ID, they didn't fix anything.
If so, they just make software use an alternate code-path, a fallback.
Which in turn automagically seems to fix all the woes.
I think that's what early VM workarounds made use of, too.
They did overwrite CPU ID for the VM from the host side (explicitly remove VME flag in a VM's config file).
That got XP running inside the VM, at the time. Though it's notable that XP itself did the magic here, not AMD.

- Since I'm no Ryzen owner, I cannot test this, of course. So what I say is purely speculation and hypothetical. 😔
To double check, please use NSSI on Real-Mode DOS on a Ryzen PC and check CPU feature chart.

Let's please note that fallbacks for non-fully Pentium compatible CPUs were added into software way back in the 90s.
To get things running on Cyrix-like CPUs, so to say.

However, it's uncertain if those fallbacks from eons ago were ever properly tested. 🤷‍♂️
Their inclusion was more of a political decisions, maybe, than anything else.
All modern CPUs had VME, after all, including late 486 cores.
So a reliance upon their practical use is abnormal, strictly speaking.

Edited. Edited again. Formatting fixed.