NT != MSDOS, that is the difference. Windows 2000 and XP are Windows NT (5.0 and 5.1). NT3.5 was the first release to drop MSDOS (and thus the first release of NT, the number was so you could compare it with Win3.1).

The big problem wtih dosbox for windows is the environment. MSDOS has almost no environment, you just have some files and you run one. Windows has a registry and lots of tools, services and libraries which need to be not just present, but configured and altered depending on the situation.

Wine is the closest we have to Dosbox for Windows, but it has the above problems (on top of more complex compatibility). There is also no Windows port for Wine, but as Wine gets better and Windows 8/9 gets less compatible, Wine for Windows makes a lot of sense.

Lastly Wine doesn't emulate the hardware, so you need a VM (like dosbox has) if you want to pretend to run old hardware. This could be bundled in, but the performance hit gets a lot bigger with newer more complicated hardware.

I forgot that MS dropped DOS from NT that soon, but, that was never really used outside of corporate offices, so it's not an important detail.

You're forgetting about ReactOS. Unfortunately, the progress on that is glacially slow. But, it would be the most likely option for such a machine. Certainly more realistic than DOSBox.

I'm not forgetting, ReactOS is not useful in this situation. ReactOS is just Wine with a kernel (and applications), which doesn't help at all because you don't want to replace your existing OS, you want to run something on it. You could use this when bundling in a VM, but the difference bundling VM/Linux/Wine and bundling VM/ReactOS is pretty much just an implementation detail.

Of course it would help. MS isn't going to support older ABIs forever, and Wine doesn't support drivers at all.

This doesn't make any sense to me. I think you might be saying that ReactOS is better because you can run old Windows drivers on ReactOS.... but this doesn't help at all to bundle a game (or other software) to work on an existing new PC/OS. Doubly so if you are using a VM and can control the emulated hardware anyway.

Many game compatibility problems are rendering-related. There are various projects in the works to redirect Direct3D/DirectDraw to OpenGL or similar (e.g. DXGL); a sufficiently advanced wrapper would solve many compatibility problems indefinitely (much like what DOSBox has done for DOS games). Drivers aren't so much of an issue for Windows games since they talk to APIs rather than the hardware directly.

Modern games should remain compatible for longer going forward since Microsoft's newer APIs are designed to install side by side without conflicting. DirectX works like this from 10 onwards. Of course all of this still relies on video card manufacturers retaining backwards compatibility with the expected rendering behaviour.

This is what Wine does.

Unfortunately 'should' doesn't always work. Even ignoring driver issues there are countless cases of Windows 95/98 games not working (or being difficult to get working and buggy) under Windows 7/8. And even then you are still stuck with Windows and x86, no ability to move platform. So there is definately a need for a dosbox like wrapper here.

I was meaning on Windows, since Wine hasn't been ported yet.

I was specifically meaning DirectX 10+ games. Legacy games will always be subject to compatibility changes between versions because they don't use these new APIs.

Making a DOSBox-like replacement is feasible to some degree but having actual architecture independence would require emulating the CPU which adds extra layers of complexity and increases hardware requirements. This isn't too bad for 9x-era hardware (DOSBox can already run the full Windows 9x with some fiddling) but games from the XP era onwards would tend to have much greater hardware requirements. Because of this I'd expect the first step to be a Wine-like solution that only works on x86 for performance reasons.

I recommend trying out VMWare Player. It's free and gives amazingly good performance so you can see what can be done.

I have an XP VM set up in it and it will happily run almost any XP game with little performance hit. To be fair I am running it on x86 still, so I haven't benchmarked it on Anything else, but the abstraction is there for the future when we have some completely different (but powerful) system.

Virtual machines make use of hardware-assisted virtualisation by default, essentially providing performance boosts, but I don't think this works between architectures. Performance of a fully emulated CPU will be much worse than hardware-assisted virtualisation.

Oh, A Thing Worth Mentioning:

for people willing to have a glimpse into the future of DOSBox, here are a couple of custom builds to download and experiment with:

- DOSBox SVN Daum build (SVN-based, DOSBox-X patch with ATA/ISA/PCI, 3dfx, GUI, savestates for weeny "omg DOS games is too hard for me!" chaps out there and whatnot)
- DOSBox-X branch latest Windows build.

VOGONS discussion about DOSBox-X.