How to disable the built-in XMS driver in Windows ME's IO.SYS

[PDU]

This is actually my first post here. If I made anything wrong, please just let me know.

Is there a way to disable the built-in XMS driver in Windows ME's IO.SYS or load the EMM386.EXE in WinME real mode?

[jaclaz]

I am not sure to understand the question, normally one would replace the memory manager with a "newer/better" one, *like* Umbpci.sys:

https://www.mdgx.com/dos.htm#DOS

https://www.mdgx.com/umb.htm

but there are more and - depending on your machine and amount of RAM[1] - it may be tricky to find the "right" one and the "right" configuration for it.

jaclaz

[1] this "summary" thread might be useful:

https://msfn.org/board/topic/118097-day-to-day-running-win-9xme-with-more-than-1-gib-ram/

 

[PDU]

1 hour ago, jaclaz said:

I am not sure to understand the question, normally one would replace the memory manager with a "newer/better" one, *like* Umbpci.sys:

https://www.mdgx.com/dos.htm#DOS

https://www.mdgx.com/umb.htm

but there are more and - depending on your machine and amount of RAM[1] - it may be tricky to find the "right" one and the "right" configuration for it.

jaclaz

[1] this "summary" thread might be useful:

https://msfn.org/board/topic/118097-day-to-day-running-win-9xme-with-more-than-1-gib-ram/

 

I think I did not make myself clear. UMBPCI.SYS is OK and a very good choice of using UMBs. The problem is not for UMBs. The WinME IO.SYS has a built-in XMS driver, which prevents loading of any other open source XMS driver alternatives, like HIMEMX.EXE or HIMEMSX.EXE. This built-in XMS driver also has an evil INT15H AH=87H handler, which hangs the system if you try to load EMM386.EXE in your config.sys. Without EMM386.EXE, Win311 can not be run in 386 enhanced mode, as there is no GEMMIS API provider. The open source alternatives like JEMM386 does not have GEMMIS API. Leaving that the only hope of running win311 386enh mode under winme real mode is to use qemm386 / 386max, which are both buggy, outdated and unstable. Therefore, I asked is there a way to disable the built-in XMS driver in winme io.sys, so that loading emm386.exe may be possible.

[jaclaz]

I see, so your "real" question is:

I want to run WFWG (Windows 3.11) from Windows ME DOS (Dos 8.0) in 386 enhanced mode, but it doesn't work because Dos 8.0 cannot load EMM386.EXE, an the only other seemingly compatible memory manager is qemm386 which is buggy/outdated/whatever.

Any way to workaround the issue?

(this way you are not "limited" to "disable the built-in XMS driver")

I think you are (loosely) here:

http://reboot.pro/index.php?showtopic=14204

(no solution found there)

Since Roytam is also an user here on MSFN, maybe he has some related news.

jaclaz

Edited January 3, 2022 by jaclaz

[PDU]

Yes, this is the question. I did not read that thread. I will see if that helps. Thank you jaclaz.

 

[MERCURY127]

u can patch one of four winme's io.sys for cancel boot to win directly and execute config.sys/autoexec.bat.
after this, u can insert in config.sys ordinary string

device=emm386.exe

and io.sys will load it. i am not sure that u can run win.com after this, but u can try.

[jaclaz]

Maybe useful, maybe not:

https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/275423

http://taris111.blogspot.com/2011/12/windows-me-ems-memory-support.html

http://www.columbia.edu/~em36/wpdos/emswinme.html

jaclaz

[PDU]

22 hours ago, MERCURY127 said:

u can patch one of four winme's io.sys for cancel boot to win directly and execute config.sys/autoexec.bat.
after this, u can insert in config.sys ordinary string

device=emm386.exe

and io.sys will load it. i am not sure that u can run win.com after this, but u can try.

four io.sys ? r u suggesting the CD-ROM version, HDD version, EBD version and the OEM audit mode version ? 

None of that works.

The 

device=emm386.exe

hangs the system.

Besides, only EBD version and audit mode version worth patches. The other two io.sys can not be used as real mode kernels.

[PDU]

OK，after two sleepless nights. I have done this.

