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

Date:May 25, 2006 / year-entry #179
Tags:history
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20060525-04/?p=31073
Comments:    20
Summary: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...

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:
    May 25, 2006 at 11:46 am

    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:
    May 25, 2006 at 1:15 pm

    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. Raymond Chen - MSFT says:
    May 25, 2006 at 1:19 pm

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

  4. Jonathan says:
    May 25, 2006 at 1:47 pm

    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:
    May 25, 2006 at 5:33 pm

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

  6. Gabe says:
    May 25, 2006 at 5:43 pm

    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:
    May 25, 2006 at 6:22 pm

    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:
    May 25, 2006 at 7:32 pm

    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:
    May 25, 2006 at 2:19 pm

    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:
    May 25, 2006 at 9:47 pm

    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:
    May 25, 2006 at 3:03 pm

    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:
    May 26, 2006 at 3:41 am

    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:
    May 26, 2006 at 4:11 am

    Debug not the program, you must.

  14. Roger says:
    May 27, 2006 at 9:29 pm

    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:
    May 28, 2006 at 9:03 am

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

  16. bork says:
    May 30, 2006 at 5:47 pm

    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:
    May 30, 2006 at 9:03 pm

    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:
    May 30, 2006 at 10:04 pm

    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:
    May 31, 2006 at 1:43 am

    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:
    May 31, 2006 at 1:43 am

    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.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index