VOGONS


First post, by ONIXLabs

User metadata
Rank Newbie
Rank
Newbie

NTVDMEX — a new NTVDM for Windows XP

Today I'm publishing the first public build of NTVDMEX, a from-scratch replacement for ntvdm.exe, the part of Windows XP that runs MS-DOS and 16-bit Windows programs.

It's an alpha. It runs on Windows XP SP3, 32-bit, and nowhere else. But it runs Doom, Duke Nukem 3D, Skyroads, Wolf3D, Lemmings, and Windows 3.x's Paintbrush, Notepad and Calculator, and a whole host of other games and applications, each in its own window on the XP desktop.

Download v0.1.0-alpha on GitHub: https://github.com/MrMatthewLayton/ntvdmex/re … ag/v0.1.0-alpha

What NTVDM is, and why replace it

When Windows XP starts a 16-bit program, it hands it to a support process: the NT Virtual DOS Machine, ntvdm.exe. NTVDM gets the processor into Virtual-8086 mode, lets the program's code run on the real CPU, and steps in whenever the program asks the machine for something: a DOS call, a BIOS service, a video mode, a sound card, a timer.

Stock NTVDM was built for business software. It never emulated a Sound Blaster (properly), and many games' graphics and timing were beyond it. People got by with add-ons (like VDMSound), or gave up and moved to DOSBox, which emulates the whole PC in software.

NTVDMEX takes the other road. It is not an emulator. Like the original, it uses the NT kernel's own support for DOS machines, so 16-bit code runs at the speed of the real processor, and it reimplements everything the program asks of the machine:

DOS: a DOS kernel of its own, with XP's own COMMAND.COM running on top of it.
Devices: VGA and VESA graphics, Sound Blaster, OPL (AdLib) music, MIDI, the mouse, joysticks and the timers games depend on.
Protected mode: a DPMI host, so DOS extenders work. Doom, Duke Nukem 3D and other DOS/4GW games run in 32-bit protected mode, still on the real CPU.
Windows 3.x: NTVDMEX runs XP's own 16-bit KERNEL, USER and GDI as the guest's Windows, and implements the 32-bit side they call into. Each Windows 3.x window is a real XP window, with XP's theme, sharing the desktop with everything else.

What's in the alpha

Confirmed by hand on a real Windows XP SP3 machine with this build:

DOS: Doom (with sound and mouse), Duke Nukem 3D, Skyroads, Mario.
Windows 3.x: Paintbrush, Notepad, Calculator.

Earlier builds have also run Lemmings, ZAR, QuickBASIC 4.5 (including Make EXE), QBasic and EDIT. Programs run windowed or fullscreen, several at once, each in its own window, and a tray icon manages them all.

Plenty will not work yet. That's what an alpha is for.

Trying it

You need Windows XP SP3, 32-bit, on a real machine or in a virtual machine. (64-bit Windows has no Virtual-8086 mode, so there will never be a 64-bit NTVDMEX...well, there might be one day, but it will be a lot more work)

1. Download the zip, check it against SHA256SUMS, and extract it anywhere.
2. Run install.bat as an administrator.
3. Close any DOS or 16-bit programs that are already running, or reboot.
4. Run smoke.bat. It should say PASS.
5. Run DOS and Windows 3.x programs the way you always have.

Installing changes one registry value and overwrites nothing: Windows' own NTVDM stays on disk, untouched. status.bat tells you which one is in charge, and uninstall.bat gives the machine back to stock NTVDM.

Known issues

The ones you're most likely to meet:

  • ZAR's sound sometimes fails to start. Quit and start it again.
  • Saving files fails in Windows 3.x Sysedit and Write, and some Windows 3.x programs draw or close wrongly.
  • Leaving fullscreen can leave the fullscreen picture on the desktop.
  • Doom's sound effects are about 98% there.
  • DOS programs always open their own window, rather than running inside the console that started them.
  • On some machines, DOS/4GW games have run very slowly, and the cause isn't known yet.

