Windows Millenium Edition - Disable Himem.sys from Loading

[alpha-beta]

Hello everyone,

Before I start and to save people's time I'm not interested in running 98/95 on this machine so you can withhold those repeated responses/suggestions to prevent flooding of these kinds of posts in this topic that we've all seen many times over. I think Windows ME got a bad reputation back then so I'm already familiar with the negative impressions it has built up but maybe one day it can be restored.

I'm running an older Pentium II in a legacy machine using Windows Millennium Edition and I want to do some testing with QEMM and some other DOS memory managers for compatibility but Windows ME insists on preloading its own himem.sys memory manager first so it prevents it from loading. I've already done the ME DOS patch on it to access MS-DOS mode. I would like to tackle one problem at a time.

How do you disable the Windows Millennium Edition's own Himem.sys inside IO.sys from loading each time at boot?

Has anyone here at BetaArchive tried to do this?

Is there a beta version of Windows ME that did not load its himem.sys from IO.SYS and acted more like 98SE that allowed using the config.sys before it got changed?

I would like to find a way to disable himem.sys from autoloading in Windows ME if there is a solution.

Thanks in advance!

[LilShootDawg]

I'm pretty sure you need HIMEM.SYS to actually be able to run non-NT systems.

[JohnPRichardson]

Well, there's bad news, but maybe also good news on that...

MDGx is pretty much the place to look for info on this:

http://www.mdgx.com/wme.htm

for Win ME data or:

http://www.mdgx.com/

for his whole site.

Hopefully, your hardware is compatible with UMBPCI.SYS, as that is one of the few memory managers that works properly with Windows ME. UMBPCI.SYS and some manual editing worked better for me at getting Memory-picky DOS programs to run. Better than Qualitas' 386MAX or Quarterdeck's QEMM (although QEMM97 did help me with a few Windows titles).

Like I said, go to http://www.mdgx.com/wme.htm, click on article:
2-13-01 Win9x/ME Original ©Trick: 95/98/ME SETUP + MEMORY MANAGERS

Lots of useful info there...

[alpha-beta]

I'm pretty sure you need HIMEM.SYS to actually be able to run non-NT systems.

I want to disable himem.sys from automatically loading the one inside IO.SYS built for Windows ME. I will use the himem.sys one from Windows 98 if the himem.sys version found in Windows ME if it can't be extracted as single file and loaded in the config.sys manually. Since it loads the one inside IO.SYS first it prevents loading a different one even in the config.sys.

[alpha-beta]

Well, there's bad news, but maybe also good news on that...

MDGx is pretty much the place to look for info on this:

http://www.mdgx.com/wme.htm

for Win ME data or:

http://www.mdgx.com/

for his whole site.

Hopefully, your hardware is compatible with UMBPCI.SYS, as that is one of the few memory managers that works properly with Windows ME. UMBPCI.SYS and some manual editing worked better for me at getting Memory-picky DOS programs to run. Better than Qualitas' 386MAX or Quarterdeck's QEMM (although QEMM97 did help me with a few Windows titles).

Like I said, go to http://www.mdgx.com/wme.htm, click on article:
2-13-01 Win9x/ME Original ©Trick: 95/98/ME SETUP + MEMORY MANAGERS

Lots of useful info there...

I've looked there before. I like the font they use for their site. But I couldn't find anything specific on completely disabling the himem.sys from inside Windows ME's IO.SYS from auto-loading. Was there something there you saw there that I missed?

Don't worry about which memory managers are compatible yet but I'll also try yours too if mine doesn't work. One step at a time. I just want to completely disable the autoloading of the himem.sys of Windows ME first when booting to DOS if this is possible.

There should be a way to do it with a switch in MSDOS.SYS if it exists or if not has there been a method to hex modify the IO.sys file to skip loading the internal himem.sys or to use a specified file in the root directory instead of loading the built in WinME?

Thanks for the responses maybe someone will have an answer to this.

[jimmsta]

I think what you're looking for is here: http://www.mdgx.com/dos.htm#ME
There's patches for io.sys and command.com to allow proper 'real DOS' modes that are absent from WinME's default installation.

edit: What you'll want to do is setup your own himem.sys replacement in the config.sys that you create after applying one of the patches on that page. Scroll down for some recommendations - they all support WinME, according to the notes on the page.

[alpha-beta]

