3.1 games run on Vista 32bit. Occasionally there are problems such as graphics corruptopn or GPF's but mostly they run fine.

16bit 3.1 games will not run on Vista 64bit without emulation.

Yep, DosBox runs Windows 3.x games very well. I am able to play FMV games like Star Trek Klingon very well.

3D Acceleration in VM's will take off when the next revision of WDDM comes out later this year?
I want to say you have the ability to use Vmware's DirectX using Vmware Server but I'll have to doublecheck (if not then the free Vmplayer does for sure) and IIRC on their webpage you can use it from 2000/XP guests as well. If so then there should be no issue with Vista guest's.

Programming Windows support in DosBox in no way increases DOS game compatibility and quite possibily could make DOSBox game compatibility worse. I do not think the devs would want this in DosBox so if they ever do then they'd have to create a seperate project.

Considering Win95 works (with some problems) in DosBox right now it shouldn't be too much of a problem to support Win98. (Wouldn't bother with ME). Then all we'd have to worry about is 3D. DosBox supports glide with a patch so support for glide in guest Windows to host OGL (OGL because DosBox is all about compatibility with other OS's) shouldn't be a problem.

All of that could be done fairly easily....heh......

Then all we'd have to worry about is D3D->OGL . Alot of wrappers already do this on Windows but I'm not sure if they are opensource or not.

With all that said....

Most games required 3D work fine in Windows XP. Just check my PC Game Compatibility list in my signature. Most of these games do not require processor emulation which would slow them down significantly in DosBox while they would run far better on open source emulators like Qemu or closesource projects like VPC/Vmware.

Qemu is the better bet all it needs is someone to do the 3D work.

Win95 and Win98 programs makes use of a lot of shared library files (DDL's) and routines (API's - Application Programming Interfaces) that are part of the Windows 9x operating system. So your WINBox-fork would have to implement them (just like Wine - the Windows Emulator for Linux). A very big effort.

You might be able to get some of the older Win95 programs to work in DOSBox (but installing them will be pain) with the help of HX DOS.

I thikn WINE is all you need. If someone creates win32 host support for it, you'd have a full-speed emulation environment which can only get better in compatibility.

`Moe` wrote:

I thikn WINE is all you need. If someone creates win32 host support for it, you'd have a full-speed emulation environment which can only get better in compatibility.

WINE is a stupendous product (being able to run WoW on a 64-bit Linux is particularly amusing), but it makes little to no effort in one crucial area to games: device level hardware compatibility.

This is of course, one of the main purposes of DOSBox, directly emulating non-existing hardware. So I can see where the original poster is coming from, as your copy-protected game Foo is not going to run under WINE, since as we all know Wine Is Not an Emulator, and it won't support the esoteric usage of the CDROM drive by the protection or the goofy ring-0 driver somebody wrote.

That being said, I don't agree philosophically that DOSBox should be forked in anyway. The relevant Windows generation to worry about (from a loss of compatibility) standpoint is Win95/WIN98, so if you want to preserve those games, I would instead contribute to ensuring DOSBox has appropriate hardware emulation to allow Win95/98 to run with expected device services (Video, CDROM, Audio). Then you could write a "driver" in Win9X for each of these subsystems (that talked through to DosBox) and let DirectX do it's thing, without changing it on the Windows side at all.

Now, that's a huge undertaking, and I'm not volunteering, just saying that's how I would do it if I was =). But actually what I would do is just run QEMU and use host hardware in that manner.

-Frob

The main problem is dosbox does not support quick time which was required for many old games. I know for sure 0.65 did not support it. Not sure about 0.70.

Did you install it?

abyss: search for quick time with dosbox and you will learn that someone had it working already. For Win3.11 don't bother with anything below Dosbox 0.70 (well, mostly for any game don't bother with pre 0.70 versions...)
And why you need to hijack this thread with something you didn't even research is beyond me.

@original poster: Dosbox is open source, WINE is open source and so is Quemu. You don't even have to fork Dosbox, you can just take its source (sticking to the GPL (if Dosbox is under the GPL - too tired to check now) and have a go at it. If you can't because you don't know (enough) of programming you just need to make other coders see your vision 😀
*I* would test it 😀

Arrrg jamyskis I screwed up your post! Sorry! Here's my reply tho!

The problem is that a lot of people are using Vista 32-bit though which causes a few problems. The alternative would be to implement a third-party VDMSound-style subsystem implementing 16-bit support, since Microsoft decided it was irrelevant for the 64-bit version of Vista.

Thank god no. NTVDM is horrible. NO MORE! I'm glad an equivalent isn't included in 64bit Vista. Also if you use WDDM drivers in 32bit Vista you will not be able to run a full-screen command prompt so no DOS games for you! (Unless they use DosBox of course)....or they can revert back to XP video drivers which is not a good idea.

That's fine for Vista users, but what about people with Macs/Linux/whatever?

There is always Wine.....I haven't been very fond of it since it makes more since to just play the games that run well in Windows to just play them in Windows.....

Besides, WDDM is supposed to help improve driver stability, I wasn't aware that it had any effect on virtualisation technology. Then again, I'm not an expert in this field.

It's more about virtualizing the GPU to allow multple threads . WGF2.0 will allow this. Don't know when it will be out exactly. Hopefully when SP1/Longhorn server is released.

I must admit that I've not tried the patch so I can't judge. Is this low-level 3D hardware emulation or an interface with the existing host 3D hardware? I might download the DOSBox CVS later on and the patch and see if I can get it going under Linux to take a look.

