You have lumped virtualization in with emulators. Describe what your intended purpose is and mabye your questions can be answered.

DosFreak wrote on 2025-05-21, 11:23:

You have lumped virtualization in with emulators. Describe what your intended purpose is and mabye your questions can be answered.

TLDR would be "which approach will push me closer to 60fps in Quake 2/Half-Life 1, will not looking atrocious in the process".

Please don't say "use patches for modern systems", I know, but there is obscure stuff that never got TLC to either work good/at all on modern stuff.

The emulators are hardware hungry, DOSBOX is HLE, meaning faster afaik but dunno what happens if you slap W9x in it, and I just discovered SoftGPU.

I wonder if there's anyone who tried and could report what emulated CPU can Intel Core Ultra 9 285K do at full speed in PCem / 86Box / DOSBox-X.

There is a Reddit discussion on the topic of 86Box performance:
https://www.reddit.com/r/86box/comments/17gax … _what_cpus_you/
Interpolating that number for Intel Core Ultra 9 285K, it should run Pentium II 400MHz.
Someone achieved that speed on overclocked 9950X3D:
https://github.com/86Box/86Box/discussions/5450
I've observed that PCem could be around 20% faster than 86Box.
86Box team stated that Pentium III emulation is unlikely for performance reasons as well as lack of documentation (the same applies for the newer graphics cards).

On Power PC Macintoshs, SoftPC 3 and SoftWindows 98 were quite good.
Both had pass-through feature for Voodoo 1 and 2.

Virtual PC 4 was faster and added MMX emulation, but lost Voodoo support.
It had to do with the Endian type (big/little).
In order to get the Voodoo working, the Endian type had to be switched, which caused worse performance.

Except for that, there's PCem/86Box.

Commercial virtualization solutions from 2000 onwards don't care about Windows 9x.
The professional Windows 2000 -and NT4 and OS/2 to a stretch- was the lowest platform of interest.

PS: Back in the early 2000s, I had used Qemu emulator+Kqemu accelerator for the difficult OSes.
Otherwise, I've used Virtual PC 2007 (virtualizer) to run OS/2 Warp and Windows 9x.
There was no 3D acceleration, of course.

Jo22 wrote on 2025-05-21, 12:54:

On Power PC Macintoshs, SoftPC 3 and SoftWindows 98 were quite good. Both had pass-through feature for Voodoo 1 and 2. […]
Show full quote

On Power PC Macintoshs, SoftPC 3 and SoftWindows 98 were quite good.
Both had pass-through feature for Voodoo 1 and 2.

Virtual PC 4 was faster and added MMX emulation, but lost Voodoo support.
It had to do with the Endian type (big/little).
In order to get the Voodoo working, the Endian type had to be switched, which caused worse performance.

Except for that, there's PCem/86Box.

Commercial virtualization solutions from 2000 onwards don't care about Windows 9x.
The professional Windows 2000 -and NT4 and OS/2 to a stretch- was the lowest platform of interest.

PS: Back in the early 2000s, I had used Qemu emulator+Kqemu accelerator for the difficult OSes.
Otherwise, I've used Virtual PC 2007 (virtualizer) to run OS/2 Warp and Windows 9x.
There was no 3D acceleration, of course.

Emulation can probably cover this entire mini-era, but the further from '96 you are, the worse the results (provided no host hardware upgrades).

Commercial, or currently free-ish, products seem to be getting passthru tricks and of course SotfGPU, and with not being emulators are easier to run, question is how good does a solution like SoftGPU perform, YT vids are sparse, and there isn't that much of a talk about them.

And then there is "does 3D accelerated DOSBOX-XYZ out do all of these, and what happens if you slap W9x inside it for non-DOS stuff"?

2mg wrote on 2025-05-21, 19:01:

Emulation can probably cover this entire mini-era, but the further from '96 you are, the worse the results (provided no host hardware upgrades).

PCem/86Box can emulate Pentium II, which technically is good enough.

In practice, Windows 95 RTM was fine with 2D graphics cards and a 16MB of RAM and a 386DX-40 higher.
In real life, laptop owners with 4MB RAM were around, too. I knew them.

Windows 98SE runs on a 486DX2-66, but a Pentium or Pentium MMX are recommended as practical minimum.
A Pentium MMX, that's about what Virtual PC 4 and up did emulate in late 90s on PowerPC Macs,
which in turn did officially support Windows 95/98/Me and 2000 on the application box.

Games written in late 90s also usually ran via Direct3D software renderer, still.
They didn't require 3D accelerators yet, because many users had 2D cards, still.
Fast forward to 2001, and the situation was different now.
Past GeForce 256, I think, 3D graphics cards became a thing in people's minds.
Starting with DirectX 8, I think.