I think what you're looking for is here: http://www.mdgx.com/dos.htm#ME
There's patches for io.sys and command.com to allow proper 'real DOS' modes that are absent from WinME's default installation.

edit: What you'll want to do is setup your own himem.sys replacement in the config.sys that you create after applying one of the patches on that page. Scroll down for some recommendations - they all support WinME, according to the notes on the page.

That real DOS mode patch has already been applied. That's not the problem.

The problem is WinME loads its own Himem.sys from inside IO.SYS.
Another problem is it also loads SMARTDRV from inside IO.SYS as well right after.

I want to disable the auto loading of Himem.sys from inside IO.SYS.
Next I want to disable autoloading of SMARTDRV as well. But by disabling the WinME Himem.sys from loading may automatically cause the autoloading of SMARTDRV to stop if it requires Himem.sys to load first as a prerequisite.

Even placing your own Himem.sys in the config.sys I believe it forces the WinME version to load before checking the config.sys for other drivers to load so WinME's Himem.sys has forced priority.

However my goal is to completely disable the autoloading of Win ME's Himem.sys within IO.sys from loading in the first place which will solve all other issues.

[jimmsta]

I think your only option would be to replace io.sys with dos 7.1 (98SE)'s IO.sys, which doesn't impose the forced loading of internal components -- unless someone manages to figure out how to disable those components from loading within the WinME IO.sys. WinME should function properly on top of the 98SE IO.sys, as just that is done with MDGx's own 98SE2ME, which transplants some major parts of ME on top of 98SE.

[Battler]

Actually, you would have replace ME's entire MS-DOS 8.00 with 98SE's MS-DOS 7.10, or else already COMMAND.COM would fail to load with Incorrect DOS version.

[os2fan2]

The Windows ME himem.sys is identical to the 98se version, with some load-point and text message changes. It reports 3.95.

Windows ME has a himem.sys built-in to IO.SYS, which answers to 3,99 as a version number. I imagine if you found a version that answers to 4.00, then you could use that instead.

On the main, I have done some work on replacing the DOS version in some of the Windows. Windows 95 will run under MS-DOS 7.1, but to use the DOS prompt under Windows, you have to make the dos pretend it's 7.0. While MS-DOS can see fat32 partitions under DOS, when the OSR1 shell is loaded, this functionality is lost.

Windows ME xcopy does not hook up to the DOS STDIN, and produces blank messages under vanilla DOS. It uses a unicode interface.

Have a look at http://reboot.pro/topic/5497-ms-dos-71/ and http://reboot.pro/topic/18130-ms-dos-7-help-file/ which is where the write-up on most of this ends up.

[Battler]

The other solution would, of course, be to patch 98SE's IO.SYS to report itself as MS-DOS 8.00. Then you could leave all other files untouched.

[jimmsta]

I spent the better part of 1998-2000 on 98SE, and then again from 2003-2007 modding it and managing the 'W9x Power Pack'. I never attempted anything beyond applying pre-built patches to my installs, but I did spend some time experimenting with various things under the hood.

Due to some recent experiments in the land of FreeDOS and DOS 7.1, I'm going to take a stab at modding 98SE's IO.SYS for you. I don't think it should be too hard to formulate a patch to report back the appropriate version number.

I'll do some work on this today, as I'm curious to see if this would be possible to do - and ultimately achieve the goal of the thread.

Edit: I found this page with a whole lot of patches and downloads to make 7.1 work under ME, as well as patch ME's 8.0 dos to allow different memory managers to be loaded - http://www.multiboot.ru/msdos8.htm

[os2fan2]

The current state of my dos71 project allows you to load different bootscreens on the config.sys menu, and pretend to be different versions for different win9x loads.

So you can show a dos screen or a win95 or win98se screen. It's a decent hack.

The dos version is set correctly for each option.

I'm the wendy mentioned on the msdos8 site.

[alpha-beta]

I think your only option would be to replace io.sys with dos 7.1 (98SE)'s IO.sys, which doesn't impose the forced loading of internal components -- unless someone manages to figure out how to disable those components from loading within the WinME IO.sys. WinME should function properly on top of the 98SE IO.sys, as just that is done with MDGx's own 98SE2ME, which transplants some major parts of ME on top of 98SE.

I think the 98SE2ME still isn't running pure WinME. It's still 98SE using WinME updated system files as I understand it.

