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?

  • 8
    The real question is....why would anyone use Windows ME in the first place? ;-) – cbmeeks Aug 2 '17 at 15:32
  • 3
    My conjecture: They wanted to officially demote any real mode DOS functionality as unsupported. Meaning they won't have to support it. – rackandboneman Nov 8 '18 at 22:19

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 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.

| improve this answer | |
  • I assumed that there was a helper utility that would switch to protected mode then start IO.SYS, MSDOS.SYS etc. and that both versions were the same. Thanks for clearing that up. – wizzwizz4 Jul 11 '17 at 6:22
  • It's unclear to me why this patch would need to be applied by a tool whose purpose is to create bootable USB media. Isn't that media booting in floppy-disk emulation mode? – Cody Gray Jul 11 '17 at 11:19
  • 2
    @CodyGray Based on the comment from the Rufus source code quoted in the question it appears that the authors don't know what the patch actually does. I'm guessing they also can't depend on BIOSes booting a USB drive in floppy emulation mode anyways. – Ross Ridge Jul 11 '17 at 21:06
  • 2
    My understanding is that USB boot on PC bioses emulates a hard drive, not a floppy. – Peter Green Sep 19 '18 at 18:41
  • @PeterGreen BIOSes can either emulate USB drives as either floppies or hard drives. If the BIOS hasn't been configured to use one or either then it'll will choose which to emulate automatically. The criteria can vary, but the 530MB limit on floppy drive emulator is often used as the deciding factor. – Ross Ridge Sep 19 '18 at 18:58

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.

| improve this answer | |
  • 1
    Actually, I've got this the wrong way around, and am about to lose service so cannot immediately fix it. Will delete and fix later if time allows. – Tommy Jul 10 '17 at 22:23
  • 5
    Updated and reinstated; since it mentions the meaning of EB versus 75 I think it still adds something as an answer. – Tommy Jul 11 '17 at 12:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.