2mg wrote on 2025-05-21, 19:01:

Commercial, or currently free-ish, products seem to be getting passthru tricks and of course SotfGPU, and with not being emulators are easier to run, question is how good does a solution like SoftGPU perform, YT vids are sparse, and there isn't that much of a talk about them.

I know, there's not much talk about this.
Maybe it's because Windows 95/98SE are being not so much in the focus of interest anymore.

Even Windows 2000/XP nolonger matter so much, business have moved on too (remember "XP mode" for Windows 7?)
We now have a generation being nostalgic for Windows 7 gaming and the associated hardware. Sigh.

About 10-15-20 years ago, the mid-late 90s were still a thing (in retro/vintage gaming).
hot-rod 486 PCs, 586 PCs, Super VGA games, sound cards. It was fun.
Nowadays, I can already be glad that the ancient IBM PC is still a thing, at all.
It's being primitive by my standards but better than nothing (grew up with fast 286, VGA, DOS 6.2, 16-Bit/Stereo sound)..

Personally, I have hopes that UTM improves emulation over time or that the processors evolve.
It's not useful to x86_64 PCs, though, but ARM platform.
https://mac.getutm.app/

Alternatively, slightly older thin clients can serve as nice little Windows 98 machines. PCI slots can be found in some.
Newer ones run Windows 2000/XP, rather. Via Nano based ones, for example.

2mg wrote on 2025-05-21, 19:01:

And then there is "does 3D accelerated DOSBOX-XYZ out do all of these, and what happens if you slap W9x inside it for non-DOS stuff"?

Before PCem was a thing, many here experimented with running Windows 9x on DOSBox (official one).

Personally, I managed to run a copy of Windows 95 RTM but it wasn't most stable.
Still cool for playing humble games such as Hover, though.

Apparently, the correct combination of Windows 95 revision (RTM, A,B,C) and drivers is needed here.
Some of the CVS builds (later SVN builds) had better support for this, I think.

Nowadays, DOSBox-X is leading here, I think.
Have a look at DOSBox-X site/forum, please, if you're interested. :)
Vogons is for official DOSBox only, understandably.

Edit: Photos taken from my boxed copy of VPC4 (Mac).
It gives an idea about the specs of the emulated PC hardware of the time.

Jo22 wrote on 2025-05-21, 19:48:

...

Yeah, I was kinda out of the loop, and now I see SoftGPU as a 3D accelerator for VMs that never did W9x properly, DOSBOXes tailor made for W9x installations, and then there's 86box being more accurate and PCem being faster.

So I wanted to check out if we've reached a point where one of these is superior, a go-to choice, in a broad sense.

If you really want "performance" there's BoxedWine, because that's platform agnostic and leverages Wine and OpenGL passthrough combined with CPU emulation (A very enhanced DOSbox core emulating Linux for this). It also gets the pesky part of having a Windows 9X installation out of the way....

Some say SoftGPU's fast, but I never got it to work beyond llvmpipe/gallium myself which doesn't have dithering and performs on par with PCem's 3dfx Voodoo3 to me (which is fast, but gets bottlenecked by CPU emulation)

DOSBox Pure on RetroArch's also an option because it has 3dfx Voodoo emulation through OpenGL (no wrappers) and supports Win9x officially, but still has classic Dosbox core issues like hanging on starting dos games in win9x and a lack of MMX. There's also a CPU emulation bottleneck there.

There's still a lot of gaps in early 3d GPU emulation. 3dfx is approached the most because they've let loose the code and papers back in the 2k closure and they were once a lowest common denominator for games to support, so for most that's sufficient (stupid brand nostalgia aside). Also if a funny old 3d card's figured out, it'll end up getting a lot of false bug reports about it because early 3d support was rough. ViRGE already had plenty of that from those unfamiliar with it.

leileilol wrote on 2025-05-22, 02:04:

If you really want "performance" there's BoxedWine, because that's platform agnostic and leverages Wine and OpenGL passthrough c […]
Show full quote

If you really want "performance" there's BoxedWine, because that's platform agnostic and leverages Wine and OpenGL passthrough combined with CPU emulation (A very enhanced DOSbox core emulating Linux for this). It also gets the pesky part of having a Windows 9X installation out of the way....

Some say SoftGPU's fast, but I never got it to work beyond llvmpipe/gallium myself which doesn't have dithering and performs on par with PCem's 3dfx Voodoo3 to me (which is fast, but gets bottlenecked by CPU emulation)

