VOGONS


First post, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie

I just started trying to get Windows 3.1/3.11 working on my X99-based system, which is currently running a functional dISAppointment (v0.2).

So far I'm successful in getting standard mode (WIN /S) ready to use, with SVGA and sound, but I'm hitting a wall on getting 386-enhanced mode working.

Here's some info about my system environment.

I've configured my SATA controller to AHCI mode as when I tried some DOS benchmarks, it appears my SSDs perform much better with AHCI (~500MB/s linear read) compared to IDE mode (~260MB/s linear read). Also, the amount of UMB I can access is nearly the same when using AHCI compared to IDE, and other OSes I'm using on this system also have working AHCI support, so there's no reason not to use AHCI here. I'm using AHCICD.SYS/AHCICD.DLL for optical drive, by the way.

For Win3.x I'm using a modified Win98SE IO.SYS (MS-DOS 7.10) which includes the W3XSTART patch for enabling Win3.x operation.

To further ensure a compliant environment, I created a specialized MS-DOS startup config using mainly the following TSRs:

- HIMEM.SYS from Win3.11 (naturally limits RAM to 64MB)
- IFSHLP.SYS from Win3.11
- SMARTDRV.EXE from Win3.11

Haven't loaded DOSLFN for this config yet, but AFAIK it doesn't magically enable LFN for Windows apps so its usefulness may be limited. I remember there are some utilities that enables LFN for Windows 3.x to some extent.

And here are the drivers and configuration I used for Windows 3.11.

For video I'm using the patched SVGA driver (svga256.drv) which works without major issues on my system, even during GUI install phase. The default VGA driver is too glitchy (such as missing texts in some places) for normal use on this system, though barely okay for GUI install phase.

USB mouse doesn't appear to work correctly while in Win3.11 so I have to use a PS/2 one. No issues with USB keyboard, though. Should be noted that while in DOS, only CuteMouse can enable proper USB mouse operation (I'm using 2.1).
(EDIT: Can be fixed by using Win-OS/2's MOUSE.DRV. See comments.)

I've disabled 32-bit disk and file access since they obviously won't work correctly on such environments (the partitions are FAT32 after all).

At this point, trying to start Windows in 386-enhanced mode would lead to a black screen with a blinking cursor at around the beginning of 3rd line. I can CTRL-ALT-DEL at this point.

I originally tried Windows for Workgroups and ran into the same problem, and thought it might be related to networking (see here). However, after further testing with both WfW and Win3.11 it doesn't appear to be the case, as trying to start 386-enhanced mode failed at the same point regardless.

Then I found this (AHCIFIXD.SYS/AHCIFIX.386). I added the driver to system.ini and Windows 386-enhanced mode booted a bit further. I don't see the screen with blinking cursor anymore, but still a hang. After about 20-30 seconds I get a single PC speaker beep and if I waited too long I won't be able to CTRL-ALT-DEL anymore and have to manually reset the system. Bootlog (WIN /B) does not show anything failed to load. It seems AHCIFIX is indeed needed, but it's not everything required for a successful 386-enhanced mode startup...

For the time being I'm using Windows 3.11, not Windows for Workgroups, since the latter no longer offers the option to boot Standard Mode out-of-box and needs some modifications in order to do so.

As for sound, I've a CT2950 installed on my dISAppointment. It seems the SB16 driver either doesn't work with Standard Mode, or I did not install it correctly, as it complained about drivers missing. But Windows' built-in SB 1.5 driver works fine for both sound and MIDI (via daughtercard) while in Standard Mode.

Last edited by LSS10999 on 2024-06-11, 15:53. Edited 1 time in total.

Reply 2 of 10, by Jo22

User metadata
Rank l33t++
Rank
l33t++

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.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 3 of 10, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 4 of 10, by Jo22

User metadata
Rank l33t++
Rank
l33t++

🤷‍♂️

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).

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 5 of 10, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 6 of 10, by Jo22

User metadata
Rank l33t++
Rank
l33t++

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

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 7 of 10, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 8 of 10, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 9 of 10, by Jo22

User metadata
Rank l33t++
Rank
l33t++
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.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 10 of 10, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie

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".