Retrofitting DOS Mode to WinME
Out of the box, Windows ME has no hard drive based maintenance operating system. This mimics a limitation of NT, but the cause is different; whereas NT is a completely different OS that does not pass through a "DOS" phase during startup, Windows ME is a Win9x that has the standard "DOS" phase of startup modified so that it loses the capability of booting DOS mode instead.
There were two workarounds for this available via the web; this article also illustrates a third that is in my opinion the best of the three. There is a fourth approach that I have not developed, but will cover conceptually. But before we look at these solutions, we need to understand...
The problem
In previous Win9x, the first startup files were common for both DOS mode and Windows. This led to the simplistic conclusion that "Windows 9x runs on top of DOS". Perhaps as a populist response to the peanut gallery, or perhaps to condition consumers to the limitations of NT, Microsoft combined the initial boot files into a monolithic slab with the following effects:
When WinME starts up, Config.sys is ignored, and Autoexec.bat is processed only in that Set statements (as well as "convenience syntax" Prompt and Path statements) are incorporated into the global system variables. WinStart.bat is also ignored.
This means you can no longer load real-mode drivers (e.g. for old and poorly supported devices such as scanners or CD-ROMs), TSRs or run non-resident DOS programs, such as pre-boot virus scans. It also means that DOS applications requiring baroque Files, Buffers etc. settings on Emm386.exe access to UMB will not have their requirements satisfied. There's a workaround for Files settings, but that's as far as it goes.
When Windows shuts down or is restarted in the approved manner, it overwrites Config.sys and Autoexec.bat; in addition, WinStart.bat is used internally. This becomes a problem when designing a DOS mode retrofit.
A side effect of disrupting the "DOS" phase of startup is that there's no longer an opportunity to safely check the file system before Windows starts writing to it - which was the original purpose of automated Scandisk following a "bad exit". Instead, Scandisk operates in Windows mode while Windows is loading, and is often interrupted by writes to the file system. Scandisk.ini is present, but ignored; a poorer ability to control auto-ScanDisk is offered via the Advanced button within the Scandisk dialog box. Settings are prone to spontaneous slippage, and in any case are ignored unless you run a Scandisk session after setting them.
Solution 1: The "geocities" method
See http://www.geocities.com/mfd4life_2000
This is the best known method, and for many commentators, the only method known. Consequently, the whole notion of WinME DOS mode retrofit is tainted with problems particular to this method.
Pros:
Cons:
The approach involves editing core Windows ME code so that Windows ME boots into a DOS mode instead of loading Windows in the usual way. As Windows GUI mode is a complex beast, I'd be reluctant to hack its code, so I've passed on this method and can tell you no more about it.
See http://mvps.org/dts/WinME_DOS/Win-ME.htm
This method was developed by three talented MVPs, but is not part of any official MVP policy; indeed, some MVPs disassociate themselves from it and object to it being called the "MVP method".
Pros:
Cons:
This approach involves copying the DOS mode files from a suitable previous Win9x version; one that is FAT32-compatible if FAT32 is in use (typically, Windows 98 Second Edition). By changing the current copy of IO.sys, the system will either boot into WinME GUI or the older Win9x DOS mode. That means you have to choose which OS you want to boot, before restarting to put that into effect; you can't choose at boot time from an F8 boot menu.
But because WinME overwrites Config.sys and Autoexec.bat on shutdown, the DOS mode will boot up in a very poorly optimized form, with the wrong version of code pointed to by the WinME-appropriate Path statement. This leaves you in a netherworld, until you either explicitly run a .bat file that does what a .bat file can do to correct matters, or swap in appropriate Config.sys and Autoexec.bat files and reboot.
This is built on the shoulders of the "MVP method", and you should start there as the same file set is required to implement it. The difference is that the problem of overwritten Config.sys and Autoexec.bat is side-stepped by using other files instead.
Pros:
Cons:
A concern is, what happens if the changeover process is interrupted? You might end up with a mixture of startup files from both OSs and be able to boot neither. This risk is reduced in this method, because only IO.sys is changed; immutable template copies of WinME and DOS mode IO.sys are kept on hand, and one of these is copied over the active IO.sys to put that OS into active bootability. That is the only change required.
For various reasons, there's no canned downloadable version of this method. I'll descibe how it works, but it will be up to you to impliment it yourself, so I guess it's only suitable for those comfortable with the geekery involved. To set up this method, start by implementing Solution 2, and then extend this by editing the DOS mode copies of IO.sys and Command.com in the root of C: - observing the following cautions:
In other words, "rich" text editors such as Word, WordPad or HTML editors are right out, as are editors that can only display text, such as Notepad or DOS Edit. You want a "hex editor" that never deletes or inserts bytes, as doing so will break offsets within the file that are critical to the code's functionality.
Your objective is to locate and change all occurrences for file names "MSDOS.SYS", "Config.sys", "Autoexec.bat", "Command.com" and, for cosmetics, "Logo.sys". Choose names that have the same length as the originals, and note that Autoexec.bat is referenced as "Autoexec" with no extension specified (yes, that means that if no Autoexec.bat exists, Autoexec.com would be processed instead, etc.). You can use name such as BOOT.BMP for Logo.sys if you like; copy an existing Logo.sys to BOOT.BMP and edit to taste via Paint or whatever.
Finally, note that the forms of these names within the code may be any of "CONFIG.SYS", "CONFIGSYS", "CONFIG SYS" padded with spaces or nulls, etc. Be inventive in your Search and Replace, and be discerning too; don't do a blind S&R, use your eyes and wits to know what to change. If this sounds daunting, quit now.
When done, rename the edited DOS mode Command.com to the alternate name you used, and place that file in the root of C:, along with DOS mode appropriate alternate-named MSDOS.SYS, Config.sys, Autoexec.bat (and optionally for cosmetics, Logo.sys). You should end up with the following files in C:\
WinME template copy of IO.SYS, e.g. IO.ME
Edited DOS Mode template copy of IO.SYS, e.g. IO.DM
One or other of the above as IO.SYS
Edited alternately-named DOS Mode Command.com
Alternately-named DOS Mode MSDOS.SYS
Alternately-named DOS Mode Config.sys
Alternately-named DOS Mode Autoexec.bat
Alternately-named DOS Mode Logo.sys
WinME Command.com, MSDOS.SYS etc.
In the alternatively-named DOS mode MSDOS.SYS, edit the [paths] section to point to the subtree that contains your DOS mode code files, e.g. WinDir=C:\ME-DOS, WinBootDir=C:\ME-DOS etc. Any Path statements in the alternatively-named DOS mode Config.sys and Autoexec.bat should reference the DOS mode subtree, not the Windows Millennium installation, i.e. Path=C:\ME-DOS;C:\ME-DOS\Command rather than C:\Windows;C:\Windows\Command etc.
To swap from one OS to the other, first strip the attributes off C:\IO.SYS, then copy over the appropriate version from the relevant template copy. Because you want this process to work from either OS, it's best to explicitly use both versions of the Attrib command, knowing that one will fail with an "incorrect version" error. For example...
:: ME-DOS.BAT
@Echo Off
C:
CD \
C:\Windows\Command\Attrib.exe -r -s -h C:\IO.SYS
C:\ME-DOS\Command\Attrib.exe -r -s -h C:\IO.SYS
CLS
Echo.
Echo Selecting DOS Mode for next bootup...
Echo.
Copy /Y C:\IO.DM IO.SYS
Echo.
Echo The next boot will restart in DOS mode (IO.SYS = IO.DM)
Dir C:\IO.* /A
Echo.
Pause
Echo.
:: WINME.BAT
@Echo Off
C:
CD \
C:\Windows\Command\Attrib.exe -r -s -h C:\IO.SYS
C:\ME-DOS\Command\Attrib.exe -r -s -h C:\IO.SYS
CLS
Echo.
Echo Selecting WinME for next bootup...
Echo.
Copy /Y C:\IO.ME IO.SYS
:: Restart
Echo.
Echo The next boot will restart in WinME (IO.SYS = IO.ME)
Dir C:\IO.* /A
Echo.
Pause
Echo.
The ":: Restart" line can be un-commented out to "Restart" if you want this .bat to reboot the system after selecting WinME as the next OS to boot. The Restart.com is specifically the one from the Win98 Emergency Boot Disk and is nice because it does nothing if executed within WinME GUI, but will restart the PC if in DOS mode. For safety, it's best to keep this utility in the Path for DOS mode, but not for WinME, i.e. locate the file within (say) C:\ME-DOS or C:\ME-DOS\Command.
You can use either of these batch files from either OS, i.e. if you chose to boot DOS mode next, then changed your mind, you can change back without having to first boot into DOS mode and return from there.
There are two limitations or issues with this DOS mode:
I make no apologies for the first limitation, as I consider disk compression to be best avoided. I have done zero testing with this, so if you want to support disk compression, that's up to you.
On the second limitation; what will happen if you do a Sys or a Format /S from this DOS mode, is that the target disk might get an IO.sys that looks for an alternate-named Command.com, but only the originally-named Command.com will be present on the target disk. Expect problems.
In closing, it's worth mentioning that I've used this method for several years on several PCs, and it works as well as earlier Win9x's built-in DOS modes. In fact, in some ways it works better; the "double-launch DOS mode" problem does not apply, nor is there unwanted and buggy interaction between DOS and GUI modes of Config.sys [Menu] %Config% variables, which does apply to Win9x "Specify a new..." DOS mode. I've fleshed out my own use of this approach somewhat, but have needed to make no changes to any of the files involved for years.
But I offer no warranty; you use this information entirely at your own risk, and your mileage will depend on the quality of your code editing and how well you maintain your "undo" trail.
Solution 4: Pre-file OS selection
Solution 1 involves changing the nature of WinME itself, whereas solutions 2 and 3 involve selecting the desired OS at the IO.sys level. It's also possible to swap the partition boot code so that an alternative to IO.sys is loaded instead, or at the partition level so that an alternate partition is booted instead.
A variety of third-party partition boot managers can be used to create and select alternate primary partitions on the same hard drive (something that MSware tolerates, but FDisk does not facilitate). NT offers a mechanism to use arbitrary 512-byte code files as alternate partition boot code (read up on NTLDR and Boot.ini), so one could conceivably use that to triple-boot between an NT, Windows ME, and a DOS mode. You would need to host Windows ME and an alternate Win9x GUI on separate volumes, given that both will use the same "\Program Files", but you could use the "solution 3" approach to hosting WinME plus an alternate DOS mode on the same volume.
(C) Chris Quirke, all rights reserved - April 2003