DOSBox Pure on RetroArch's also an option because it has 3dfx Voodoo emulation through OpenGL (no wrappers) and supports Win9x officially, but still has classic Dosbox core issues like hanging on starting dos games in win9x and a lack of MMX. There's also a CPU emulation bottleneck there.

There's still a lot of gaps in early 3d GPU emulation. 3dfx is approached the most because they've let loose the code and papers back in the 2k closure and they were once a lowest common denominator for games to support, so for most that's sufficient (stupid brand nostalgia aside). Also if a funny old 3d card's figured out, it'll end up getting a lot of false bug reports about it because early 3d support was rough. ViRGE already had plenty of that from those unfamiliar with it.

BoxedWine seems interesting, if I understand it, you can install it on modern Windows, and then run it and get Wine that handles old Win games?
What about otvdm/winevdm, is that one just adding 16bit installers for modern Windows, no other emulation?

Regarding SoftGPU - you say it would basically bypass the CPU hogging of emulators, but the end result isn't much better than Voodoo3 in those emulators?
Wouldn't that still be somewhat better, sure the 3D part is still limited to Voodoo3, but at least no CPU related slowdowns - https://www.youtube.com/watch?v=j4DXZw_-xXE ?

Is Dosbox Pure the only one that is W9x oriented?
Since the two others had guides for doing it for years now, and support stuff like MMX, afaik even OG Dosbox had some improvements in nightlies, or patches that expand it's capabilites.

BTW if DOSBOX Pure has issues running games in W9x MSDOS mode, I could just boot directly into it's DOS and run them from there, right - question is do I need a DOS set of drivers for any of those approaches (as W9x wouldn't pass them to DOS)?
I could just have another DOSBOX for those DOS games only.
Also, why the CPU issues in that approach, is running Dosbox + W9x so CPU intensive?

That post about GPUs and emulation is from 2020, 86box does Voodoo3 (tho I still don't know if it's optimized) for example.
Sure, NV cards aren't done (yet, but here's to hoping).
But in emulation, even if you had GeForce DDR, the CPU would bog you down for games that need it, unless you're thinking about using GF DDR with ~200mhz CPU and playing an 1997 or below games with good FPS.

PS: if you've tried 86box (and PCem), is your mouse laggy? I've tried some pro-tips, but it's always laggy, especially in 86box, yes even when emulation is 100% and in desktop.

Hi, some info on BoxedWine:
Boxedwine (Wine on multiple platforms)
https://www.boxedwine.org/

Boxedwine […]
Show full quote

Boxedwine

Boxedwine is an emulator that runs Windows applications.
It achieves this by running an unmodified 32-bit version of Wine, and emulating the Linux kernel and CPU.
It is written in C++ with SDL and is supported on multiple platforms.

Boxedwine is open source and released under the terms of the GNU General Public License v2 (GPL).

Features

Runs 16-bit Windows applications
Runs 32-bit Windows applications
Runs in a browser with Emscripten (wasm and asm.js)
Runs on Windows, Mac and Linux
Currently supports running multiple Wine Version: from 1.6 to Wine 5.0

Edit:

2mg wrote on 2025-05-21, 20:55:

Jo22 wrote on 2025-05-21, 19:48:

...

Yeah, I was kinda out of the loop, and now I see SoftGPU as a 3D accelerator for VMs that never did W9x properly, DOSBOXes tailor made for W9x installations, and then there's 86box being more accurate and PCem being faster.

So I wanted to check out if we've reached a point where one of these is superior, a go-to choice, in a broad sense.

Hi there, I'm not up-to-date either, I'm afraid. 😟
I hope time will solve the performance issue, though, eventually, due to further improvements in technology.

That being said, there's one core problem.

Emulating a higher-end computer, such as Pentium III won't automagically improve performance.
Because emulation of such a highly complex computer costs raw power on itself.

Emulating a lower-end system very efficiently, by contrast, might actually gain lots of performance.
Unfortunately, that's not what PCem/86Box offer: You can't select, say, a Pentium MMX and override CPU frequency to be @500 MHz.
It's against the philosophy of emulating real-world hardware accurately.

That's what DOSBox does, for example, it does take shortcuts in emulation.
At reasonable cost of accuracy; cycles can be set at will.
Early PS1 and N64 emulators did same, I think.
They focused on emulation the concept of the architecture, rather than cycle exact emulation.

Emulators like BSNES were cycle-exact down to the chip level, which took a hot-rod gaming PC down to its knees.

In PC emulation, something similar would require emulating the i8042 keyboard controller with its firmware and the counterpart in the AT keyboard, the SB16 with its DSP chip and original firmware etc.