The attached screenshot is a WFWG in 386 enhanced mode with msdos 8.0.

I tested it in 86Box. I do not have a physical machine for testing.

I need some more time to collect all tech details and patches to the IO.SYS

In summary, the built-in XMS driver can not be fully disabled, but it can be disabled partially to allow HIMEMX.EXE to be loaded, followed by EMM386.EXE.

The W3XStart patch is needed, also the WIN386.EXE patch as here

https://www.vogons.org/viewtopic.php?t=31922

and here

https://retrocomputing.stackexchange.com/questions/12946/running-dos-windows-3-and-windows-98-from-one-fat32-partition

[jaclaz]

Good work.

Only for the record, the Win386.exe patch is Rloew's  one:

https://msfn.org/board/topic/155954-how-do-i-stop-garbled-directory-after-exiting-win311/

https://msfn.org/board/topic/155954-how-do-i-stop-garbled-directory-after-exiting-win311/#comment-993238

jaclaz

[PDU]

Here is the detail of the patch:

Use original Windows ME OEM audit mode IO.SYS. (i.e. the one in those dta files and can boot hdd without patch)

Use IO8DCOMP to decompress it

In the decompressed file

Search 

9A 9D 02 21 1F

at offset 14689H

Replace it with 

EB 0D 90 90 90

The Built-in XMS Driver will be disabled, but not entirely!

HIMEM.SYS can not be loaded. It will hang the system if your try.

However, the HIMEMX.EXE, an open source alternative, can be loaded normally with /METHOD:KBC

The EMM386.EXE can be loaded with HIMEMX.EXE.

After applying W3XStart patch, the following trick must be used to start wfwg in 386 enh mode

ren win.com winx.com

copy system.ini system.in1

del system.ini

winx /3

(You got error)

copy system.in1 system.ini

winx /3

Now have wfwg in 386 enh mode.

Make the above process as win.bat.

This seems like correcting one error with another error. But, it works.

 

 

Edited February 2, 2022 by PDU

[_Smoker]

Full:

1. Download http://download.microsoft.com/download/winme/patch/22527/winme/en-us/311561usam.exe
2. Extract with 7z winboot.ebd from 311561usam.exe
3. Apply Real DOS-Mode Patch for Windows Millennium v1.3 By Reines
    8075098D==>>80EB098D
4. Decompress winboot.ebd as IO.SYS
5. Disable the built-in XMS driver
    9A9D02CE1E==>>EB0D909090
Done!

My config.sys

device=xmgr.sys
;device=himemx.exe
device=emm386.exe

My autoexec.bat
@echo off
emm386

Result

Windows Expanded Memory Driver  Version 4.95
Copyright 1988-1995 Microsoft Corp.

  Available expanded memory . . . . . . . . 32,76KB

  LIM/EMS version . . . . . . . . . . . . .   4.0
  Total expanded memory pages . . . . . . .  2,07
  Available expanded memory pages . . . . .  2,04
  Total handles . . . . . . . . . . . . . .    64
  Active handles  . . . . . . . . . . . . .     1
  Page frame segment  . . . . . . . . . . .  D000 H

EMM386 Active.

[PDU]

I come back again for some updates. 

The patches provided by _Smoker and me are for different versions of IO.SYS.

It is confusing, but essentially the same thing. The patch knocks out a far call instruction to a procedure that install handlers to INT 15H AH=87H/88H and AX=E801, also INT 2FH AX=4300H / 4310H and 4309H, also the source of some GDT entries.

This will make HIMEMX.EXE to work. However, if some one has tried our way of patching, some side effects will be found. like wrong mem command output, system hangs in safe mode, running to massive non-sense output in loading some applications.

Also, to start the wfwg in enhanced mode, some tricks like I mentioned must be used. 

To solve all these problem. I made some analysis and developped a small new driver program for the purpose of loading EMM386 and WFWG.  I call it IO8EMMOK. it can be downloaded from GitHub https://github.com/pufengdu/IO8EMMOK

IO8EMMOK.SYS is a wrapping driver that convert the built-in XMS driver to a generally normal XMS driver. I wrote the tech details in the comments of the source codes.