Also replacing the 98SE IO.sys onto WinME's IO.sys would cause WinME not to load if I remember correctly testing this out on a laptop. It would seem this would work with 98SE's IO.SYS but WinME has some sort of checking going on to prevent this method. I suppose Microsoft predicted someone would try this and they purposely disabled this from happening.

[alpha-beta]

The Windows ME himem.sys is identical to the 98se version, with some load-point and text message changes. It reports 3.95.

Windows ME has a himem.sys built-in to IO.SYS, which answers to 3,99 as a version number. I imagine if you found a version that answers to 4.00, then you could use that instead.

On the main, I have done some work on replacing the DOS version in some of the Windows. Windows 95 will run under MS-DOS 7.1, but to use the DOS prompt under Windows, you have to make the dos pretend it's 7.0. While MS-DOS can see fat32 partitions under DOS, when the OSR1 shell is loaded, this functionality is lost.

Windows ME xcopy does not hook up to the DOS STDIN, and produces blank messages under vanilla DOS. It uses a unicode interface.

Have a look at http://reboot.pro/topic/5497-ms-dos-71/ and http://reboot.pro/topic/18130-ms-dos-7-help-file/ which is where the write-up on most of this ends up.

If it's some version number check how would you go about changing the WinME detection to make sure it sees the WinME IO.SYS's himem.sys version of 3.99 is still reported if substituting with 3.95 or other himem.sys version?

Now is there a way to change whatever WinME is using for detecting for himem.sys v3.95 of 98SE instead of 3.99? This would then allow WinME to load into the operating system and be happy unless there is some code within the himem.sys v3.99 that it requires?

We would still need to disable the autoloading of the WinME's Himem.sys v3.99 from IO.SYS first to even try anything. Then allow loading of the config.sys file of himem.sys v3.95 of 98SE. Or extracting the himem.sys v3.99 from IO.SYS as a stand alone himem.sys to be loaded in config.sys for WinME OS booting if WinME OS cannot load with 98SE's himem.sys v3.95.

Even if you were to boot into 98SE DOS v7.10 and somehow replace whatever WinME is detecting to see himem.sys v3.99 and replace all Windows ME DOS commands with 98SE DOS commands would there be any other functions of WinME that will be affected?

How about exiting to the Command Prompt from WinME in the Shutdown options?
Is this possible?

[alpha-beta]

The other solution would, of course, be to patch 98SE's IO.SYS to report itself as MS-DOS 8.00. Then you could leave all other files untouched.

This would be an interesting alternate solution to test. However I would be curious if all WinME DOS files will work properly unless there is some hidden functionality in the WinME himem.sys v3.99 that some of its files needs? Still interested in testing both methods.

As then I could check if WinME is happy using himem.sys v3.95 from 98SE pretending to be himem.sys v3.99 from WinME. This would avoid autoloading of the WinME IO.SYS's himem.sys v3.99 and the Smartdrv.

But is the possibility of disabling the autoloading of WinME's internal himem.sys v3.99 from IO.sys possible still? Second the disabling of autoloading of WinME's smartdrv.exe is the other issue. Then changing whatever checks WinME's is doing to accept loading himem.sys v3.95 from 98SE within config.sys.

This would at least allow the use of WinME type files in Real Mode as it was intended.

Some other patches that could follow is restoring the WinME's format.com/s and sys.com to properly format DOS ME bootable system files for floppies and hard drives which was removed for no good reasons. This would make WinME function pretty much properly enough for modern day testing.

[alpha-beta]

I spent the better part of 1998-2000 on 98SE, and then again from 2003-2007 modding it and managing the 'W9x Power Pack'. I never attempted anything beyond applying pre-built patches to my installs, but I did spend some time experimenting with various things under the hood.

Due to some recent experiments in the land of FreeDOS and DOS 7.1, I'm going to take a stab at modding 98SE's IO.SYS for you. I don't think it should be too hard to formulate a patch to report back the appropriate version number.

I'll do some work on this today, as I'm curious to see if this would be possible to do - and ultimately achieve the goal of the thread.

Edit: I found this page with a whole lot of patches and downloads to make 7.1 work under ME, as well as patch ME's 8.0 dos to allow different memory managers to be loaded - http://www.multiboot.ru/msdos8.htm

I have visited that page before but


MS-DOS 8.0 Patch:
IO.SYS 000003AA 75 -> EB
COMMAND.COM 00006510 75 -> EB
You can remove version check by replace byte sequence 3D 08 00 74 ->90 90 90 EB in all external commands for full compatibility with version 7.10