If we would take things ad absurdum, then the thermal change of the chips during heating up should be emulated.
Because it affects timings of a fraction of a hertz.

Edited. Typos fixed.

Edit: What I think would be worth to do is rewritting parts of GDI and DirectDraw/Direct3D of Windows 9x.
Since Windows 95/98/Me are virtually the same here, it might help all users.
The rewrite of the hardware-dependend part (HAL) or an improved software renderer (HEL) would be useful a like.

Or in other words, it might help to not just write a GDI/D3D wrapper to host hardware,
but make GDI/D3D issue graphics calls directly to the host system.
Say, by using OpenGL or SDL, Allegro to draw graphics primitives.

Before anyone says that's nonsense, I'd like to point out that Insignia SoftWindows did this before.
The Macintosh version of SoftWindows 1.x, I think, ran on 68000 Macs and included a custom Windows 3.1x.

This Windows 3.1x had large parts of the graphics system (GDI) being rewritten to use native code. Whatever that means in detail.
It perhaps meant that some 68000 code was inserted to be processed by the host side of the emulator.

What also had been done was considering that GUI applications don't need raw processor power, actually.
What Macintosh and Windows programs do most of time is calling API functions.

So by mapping these GUI functions from inside the emulation to the corresponding functions on the host side could reduce workload.

Or let's take the audio support in Windows.
Instead of emulation of a Sound Blaster Pro or 16, a synthetic device could be provided by the emulator.
To use it, a special communications channel and a custom device driver would be needed.
SoftWindows 2 did that, too, I think. It had audio support for Windows in the settings.

The emulation of Windows 9x could be so easy, considering that it's a mountain of VXDs.
Hardware abstraction and emulation is its domain.
It was known for being capable of emulating Sound Blaster cards entirely in software (via VXDs), so that DOS programs on Windows 9x could use it.

Edit: Or let's put it this way: It could reduce the load of the emulated CPU if GDI/D3D would be proccessed in native code on the host, at very least.
I don’t mean the drawing part, but the calculation part.
If there was a tiny stub of GDI/D3D inside the emulator that talks to the big GDI/D3D implementation running on the host side, it might improve performance a lot.
This implementation could run separately onnthe host side in its own thread (say as a DLL), so that a multi-core PC could run it on a dedicated core.

Edit: There are several ways to implement things in creative way, I think.
Use of dynamic recompilation as a help, using a state machine etc.
Running Windows 9x kernal side by side with host OS, like WABI did with Windows 3.1 386 Enhanced-Mode kernal on Unix/Linux.
I wished I had the technical know-how to go into the details here, but I'm just a layman.

2mg wrote on 2025-05-22, 14:08:

Is Dosbox Pure the only one that is W9x oriented?
Since the two others had guides for doing it for years now, and support stuff like MMX, afaik even OG Dosbox had some improvements in nightlies, or patches that expand it's capabilites.

Forget about DOSBox for win95 emulation. No matter what certain ports claim, none of them have made changes substantial enough to make it stable/reliable. There are fundamental issues with the way DOSBox does CPU emulation that make it incompatible.

jmarsh wrote on 2025-05-22, 15:10:

2mg wrote on 2025-05-22, 14:08:

Is Dosbox Pure the only one that is W9x oriented?
Since the two others had guides for doing it for years now, and support stuff like MMX, afaik even OG Dosbox had some improvements in nightlies, or patches that expand it's capabilites.

Forget about DOSBox for win95 emulation. No matter what certain ports claim, none of them have made changes substantial enough to make it stable/reliable. There are fundamental issues with the way DOSBox does CPU emulation that make it incompatible.

That's right, I think, but on other hand, Windows 95 did require nothing more than a basic industry standard PC/AT mainboard and a 386SX processor.
The technological level of 1985, in short.

An IBM 5170 motherboard, EGA/VGA card, 8 MB RAM board and an interposer with an 386 CPU.

With the exception of the 80386, a Macintosh 128 in 1984 was more complex, hardware and software wise.
Especially the firmware of it, with "BIOS"/QuickDraw/Toolbox..

To a large extent, the root cause of instability of Windows 95 running on DOSBox is the fault of Windows 95 itself, I think.
From very start, it was a piece of scrap metal, a rushed hack.

The reason it probably ran okay on real hardware was because of workarounds/hacks provided by commercial AT BIOSes (Award/AMI), debug registers of the i386 and what not.

And because instructions on real hardware don't pass in one cycle, too.
Thus, on DOSBox, timing loops in Windows 95 might not correctly work.
But that's not fault of DOSBox. An OS shouldn't make such assumptions about how long individual instructions take for execution.
Especially not in the 90s, when technology was evolving so fast and 486/586 clone processors were a thing.