The patch intercepts the glide calls and redirects them to the host glide wrapper (zeckensack/dgvoodoo/openglide) and then uses either D3D/OGL to display.

But wouldn't performance suffer big time, converting from Glide to OpenGL and then to Direct3D and then back to OpenGL (for portability)?

Not for glide games in DosBox. (Okay compared to an original DOS machine then probably yes it will be slower). Also it only goes one way Glide->D3D or Glide->OGL depending on the host wrapper used.

If there were to be a windows port of DosBox and an effort to do D3D in DosBox then it would likely be D3D->OGL for compatibility sake, although Windows only D3D->D3D......or mabye D3D->D3D could work in Linux too if Wine was used in some fashion.....

Actually I'm going to have to beg to differ on this one. I have a collection of 1250+ games and about 15-20% of my Windows 95-98 games (i.e. 1999 and before) do not run properly under XP. I can only imagine that this is even worse under Vista. Sometimes these are just speed issues which I can deal with using winThrottle (the definitive CPU brake *hehe*) but more often than not it's an issue with the OS or hardware (for example, Sonic R doesn't like Athlon processors for whatever reason)

I said MOST games. 😀

Check my PC Game Compatibility list.... Yeah, Sonic R only works with P3/K6 erra processors IIRC. I'll have to check my list again to verify.

I've been going through my list testing Vista compatibility and so far:

1. No hardware sound in DirectSound3D gamesunless you have an X-FI sound card and are using the Alchemy Wrapper. Also I don't think it wraps A3D games either.....

2. Some installshield installers do not install....(Haven't narrowed down which versions yet exactly.)

3. No way to reduce sound acceleration....

4. No way to reduce video hardware acceleration if using WDDM drivers.

5. Graphical distortion in some games.

6. Audio distortion in some games.

7. I've noticed some games messing with DWM, had one game that made DWM eat memory like crazy and it wouldn't stop. heh. After I get done testing the rest of my games I'll go back and test it but it was pretty scary. Heck, I don't even know why DWM is running on this laptop anyway since it cannot even run Aero and is using XP video drivers....

8. Copy protection drivers require updates.

Can't think of anything else right now, I'll have to check my list.

Back when DOSBox first began most PCs were not fast enough to run DOS games newer than 1993. Now it's 2007, and DOSBox's compatibility is only thanks to the long development time, and we now have PCs fast enough to run emulated Tomb Raider (I can run Screamer 2 at a respectable speed on my humble Athlon 2400 512MB RAM with DOSBox 0.70). Eventually the hardware needed to run Win95 and Win98 and its software is going to be completely overtaken - give it 5 years and 32-bit support will probably begin to be phased out.

Of course. In much less than 5 years there will be a VM that will run our old Windows games with 3D acceleration. I guarantee it. Once WGF 2.0 comes out and all of the hardware is compliant and Vista SE or whatever they call it is released then I'm betting MS will implement their hypervisor support into their next client OS (it'll be in longhorn server later this year) and then Windows users can play their games in their guests. Hopefully they'll provide an emulated D3D card because obviously virtualizing a modern GPU won't help out old games that don't work well with modern GPU's.

Maybe virtualisation is a better solution in the short-term, but in the long term it would be better if an environment was available that offered complete control over the system emulated, including processor speed.

I don't see MS/Vmware working on emulated processors....they love their virtualization which sadly is not good for older games. I think we'll have to look towards open source Qemu\Dosbox for our emulation needs.

Actually WINE is one part of the puzzle, especially if we'd like to create an open-source retro Wingaming environment that doesn't require a copy of Windows to run (like DOSBox with MS-DOS). And in the short-term WINE is a good solution - but again, not long term.

Yeah, I don't know what WINE's longterm goals are. There has been alot of work put into it and their code is used in alot of other projects but as you state I don't know how usefull it will be in the long term and it's not usefull as a one-stop solution to gaming.

frobme wrote:

WINE is a stupendous product (being able to run WoW on a 64-bit Linux is particularly amusing), but it makes little to no effort in one crucial area to games: device level hardware compatibility.

This is of course, one of the main purposes of DOSBox, directly emulating non-existing hardware. So I can see where the original poster is coming from, as your copy-protected game Foo is not going to run under WINE, since as we all know Wine Is Not an Emulator, and it won't support the esoteric usage of the CDROM drive by the protection or the goofy ring-0 driver somebody wrote.

Why should a windows (non-)emulator emulate any special hardware? It is windows, after all, it just needs to emulate APIs. That's the great advantage. some CD-ROM copy protection mechanisms are working in Wine and is being worked on generally, there have been several architectural changes just for these ring-0 driver issues. It's not as far as WineX (aka Cedega), but there is progress.

WGF 1.0 and even XP drivers shoud be more than enough to support 3D acceleration on host (they support very primitive multithreading and resource managing, but it's not a problem if you have only one 3D application running and/or disable the lovely 3D desktop).

As far as I understand: work that needs to be done here is within the VM, and for the guest OS. In virtual machine user will need to install custom "stub" windows 3D driver which talks to VM code that wraps around host 3D API (wmware already uses such driver for faster 2D drawing performance). Essentialy this should be similar to Wine D3D-OGL translation, just that this should be more compatible as wrapper kernel interfaces are below native MS D3D libraries.
I don't think that emulating 3D card hardware makes sense, even Voodoo1 emulation would probably be dead slow, and virtually no games talk to 3D cards directly anyway.

That said, unless (hardware based?) CPU virtualisation is used, Dosbox probably doesn't have good enough performance to pair it with late 90's 3D games, especially as some tend to use MMX and later instruction sets. So better target for this is (open source) virtualisaton software.