For that kind of stuff, only SoftICE comes to mind.
https://en.wikipedia.org/wiki/SoftICE

If you absolutely can't get Windows' 386 Enhanced-Mode Kernal running, then there's a workaround:
You can try using Win-OS/2 system files.
For a long time, that's what Qemu dosemu project had used to get Windows 3.1 running.

Link: http://www.dosemu.org/docs/README/1.2/windows.html

IBM's Win-OS/2 has another "feature" if we will. It will request memory via DPMI rather than via himem.sys (XMS).
So it works in reverse to a real MS Windows 3.1 (here, Windows is a DPMI provider rather than a DPMI client).

Anyway, these are just some thoughts..

Edit: I'm assuming that some DPMI provider like QEMM, EMM386, 386Max or Helix Cloaking is running..

Edit: Typo fixed. Link added.

Jo22 wrote on 2024-06-10, 20:06:

If you absolutely can't get Windows' 386 Enhanced-Mode Kernal running, then there's a workaround: You can try using Win-OS/2 sys […]
Show full quote

If you absolutely can't get Windows' 386 Enhanced-Mode Kernal running, then there's a workaround:
You can try using Win-OS/2 system files.
For a long time, that's what Qemu dosemu project had used to get Windows 3.1 running.

Link: http://www.dosemu.org/docs/README/1.2/windows.html

IBM's Win-OS/2 has another "feature" if we will. It will request memory via DPMI rather than via himem.sys (XMS).
So it works in reverse to a real MS Windows 3.1 (here, Windows is a DPMI provider rather than a DPMI client).

Anyway, these are just some thoughts..

Edit: I'm assuming that some DPMI provider like QEMM, EMM386, 386Max or Helix Cloaking is running..

Edit: Typo fixed. Link added.

Interesting... so with Win-OS/2's files... which DPMI provider should I use?

I think what you listed were simply EMS/UMB managers and not necessarily DPMI. I normally don't use any such managers for a Windows startup config, even on old PCs that could already run Win3.x with little effort, as in most cases they don't work well with Windows. The DPMI providers I know of are something like DOS4G(W), DOS32A, CWSDPMI, QDPMI (part of QEMM) as well as the new HDPMI (part of HX).

(Can't say about 386MAX or NetRoom, as when I tried loading those memory managers the system outright reboots which, if done from a VM such as VBox, would probably be a Guru Meditation crash.)

Speaking of HX (HDPMI), I did give HX's experimental DOSX (can be found in UNSUPP) a try. It kind of works but certainly not as compatible as running Standard Mode in a compliant environment.

Using HIMEMSX instead of Win3.x HIMEM, without parameters, substituted Windows' DOSX with HX's, started HDPMI16+32 resident before finally invoking WIN /S to start the system. In this state I can start Windows in Standard Mode just fine, and some programs do work. But as soon as I start File Manager the system crashes with output of stacktrace briefly visible before it automatically reboots.

My system actually has very limited amount of memory available below 4G boundary, only about 1.4GB. I think it's probably because of my video card. As such, I cannot reach any conclusion regarding whether HX's DOSX coupled with at least HDPMI16 can work with more than 2GB of available RAM.

🤷‍♂️

To be honest, I never tried Windows with such a configuration.

Windows 3.1x (non-WfW) has two kernals that can do Standard-Mode, btw.
Krnl286.exe through DOSX Extender and krnl386.exe with disabled VXD support.

It's possible to run krnl286.exe manually by calling DOSX from inside Windows directory.
C:\Windows> C:\Windows\System\dosx

This isn't necessary here, though, since apparently the 386 Protected-Mode kernal works just fine (a good sign).

Well... I never really tried debugging stuffs in DOS as I don't have anything that ever needed such analysis back then.

Don't know if I ever can hook something like SoftICE to the Windows kernel itself, and whether I can at least let the debugger bring out some useful info the moment when the crash/hang happens...

Still, it's definitely something interesting to try out.

Debugging Windows 3: https://www.os2museum.com/wp/kernel-debugging … ith-virtualbox/

Jo22 wrote on 2024-06-10, 20:06:

If you absolutely can't get Windows' 386 Enhanced-Mode Kernal running, then there's a workaround: You can try using Win-OS/2 sys […]
Show full quote

If you absolutely can't get Windows' 386 Enhanced-Mode Kernal running, then there's a workaround:
You can try using Win-OS/2 system files.
For a long time, that's what Qemu dosemu project had used to get Windows 3.1 running.

Link: http://www.dosemu.org/docs/README/1.2/windows.html

IBM's Win-OS/2 has another "feature" if we will. It will request memory via DPMI rather than via himem.sys (XMS).
So it works in reverse to a real MS Windows 3.1 (here, Windows is a DPMI provider rather than a DPMI client).

Just actually tested this. The commands I found in "winemu.bat" apparently calls "OS2K386.EXE" directly. This still runs in Standard Mode, however.

Since it uses an external DPMI provider instead of Windows' own, it behaves very similar to calling WIN /S with DOSX replaced by HX's. (HDPMI16 and 32 already resident)

That is, can use more RAM with HIMEMX/HIMEMSX, and of course, WINFILE crashes the system in the same manner. Further tests indicate the WINFILE crash has more to do with HX than the amount of available RAM, as it crashed even when using just Win3.11's HIMEM.SYS (64MB). Maybe I should use a different DPMI provider for such a setup.

Still, Standard Mode is kind of restrictive compared to 386-enhanced Mode so I'm not sure how far I can make use of it. IIRC an earlier version of Win32s can be used in Standard Mode... or maybe not... will search for a bit more info about it...

EDIT: Nope... couldn't find anything about a version of Win32s that could be used with Standard Mode. Guess I was wrong.

PS: The MOUSE.DRV from Win-OS/2 actually fixed my issue with USB mouse. Now it works without any issue.

Still can't find a good way to inspect what's really going on with the system when trying to run 386-enhanced mode (AHCIFIX.386 loaded). Some notes.

- If I let it print a bootlog (WIN /B), the screen won't go blank, though it'll still give me the beep after a while.
- SoftICE 2.8 doesn't run. Trying to run manually it complained need to stay at top memory, while trying to load it as device driver (after HIMEM.SYS) it complained about having no extended memory. This is with Win3.11's HIMEM.SYS. Don't know why.
- Tried lDebug. I could load WIN.COM and let it run by entering "G", but it doesn't appear I could make any lDebug output to appear on the screen as the console output was kind of messed. Mashed the keyboard a bit and found the cursor moved a bit to the top (don't know which command triggered it, or maybe the system did so on its own). Apparently I was back into lDebug's shell, but I can't see anything as nothing I typed were visible at that moment. Don't know if I could pipe whatever output to a file similar to linux's "tee" command.

