This is not exactly related to my patch but still of some interest and deserves investigation. So, WFW 3.11 runs just fine with CVS (as of today) and my patch in both normal and dynamic core. I was actually quite surprised to see it running with dynamic. But... when I tried the same with the Daum Cafe build only the normal core worked. With dynamic core DOSBox exited after showing Win3.11 splash screen. Before anybody jumps to (seemingly obvious) conclusion that some other patch is bad, here is another piece. I use VS.NET 2003 and can compile either Release or Debug configs. Release is working but when I tried Debug I've got DOSBox exiting at about the same time. The behavior was different, though. It dropped to console to notify about interrupt CD occuring (and letting me know that "this is BAD"). Interrupt CD is byte sequence "CD CD" which is coincidentally the sequence used by Debug memory manager to fill uninitialized memory. It looks very likely that there is unitialized memory access somewhere, possibly in some old code, which laid dormant until now. While the behavior if slightly different in ykhwong's build it still may be caused by the same issue. (Secret hope -- it's the same thing that causes Win95 installer to exit unexpectedly... very unlikely but who knows? We all know that one day Win9x will run in DOSBox 😏 )
BTW, I think that unimplemented ARPL (opcode 63) should be stubbed in all cores. It is not necessarily required until we get NT kernel running and right now it just produces too much debug output wiht C_DEBUG.

There are many cases of uninitialised variables in DOSBox. The interrupt CD by the emulated machine's memory, including its interrupt vector table, being filled with 0xCD upon allocation. Simply clear the memory.

1//src/hardware/memory.cpp
2//add the following (line 492) to constructor of MEMORY
3memset (MemBase, 0, memsize*1024*1024);

Yes, I tried that (was actually going to edit my previous post when I saw yours), and it does "fix" int CD issue in Debug. However, it still bothers me a lot. It is not exactly uninitialized variable in DOSBox -- that's Win3 code calls to uninitialized memory. While I don't have any illusions about Win3 correctness, this is just too much. If this is true then even on the real hardware Win3 is trying to execute some random code bytes on startup. Thing like this would cause it to fail way more often than it actually did. On the other hand, the same Win3 startup code does apparently speculative read of all possible CRTC registers, existing and non-existing, so who knows?
I will be out for a couple days so, please, don't expect me to actively participate in the discussion. Will be back on Monday.

This is most likely caused by IRQs occurring on interrupt vectors that haven't been set by a program. I've seen this happen by a program that tried to detect the SB's IRQ by hooking the appropriate vectors one at a time and starting short DMA transfers. On real systems, the unhooked interrupt vectors point to an IRET instruction, so this is no problem. In DOSBox, they point to 0000:0000 or CDCD:CDCD (with value CD CD there).

Win3 is probably doing something similar. Pointing all uninitialised interrupt vectors to an IRET instead of into no mans land should fix this.

> Win3 is trying to execute some random code bytes on startup

No, if a dos table entry for example is zero (release build) it
is considered to be nonpresent, if it's 0xcdcdcdcd it's rubbish
(debug build). Similar to what kippesoep said.

> BTW, I think that unimplemented ARPL (opcode 63)

ARPL is implemented correctly, and it is one critical point that
is needed to get enhanced mode windows of any kind to run. It
serves as switch from user-callbacks to the windows kernel code.

wd

Kippesoep wrote:

This is most likely caused by IRQs occurring on interrupt vectors that haven't been set by a program. I've seen this happen by a program that tried to detect the SB's IRQ by hooking the appropriate vectors one at a time and starting short DMA transfers. On real systems, the unhooked interrupt vectors point to an IRET instruction, so this is no problem. In DOSBox, they point to 0000:0000 or CDCD:CDCD (with value CD CD there).

I encountered this INT 0XCD exception while using Microsoft Quick C 2.5 IDE. I agree to your ideal to initialize unused vectors for compatibility.

we initilize the lower part of the interrupt table to irets
the upper part we don't
Some games have issues when an entry in the interrupt table isn't 0:0. (while others don't check wether it's 0 before calling) The current solution is one we (authors) believe to be the most compatible.

vasyl wrote:

I was actually quite surprised to see it running with dynamic. But... when I tried the same with the Daum Cafe build only the normal core worked. With dynamic core DOSBox exited after showing Win3.11 splash screen.

fexs.diff made a problem that dosbox exits as soon as win3.11 splash screen shows.

If we're going to discuss this it should probably be in Moe's "What's next" thread. I believe he suggested implementing the Qemu processor core which is probably the best bet...heck implement that and then we could boot any OS that Qemu supports.

@ykhwong: nice one! I haven't noticed any problems from that patch. You might wanna post this to the sourceforge page for further reference...

Okay, I did it. Thanks, gulikoza.

All right, I am back. I have some minor comments. wd is right, ARPL is implemented but its implementation never gets executed under Win3 in current build -- I am getting it called only from VM triggering "invalid instruction" exception (correct behavior in this case). However, considering all hacks in Win3, I would not be surprised if it was actually supposed to work this way. If this is the case (wd, please confirm if you know), I would suggest modifying "invalid opcode" trace to handle this as a special case, like show warning only once. It looks like there will be quite a few people trying Win3 with DOSBox soon, some of them may want to use C_DEBUG-enabled builds.
Qbix, I am not sure I've got the exact point of your port. You mean that the current implementation actually expects the memory to be zero-filled and that memset workaround is actually proper fix, right? It looks like a sensible and right thing to do in any case.

vasyl, I don't understand your question. Maybe we aren't talking about the same thing ?

My fingers seem to have played joke on me by typing "port" instead of "post" -- that made my question somewhat strange. In any case, the more proper question would be: do you know of any reasons not to add that memset in memory.cpp?

> ARPL is implemented but its implementation never gets
> executed under Win3 in current build

It is executed correctly: windows switches to v86 mode
to perform e.g msdos stuff, and the ONLY possibility
to return to the windows kernel is any kind of hardware
exception. Windows uses ARPL to trigger a GPF.

If you don't like the invalid opcode message you can
turn it off, but it should be on by default as in most
cases it indicates that something's gone wrong.

wd

Thanks, that makes sense. I don't want to disable that trace, I'd like to see it less spammy. Yes, the trace itself can be disabled but in that particular case there is some rather heavy supporting code that can only be removed by recompiling. Anyway, it's not a high-priority item.
I have one correction/addition to the thread in "Guides" forum, the one about Win3.1x -- cannot post there so just doing it here. The thread should mention that WFW 3.11 had "universal" SVGA driver included and that one seems to be working with my patch. I am still trying to figure how to get WinBench 96 running (seems to have quite a few dependencies: VFW, fonts, etc.) to check if there is any benefit of running "Turbo" driver. It was faster on the real hardware but DOSBox may have different timing behavior.

The generic SVGA driver used VESA mode 6a (or whatever 800x600-16 was), doesn't it? So the drawback is simply: 16 colors.

There is an inofficial patch at http://www.japheth.de/dwnload1.html (bottom of the page) to make the svga driver display 256 colours. Might be worth checking out.

Vasyl: I made the change to the guide, but should now mention that the normal one only displays 16 clours 😀

WFW 3.11 was more advanced in that respect. The supplied SVGA driver supported 256-color modes up to 1024x768. Just check the screenshot. I am sure that Win 3.1 did not have that.

I'm pretty sure Win 3.1 didn't have much in the way of out-of-the-box SVGA support. You had to get your hands on drivers from the manufacturers and/or vendors and install them manually.