If DOSBox really was the main reason, I think, then it's surprising that Windows 3.1 can run so stable on it.
The big difference between Windows 3.1x and 95 is, that Windows 3.1x wasn't yet such a pile of VXDs.

The architecture of 3.1 was more down to earth, I think.
And still had large parts of 16-Bit Protected-Mode code in place that relied on segmentation.
Which technically could provide another layer of protection or stability, due to code/data segments being executable/non-executable.

But I agree, the official version of DOSBox isn't ideal for running Windows 95.
To make Windows 95 run both quick&stable, it would require a special build full of dirty hacks that take care of the bad habbits of Windows 95. 😉
It might need to consider the different OSR versions of Windows 95, too, maybe.

Edit: I'm just a layman here. I think that Windows 95 does rely on lots of things like V86 and trapping.
Providing VME might help to gain stability, maybe? It fixed many of the shortcomings of V86.
If Windows 95 can use it, a lot of quirky Windows 95 workaround code for normal V86 could be avoided, maybe?

it's interesting that emulating a PC from late 90's is till harder than most consoles from same or later periods, or at least seems more demanding, there are so many system components to emulate

gerry wrote on 2025-05-22, 17:09:

it's interesting that emulating a PC from late 90's is till harder than most consoles from same or later periods, or at least seems more demanding, there are so many system components to emulate

Hi there! A plain PC/AT Model 5170 is quite straightforward to emulate, I think.
80286 level emulation was provided by Insignia's SoftAT, SoftWindows 1.x and Windows NT 3.x (RISC) for example.

The 80286 platform was very clean and free of most BIOS extensions.
It was good enough already to run Windows 3.1 and most DOS applications.

Attached are two pictures of SoftWindows for Mac running inside Basilisk II.
Emulation in emulation, so to say.

gerry wrote on 2025-05-22, 17:09:

it's interesting that emulating a PC from late 90's is till harder than most consoles from same or later periods, or at least seems more demanding, there are so many system components to emulate

A Dreamcast from 1998 had a 200 MHz RISC processor, and the Playstation 2 from 2000 had a 300 MHz RISC.

On the PC side, by the end of the 90's we had 800 MHz Pentium 3's and over 1 GHz in 2000! On top of that, x86 is like the prime example of a CISC CPU which generally makes instruction decoding more complicated and resource-hungry.

Console hardware always lagged far behind the latest and greatest PCs.

Jo22 wrote on 2025-05-22, 15:59:

To a large extent, the root cause of instability of Windows 95 running on DOSBox is the fault of Windows 95 itself, I think. Fro […]
Show full quote

To a large extent, the root cause of instability of Windows 95 running on DOSBox is the fault of Windows 95 itself, I think.
From very start, it was a piece of scrap metal, a rushed hack.

The reason it probably ran okay on real hardware was because of workarounds/hacks provided by commercial AT BIOSes (Award/AMI), debug registers of the i386 and what not.

And because instructions on real hardware don't pass in one cycle, too.
Thus, on DOSBox, timing loops in Windows 95 might not correctly work.
But that's not fault of DOSBox. An OS shouldn't make such assumptions about how long individual instructions take for execution.

It is the fault of DOSBox because it doesn't handle exceptions (among other things) properly. It gets away with it for DOS stuff because they weren't commonly used except in DOS extenders that made use of paging - and it works around that by providing ample physical memory so that most games don't need it.

UselessSoftware wrote on 2025-05-22, 17:21:

Console hardware always lagged far behind the latest and greatest PCs.

PS2 VUs and Dreamcast's SH-4 optimizations had an edge on pulling polys though. There's also how PS2's video memory worked allowing for some rather 'free' buffer effects (giving certain ports problems coming to PC *cough*MGS2*cough*)

jmarsh wrote on 2025-05-22, 17:58:

It is the fault of DOSBox because it doesn't handle exceptions (among other things) properly. It gets away with it for DOS stuff because they weren't commonly used except in DOS extenders that made use of paging - and it works around that by providing ample physical memory so that most games don't need it.

Okay, but you didn't respond to my statement about Windows 3.1x.
The 386 Enhanced-Mode seems to work since about DOSBox 0.65, I still had issues with 0.63 - back then I ran Windows with WIN /S.

Some of the custom builds can run certain versions of Windows 95, also.
In my example, it's Windows 95 RTM if memory serves.
The fact that certain versions of Windows 95 do make trouble and some don't so much do let me question stability of Windows 95.

Btw, if this was about OS/2 then I would agree that DOSBox is utterly lacking.
But that's another story, OS/2 was a real operating system with lots of sophistication. :)