Just tried bringing up a new install of WfW 3.11 (old Win3.11 files moved elsewhere), and it behaved the same as old Win3.11 with AHCIFIX.386. On the other hand, the FAT32 compatibility patch for WIN386.EXE that I found somewhere on this forum only supported the file version that came with WfW -- can't be used with my old Win3.11 install.

LSS10999 wrote on 2024-06-11, 11:30:

Still, Standard Mode is kind of restrictive compared to 386-enhanced Mode so I'm not sure how far I can make use of it. IIRC an earlier version of Win32s can be used in Standard Mode... or maybe not... will search for a bit more info about it...

EDIT: Nope... couldn't find anything about a version of Win32s that could be used with Standard Mode. Guess I was wrong.

PS: The MOUSE.DRV from Win-OS/2 actually fixed my issue with USB mouse. Now it works without any issue.

Hi there, sorry to hear it's still causing issues. :(
Standard-Mode.. Yeah, it's a bit limiting, really. OS/2 v1.3 was more capable on an 80286 system in comparison. Virtual memory, memory-protection, full-fledged drivers..

Unfortunately, I'm afraid I can't really help much with 80386 stuff here, since I grew up with an 80286 at the time Windows 3.1 was still current (I'm guilty for mentioning this so often, hah).
And my father's PC ran Windows 95 already when I was into Windows 3.1..

So I can't talk much from experience when it comes to 386+Win3.1 - or V86 stuff in general.
I mean sure, I've helped my father sometimes back then, but he was mostly upgrading PCs to Windows 95 already by this point.

I think X99 is very, very different from Z97 (against which AHCIFIX.386 was said to be tested according to the author), despite being of the same generation. What holds true for Z97 does not necessarily hold true for X99.

Here are some other issues with X99 regarding legacy stuffs, that probably would work with Z97, as well as a good amount of later generation consumer-grade CPU/chipsets:

- UMBPCI: Xeon E5 doesn't support shadow RAM while Xeon E3 does, according to their respective datasheets.
- UniATA: Neither IDE nor AHCI works with it (0x7B). As such, attempts to run NT 3.51 on this system were not successful, either.

Considering the situation with UniATA, I suspect what caused AHCIFIX.386 not to work on X99 is probably similar, and likely needs a separate fix (code path). Perhaps previous Xeon E5 generations like X79 were also like this.

EDIT: Looks like AHCIFIX.386 does work. The problem lies deeper than that. I briefly switched to IDE mode and excluded loading of AHCIFIX/AHCIFIXD and tried launching Win3.x in Enhanced Mode again, and it stopped at the same place, same beep.

I also tried starting Windows in Enhanced mode with EDR-DOS. Same behavior, except the system totally hung (can't use CTRL-ALT-DEL) and without the beep.

This leaves only these possible causes of the issue:
- My SSDs are very large and were formatted with FAT32 MiB-aligned with GParted during initial deployment.
- Perhaps I should use XMGR.SYS + LIMITMEM to limit available memory rather than Win3.x's HIMEM.SYS? (HIMEMX/HIMEMSX doesn't work out-of-box even with Standard Mode, as Win3.x simply can't see it.) (EDIT: That doesn't make any difference.)

PS: I'm not sure about how far Win3.x can support FAT32 in 386-enhanced mode. Haven't really spinned up Win3.x instances for quite a while. I did have success with Win3.x and DOS 7.10 a long time ago but was on a very old PC using a very small HDD (853MB).

EDIT 2: Tried ONTRACKW.386 driver and it refused to load, complaining about "interrupt conflict".