iMic

It's a workaround, but it essentially equates to "run Windows 98 for Real Mode DOS applications". Works for some, but we want to run Windows Millennium throughout. My recollection of how DOS mode under Windows worked is rusty, but from what I understand, "Restart in MS-DOS Mode" would exit Windows and return to DOS mode, but anything that was loaded in AUTOEXEC.BAT or CONFIG.SYS before Windows was loaded is still present after Windows has shut down. So it's not a completely clean DOS environment, but it does allow you to rapidly jump back into Windows when you're done. Rebooting the computer and pressing F8 on startup to boot to a Command Prompt starts a clean DOS environment. I haven't had a lot of time to revisit this project, and even if I did, I think I'd get stuck on the "Restart in MS-DOS Mode" issue. At this stage it isn't cancelled, but it's going to take quite a while and it might look a bit different by the time it's done.

I'm currently compiling an archive of the updates and hotfixes that Microsoft officially released for Windows Millennium Edition during its short life. I'm sure several people will ask "Why?", given that there's already community efforts to integrate these fixes along with a bunch of other community-produced unofficial patches into Cumulative Updates and Unofficial Service Packs. In addition to tinkering with old Windows and dabbling in retro-computing, I do a lot of work toward software preservation with different groups. And I've committed to the task of cataloguing and preserving these files for Windows Millennium Edition specifically, since it's one of the more overlooked versions of Windows, compared to a lot of preservation and documenting efforts that surround Windows 98, 2000, XP and so on. Of course, once this is done, I'm happy to make my archives open to the public and the Internet Archive for everyone to benefit from. I've managed to account for over 100 updates and hotfixes - probably closer to 150 by now - but there's a couple that I haven't been able to track down information about, find their files, or even their purpose. So I'm turning to the community to shed any light on these select few in the hopes that someone, somewhere out there might know something - or even have a file kicking around on an old CD or hard drive somewhere. (And yes, I've extensively searched the web and even these forums.) The Mysterious VMOUSE Update I know there isn't anything particularly mysterious about it - it's just a Microsoft hotfix that was released without a title, a known purpose, or any kind of documentation. Included as part of the IntelliPoint 4.1 and 4.12 software suites, and known by many names: 98VMOUSE.EXE (Windows 98). Contains VMOUSE.VXD 4.10.0.2225. 98FMOUSE.EXE (Windows 98). VMOUSE.VXD contained within differs from 98VMOUSE by only one byte - a switch from 08 to 0A at offset 0x3525. I'm no expert in x86 assembly, but according to W32Dasm, it seems like it's a compare between two operands, and the 08 / 0A is one of the comparison values (08 being 8 and 0A being 10, respectively). 98JMOUSE.EXE (Windows 98). Japanese version? MEVMOUSE.EXE (Windows Me). Contains VMOUSE.VXD 4.90.0.3003. MEFMOUSE.EXE (Windows Me). VMOUSE.VXD contained within differs from MEVMOUSE by only one byte - a switch from 08 to 0A at offset 0x2519. See information for 98FMOUSE above. MEJMOUSE.EXE (Windows Me.) Japanese version? Q318307.EXE and ME318307.EXE on MDGx' Website. Identical to 98VMOUSE.EXE and MEVMOUSE.EXE, respectively. "VMouseForWin98" and "VMouseForWinMe" inside the IntelliPoint MSI installation bundle that calls them. According to the INF files inside each, 318307 appears to be the QFE / KB number. It doesn't correspond to any public-facing knowledge base article however, available on the modern web or via the Wayback Machine. Strangely the update also creates a registry entry: ;Enable Q318307 HKLM,"System\CurrentControlSet\Services\VxD\VMD","Enable Q318307",0x00000001,01 Which I can confirm is referenced from inside VMOUSE.VXD, so it must do something. I thought for a while it may have something to do with smoother cursor motion, polling or refresh, etc... but nothing conclusive. If anyone can provide any information on what this fix does, or if it may have ever been linked with an article number, that would be appreciated. "Cannot Wake Computer from Standby with USB" (264386) (Internet Archive Link.) This one may have only ever existed in the Japanese market, as it seems to mainly affect Fujitsu and NEC branded computers. It contains USBD.SYS 4.90.3001.1 and USBHUB.SYS 4.90.3001.1 in the Japanese version; the US release probably contained 3001 versions as well. "264386JPNM.EXE" was the Japanese filename, and the only known location for it online now is inside a password-protected archive at this link: http://radioc.web.fc2.com/column/w98lib/mefix/wme_hidden_fix.htm The password hint is "PASS is the name of the person who said "It's nice weather today" on page 26 of the Windows Me Quick Start Guide". This doesn't appear however in the English version of the Quick Start Guide, so I assume it's limited to the Japanese one, which I don't have and haven't been able to find. Anyway, if anyone has the Japanese version of this file, knows more about it, or can surprise me with an English / USAM, etc version of this update, that would be fantastic. "Computer Suspends After Resuming with Keyboard Power Key" (281921) (MS FTP Mirror Link.) Contains CONFIGMG.VXD 4.90.3002 and VPOWERD.VXD 4.90.3004. The Japanese version filename is known - "281921JPNM.EXE" - but the English version is nowhere to be found. Unlike 264386 above, I know an English version must have existed at some point, as I've found the CONFIGMG.VXD 4.90.3002 standalone file that would have been contained in it, but not the update itself. Although VPOWERD.VXD was replaced by several newer Windows Millennium Edition updates, this is the only one I'm aware of that contained a newer CONFIGMG.VXD file. Although I have this file, I'd like to eventually find the package it was contained in, as presumably it also contained a Security Catalog file needed to pass Windows' System File Protection on a standard install. "WMI Scripts Generate "Permission Denied" Error Message" (282949) (Internet Archive Link.) Contained a newer version of WMEMPROX.DLL. The Knowledge Base article confirms that it was released for Windows 95, 98 and Millennium Edition. I have been able to locate the Windows 98 version of this update, titled "q282949_win98.exe" from the source I located it from, but I'm unsure if that was its original title. Unfortunately that same source did not have the update for Windows Millennium Edition, and the 98 version does not install on Windows Me. "Windows Me Help and Support Update, November, 2000" (278497) This update contained an issue that would cause the computer to hang while installing it, and so it was pulled and replaced by Microsoft soon after with update 299014 "Help and Support Update Hangs During Reboot". It contains HELPCTR.EXE 4.90.3002 and HCUPDATE.EXE 4.90.3002. The filename is currently unknown, however the 299014 update that replaced it has the filename "Q299014.EXE". Q299014 almost completely replaced it, but Q278497 would have contained a Setup INF file that created a registry entry in Active Setup with a unique GUID. As this GUID is currently unknown, it continues to appear in Windows Update v3 (via sites like Windows Update Restored), as these sites check for a specific registry key containing this GUID. So I would like to find it, so I can integrate this GUID into a global "ignore list" for Windows Update. For reference, 299014's GUID is "{ce3a4089-cd35-4358-b5c7-36625717011b}". It'll look something like that, but a different combination of alphanumeric characters separated by dashes. I have also tried the inverse - presumably Windows Update Restored may have the necessary files somewhere that contain this GUID, but it's not included in whatever files are downloaded from the server. Attempting to download the update through there also fails - it appears to be one of the missing ones on the server end, so although it appears in the updates list, it fails every time. EDIT: It looks like this update in Windows Update v3 might be referring to Q299014 after all, but it's missing an additional file - wuwmupd1.cab - which is downloaded and installed alongside it. Cheers, iMic.

I'm currently experimenting with a workaround that permits restarting to MS-DOS mode using the existing AUTOEXEC.BAT and CONFIG.SYS configuration. When "Restart in MS-DOS mode" is selected, Windows checks for the presence of "Exit to DOS.pif" in C:\WINDOWS. This PIF can contain absolutely anything - you can instruct it to launch any DOS application, in MS-DOS mode or in an MS-DOS Prompt window, it doesn't matter. This could also be - for example - a script or application that does the necessary setup for restarting to a command prompt from within Windows, effectively bypassing Windows' own internal mechanisms. I've created a proof-of-concept "EXITDOS.BAT" that is called from "Exit to DOS.pif". This script performs the following operations - Checks for AUTOEXEC.BAT and CONFIG.SYS. If either file is not found, it creates new ones from the AUTOEXEC.WIN and CONFIG.WIN files generated by the patched REGENV32. Ensures those AUTOEXEC.BAT and CONFIG.SYS files are not hidden, and are writable (not read-only). Checks for AUTOEXEC.APP and CONFIG.APP, and removes them if present. These are generated when returning to Windows from an MS-DOS mode session, and should be automatically removed, but sometimes they can persist. If the .APP files from a previous MS-DOS mode session are not removed before restarting to a new MS-DOS mode session, it can prevent the computer from returning to Windows when EXIT or WIN /WX is typed, until those .APP files are removed. Copies the current contents of AUTOEXEC.BAT to AUTOEXEC.WOS. WIN.COM removes the AUTOEXEC.BAT containing our temporary entries and renames AUTOEXEC.WOS back to AUTOEXEC.BAT when the computer restarts from MS-DOS mode. Checks if COMMAND.COM is to be launched after restart, or if a different application path is specified as a parameter instead. Adds some temporary commands to the end of AUTOEXEC.BAT for the MS-DOS session. (See Below.) Issues a command to restart the computer. When the computer is in MS-DOS mode, typing EXIT or WIN /WX removes the temporary AUTOEXEC.BAT containing the temporary commands we added, and restores the temporary backup version created earlier (AUTOEXEC.WOS) to AUTOEXEC.BAT. This is a documented function of Windows, and actually how applications that restart into MS-DOS mode with "Specify a new MS-DOS configuration" selected are handled - we're just exploiting its abilities for our own purposes. If only WIN is typed, Windows Millennium will still start up, but will return to an MS-DOS mode when the computer is restarted again. Typing EXIT or WIN /WX is what instructs the computer to re-configure itself and return to a normal startup again. The temporary commands added to the end of AUTOEXEC.BAT are: ECHO Type EXIT to return to Windows. CALL %WINDIR%\COMMAND.COM %WINDIR%\WIN.COM /WX Calling COMMAND.COM is what drops the computer to a command prompt instead of immediately launching Windows. When EXIT is typed, the command interpreter closes, and the next line - WIN.COM /WX - is called, setting the computer up for a normal startup and rebooting the system again. What all this means is that "Restart in MS-DOS mode" works. It's not particularly elegant, but there are some ways it could be improved - The EXITDOS.BAT file could be rewritten as a dedicated .COM or .EXE executable with the same functionality instead, which would improve performance, and reliability if it isn't calling out to a bunch of extra DOS utilities like XCOPY and ATTRIB. "Exit to DOS.pif" could be skipped entirely if the filename were patched to "EXITDOS.COM" (or whatever it would be) in SHELL32.DLL, removing one extra file and bypassing the PIF manager. However this would prevent the user from specifying their own "Exit to DOS.pif" with different functionality if they wished. On the other hand, this method has an advantage - you can also restart into MS-DOS mode simply by typing "EXITDOS", or restarting into MS-DOS mode and launching a different application by typing "EXITDOS PATH\TO\EXAMPLE\PROGRAM.EXE", either from an MS-DOS Prompt, a Batch File, or the Start > Run dialog. This leaves one feature broken - right clicking a DOS application, selecting Properties > Program > Advanced > MS-DOS mode > "Use current MS-DOS configuration" to launch an application. Fixing this would involve finding out where this function is handled in the OS, and patching it to call out to EXITDOS instead. Of course patching it here would probably eliminate the need for "Exit to DOS.pif" in Start > Shutdown as well, as it's likely these are hooked to the same or similar functions. I think if this were achieved, most would consider this a satisfactory solution to handling MS-DOS mode in Windows Millennium, since it would contain all the functionality present in Windows 95/98, handled a little differently, but without the need for any compromise. Any improvements made thereafter would just be polishing it up.

If anyone wants to see what I currently have, I've made it available for download here. https://app.box.com/s/jfiy8p0m2p2vbvh4zzolznh3lp2yanfe Keep in mind it is for testing, is in no way complete, and should not be installed on critical use systems. Testing in a Virtual Machine is recommended.

I recently had some free time on my hands, and started working on putting Real Mode DOS support back into Windows Millennium. Not only the common patches available around the internet, but all of it - Restart to MS-DOS mode enabled, AUTOEXEC and CONFIG processed on boot, advanced PIF options in DOS application properties panels, and applications can be instructed to reboot into DOS and back into Windows when they’ve completed. It accomplishes this by redirecting the rewrites of AUTOEXEC and CONFIG in REGENV32.EXE, using a specialised IO.SYS and COMMAND.COM from the Windows Millennium CD NETTOOLS (CBS.DTA and LTOOLS.DTA), and using the MS-DOS application layer (WINOA386.MOD and PIFMGR.DLL) and command line utilities (SYS.COM) from Millennium Developer Release 1. The current testing version also includes WIN.COM from Windows 98 Second Edition as this allows the user to type "exit" from DOS and restart back into Windows, however the aim would be to eventually re-integrate this functionality back into Windows Me's WIN.COM instead. "Restart in MS-DOS mode" is restored by removing the "NoRealMode" value from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\WinOldApp in the Windows registry. So, what currently works? "Restart in MS-DOS mode" from the shutdown dialog restarts to a command prompt - with a caveat. (See Issue 1 below.) Typing EXIT or WIN from MS-DOS mode restarts the computer back into Windows. DOS applications can be configured to restart in MS-DOS mode from the Properties window, and custom AUTOEXEC.BAT and CONFIG.SYS entries can be specified per application. The IO.SYS included with NETTOOLS automatically loads IFSHLP.SYS, and automatically calls WIN on startup, so these lines are not required in AUTOEXEC and CONFIG. The Windows Me boot logo is preserved. Windows XMS driver, integrated into IO.SYS, loads and mostly replaces the functionality of HIMEM.SYS. EMM386 loads and works, both in DOS mode and within Windows, although it currently requires the IO8EMMOK driver (https://github.com/pufengdu/IO8EMMOK) to be loaded first in CONFIG.SYS to make the built-in XMS driver behave more like a standard HIMEM. AUTOEXEC.BAT and CONFIG.SYS are processed and loaded at startup. Holding CTRL on startup brings up the Windows Millennium Startup menu, and it now includes "Command Prompt Only" in addition to the normal startup options. Creating a MS-DOS boot disk by using the SYS command line utility has been re-enabled. When editing PIF properties, "DEVICE=C:\Windows\Himem.Sys" is no longer autofilled in CONFIG.SYS as this is not required on MS-DOS 8 / Windows Millennium. The modifications can be installed via a Setup INF, without the need to disable System Restore or System File Protection. There are still some issues to work on however - Selecting "Use current MS-DOS configuration" in an application's MS-DOS mode properties / PIF and using it to restart into MS-DOS mode just shuts down the computer. Selecting "Specify a new MS-DOS configuration" and entering a custom AUTOEXEC and CONFIG works fine. This includes the "Exit to DOS" PIF used when selecting "Restart in MS-DOS mode" from the Start > Shut Down menu, which just shuts down the system if the Exit to DOS PIF doesn't have a custom AUTOEXEC and CONFIG specified. Because resuming from Hibernation is handled partly in IO.SYS, the alterations to this file mean that Hibernation still needs to be tested. Likewise, System Restore needs to be tested to ensure it can still create and restore system snapshots correctly. Update KB311561 contains an updated IO.SYS with some bug fixes. The IO.SYS used to currently boot into DOS mode does not contain these fixes. The first issue above has been the sticking point for this project. When "Use current MS-DOS configuration" is selected, or "Restart in MS-DOS mode" is selected from the shutdown dialog without an "Exit to DOS.pif" specifying a new MS-DOS configuration present in the WINDOWS folder, the computer just shuts down instead of restarting into DOS mode. After experimenting side-by-side with Windows 98, I think I know what the problem is. When restarting into MS-DOS mode in Windows 98 using "Use current MS-DOS configuration", Windows shuts down and returns the computer to an MS-DOS command prompt without restarting the computer, using the already-loaded AUTOEXEC.BAT and CONFIG.SYS. However when "Specify a new MS-DOS configuration" is selected, because the AUTOEXEC and CONFIG files need to be replaced temporarily and DOS loaded from the ground up, Windows does restart the computer. Therein lies the problem - the functionality that allowed Windows 98 to end its session, unload and drop back to a DOS prompt without restarting the computer isn't present in Windows Millennium, so instead, the computer just shuts down when "Use current MS-DOS configuration" is selected. When a custom MS-DOS configuration is specified, it forces a warm restart instead, bypassing whatever function of the OS is broken, and it works - but because we had to specify a custom configuration in the PIF, the existing AUTOEXEC.BAT and CONFIG.SYS in the root of the C drive is ignored. Dencorso over in this thread may have an explanation as to why this occurs - So the problem is likely deep within the Windows Kernel itself. This is about as far as I can go, with my current knowledge, at least without some assistance to either point me in the right direction or to come up with a suitable workaround for this issue. As it stands, it means that *any* DOS application needs to have its own AUTOEXEC and CONFIG entries specified in the properties dialog - it can't inherit the existing entries from the AUTOEXEC.BAT and CONFIG.SYS already in the root of the C drive. Now this isn't inherently a bad thing - if an application does require DOS mode, then set it up in properties, include EMM386, MSCDEX, MOUSE, whatever it needs, and double click to restart the computer and run it. That part works fine. Likewise if you want to run something before Windows Me boots in AUTOEXEC and CONFIG, that's fine too. Or if you want to reboot to a command prompt by holding down CTRL and selecting Command Prompt Only, that also works. But you can't double-click a DOS application icon in Windows and have it use the existing AUTOEXEC and CONFIG. And at the moment, to make "Restart in MS-DOS mode" work, I'm bundling "Exit to DOS.pif" with the package and anyone that wants to have a custom AUTOEXEC or CONFIG in that MS-DOS mode session just needs to specify their contents in that PIF file instead. It works, but it's a "95% of the way there" solution when ideally, we want that last 5 percent.

@deomsh That was absolutely the right one - thank you so much! It doesn't seem to have the latest versions of each file, but it does get me considerably closer to having a complete set. I'm starting to think FLOPUPD5 might actually be an official update as well, just a somewhat unusually packaged one... it's hard to tell. There's two more I'm also now looking to track down, but I've only just started looking for these. I'm not sure what their file names are yet, only their KB article numbers, but I'll continue searching and see what I can dig up. Otherwise if anyone happens to have these around anywhere (or know what their file names are) - Q181087 "Computer Hangs When Using the DIR Command in DFS Shared Folders" http://support.microsoft.com/support/kb/articles/q181/0/87.asp DFS.VXD 4.10.1691 VNETSUP.VXD 4.10.1691 VREDIR.VXD 4.10.1691 Q162211 ""Fatal Exception 0E" May Occur During Critical Suspend" http://support.microsoft.com/support/kb/articles/Q162/2/11.asp VPOWERD.VXD 4.00.952

I'm currently in the process of archiving some of the lesser known updates that Microsoft released for the various Windows 9x versions. Specifically, the ones that were actually released by Microsoft - none of the unofficial service packs or community created updates. Although many of the community updates are better than the ones Microsoft produced, I'd still like to find them. The one I'm having difficulty tracking down is the one documented in Knowledge Base article 159153 "Error Messages While Backing Up to Some Floppy Disk Drives", which was released as FLOPUPD.EXE for RTM + OSR1 and FLOPUPD2.EXE for OSR2. I've since managed to track down FLOPUPD2, but not the original FLOPUPD. I'm aware there is another version on MDGx as well named FLOPUPD5, but it appears it might be a community packaged update. Additionally, it notes that "Requires 90 MHz or faster x86 CPU + minimum 32 MB RAM!", but one of the reasons I'm archiving updates for the earlier RTM build is specifically for retro-computing - so we can update the operating system after installing it on lower end i486 based systems, often with a maximum of 32MB RAM. (And no need for FAT32 or USB support, either.) The update released by Microsoft has no such requirement. There is one mention of it on the MSFN forums - a post from 2006 by erpdude8 - so I'm hopeful that someone might still have it kicking around. If anyone happens to have FLOPUPD.EXE sitting somewhere on one of their drives and is willing to upload it somewhere, I would be extremely grateful. Cheers, Mic.