A lot of the Windows internals are mysterious and undocumented, but I think the technology is probably all out there already. You can go a long way with running Wine in Linux, for example.

It's just a painstaking matter of putting everything together in a nice neat easy-to-use package, and then testing the hell out of it – an excruciating, tedious exercise in user interface design and debugging.

Wine with "Emulate a desktop" checked makes me think of it as a "WindowsBox", and that feature actually works wonders with program compatibility at certain cases. It's also the only way to run fullscreen programs in a window. The only problem is I don't think Wine for Windows is as full featured as it's linux roots.

How fast can a VM boot say.. windows 98 when the OS is mounted on a RAMDisk or very fast SSD device? Usually a VM is the way to go if you have a really stubborn program that wont run or install properly.

If there ever was such a thing, a complete solution would closely resemble Wine + ReactOS VM+ a DirectX backwards compatibility layer. You have the problem of application compatibility (like the ACT tries to solve in later OSes), kernel compatibilty, Windows API versions over the years (MFC to .NET) and all the libraries that go with them (DLL HELL!), and then you can get down to the specific game and graphics API (WinG's, DDraw, DirectX, GL, etc) issues. Unlike DOSBox where you can emulate a specific and finite set of conditions and hardware, a WindowsBox solution would be massively complex. MS has failed to make any version Windows this backwards compatible and you'd basically need their source to do it particularly well.

Getting more simplistic, I think it would be possible to make a "Win3.11Box" or even Win95 emulator to help with kernel and early DDraw compatibility. This is essentially Wine at the moment. Some things would be handled by your OS, other things like graphics could be entirely emulated and drawn to the app window.

If one was adventurous enough and were looking to boot one specific more modern game, I'd imagine you could make a WinPE environment based off XP SP1 or similar that's really stripped down and with only your specific hardware drivers. That'd be pretty small and efficient; but still you'd still wouldn't solve the problem of running another OS.

DracoNihil wrote:

How fast can a VM boot say.. windows 98 when the OS is mounted on a RAMDisk or very fast SSD device? Usually a VM is the way to go if you have a really stubborn program that wont run or install properly.

It seems to me one of the principal advantages of a mythical "WindowsBox" over a virtual machine is that, like DOSBox or Wine, they would not require any proprietary software from Microsoft, or at least nothing that couldn't legally be downloaded for free; nor would they require end users to re-install the OS from scratch.

The other principal disadvantage to a VM is that operating systems older than XP (or possibly Windows 2000) have no hardware 3D acceleration, and probably never will. Again, all the pieces seem to be out there already, but someone has to put them together.

I wonder, how hard would it be to compile one of the current versions of Wine for use on Windows using something like MinGW or even Cygwin? I bet simply doing that would help solve a lot of compatibility headaches, especially with 16bit applications since it has been demonstrated that Win16 programs can be run under 64bit versions of Linux using Wine.

Presumably if it was easy, someone would have done it a long time ago.

I think that it would be difficult to do a fully functional Windows emulator without violating Microsoft software patents or ripping Microsoft code and getting a cease and desist letter. Even if it does turn out to be easy, that wouldn't stop Microsoft from trying to patent troll you to death with endless lawsuits that you cannot afford to defend against.

FreeDOS exists and ReactOS is continuing.

truth5678 wrote:

FreeDOS exists and ReactOS is continuing.

As is Wine. 😉 Microsoft knows damn well that people are going to keep cracking and pirating and reverse-engineering Windows, so I don't think they even bother with it. With their other products though, that's where they get protective.

mr_bigmouth_502 wrote:

Microsoft knows damn well that people are going to keep cracking and pirating and reverse-engineering Windows, so I don't think they even bother with it.

That's probably because the segment interested in doing so is sufficiently small as to not pose a great threat to their market share, so far.

Really? Pretty much every computer-savvy person I know has used a pirated copy of Windows at some point, and I know a lot of computer-savvy people.

Wine won't work well for old Windows 95/98 era Games. Wine's focus is more on modern Windows XP and above. There is little effort in the Wine community to maintain backwards compatibility with older apps and Games. Just try running 16 bit apps in Wine, doh! Also, if you want things like Voodoo emulation, then you would need to use a wrapper dll.

A better solution would be a true Windows VM box that emulates VooDoo 2 SLI and DirectX 7 and lower games. I'd be happy with that. Granted, you would still need a copy of Windows 9x to install into it, but that is fine with me.

laxdragon wrote:

Wine won't work well for old Windows 95/98 era Games. Wine's focus is more on modern Windows XP and above. There is little effort in the Wine community to maintain backwards compatibility with older apps and Games. Just try running 16 bit apps in Wine, doh! Also, if you want things like Voodoo emulation, then you would need to use a wrapper dll.

A better solution would be a true Windows VM box that emulates VooDoo 2 SLI and DirectX 7 and lower games. I'd be happy with that. Granted, you would still need a copy of Windows 9x to install into it, but that is fine with me.

I thought one of Wine's main features was being able to run older programs on newer systems. 😜

mr_bigmouth_502 wrote:

laxdragon wrote:

Wine won't work well for old Windows 95/98 era Games. Wine's focus is more on modern Windows XP and above. There is little effort in the Wine community to maintain backwards compatibility with older apps and Games. Just try running 16 bit apps in Wine, doh! Also, if you want things like Voodoo emulation, then you would need to use a wrapper dll.

A better solution would be a true Windows VM box that emulates VooDoo 2 SLI and DirectX 7 and lower games. I'd be happy with that. Granted, you would still need a copy of Windows 9x to install into it, but that is fine with me.

I thought one of Wine's main features was being able to run older programs on newer systems. 😜

Windows programs/games on Linux.

In all of this discussion, it might be worth noting another approach. Danoon was experimenting with adding parts of WINE into his Java port of DOSBox with some success. Before anyone gets too fixated on the Java part of it, think of what might be possible with normal DOSBox or the DOSBox-X branch. I think this could be the best solution. Danoon has managed to get Full Tilt! Pinball and the Caesar 3 demo in jDOSBox without Windows being installed in it first. The goal should be to get Windows games to run without a copy of Windows.

Java Port

collector wrote:

The goal should be to get Windows games to run without a copy of Windows.

Technically HX DOS Extender can do that already (it can even run DOSBox in DOS, apparently!), except without the underlying drivers there's no sound support.
http://www.japheth.de/HX.html

Another goal should be to be able to overcome the 16-bit limitation of x64.

That 16-bit limitation is due to Microsoft not wanting to re-write stuff. A x64 processor in long (64-bit) mode can run all 286 protected mode software, including 16-bit Windows 3.1x applications, without a problem. MS would have had to decouple the old WoW libraries from the NTVDM system (which used V86 mode) in order to get it working. Given how few Win16 programs are in use these days, it wasn't worth the effort.

Wasn't Microsoft's decision first influenced by a choice AMD made in designing AMD64? The details escape me at the moment.