VOGONS

Common searches


First post, by captain_koloth

User metadata
Rank Newbie
Rank
Newbie

As I know just enough about computers to be dangerous and fake what I'm talking about but not really enough to actually understand them, I'm going to ask a question that runs the risk of being somewhat ill-formed: why is the state of Win 9x compatibility/emulation so poor compared to either earlier (DOS/3.1) or later systems?

DOS/3.1 through DOSBox are basically perfect (please, I don't mean to start a discussion on that topic, I just mean from the point of a view of a casual nostalgic gamer, it's 99% of the way there). Nearly all games designed for XP or later can be coaxed to run on Win 7-10. But anything from about 1996-2003? Here be dragons... Why is this? You can run these OSs in a virtual machine or PCEm, but compatibility is awful and there are lots of problems (I dont mean to suggest of course that PCEm isnt technically impressive- it's just not in a state yet where casual users would make use of it). Same with trying to install Win 95 in DOSBox.

Can anyone explain why this is? From my reading my understanding is that Win 9x uses a different file structure and codebase from either DOS/3.1 or the XP and later systems, but as above I dont understand the specifics well- can anybody explain this? Why is this apparently such a difficult unsolved problem? What makes Win 9x so different from the systems that came before and after that makes them difficult from a compatibility or emulation perspective?

Reply 1 of 41, by Jo22

User metadata
Rank l33t++
Rank
l33t++

I guess it's because Win9x is very hacky by nature. A mutant, so to say. It relies heavily on things like V86 and BIOS/Real-Mode compatbility, for example.
On top of that, it uses / relies on obscure implementations of "standard" x86 platform stuff like ACPI (for sample) and has got a
lot of 16-Bit/32-Bit mixed code (sample: GDI) and uses an extreme amount of thunking underneath.

Another point is that it was meant to be a pure consumer's OS, I think.
VitualBox/VMWare devs get paid to support professional OSes, like OS/2 Warp or Windows 2000 (NT series).

That being said.. Back in the 90s, companies like Connectix with Virtual PC (for Mac) offered a rather fine Win9x support.
They included USB, printer and Voodoo 2 support (up to VPC 3.x). Same for Soft-Windows98..

DOS.. MS-/PC-DOS itself is very calm and relies on the standard BIOS service routines from the 1980s mainly.
Applications, however, are hit and miss. They may work fine in some virtualizers/emulators, but perhaps not in others.

Hot-rod DOSes like DR-DOS, Novell DOS, PTS-DOS, FreeDOS or Caldera DOS may not work as nice everywhere,
since they often included socalled "optimizations" which in most cases by-pass the official programming guidelines.

Windows 3.x.. Windows 3.1 uses DOS and BIOS/VGA-BIOS for its input/output.
It also has two Protected-Mode kernals, which one of is pure 16-Bit, whereas thee other one is 32-Bit (+V86, VXD virtual drivers, paging)
So as long as DOS or it's auxilary drivers (Himem.sys, SmarDrive etc) work fine, so will it, too.

Windows for Workgoups 3.11 is a bit special though. It can "live alone" once FastDisk and swapfile is enabled.
In short, it emulates some core DOS and BIOS functions by itself, so it can stay in Protected-Mode all the time.

Edit: Win32s might be another special case. The final release is very hard to emulate in a stable way.
For some programs, like Virtual PC 2007, you need hardware assisted virtualization in order to make it work.
Edit: Some fixes.

Edit: Here's an article at Wikipedia describing the Architecture of Windows 9x.:
https://en.wikipedia.org/wiki/Architecture_of_Windows_9x

As you can see in the schematic below, rhe Virtual Machine Manager is the very heart of it.

Attachments

  • win98-struktur-scr-.gif
    Filename
    win98-struktur-scr-.gif
    File size
    18.03 KiB
    Views
    1660 views
    File license
    Fair use/fair dealing exception
Last edited by Jo22 on 2019-10-06, 09:06. Edited 1 time in total.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 2 of 41, by robertmo

User metadata
Rank l33t++
Rank
l33t++

emulation is too slow for win9x anyway

virtualization software doesn't care about win9x and will start care less about following win versions including win7/8

though you can play some games in dosbox with d3d/glide support
qemu with glide support
dgvoodoo2

Reply 3 of 41, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

The Wine project represents the state of the art in emulating the Windows API, which was a gargantuan beast of ever growing and shifting dimensions.

https://en.wikipedia.org/wiki/Windows_API

The Wine project consists of almost 3.5 million lines of code; which can give you a sense of scope. It's taken a massive open-source community to steadily re-implement the equivalent functionality that Microsoft commerially funded using their armies of Windows programmers.

That said, Wine passes through the running executable's instructions to the processor, which limits Wine to running on x86 and x86-64 processors for which the running binary was compiled. This aspect makes Wine more of an open-source port of the windows API instead of a true emulator like DOSBox, which can emulate x86 DOS on non-x86 machines.

The only work-around to run Wine on non-x86 hardware is to emulate the x86 processor itself using a virtual machine on which Linux and then Wine is run.

Reply 4 of 41, by Kerr Avon

User metadata
Rank Oldbie
Rank
Oldbie
captain_koloth wrote:

As I know just enough about computers to be dangerous and fake what I'm talking about but not really enough to actually understand them...

Blimey, it's my boss from work, I'd better look busy 😀

Reply 7 of 41, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
keenmaster486 wrote:
Akuma wrote:

....psssstt 'krcroft' , what does wine stand for ? 😁

Wine Is aN Emulator

Lol. Yeah; Wine only needs a software x86_64 and x86_32 instruction emulation layer to complete the role of a total Windows emulator.. but VMs generally do that job just fine, leaving the huge API layer to Wine. The combination is pretty unelegant though compared to stand alone emulators like DOSBox; "run and done!".

Wine would have to combine forces with something similar in magnitude to a VM layer before it becomes a standalone emulator like DOSBox. VirtualBox is 11M LOC, and even if they could whittle that down to say half that you're looking at roughly doubling or even tripling the community; something on the order of a 2 or 3 billion dollar project.

Reply 8 of 41, by Caluser2000

User metadata
Rank l33t
Rank
l33t

For a start DosBox is not designed to run win95. There are plenty of ways to run Win9x with out using DosBox. Various VMs and VPC setups including MSs own which was originally Connectix mentioned by Jo22. What really is the problem apart from win9x not playing nice with DosBox?

There's a glitch in the matrix.
A founding member of the 286 appreciation society.
Apparently 32-bit is dead and nobody likes P4s.
Of course, as always, I'm open to correction...😉

Reply 9 of 41, by Jo22

User metadata
Rank l33t++
Rank
l33t++
krcroft wrote:

Wine would have to combine forces with something similar in magnitude to a VM layer before it becomes a standalone emulator like DOSBox.

Well, this one comes quite close to that.
Boxedwine (Wine on multiple platforms)
😉

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 10 of 41, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
Jo22 wrote:
Well, this one comes quite close to that. Boxedwine (Wine on multiple platforms) ;) […]
Show full quote
krcroft wrote:

