How come you think there's even a single dos game that would not
require emulation of privileged instructions on your (pretty protecting) OS?

wd wrote:

How come you think there's even a single dos game that would not
require emulation of privileged instructions on your (pretty protecting) OS?

In english please 😁

No (==translation).

Vogons wrote:

wd wrote:

How come you think there's even a single dos game that would not
require emulation of privileged instructions on your (pretty protecting) OS?

In english please 😁

Translation->Code a solution yourself that works will all OS's and CPU types without emulation.

Good luck.

I guess you're asking about native execution, which is possible (to some extent) on a compatible host CPU. Look up info on QEMU+KQEMU or VirtualBox for examples of virtualizers that allow partial native execution with fallback to emulation. Perhaps DOSBox could do something similar, but it certainly seems like a lot of work to implement; and it might not fit in with the developers' plans for DOSBox, anyway.

Well it doesn't work. Virtualization is fine if the guest is nice, like 32bit user mode
or virtualization-aware 32bit OS code. But for anything that targets DOS you
HAVE to do lots of emulation, even for code in 32bit user mode (which usually
calls extender/bios/dos routines).
That's surely not the translation the poster is looking for.

Indeed, one has to look a bit harder for info about how well certain types of guest systems take advantage from such virtualization. It does not surprise me that DOS would require a lot of fallback to emulation. 😉

We should just program DOSBox to do a processor check for either protected mode/or a list of demanding games and not run if it's not a certain cpu type. 😉

@wd: fair enough.

@ripsaw8080: the type of virtualization I have tried is nowhere near as fast as the real thing. Basically I meant the ability to operate more like soundfx2000 in these cases, which doesn't emulate CPU whatsoever.

But with soundfx2000 (or VDMSound) you're talking about the NTVDM, or something like it, which is a virtualizer that basically does the kind of thing I was referring to: execute as much code natively as possible, and emulate the rest. As you probably know, the NTVDM is very quirky and has spotty compatibility with DOS programs, games in particular. I'm sure DOSBox would do a better job of emulating the hardware, but you're still talking about integrating native execution.

dosemu for Linux does more of what you're asking for, though the problem there... it's stuck on Linux. 🙁

Though it is great, it sucks for anything that isn't a modern DOS game without independent timing and speed throttling (i.e. the whole damn '80s)

wd wrote:

Well it doesn't work. Virtualization is fine if the guest is nice, like 32bit user mode or virtualization-aware 32bit OS code. B […]
Show full quote

Well it doesn't work. Virtualization is fine if the guest is nice, like 32bit user mode
or virtualization-aware 32bit OS code. But for anything that targets DOS you
HAVE to do lots of emulation, even for code in 32bit user mode (which usually
calls extender/bios/dos routines).
That's surely not the translation the poster is looking for.

Isn't DOSBox BIOS and DOS handling simulation? It's native code, not processed by the CPU emulation like executables. Slightly slower than original for some instances depending on extra overhead, but way faster than emulation.

someone should port dosemu to windows

The advantage of DOSEMU was its use of v86 mode, which because of stupid AMD, we don't have in 64bit mode(rather than have the project die off, they've since switched to using QEMU CPU core for execution.) I posted on vogons about a patent application by Microsoft I ran across, where they were looking to patent a method of switching back and forth between real and 64bit mode, doing so would allow the use of v86 mode. It's ludicrous that they're trying to patent an innate function of CPUs(I patent mov ax, immediate!,) but using that technique could speed up execution of 16bit code, aka DOS, to near full speed.

Isn't DOSBox BIOS and DOS handling simulation? It's native code, not processed by the CPU emulation like executables.

?
Neither is DOSBox BIOS and DOS handling simulation (whatever that means)
nor is it executing the target code natively. The dos/bios callback code is native
code but till the code flow gets there you'll have entered at least one mode switch.

The advantage of DOSEMU was its use of v86 mode

This is also its disadvantage because v86 mode can NOT provide a full virtualization
mode, just check how many hacks (re-enabling the interrupt flag periodically)
they needed just to run dos4gw games.

but using that technique could speed up execution of 16bit code, aka DOS, to near full speed.

Did you check what type of game the OP is talking about? There are only few games
that currently are too slow to play on an x86 system that are 16bit code, and using
a 64bit to 16bit mode switch when executing 16bit code does not sound of any use.

BIOS and DOS built in handling is simulation vs emulation like MESS. With MESS using a binary BIOS image and a disk image of DOS, the BIOS & DOS code is being processed by the CPU emulation. With DOSBox's built in BIOS and DOS, those functions are compiled like the rest of DOSBox, are native to the host. I was saying the BIOS and DOS functions are run natively, not the target code.

> Did you check what type of game the OP is talking about? There are only few games
that currently are too slow to play on an x86 system that are 16bit code, and using a 64bit to 16bit mode switch when executing 16bit code does not sound of any use.

The use is to be able to use what functionality is lost in 64bit mode.

The use is to be able to use what functionality is lost in 64bit mode.

Using something just because it is there won't help.

No kidding.