The [release notes](https://github.com/MrMatthewLayton/ntvdmex/re … ag/v0.1.0-alpha) link each one to its issue.

How it was built

A few principles have shaped NTVDMEX, and they're worth saying out loud.

Clean room. NTVDMEX contains no Microsoft code and never will. What it knows comes from published specifications, from black-box measurement, and from studying the interface XP expects a DOS machine to provide. Anyone who has seen the source or internal design of NTVDM, WOW, Windows 3.x or MS-DOS, however they saw it, is welcome to contribute, just not to the parts of NTVDMEX that do the same job. [CLEAN-ROOM.md](https://github.com/MrMatthewLayton/ntvdmex/bl … n/CLEAN-ROOM.md) has the details.

The specification first, then the programs. A device is implemented because it's part of the period-correct PC, not because one game happened to need it. Small test programs ask the machine one question each: an interrupt, a register, a status bit. They ask it of NTVDMEX and
of reference machines: real MS-DOS 6.22, XP's own NTVDM, and other implementations. Where the reference machines agree, that's the answer. Where they disagree, the decision is written down. NTVDMEX never gets a vote on what's correct; it's the thing being tested. Games come after, as the acceptance test.

Real hardware. A virtual machine can't test everything that matters here. Before anything is released, it runs on a real XP machine, and a person plays the games and listens to the sound. No counter stands in for that.

One build, tested, then published. Every change goes through a pull request. CI builds it for XP, runs over 3,000 checks that don't need Windows at all, and enforces the code style. A release is the exact zip that CI built and that was then tested on XP. Nothing is rebuilt after the test.

Engineered with AI. All software engineering was done with AI (Claude). I have been a professional software engineer for almost 20 years. I knew what to ask for, and how to guide the process. AI is the reason I was able to build NTVDMEX before the heat death of the universe. If your immediate reaction to that is to call it "AI Slop", then so be it. Believe me, it's no skin off my nose. I built it for me. I'm sharing it with you.

What's next

The issue tracker (https://github.com/MrMatthewLayton/ntvdmex/issues) holds everything open. Next up are the host's user interface, more Windows 3.x programs, and closing the gaps the alpha turns up.

How you can help

Try it, especially on hardware I don't have, and on the programs you care about. When something fails, open an issue (https://github.com/MrMatthewLayton/ntvdmex/issues/new/choose) with the program, what you expected, what happened, and the log from debug\out\ntvdmhost.log.

Contribute. It cross-compiles on macOS or Linux, and most of the logic is tested without Windows. CONTRIBUTING.md (https://github.com/MrMatthewLayton/ntvdmex/bl … CONTRIBUTING.md) explains how, and there are issues labelled good first issue (https://github.com/MrMatthewLayton/ntvdmex/la … 20first%20issue) to start on.

NTVDMEX is MIT-licensed.
https://github.com/MrMatthewLayton/ntvdmex

Reply 1 of 4, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

You can't call it a clean-room implementation if it was written by AI.

Reply 2 of 4, by digger

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote on Today, 15:57:

You can't call it a clean-room implementation if it was written by AI.

It can be. Have an AI agent decompile and analyze the code using something like REA, and instruct it to write a specification/reimplementation/API document that does not contain any encumbered code. The document should describe interfaces and behavior only. No implementation logic.

Then, in a different totally clean context, feed an AI agent that document and tell it to write a new implementation from scratch, based only on that document.

Reply 3 of 4, by eM-!3

User metadata
Rank Newbie
Rank
Newbie
ONIXLabs wrote on Today, 14:02:

It runs on Windows XP SP3, 32-bit, and nowhere else.

I will try to test it on Windows Server 2003. I hope you will cover other 32-bit OSes later on.

jmarsh wrote on Today, 15:57:

You can't call it a clean-room implementation if it was written by AI.

I don't think this clean room etc. is really required here as this program is not competing with MS but enhancing their old OS capabilities. Just like game mods or song remix.

Anyway, I really wouldn't mind to see some better versions of old MS tools for very old OSes based on leaked sources even with it being questionable from legal point of view.

Reply 4 of 4, by ONIXLabs

User metadata
Rank Newbie
Rank
Newbie
eM-!3 wrote on 52 minutes ago:
I will try to test it on Windows Server 2003. I hope you will cover other 32-bit OSes later on. […]
Show full quote
ONIXLabs wrote on Today, 14:02:

It runs on Windows XP SP3, 32-bit, and nowhere else.

I will try to test it on Windows Server 2003. I hope you will cover other 32-bit OSes later on.

jmarsh wrote on Today, 15:57:

You can't call it a clean-room implementation if it was written by AI.

I don't think this clean room etc. is really required here as this program is not competing with MS but enhancing their old OS capabilities. Just like game mods or song remix.

Anyway, I really wouldn't mind to see some better versions of old MS tools for very old OSes based on leaked sources even with it being questionable from legal point of view.

In terms of OS support, the post says Windows XP SP3 because that's the only place it's been tested, but it may well work on older service packs too, and I'd never actually considered Windows Server 2003 either.

But yes, I would like to support other OS's in future. Windows 2000, and Windows 7 should be relatively trivial to do (though initial tests on Windows 2000 failed because it doesn't have the same vectored exception handler API that Windows XP does).

The challenging bit will be supporting 64 bit OSs and non-Microsoft OSs, as both come with REALLY non-trivial problems to solve.