Wine would have to combine forces with something similar in magnitude to a VM layer before it becomes a standalone emulator like DOSBox.

Well, this one comes quite close to that.
Boxedwine (Wine on multiple platforms)
😉

Indeed; nice find!

Reply 11 of 41, by JonathonWyble

User metadata
Rank Member
Rank
Member
krcroft wrote:

The Wine project represents the state of the art in emulating the Windows API, which was a gargantuan beast of ever growing and shifting dimensions.

I always saw Wine as a compatibility layer that makes it so that Linux operating systems can run Windows-compatible programs, not really as an emulator. Or were you talking about a different kind of software known as "Wine"? If not, then I guess the fact that Wine is a compatibility layer does sort of count as an "emulator".

1998 Pentium II build

1553292341.th.19547.gif

Reply 12 of 41, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
JonathonWyble wrote:
krcroft wrote:

The Wine project represents the state of the art in emulating the Windows API, which was a gargantuan beast of ever growing and shifting dimensions.

I always saw Wine as a compatibility layer that makes it so that Linux operating systems can run Windows-compatible programs, not really as an emulator. Or were you talking about a different kind of software known as "Wine"? If not, then I guess the fact that Wine is a compatibility layer does sort of count as an "emulator".

Was just trying to answer the question 🤣
The closest thing we have to a Windows emulator is an x86 VM + Linux OS + Wine. Together, they provide CPU instruction compatibility, hardware driver and UI interface, and finally Windows API compatibility; all of which are needed by Windows applications and games. So yeah.. it's a difficult problem!

Last edited by krcroft on 2019-10-06, 22:42. Edited 1 time in total.

Reply 14 of 41, by Jo22

User metadata
Rank l33t++
Rank
l33t++
JonathonWyble wrote:

I always saw Wine as a compatibility layer that makes it so that Linux operating systems can run Windows-compatible programs [..]"

Well, "compatibility layer" is probably the most precise term (+1 to you). 😀
On a broader scaler, "to emulate" means "to mimic", I believe.

