Probably a stupid question, but...

If it doesn't fit anywhere else, drop it in here. (not to be used as a chat/nonsense section)

Moderator: Moderator Team

Post Reply
MugenFighter
Posts: 333
Joined: Tue Feb 24, 2015 6:03 pm

Probably a stupid question, but...

Post by MugenFighter »

If ReactOS's NTVDM uses an emulated CPU core than how is it different from DOSBox? I have no problem with ReactOS's NTVDM, but I am curious.
I'm a MugenFighter, but not the one you are thinking about. I'm actually MugenFighterTube. Now don't ask about MugenFighter's characters.
hbelusca
Developer
Posts: 1204
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Probably a stupid question, but...

Post by hbelusca »

MugenFighter wrote:If ReactOS's NTVDM uses an emulated CPU core than how is it different from DOSBox? I have no problem with ReactOS's NTVDM, but I am curious.
First of all, our NTVDM uses our own (well, Aleksandar Andrejevic's own :) ) emulated CPU (called "Fast486"), which is currently an interpreter-type CPU emulator that fully emulates an Intel 486 CPU: it is not a dynamic recompiler. On the contrary, DosBox has both (when you use "CPU simple", you use the interpreter, while if you use "CPU fast" or "dynarec", you use the dynamic recompiler). The advantage of the interpreter-type CPU is that it's completely trivial to port its (emulation) code to other host architectures (by that I mean, having the same code that emulates the same CPU, being able to run on different architectures like, x86, x64, arm, whatever): you just recompile it. The main drawback however is that it's slow, because for each CPU instruction to be emulated it has to run many host instructions, and is not actually optimized to run on the host architecture. On the contrary, a dynarec recompiles on the fly (with many optimizations) the emulated code into host instructions. However, the associated disadvantage is that it's harder to port it to other host architectures (you basically have to "mostly" rewrite it).

DosBox' main purpose is also to have a wide coverage of DOS-emulated games that can be run "fast", however, at the expense of some shortcuts in the emulation, while ReactOS' NTVDM was written with "completeness" (in CPU functionality) in mind. As a result, while stuff run within ReactOS' NTVDM will be slower than on DosBox, you may find that it can successfully run programs like FASM in those exotic CPU modes like 32-bit "unreal mode", while DosBox (unless they fixed it recently), cannot. Of course, this has to be moderated by the fact that the rest of our (hardware) emulation may not be perfect / complete... (hence you can for example still find some little bugs when an app uses some graphics mode etc...)

Finally, ReactOS' NTVDM was also written in the same mind as the Windows' NTVDM: to be tightly integrated to the rest of the OS. This means that it is automatically started by the core components when a DOS application (or an application detected as such) is started (and the same will be true when we'll support Win16 emulation), and it can exploit all the gory undocumented console APIs to do its display (e.g. the console graphics screenbuffers). Thus, while our NTVDM will also work on Windows 2003 (after you replace the Windows' version by ours), the drawback is that it won't work on other Windows versions where those undocumented interfaces have changed. This is what happens on x64 versions of Windows (Vista+) where the core components do not call ntvdm anymore when a DOS application is run (instead they load a "ntvdm64.dll" that will pop up an unsupported error message), and, on Windows 7+, a bug they have introduced in their implementation of the console graphics screenbuffers leads to the inability for our NTVDM (when being run on x86 versions of these OSes) to use them anymore (however, text mode will still work). The choice of tight integration to the OS (as done as on Windows) was also chosen for "documentation" purposes (to document how the similar thing actually works on Windows; that's by the way the whole purpose of the ReactOS project).
MugenFighter
Posts: 333
Joined: Tue Feb 24, 2015 6:03 pm

Re: Probably a stupid question, but...

Post by MugenFighter »

hbelusca wrote:
MugenFighter wrote:If ReactOS's NTVDM uses an emulated CPU core than how is it different from DOSBox? I have no problem with ReactOS's NTVDM, but I am curious.
First of all, our NTVDM uses our own (well, Aleksandar Andrejevic's own :) ) emulated CPU (called "Fast486"), which is currently an interpreter-type CPU emulator that fully emulates an Intel 486 CPU: it is not a dynamic recompiler. On the contrary, DosBox has both (when you use "CPU simple", you use the interpreter, while if you use "CPU fast" or "dynarec", you use the dynamic recompiler). The advantage of the interpreter-type CPU is that it's completely trivial to port its (emulation) code to other host architectures (by that I mean, having the same code that emulates the same CPU, being able to run on different architectures like, x86, x64, arm, whatever): you just recompile it. The main drawback however is that it's slow, because for each CPU instruction to be emulated it has to run many host instructions, and is not actually optimized to run on the host architecture. On the contrary, a dynarec recompiles on the fly (with many optimizations) the emulated code into host instructions. However, the associated disadvantage is that it's harder to port it to other host architectures (you basically have to "mostly" rewrite it).

DosBox' main purpose is also to have a wide coverage of DOS-emulated games that can be run "fast", however, at the expense of some shortcuts in the emulation, while ReactOS' NTVDM was written with "completeness" (in CPU functionality) in mind. As a result, while stuff run within ReactOS' NTVDM will be slower than on DosBox, you may find that it can successfully run programs like FASM in those exotic CPU modes like 32-bit "unreal mode", while DosBox (unless they fixed it recently), cannot. Of course, this has to be moderated by the fact that the rest of our (hardware) emulation may not be perfect / complete... (hence you can for example still find some little bugs when an app uses some graphics mode etc...)

Finally, ReactOS' NTVDM was also written in the same mind as the Windows' NTVDM: to be tightly integrated to the rest of the OS. This means that it is automatically started by the core components when a DOS application (or an application detected as such) is started (and the same will be true when we'll support Win16 emulation), and it can exploit all the gory undocumented console APIs to do its display (e.g. the console graphics screenbuffers). Thus, while our NTVDM will also work on Windows 2003 (after you replace the Windows' version by ours), the drawback is that it won't work on other Windows versions where those undocumented interfaces have changed. This is what happens on x64 versions of Windows (Vista+) where the core components do not call ntvdm anymore when a DOS application is run (instead they load a "ntvdm64.dll" that will pop up an unsupported error message), and, on Windows 7+, a bug they have introduced in their implementation of the console graphics screenbuffers leads to the inability for our NTVDM (when being run on x86 versions of these OSes) to use them anymore (however, text mode will still work). The choice of tight integration to the OS (as done as on Windows) was also chosen for "documentation" purposes (to document how the similar thing actually works on Windows; that's by the way the whole purpose of the ReactOS project).
Wow I that's pretty cool.
I'm a MugenFighter, but not the one you are thinking about. I'm actually MugenFighterTube. Now don't ask about MugenFighter's characters.
Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests