13 Mar 2014

43086

6

NTVDM progress

A while back Aleksander Andrejevic began working on a NTVDM implementation for ReactOS to support 16bit programs. This was one of the more often requested features by the community, which was met with some ambivalence by the developers themsleves since it entailed a significant amount of work. Aleksander then appeared and instead of simply asking for the feature, rolled up his sleeve to do the actual work. Since then NTVDM has made significant progress and other developers like Hermès Bélusca-Maïto and community member Vampyre have joined in to help. This post will give a brief summary of what work has been completed and what remains to be done.

NTVDM is composed of quite a few pieces and is in effect a virtual machine in its own right, tightly integrated into the operating system to provide a seamless experience. For NTVDM, emulation support has been implemented for a 486-compatible CPU, very basic video, basic memory management, basic sound, a 32bit BIOS, and 32bit DOS. Quite a few things are still missing though, including in the previously listed features. For example, video support does not exist for VESA+ or EGA fonts. Sound only works via the internal PC speaker, not through an emulated SoundBlaster. The CPU emulator also does not have a floating point unit.

Other missing bits revolve around the actual integration with the operating system. Right now to run a DOS program NTVDM must be called explicitly by a user to start the program. The end goal is for users to be able to simply click on a program and have NTVDM automatically start. This requires some work in the CSRSS, which will also be responsible for deciding whether to start a new instance of NTVDM or reuse an existing one. The latter feature is especially important for Terminate and Stay Resident programs, which include a lot of games.

One thing to note about ReactOS' NTVDM is that unlike Windows' version ReactOS' does not set the CPU into a 16bit emulated mode. This mode in theory reduces overhead compared to the emulation done by ReactOS, but CPUs these days are fast enough that performance should not be an issue. An advantage of ReactOS' approach though is that our NTVDM is usable on 64bit x86 processors and potentially ARM processors as well.

Overall NTVDM has seen significant progress over the past year and there is an expectation that it will soon be ready for merging back into trunk. Even then it will not be complete, but at least then it should be easier for interested testers to play around with it.

Comments (6)

  • anon

    I am admittedly out of my depth here since large scale programs and OS's are not my thing, but I have potentially stupid question to ask.

    Given that you are going with a VM route that should allow DOS even on arm processors.

    Is there a way to use Bochs as a VM?
    Perhaps the code could be repackaged somehow?
    It already does sound and networking, has programmable hardware and compiles well.
    Large projects like this are not my area of expertize though so ther may be lots I don't realize.

    I have a customized version I use for running old dos software in order to bring data forward.
    I have also used it to trace execution of programs, to study CPU states, etc, and it has rarely let me down.

    Perhaps some answers can be used or reused from there.
    Why reinvent the wheel when you can reimplement it instead?

    Doors.

    Mar 14, 2014
  • anon

    As I have often stated in the past, the reusability of existing code is not a given. While I do not recall the specifics, I do know that Hermes and Alexander examined several potential emulation platforms to see if they were suitable to use as a basis for NTVDM. Their conclusion was that adapting them to fit into the NTVDM architecture would have been more work than just writing something from scratch.

    Mar 14, 2014
  • anon

    Not to mention that it is cleaner & more manageable in long run. :D

    Mar 14, 2014
  • anon

    Raymond Chen of Microsoft writes a blog named The Old New Thing.

    His posts "If there is no 16-bit emulation layer in 64-bit Windows, how come certain 16-bit installers are allowed to run?" (31 Oct 2013) and "Why 16-bit DOS and Windows are still with us" (1 Mar 2004) and the comments that follow illustrate some of the difficulties that have to be overcome.

    Mar 14, 2014
  • anon

    "important for Terminate and Stay Resident programs, which include a lot of games."
    I don't quite understand this one. There were not many TSR games, at least I can't remember any right now. Unless you were referring to mouse/disk cache/VESA drivers, but in this case it will be better to incorporate them directly in the VM and bridge them to the underlying OS implementation.

    Mar 14, 2014
  • anon

    Maybe the "lot of games" was a bit excessive (I'm not a gamer, and not from the DOS era, so I don't have any idea on that); however there are other applications that need them. Also, a typical example of TSR targeting NT is the VDDSound which comprises a TSR program which loads a VDD to offer SoundBlaster sound into NTVDM. There's also another VDD+TSR (that I don't remember its name) which allows you to emulate VESA display, also in NTVDM. And so on...

    Mar 15, 2014
This blog post represents the personal opinion of the author and is not representative of the position of the ReactOS Project.