So WINE can also be seen as a Win32 "API emulator" or translator.
Or "simulator", perhaps. Hoever, the term "simulator" does not implicit function.

The blinken lights on the Enterprise 1701 (TOS), had no real function, for example and were a simulation only.
Anyway, it's tricky to define, since terms and technology (computing tech is truely shortlived) may change at some point.

In the past (say 1960s), "CPU" refered to a big computer part in an extra cabinet containing the ALU component.
In the 90s, it rather became a laymans's term to describe the whole tower case of a ~486 PC.
Nowadays "CPU" is just that tiny processor on the motherboard.

Sometimes, two terms can also fit - the MS-DOS "API" is perhaps also an ABI, for example.
It's very low-level-ly tied to x86 hardware and the PC-BIOS service routines.

Unlike modern OSes, it communicates via register values and interrupt vectors (numbers / hex).
Modern OSes do call API functions by their name and pass strings over of text.

Anyway, I'm speaking under correction, since I'm not a native English speaker and not 100% sure about these terms.

Edit: Link added.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 15 of 41, by Stiletto

User metadata
Rank l33t++
Rank
l33t++
Errius wrote:

What happened to the MESS project?

After many years of seeing its code patches brought into MAME, and then its source repository brought onto the same servers as MAME, It was absorbed by the MAME project completely on May 27, 2015. The MAME project gained all its developers (many of which worked on MAME as well). In doing so, the MAME project killed off the meaning of MAME as an acronym for Multiple Arcade Machine Emulator, and it's now just called MAME.

... did you somehow not know this?

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 16 of 41, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
krcroft wrote:

he closest thing we have to a Windows emulator is an x86 VM + Linux OS + Wine.

Nay 😵 I doubt that is the best available solution. I think some of you did not follow the progress of QEMU-KVM running Windows 98, I think QEMU run Windows 98 decently and the main problem is 3D acceleration. Well, being able to emulate Windows 98 and being able to emulate Windows 98 to play games are 2 very different subject. Anything that does not require 3D acceleration run fine on QEMU as far as I can tell, including 2D-only DirectX games such as StarCraft 1997. Video up to 480p play nice and smooth with no choppy audio. With QEMU 3Dfx Glide pass-through, there are now many, many 3Dfx games that are playable now on Windows 98, Unreal, Quake2, Quake3, you named it, as long as it supports Glide APIs. I recently brought up 2 more Unreal-based games, Clive Barker's Undying and Wheel of Time. Both of them play perfectly on Windows 98.

The great things about "x86 VM + Linux OS + Wine" is Linux guest has OpenGL acceleration that Wine can use to emulate Direct3D. Unfortunately for QEMU, only the Linux hosted VM can provide OpenGL acceleration for guest, so that makes it redundant to run Wine within Linux hosted VM, one could just run Wine directly on Linux host. I have yet to venture into Wine to qualify its Direct3D emulation, but for the short period of time that I was experimenting with WineD3D for Windows, it was crap and nothing run with it.

DOSBox is another good and near perfect Windows 98 emulator from my point of view. Its Voodoo chip emulation, though not quite perfect, provides decent acceleration for legacy Direct3D games that fall under the misery of Direct3D APIs immaturity during DX3 to DX5.

Reply 17 of 41, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

That certainly might be the more efficient and cleanest option, if we're already down the VM rabbit hole. But if you're literally just running the actual Windows 98 designed and built by the OEM.. then that's not really emulating Windows. (OP asked why Windows is so difficult to emulate, not for the optimal solution running legacy Windows 9x software on new or non-x86 hardware)

Last edited by krcroft on 2019-10-07, 03:53. Edited 3 times in total.

Reply 18 of 41, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

The ideal solution has the least dependencies on a particular platform while having sufficient performance. The DOSBox method fits this better than the alternatives, although boxedwine has potential if it ports easily to non-sdl2 platforms and the interpreter cpu emulation is sufficient.

For Windows 95 specific games and for preservation by emulation, the software renderer is generally superior to any 3dfx Voodoo emulation, even with an opengl passthrough feature.

Reply 19 of 41, by leileilol

User metadata
Rank l33t++
Rank
l33t++
kjliew wrote:

DOSBox is another good and near perfect Windows 98 emulator from my point of view. Its Voodoo chip emulation, though not quite perfect, provides decent acceleration for legacy Direct3D games that fall under the misery of Direct3D APIs immaturity during DX3 to DX5.

no

(also any concept of glide passthrough won't do a thing for Direct3D)

apsosig.png
long live PCem