Here is a short summary of the details of technology. In general MS-DOS 8.0 is a DOS always in HMA without any stub below 1MB. The XMS driver is also in HMA. Since XMS driver is in responsible of controling A20, it becomes a key behind the lock case. Therefore, every time an application abitarily disable A20 and try calling DOS or XMS driver, system reboots or hangs. Every time an application rely on the address wrapping mechanism tried to run, the system reboots or hangs. This is also why MS-DOS 8.0 seems so unstable. Its A20 must be kept ALWAYS ON. However, this is an old case for DOS services, but new to an XMS driver. Most programs, including Win3x, thought the XMS driver is some where below 1MB. Therefore, it should work even with A20 off. But, this is not the case on MS-DOS 8.0. My IO8EMMOK driver provide a very simple wrapping layer to the XMS driver, making it callable with A20 off. In this case, the driver tun on A20, forwad the call, then turn off A20 again. This creates the minimal side effects, but not zero.

With this driver, no patch is needed to load EMM386.EXE. Just load the IO8EMMOK.SYS as the first driver in the CONFIG.SYS

EMM386.EXE will be happly to load as normal, no HIMEMX.EXE nor HIMEM.SYS.

I also adapted the W3XStart patch in this case as a hotfix patch, which only modify memory. It can also be downloaded from the same github repo. There is no need to decompress the IO.SYS. The compressed form IO.SYS with the one-byte real-mode patch can be used now.

With the IO8EMMOK driver, and my W3XStart hot fix, it would be easy to start WFWG in enhanced mode.

The last element of making this happen, is to use a serial mouse, not PS/2. And set mobo option of Gate A20 to "Normal"

The WFWG default mouse driver is not going to work in this way. Update it using Microsoft Mouse Driver 9.01. It is easy to find online.

I finally achieved the attached effects. WFWG is fully functioning on MS-DOS 8.0, without hanging, without tricks, without decompressing IO.SYS.

If someone found bugs of the driver, fixes are welcome.

 

Edited February 8, 2022 by PDU

[Win95rtm]

On 2/8/2022 at 11:03 PM, PDU said:

I come back again for some updates. 

The patches provided by _Smoker and me are for different versions of IO.SYS.

It is confusing, but essentially the same thing. The patch knocks out a far call instruction to a procedure that install handlers to INT 15H AH=87H/88H and AX=E801, also INT 2FH AX=4300H / 4310H and 4309H, also the source of some GDT entries.

This will make HIMEMX.EXE to work. However, if some one has tried our way of patching, some side effects will be found. like wrong mem command output, system hangs in safe mode, running to massive non-sense output in loading some applications.

Also, to start the wfwg in enhanced mode, some tricks like I mentioned must be used. 

To solve all these problem. I made some analysis and developped a small new driver program for the purpose of loading EMM386 and WFWG.  I call it IO8EMMOK. it can be downloaded from GitHub https://github.com/pufengdu/IO8EMMOK

IO8EMMOK.SYS is a wrapping driver that convert the built-in XMS driver to a generally normal XMS driver. I wrote the tech details in the comments of the source codes.

Here is a short summary of the details of technology. In general MS-DOS 8.0 is a DOS always in HMA without any stub below 1MB. The XMS driver is also in HMA. Since XMS driver is in responsible of controling A20, it becomes a key behind the lock case. Therefore, every time an application abitarily disable A20 and try calling DOS or XMS driver, system reboots or hangs. Every time an application rely on the address wrapping mechanism tried to run, the system reboots or hangs. This is also why MS-DOS 8.0 seems so unstable. Its A20 must be kept ALWAYS ON. However, this is an old case for DOS services, but new to an XMS driver. Most programs, including Win3x, thought the XMS driver is some where below 1MB. Therefore, it should work even with A20 off. But, this is not the case on MS-DOS 8.0. My IO8EMMOK driver provide a very simple wrapping layer to the XMS driver, making it callable with A20 off. In this case, the driver tun on A20, forwad the call, then turn off A20 again. This creates the minimal side effects, but not zero.

With this driver, no patch is needed to load EMM386.EXE. Just load the IO8EMMOK.SYS as the first driver in the CONFIG.SYS

