Using Yoda on an x86 may be hazardous to your systems’ health


In former times very cross-platform NTVDM was.

If you view NTVDM.EXE in a hex editor, you'll find the message "Using Yoda on an x86 may be hazardous to your systems' health" buried inside it. Yoda was the name of the internal debugger that was used to debug the MS-DOS emulator, also known as the Virtual DOS Machine or VDM. (Buried inside the Yoda source code are such wonderful variables as "luke" and "chewy".)

The Intel 80386 has a mode known as "Virtual-8086 mode" or just "V86 mode" wherein the CPU ran as if it were an 8086, except that if the program did anything interesting like issue a privileged instruction, call a software interrupt, or fault, control would return to the protected-mode supervisor for handling. (Win386 used this same CPU mode to support multiple MS-DOS sessions.) When running on an 80386-class processor, NTVDM used this mode to do its emulation, making the CPU do the heavy lifting of decoding instructions and emulating them, which took place at very close to full speed.

On the other hand, NTVDM on the non-x86 processors (Alpha, PPC, MIPS, etc.) had to implement an entire 8086 emulator, with all the decoding and execution performed in software. Yoda was the debugger you used if you needed to debug the emulator.

And that's why NTVDM has a message warning you not to use Yoda on an x86. Because on an x86, there is no instruction emulator. There is nothing to debug.

(My thanks to Andrew McLaren and Tony Gaston for providing historical background.)

Comments (20)
  1. Yoda says:

    I need to update my blog… but I’m the server that supports the blog site of http://www.msmvps.com … and I’m uh.. well yes, I am an x86 box.

  2. DriverDude says:

    Why would debugging "nothing" be considered harmful? Is it hazardous to debug the actual CPU? (Granted, Intel might take offense)

    I heard AMD64 (EM64T on Intel) does not support V86 mode when the CPU is in 64-bit mode. Therefore WinXP x64 does not run 16-bit DOS apps. If I could find one, I would try it…

    How about putting in the non-x86 NTVDM into WinXP x64, you know, for backwards compatibility?

    :=)

  3. How do you set a breakpoint on a function that doesn’t exist?

  4. Jonathan says:

    DriverDude – that could work for using DOS apps, but wouldn’t help the Win16 situation out any.  The thing you have to ask is, is it worth the cost?  I’m sure there’s much better things for developers to work on than getting DOS emulation in Win64.

  5. Andrew Feldstein says:

    Ahhhh, the 386.  The first box I ever built for myself was a 386.

  6. Gabe says:

    I’m surprised more people aren’t complaining about lack of 16-bit support in Win64. I know there has got to be a Fortune 500 out there with a mission-critical app that requires some OCX that uses a 16-bit installer, or something silly like that.

    Maybe those people just haven’t trie to run Win64 yet? Or maybe they tried it and it didn’t work, so they went back to Win32.

  7. MYG says:

    Gabe: I believe Wow64 has some kind of a special hack to allow 16-bit installers to work. Basically, if the isntaller package is recognized, the install is performed with 32-bit code.

  8. Jules says:

    Gabe: 16-bit Windows code should still work, as that runs in 286 protected mode, not Virtual86 mode which emulates real mode (e.g. DOS or thunking to BIOS calls).

  9. DriverDude says:

    I would think setting a non-existant function BP would be a "symbol not found" error? That being the case, perhaps "using Yoda on an x86 may be hazardous to your *mental* health." :=)

    I was half-joking about putting NTVDM into Win64… time to move forward.

  10. 16-bit says:

    16-bit windows (3.0) could run in real mode, with 16-bit windows program, which of course also was running in real mode. No 286 code there.

  11. Daniel says:

    Aha, so *that* is what it means… Was the x86 emulator perhaps based on Insignia SoftPC?  I vaguely remember seeing some text about it in a hex dump.

  12. Myria says:

    Technically, you can still run 16 bit code in Win64, but none of the Win16 code is there.  x64 supports 16 bit protected mode segments.  The only thing it doesn’t support is V86 mode.

    This means if you use NtSetLdtEntries you can allocate yourself a 16 bit segment and use it, even from a 64-bit process.  Not that I recommend doing so.

    Melissa

  13. 8 says:

    Debug not the program, you must.

  14. Roger says:

    Regarding x64 XP and 16bit windows installers, there are still modern enterprise apps that install using the 16 bit wise installer, and there is no hook for running the 32bit equivalent. (SQL Navigator by quest software. I’m looking at you).

    This means you end up having to run either vmware/virtual server. Or (b) run one of those watch your systems/repackage type installers.

    Ironic that a program as good as SQL navigator that works fine under x64 (once you solve it’s issues with Program Files/Program Files (x86), is hamstrung from running on x64 by the average person purely because of the 16bit installer.

    I’m sure there are other mainstream programs that suffer the same fate. Not Microsoft’s fault but annoying none the less.

  15. steveg says:

    Glad to see some light-hearted variable names. Life is too short to bSerious all the time.

  16. bork says:

    16bit wine works just fine.

    I find it quite ironic that Linux happens to be more

    compatible to old Windows than Windows itself.

  17. mikeb says:

    Raymond:

    Thanks for clearing up the Yoda message – I recall trying to Google an answer many moons ago, but was unable to resolve the mystery.  Now, I can move on…

    As for the people who are worried about 16-bit support on x64, there are plenty of good emulation environments including Virtual PC/Server and VMware.  And of course, there’s always eBay, in case you find yourself in need of 16-bit hardware.  

    I don’t think anyone will have serious problems running 16 bit apps that they really want to run.

  18. Norman Diamond says:

    Tuesday, May 30, 2006 5:47 PM by bork

    > I find it quite ironic that Linux happens

    > to be more compatible to old Windows than

    > Windows itself.

    That just shows how far behind the times Linux is J

    In fact if you look hard, you’ll find Linux compatibilities with an OS that was invented in 1969.  Compare that with whitepapers that change with each version of Windows describing the latest way to migrate from Unix to Windows J

  19. Gabe says:

    Actually, I suspect that it would be easier to get Linux to run a Windows program that was compiled 10 years ago than a Linux program that was compiled 10 years ago.

  20. Gabe says:

    Actually, I suspect that it would be easier to get Linux to run a Windows program that was compiled 10 years ago than a Linux program that was compiled 10 years ago.

Comments are closed.