I believe this patch only makes Windows ME use 98SE DOS files not Win ME DOS files?

What would happen if you format a:/s or format c:/s

Would it then format a bootable WinME Floppy disk or Hard Disk?

What causes WinME to not format bootable floppy or hard disks with format.com or make them bootable with sys.com?

Or would it fail with some error?

Also I would like the option to disable the auto loading of himem.sys v3.99 within WinME's IO.SYS or the auto loading of smartdrv.exe as a solution.

[alpha-beta]

The current state of my dos71 project allows you to load different bootscreens on the config.sys menu, and pretend to be different versions for different win9x loads.

So you can show a dos screen or a win95 or win98se screen. It's a decent hack.

The dos version is set correctly for each option.

I'm the wendy mentioned on the msdos8 site.

Ahh so Wendy is still alive and well. Maybe this dead end to 8.0 can be resurrected.

XCOPY32.MOD is actually what was in Win95, xcopy32.exe. You can "copy xcopy32.mod xcopy.exe" to test different interfaces to the same proggie. XCOPY has some creul-code stopping useful features in plain dos.

What about using the MS-DOS 5.0, 6.0, or 6.21 versions of XCOPY instead working under 95B, 98SE, and WinME?

I can't remember at the moment if they only used xcopy.exe only or required two xcopy files to operate in real DOS. I have them archived somewhere testing all MS-DOS versions on modern systems a year ago. The earliest version possible that I could get bootable was MS-DOS 3.21 on Z370 Coffee Lake.

[Battler]

The versions of XCOPY from standalone MS-DOS versions require only XCOPY.EXE itself, nothing more.

[os2fan2]

Up to MS-DOS 5, the commands in DOS were compiled to check the dos version given by truever command. Ie you could not use dosver to renumber the dos version. The purpose of this, i am told, is so that people could not steal edlin from DOS 3.1, and run it on 3.0. The art of 'diddling edlin' was born. DOS 5 contained some utilities (QBasic, Edit, Dosshell), which did not make so stringant tests. IBM's E Editor, view help, and rexx are also dosversion free.

Microsoft also used to distribute six DOS drivers as separate bundles, these do not do specific dos checks. They are mscdex, himem, emm386, mouse, ramdrive, and smartdrv. You can run the winme versions of these under MS-DOS 5.0, so there is no version check. You can even run the IBM ones under MSDOS and the MSDOS ones under IBM DOS. Every version of DOS, Windows, and programming utilities came with the latest update, so these may be regarded as being distributed with DOS, rather than part of DOS.

MSDOS 6 introduced a number of new commands (move, choice, deltree) which also run under DOS 5, as dos PCDOS 7 crc, acalc, and rexx. The 7.0 rexx did not like OS/2, but the 7.1 one did not mind.

My MSDOS 6.30 project was born off the replacement for the 'Oldmsdos' on the windows diskette. It started off replacing the dos version with 7.0, 7.1 or 8.0, but eventually we got the whole of dos 6.22 and 6.20 without version check. So the go was simply to pick the tools out of the 6.30 disk for whatever win9x you were running.

The MSDOS 7.10 project was born off some report that the newer dos versions run win9x then the older ones. Since the idea is that DOS and windows were separate things bundled together, i decided to test this.

[os2fan2]

The MSDOS 6.30 is used for installing Windows 3.x and 9x. It exists in two varieties: 6.3 and 6.30. The first is based on 6.20, the latter on 6.22. The differences are sys.com, command.com and io.sys. msdos.sys is identical in both. It is completely compatible with 6.22 stuff and 6.22 stuff will run under it. The current MSDOS 6.30 has the MSD.EXE 3.00, reversioned to 2.12. This corresponds to a release between 6.22 (2.11) and Win95 oldmsdos (2.13). Win98 oldmsdos is 2.14.

The MSDOS 7.10 project derives from the five released versions of Win9x: OSR1 to OSR5 = Win95, Win95b, Win98FE, Win98SE and WinME. The DOS was extracted out of each of these, and extra odds and ends added (eg jo.sys from OSR3-5), the lot then compared and reduced to a single set. The main differences are the version check, and some features added at OSR2 (vfat32) and OSR3 (jo.sys). Given that MSDOS 8 is all over the place (it has three different boot loaders), we adopted 7.10.2222 as the working base: ie OSR4. Note that Weniger's DOS71 is based on OSR3 = 7.10.1998, but the difference is a string in command.com, which we are going to change anyway.

