PDU

I think what you are trying to do is to load Win3.1CHT using a DOS that can boot within a very limited disk space. Have you tried to use FreeDOS? According to my test, It is capabble of loading WFWG now. See my github record: https://github.com/pufengdu/RetroFuns/blob/main/WFWG/FDWFWG.md It is still not in a perfect status, but can be expected to be better. EDIT: Very interesting to see that RM386 does not work. I remebered that M$ bought RM386 from Helix and its OPTIMIZE program. The memmaker is essentially the same as the OPTIMIZE and EMM386 suppose to be very similar to RM386. QEMM386 / 386MAX do not work as expected. I remembered that I have tried these.

Thanks for the message. I do not play LZ-DOS. Sorry. Besides, the key to load WFWG in msdos8 is to allow GEMMIS in EMM386.EXE to do its work when WFWG inits. If only IO8EMMOK.SYS is loaded, WFWG wont work. Although WFWG should work with only XMS, it is not the case in MSDOS8. BTW2, the EMM386.EXE from PC-DOS 2000 is the best in my test.

Not quit sure. If I remembered right, it works with pwin3.2, that special simplified chinese version. I will give it another try when I have some more time.

I know this is a DOS question, which may not be suited here. If this is not welcome, just let me know. I encountered this SWITCHES=/I line in the config.sys file in the IBM SGKT. Exact location follows: ibm_sw_sgtk_1_3_07_anyos_anycpu.zip\sgdeploy\sgtk\DOS\cfgfiles\CONFIG.SYS The ZIP file can be downloaded publicly from IBM official site: https://www.ibm.com/support/pages/ibm-serverguide-scripting-toolkit-dos-edition-version-1307 It contains a set of files, which are usually considered as a set of files to upgrade PC-DOS 2000 to PC-DOS 7.1. I can not find any information regarding this line in the CONFIG.SYS. This is special to PC-DOS 7.1,I think. Some preliminary experiments shows that this line seems to affect the 32BFA of WFWG. When this line is missing, WFWG can not enable 32BFA even on a FAT16 partition. When this line is added, the 32BFA is OK in WFWG. Anyone here know about the function of this line SWITCHES=/I in PC-DOS 7.1 ?

It is just a toy these days, right? I am not intended to make some mini windows. I want to make some "good DOS". I just think that throwing some bones of windows to DOS is a better idea than using various DPMI hosts. As windows is capable of multi-tasking, why not to let DOS act as some local environment, and let windows do all the magics. Just because it is too complicated and too large? But if you keep only the most basic functions. It is not that large. ove 90% of the size can be reduced. Currently, this kind of configuration is good for me to run many retro games. That is enough. I am not going to share the file list now, because I am playing with it, and it is dirty. I will share a clean and proved file list with scripts and configurations once I have cleaned it up. I can tell you how I did it. I followed the recipe here http://reboot.pro/index.php?showtopic=22584 and the pages on wikipedia: https://en.wikipedia.org/wiki/Architecture_of_Windows_9x Copy those files, write a system.ini yourself, mostly the original WinME system.ini, and a skeleton win.ini. Try to run regedit.exe, progman.exe, winfile.exe and notepad.exe. If they complain missing some files, copy them too. If you still have errors, try to use dependency walker to profile that program in a normal installation of Windows ME. Find out what is missing and supply them to your installation. Enventually, you will get a set of files to run these programs. Registry is not necessary for the above set (including the REGEDIT.EXE), although win.com will complain that when booting. The system behaves like Windows 3.x. The command.com can be configured as a shell in the system.ini. In this way, you get multi-tasking DOS environment. The start command can be use to open DOS windows as many as your memory is enough. TSRs and environment vars can be loaded differently in every DOS session. This is interesting. As for the registry again, if you only want these basics, it is not necessary. But if you desire TCP/IP stacks, NetBIOS, NTFS, COM/DCOM, WSH or something related to IE, it is a must. BTW, in this mode of running, there is no place for a real-mode DOS. CONFIG.SYS is not necessary if you do not need to load 16-bit drivers. Therefore, the Windows ME Real Mode DOS patching is not needed anymore. The hard drive version IO.SYS and COMMAND.COM works well in this mode.

Thank your both jaclaz and RainyShadow. I solved this when I was wandering on the wikipedia, and see this https://en.wikipedia.org/wiki/Windows_Console "Windows 9x support is relatively poor compared to Windows NT, because the console window runs in the system virtual DOS machine and so keyboard input to a Win32 console application had to be directed to it by conagent.exe running in a DOS VM that are also used for real DOS applications by hooking the keyboard interrupt. conagent.exe then calls Vcond (which is a VxD). Vcond then had to pass the keyboard input to the System VM, and then finally to the Win32 console application. Besides performance, another problem with this implementation is that drives that are local to a DOS VM are not visible to a Win32 console application. This can cause confusion." I found that my missing piece is called conagent.exe in the system folder. To achieve this, there is no registry setting related. The required elements are PIFMGR.DLL, which allows you to edit the PIF. CRTDLL.DLL, START.EXE, and CONAGENT.EXE, which solve the last problem.

I tried that "start notepad.exe". It does not work. I also tried to change the settings "Prevent MS-DOS-based programs from detecting Windows". By unchekcing that, the error message become can not execute XXXXX, like attached. strat notepad.exe from the progman always works. But it does not start from command prompt.

I stripped down the windows me installation. I made a very tiny installation of Windows ME, even without registry. The WINFILE, PROGMAN, TASKMAN and NOTEPAD works well when they are started from the PROGMAN or WINFILE. But, when I tried to start them from command prompt. I got error messages like "This program can not be run in DOS mode". See the attached screenshot for details. How to solve this and restore the normal Windows ME behavior? (Notepad should run if your type notepad in the command prompt window) I know I stripped too much. What is the minimum requirement for restoring this. I guess this may be related to some registry settings, what are the minimum registry settings needed. BTW, the explorer.exe does not work. Seems like some registry settings are needed.

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.

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.

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

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.

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

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.

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?