How did Windows ME “cripple” DOS?

Question

Windows ME includes the ability to create a bootable DOS floppy. This floppy contains versions of COMMAND.COM and IO.SYS that are "crippled" to remove real mode. This is done with only one changed byte in each - it is easy enough to change this back to re-enable real mode in the image:

* COMMAND.COM and IO.SYS from diskcopy.dll are from the WinME crippled version  
* that removed real mode DOS => they must be patched:  
* IO.SYS            000003AA          75 -> EB 
* COMMAND.COM       00006510          75 -> EB 

(Direct source, Closer to original source)

How do these patches work? Why is it so easy to re-enable real mode? (The patch is too similar in both for this to be accidental.) Why was real mode disabled instead of just being unused?

Answer 1

There's actually two versions IO.SYS and COMMAND.COM used with Windows ME. The normal "crippled" versions used to boot from hard disks, and the "Emergency Boot Disk" versions use to boot from floppies. It's those later EBD versions that are embedded in diskcopy.dll under Windows XP, Windows Vista, Windows 7 and Windows 8.

The EBD versions are crippled in only one respect, they can't be used to boot off a hard disk. This is what the patches you quoted actually are meant to fix. The unpatched EBD versions of IO.SYS and COMMAND.COM fully support booting into real mode MS-DOS, as that is their sole purpose. The files CONFIG.SYS and AUTOEXEC.BAT are fully supported in the EBD version.

The crippled version that Windows ME normally uses to boot from a hard disk doesn't support CONFIG.SYS and won't boot to a real mode command prompt and instead will always start Windows. It will process the AUTOEXEC.BAT file but Windows ME will remove anything from AUTOEXEC.BAT that does anything other than setting an environment variable.

Another related issue with Windows ME is that the version EMM386.EXE included with it is broken, preventing it from being used on Windows ME EBD floppies.

---

Technical Description of the Patches

Here's a disassembly of the code in the EBD version of IO.SYS that is changed by the patch:

seg000:03A4                 mov     dl, [bp+?dos_internal.?vbr.?vbr_24]
seg000:03A7                 cmp     dl, 80h
seg000:03AA                 jnz     short loc_3B5
seg000:03AC                 lea     si, [bp+?dos_internal.?error_invalid_system_disk_2]
seg000:03B0                 push    cs
seg000:03B1                 pop     ds
seg000:03B2                 jmp     ?print_error_and_reboot
seg000:03B5
seg000:03B5 loc_3B5:
seg000:03B5                 mov     dh, [bp+?dos_internal.?vbr.?bpb.?media_id_byte]
seg000:03B8                 pop     di
seg000:03B9                 mov     ax, cs:word_7FA
seg000:03BD                 mov     bx, cs:word_7FC
seg000:03C2                 jmp     far ptr 70h:0

This what the relevant code looks like before being patched. The names starting with question marks (?) in the disassembly were made up by me.

The code above compares the BIOS disk number stored in the volume boot sector (?vbr_24) to 80h, which is the BIOS disk number for the first hard disk. If these numbers are equal then IO.SYS was booted from a hard disk and it results in the jnz short loc_385 instruction not jumping to loc_385 and instead falling through to the following instructions. These instructions result in the code jumping to a routine that prints the message "Invalid system disk" and then rebooting the computer when the user press a key.

When IO.SYS is booted from a floppy ?vbr_24 will contain the value 0 (zero) which is the BIOS disk number for the first floppy drive. This results in the comparison not being equal and the jnz short loc_3B5 statement jumping to the code at at the loc_3B5 label. This causes IO.SYS to proceed to boot normally, the jmp far ptr 70h:0 instruction jumps to the main IO.SYS entry point.

The patch changes the jnz short loc_3B5 instruction to a jmp short loc_3B5 instruction. This causes the code to always jump to loc_3B5 regardless of the result of the comparison, so IO.SYS always boots normally regardless of whether it was booted from a floppy or a hard disk.

The patched code in the EBD version of COMMAND.COM is more obscure. It apparently checks to see if its being started during a hard disk boot before Windows has loaded. If so then it prints (I believe) the message "Please press CTRL+ALT+DELETE to restart your computer" and halts the computer. This check is apparently done to prevent restoring normal AUTOEXEC.BAT processing by replacing the crippled hard disk version of COMMAND.COM with the otherwise uncrippled COMMAND.COM from a EBD floppy.

While the patch to COMMAND.COM also changes a JNZ instruction to a JMP instruction, the code being changed is actually quite different. It's only a coincidence that code can be effectively disabled by the same single byte change used for IO.SYS. Also note that the code Microsoft added to IO.SYS and COMMAND.COM (relative to the completely uncrippled versions used in Windows 95 and Windows 98) was more than a single byte change. In the disassembly above the entire sequence of instructions from address to 03A4 to 03B2 inclusive wouldn't have been present in previous versions of IO.SYS.

Answer 2

EB is short jump relative. 75 is short jump if not equal. So Microsoft replaced a conditional jump with an unconditional one to prevent entry to a certain section of code — presumably there was a path that goes one way if installed on a hard disk, another if installed on a floppy disk, and Micorsoft hard-wired it always to act like it was on a floppy disk.