EMM386.EXE will be happly to load as normal, no HIMEMX.EXE nor HIMEM.SYS.

I also adapted the W3XStart patch in this case as a hotfix patch, which only modify memory. It can also be downloaded from the same github repo. There is no need to decompress the IO.SYS. The compressed form IO.SYS with the one-byte real-mode patch can be used now.

With the IO8EMMOK driver, and my W3XStart hot fix, it would be easy to start WFWG in enhanced mode.

The last element of making this happen, is to use a serial mouse, not PS/2. And set mobo option of Gate A20 to "Normal"

The WFWG default mouse driver is not going to work in this way. Update it using Microsoft Mouse Driver 9.01. It is easy to find online.

I finally achieved the attached effects. WFWG is fully functioning on MS-DOS 8.0, without hanging, without tricks, without decompressing IO.SYS.

If someone found bugs of the driver, fixes are welcome.

 

good

[roytam1]

On 2/8/2022 at 11:03 PM, PDU said:

I come back again for some updates. 

The patches provided by _Smoker and me are for different versions of IO.SYS.

It is confusing, but essentially the same thing. The patch knocks out a far call instruction to a procedure that install handlers to INT 15H AH=87H/88H and AX=E801, also INT 2FH AX=4300H / 4310H and 4309H, also the source of some GDT entries.

This will make HIMEMX.EXE to work. However, if some one has tried our way of patching, some side effects will be found. like wrong mem command output, system hangs in safe mode, running to massive non-sense output in loading some applications.

Also, to start the wfwg in enhanced mode, some tricks like I mentioned must be used. 

To solve all these problem. I made some analysis and developped a small new driver program for the purpose of loading EMM386 and WFWG.  I call it IO8EMMOK. it can be downloaded from GitHub https://github.com/pufengdu/IO8EMMOK

IO8EMMOK.SYS is a wrapping driver that convert the built-in XMS driver to a generally normal XMS driver. I wrote the tech details in the comments of the source codes.

Here is a short summary of the details of technology. In general MS-DOS 8.0 is a DOS always in HMA without any stub below 1MB. The XMS driver is also in HMA. Since XMS driver is in responsible of controling A20, it becomes a key behind the lock case. Therefore, every time an application abitarily disable A20 and try calling DOS or XMS driver, system reboots or hangs. Every time an application rely on the address wrapping mechanism tried to run, the system reboots or hangs. This is also why MS-DOS 8.0 seems so unstable. Its A20 must be kept ALWAYS ON. However, this is an old case for DOS services, but new to an XMS driver. Most programs, including Win3x, thought the XMS driver is some where below 1MB. Therefore, it should work even with A20 off. But, this is not the case on MS-DOS 8.0. My IO8EMMOK driver provide a very simple wrapping layer to the XMS driver, making it callable with A20 off. In this case, the driver tun on A20, forwad the call, then turn off A20 again. This creates the minimal side effects, but not zero.

With this driver, no patch is needed to load EMM386.EXE. Just load the IO8EMMOK.SYS as the first driver in the CONFIG.SYS

EMM386.EXE will be happly to load as normal, no HIMEMX.EXE nor HIMEM.SYS.

I also adapted the W3XStart patch in this case as a hotfix patch, which only modify memory. It can also be downloaded from the same github repo. There is no need to decompress the IO.SYS. The compressed form IO.SYS with the one-byte real-mode patch can be used now.

With the IO8EMMOK driver, and my W3XStart hot fix, it would be easy to start WFWG in enhanced mode.

The last element of making this happen, is to use a serial mouse, not PS/2. And set mobo option of Gate A20 to "Normal"

The WFWG default mouse driver is not going to work in this way. Update it using Microsoft Mouse Driver 9.01. It is easy to find online.

I finally achieved the attached effects. WFWG is fully functioning on MS-DOS 8.0, without hanging, without tricks, without decompressing IO.SYS.

If someone found bugs of the driver, fixes are welcome.

 

I tried with Windows 3.1 Chinese Edition, and it backs to DOS prompt after showing slash screen, tried to patch win386.exe but still getting same result.

loading IFSHLP.SYS makes it stalls in slash screen.

Edited April 7 by roytam1