I just saw something interesting in Windows 3.1: when running various programs in it(sound MCI setup(the prebuffer setting) in the control panel, file manager), when starting said sections up, I see the CPU #GP(E0) faulting because it's trying to RETF to kernel mode(to segment E0h from CPL 3). I saw the same kind of behaviour when starting up the Windows 95 RTM setup!
Perhaps it's something that's connected there? A common component that's failing(if it's a failure) in both Windows 3.x OSes? Doesn't 95's MINI.CAB use 3.x at it's setup?
Edit: After opening up a lot of those programs(file manager, clock and the control panel) and MS-DOS (alt-tabbing out in the middle of a dir command), I encountered the stack fault again after opening the control panel a few more times(double clicking on it). At 11BF:262B. It's opcode C0h. The modr/m byte is 02h. The stack limit value is 32CFh. It's a expand up segment. SP is 25B4h. The offset that's faulting is 405B.
The full opcode is C0 02 8A. So that's ROL [BP+SI],8A. BP=3FC0, so it's already out of range. SI=9B. So combined they're way out of range of the stack segment? The offset is calculated correctly, but incorrectly used?
So there's at least still a problem with the 80286- instruction set or the 16-bit protected-mode programming?
Edit: After reinstalling Windows, running a lots of applications seems to work fine, until I once again go into the sound settings for the MCI Sound driver(pressing the setup button and OK in the dialog that pops up for the 4 second default prebuffer setting). Then once closing it, the stack fault pops up once again, this time on offset 14C1B masked to 16-bit, so 4C1Bh. The exception happens at 11BF:144F. CS has a limit of 298F. Weirdly enough, both CS and SS have the same segment descriptor base and limit values, except one being a code segment(access rights FBh) and the other has a data segment(type F3h). In all other aspects, the two seem identical, weirdly enough?
The full opcode that's faulting is C0 AA C0 C8 01.
That's supposed to be SHR BP+SI-3740h? BP=7F80, SI=3FB.
Edit: This time, it reports SOL(Solitaire itself) as the cause of the Stack Fault?
Something's definitely wrong there...
Edit: Interestingly, the two MS-DOS prompts I started up before the crash are still in memory and paused. I also see (using mem.exe /D /P) that some program called dswap.exe, WIN data and program blocks are still in memory? So Windows 3.1 didn't expect to be closed like that(mostly the GUI it seems)?