9th April 2022, 23:38 (UTC)
Hi, Big Monstro. Thanks for the reply.
krnl386.exe with shell = (system.ini) pointed at w31space.exe is how win9x boots the system in "a" win3x environment, that can resize a drvspace compressed disks (drivespace.000).
The easiest way to examine the setup is to create a compressed drive. Then examine the contents of the folder failsafe.drv, on the actual drive (host drive).
You will find the bare essentials and boot configurations for running this win3x environment. You will also find d31frag.exe, dosx.exe, and a handful of win3x .drv files.
I assure you, this is a win3x that comes with win9x. I believe these files are available in your system, without creating a compressed drive. I suppose you might need drvspace installed.
9th April 2022, 23:58 (UTC)
Come to think of it, with a properly configured pif file, you might even be able to run win3x in win9x. Though that might have been lost, after the Chicago betas (some included it as a feature).
I've wondered if this win3x environment is standard mode only. Thinking back to the betas, that had the feature, it might be.
Edit2: Nevermind, win31.exe from the betas ran in enhanced mode. So krnl386.exe is probably similar.
Edit1: added dosx.exe to partial list of win3x files
10th April 2022, 04:30 (UTC)
This is just a guess. Win95 needs at least 5 virtual drivers loaded to boot into a safe mode like state. One, some, or all of those drivers must get in the way of resizing the compressed volume. That is probably why the win3x environment is used. Why not use dos? I don't know. Maybe to prevent too much compressed drive functionality, outside of windows.
If you boot your win9x machine with MSDOS.SYS configured to BootGUI=0, then you have to type "win" to start windows. If you resize your compressed drive with the BootGUI=0, to start the win3x environment you still need to type "win". krnl386.exe is unable to switch the computer into protected mode, on its own.
I've wanted to check out, but its not very practical, how far this environment can be pushed. Using a mix of the 16bit parts from win9x and original win3x, could a usable system be patched together? Does shell.dll from win9x add anything? Would win32s work? Could it be extended some?
If you search really old "Jaclaz" posts from "RebootPro", you can find his directions for building a 32bit dos using win9x. It basically loads all the normal virtual drivers for win9x and then points the shell to command.com. I guess you then have "long file name" support. I've always wondered if vdmsound for win9x would provide SBlaster support in a setup like that.
Are any of those virtual drivers useful to the win3x environment, if included in the boot process?
Edit: I know at some point during the Chicago beta development the kernel remained 16bit, but the virtual machine manager became capable of loading 32bit drivers. It was optional.
Anyway, this is more information for the interested. If no one knows anything or hasn't played with it themselves, I'll update this if/when I ever explore it.
10th April 2022, 9:38 (UTC)
Big Monstro, I guess if it was really just the 32bit kernel running with 16bit drivers you would be right. That would still explain why they didn't just use safe mode. But that wouldn't explain why they were using 16bit versions of drvspace and defrag.
Edit: Actually, maybe it would. Since both are disk accessing applications used with 16bit hardware drivers.
If it was a win32 environment, it would be very interesting. I was able to load krnl386.exe in Dosemu by simply having dosemu's dpmi enabled (no win.com used). I haven't tried it on an actual machine, with a real dos dpmi server.
10th April 2022, 10:04 (UTC)
However, I did once get and error window. It was a great big win3x style window and button. That would have ran independent of the win3x apps.
10th April 2022, 10:10 (UTC)
Something interesting to add. When in the failsafe.drv directory and examining the system.ini file, setup is commented out ";" and replaced by the win3x drvspace for shell.
I had guessed this was because during installation the environment was 16bit.
11th April 2022, 04:39 (UTC)
This isn't really an indicator of bit, but the Win31 apps run (from the failsafe.drv folder) with Win3x minimize and close buttons. When you run them (the same Win31 apps) in Win95/98 they are decorated with Win9x buttons.
I thought I knew from something I had read, that for sure this was a Win3x environment. But I do feel a little foolish not knowing for certain that "environment" doesn't just mean "Similar to Win3x".
At any rate, it is "very" similar, if not actually it.
I do apologize for the many posts. I recognize that the forum should not be used as my personal note pad.
If my writing is cloudy, off topic, or erratic, please feel free to point it out. I have painfully loud tinnitus, and it makes life hard. Mostly from the lack of sleep. So I may ramble on as if I have a point, when none is found. Either I don't have one, or I just didn't write out full thoughts.
13th April 2022, 03:50 (UTC)
Well, nothing too exciting.
I examined the file sizes against Win311. They looked the same. With Win311 installed over EnhanceDrDos, I replaced original files with the ones from Win98se. Everything worked fine. I did not compare files with a hex editor. But it seems that there is nothing new about them.
I created a test Msdos(Win98se) virtual disk. I copied over Win311 and re-examined how Drivespace3 boots under Win3x to resize a compressed volume. The best I could, I applied those configurations to the test virtual disk. The problem was that a real Win311 install has system files split between the Windows and Windows/System folders. After some path tweaking, I managed to get it to load Win311.
A installation of Win98se, with msdos.sys configured to BootGui=0, will boot to the dos prompt. I'll type win to initiate the Win311 resize environment. On the test virtual disk, also set BootGui=0, it loads Win311 automatically. So "BootGui=0" probably has nothing to do with it.
Win.com also has little or nothing to do with it. On the Win98se compressed system, typing win > enter just initiates what is in the temporary autoexec.bat. I have no clue why it is booting to the dos prompt or why win > enter initiates the autoexec.bat.
The "unpatched" Win98se dos loading of Win3x is done by using dosx.exe. This is nothing new. Even though it is krnl386.exe being loaded, this setup is limited as standard mode with no use of the Win3x dos box. The reason it loads "unpatched" is because win386.exe, or somthing it loads, is never touched. The reason you can't use a dos box is because nothing loads dswap.exe. This is the task switcher for win3x in standard mode and win.com loads it for krnl*86.exe.
Finally, hdpmi16.exe from Japheth's HX dos extender can be used in place of dosx.exe. For me it work with far less tweaking. I did have windows\system added to the system path. From the Windows directory I ran krnl386.exe after loading hdpmi16. It worked fine, with the same limitations.
So there isn't anything too useful here. I am getting the impression that one could load Win3x like this, from a Win3x dos box and shell pointed at a specific application, to run the Win16 application preemptively. It might save on resources only running krnl386 and whatever application was desired. I'd think network serving (like ftp) applications would be the most desired, but that would throw more complications at the whole thing.
10th May 2022, 13:37 (UTC)
Still haven't really had time to examine all of the Win3x legacy files.
Win9x also includes win32s16.dll and other win32s files. They are probably meant to provide compatibility with software written specifically for win32s.
I have used Win9x files to get 32bit applications working on Win3x. But I've only ever done it as needed. And it hasn't always worked.
As with krnl386.exe, there may be no significant difference to these files. But one would assume they are more appropriately linked to stock Win9x files.
is an article describing manually configuring win32s. I included it, as someone may end up playing this stuff. Maybe it will help.