The default path in the IO.SYS boot in MSDOS 7,10 is %winbootdir%;%winbootdir%\command, where winbootdir comes from MSDOS.SYS. We plan then to follow the layout of windows, with a command directory with the DOS stuff, and command.com and the drivers in the base directory. The directory is C:\MSDOS7.

If you boot multiple versions of windows on the same computer, you should install them on different drives, and also different windir names. This is because the same windir name is created on the system drive. For example, suppose you install windows 95 into D:\LEGACY, and win98se into E:\FENSTER. There would be then hidden directories on the c:\ drive C:\LEGACY and C:\FENSTER. These are the fallbacks for if D: or E: are not available. You need to use some boot manager, like system commander to do this trick.

The idea is then to install MSDOS7 into c:\msdos7, windows 3.1 into C:\WINDOWS, windows 95 into D:\LEGACY and win98 into E:\FENSTER and see what a glorious hack we can make of this, using just the one DOS.

msdos 7,1,2222 runs windows 3.1 quite nicely in standard mode. VPC does not like running it in enhanced mode, but i will eventually try some of the other emulators. To run OSR2, you will need to patch the DOS version, for which we use dencorso's ver710.sys (which turns 8 into 7,1), slightly modified to turn 7.1 into 6.3, 7.0 or 8.00 (there are three different files in the new 7.10, verXXX.sys). You can load this after the menu, so the same DOS menu will lead you to 6.3, 7.0 or 8.0.

We use the doslogo.se utility, to load a splash-screen after the menu. This is a patched version, you store the files in \BOOT\WIN95.SYS and \BOOT\LWIN95.RLE, and the RLE is displayed on booting as before. So when you start Win98se, you get the win98se splash, the win95 gives the win95 splash. DOS gives you the DOS splah screen.

SETMDIR is a nasty piece of work designed to change the windir setting in the pre-environment. That is, you can set the lower case windir correctly from DOS. We use it in autoexec.bat to emulate networks, ie use different copies of windows not seen at boot.

The OSR1 gui runs under MSDOS7, when we load ver700.sys. This even allows you to run a DOS prompt under the gui. You don't need ver700.sys to load OSR1, but it seems that winoldap checks the dos version, and will not offer a non 7.00 prompt.

At this point penning (the main working frame) died, and the new computer came infected with Windows 6.1 Ultimate. (it actually had nothing on it, i installed 6.1 as 'keeping up with the trend').

Since of course, we have not written documentation for verXXX or sysXXX, or SETMDIR, there is little point making a GA of this DOS at this stage.

[os2fan2]

The WinME project would centre more on at first, whether MSDOS7 with ver800.sys will run Windows ME. There is very little differences between the bulk of the 7.1 v 8.0 utilities, outside of io.sys, command.com, and some windows proggies. But there has been some good documentation at the EDM (an OS/2 project) about getting WinME to boot off a RIPL disk. This is the key element that we need to consider in the current process.

Other projects in hand are to create INF files for all of these things, and to create a third general dos disk, with qbasic, gwbasic, dosshell, and some other things to add to either msdos630 or 710.

But the mainframe needs a heavy overhaul of late, largely to get rid of stuff that one installs and regrets.

[os2fan2]

XCOPY

I'm a bit ginger about this one. But here goes. The DOS version check is not the usual 'getdosver=0x061A' type stuff, but something like 'getdosver: if highbit=0x06 if lowbit=0x1A then', which means that searching for 061A in a hexeditor does not usually work. Some proggies are noted as looking for '1A06'.

If one looks in the Win95 OEM setup stuff, there is a copy of OXCOPY, OFORMAT and OATTRIB, which are the DOS 6.x files with the versioning removed. The O- bit is because the file-names need to be different that the autosetup does not select some other DOS version, eg PCDOS or whatever.

Not withstanding, while most of the PCDOS 7 stuff runs under other versions, XCOPY did not. This suspects that either it has a non-standard dos-check, or that it uses some strange interface.

The OSR5 (WinME) xcopy uses a unicode interface that is loaded under windows. It runs under DOS but the stdout is lost.

It is worth noting that the cruel coding in XCOPY and COMMAND.COM, extend the functionality of these under Windows. That is, xcopy is as capable as the DOS one outside of windows, and more powerful under Windows. Also both of these support long file names under windows, so using the DOS version under windows 9x is not reccomended.