OK. Some more testing using testsuites and double checking using the Bochs source code as proper documentation (the 80386 manuals don't seem to fully specify the RETF (E)SP behaviour for example, nor how the immediate value if used affects it during and after the protected mode logic).
It appears that the increasing of (E)SP happens in all cases, with it also happening on the source stack of the higher privilege level procedure (to get the (E)SP and SS popped).

It did reveal a bug in the call gate system implemented in UniPCemu. When it was performing a RETF from a 16-bit procedure (using common 8086 segmentation logic, so 16-bit RETF (fallback) instructions that's using a 16-bit operand size) it would use various counters to handle the stack in the common 8086+ and 80386+ logic. But those two methods have different bases on their handling of stack pops (due to cycle-accurate handling differing between the two handlers). So it would work properly with 32-bit operand size (as it was using a correct base of 6), but on the 16-bit operand size (using the common 808x CPU logic for the RETF instruction) it would get a wrong base (it's past 6), thus causing the return stack pointer and segment to never be popped and simply assumed already popped into the local CPU buffers for handling. Thus whatever was in those buffers (SP reading buffer, ESP reading buffer and common 16/32-bit SS reading buffer) would be used (SP buffer containing zeroed data, ESP would probably be correct, but I'm not certain that's always the case,.SS would be the correct value for 32-bit RETFD, but SS would get the last 32-bit RETFD when a 16-bit operand size used. And SP for 16-bit operand size RETF would be zeroed or garbage (depending on initialized memory, usually zero (since the CPU structure is initialized with zero-fill))).

Edit: Hiren's boot CD doesn't seem to use inter-privilege RETF or call gates, but it does seem to use same-privilege level RETF in protected mode.

It still crashes unchanged.

OK. With the latest improvements to the 32-bit TSS IOPB's limit range checks, I see something interesting happening during phase 2 of the Windows 9x setup:
"An exception 0E has occurred at 0028:c0007292 in Vxd ---. This was called from 0028:C10555BC in VxD ---. It may be possible to continue normally."

Fixed 32-bit operand size for far calls. Also implemented changed D/B-bit checks according to Bochs's (E)SP and (E)IP behaviour.
Also fixed 32-bit far calls to behave properly again, when not through call gates.

(E)IP itself doesn't seem to have issues anymore on 80386+, but Windows 95 OSR 2.5 "C" still crashes on it's first boot somehow?

Many (all but the GRP5 FEh undocumented memory 8-bit behaviour and implementations (currrently a NOP for those)) of the missing 808x undocumented opcodes are now implemented, according to multiple sources that document the latest findings on them from reverse-engineering effords by other people.
Edit: And implemented the 8-bit opcode FEh undocumented instructions as well, thus completing the 808x undocumented CPU instructions to be completed (although untested).

Hmmm... Running WFW 3.11 in 386 enhanced mode crashes PROGMAN.
But running Windows 3.11 in Standard mode doesn't crash it? Although it can't install because it's seemingly trying to run the installer in MS-DOS mode when it's run on Windows 3.1 in 386 enhanced mode?

Edit: Just found out that although CS is properly committed and reverted when faulting, EIP wasn't. It was resetting it to a previous state, but not entirely to the start of the instruction on faults (think like with interrupts as well as exceptions).

Edit: Improved return point of interrupts now.

EMM386 from Windows 3.1 says something interesting now: "Insufficient memory" !?
How would that even happen?

Windows 3.1 seems to hang on a HLT now (interrupts disabled)?

Edit: Managed to fix EMM386 to load again (an error in fault handling and page fault EIP resets).
Edit: And managed to fix Windows 3.1 to boot again, this time with EMM386 properly loaded! 😁

Just found a tiny issue with the LEAVE instruction that caused paging TLB loads on the stack reads not to continue the instruction with the proper ESP register state if the stack pop caused a TLB load to require locking the bus (which TLB loads always do, unless the bus is already locked and owned by the emulated CPU core itself).

Oh great. Now with the latest changes, Windows 95 OSR 2.5's first boot fails: Windows Protection Error while initializing device CONFIGMG.

Didn't get that error code before I think? Perhaps APM-related?

OK. APM probably works fine I think.

I noticed something odd when running an already installed Windows 95 OSR 2.5 from earlier builds.

It booted up fine. Then once clicking the start menu it kept BSOD-ing at C000E975 (not sure about that first part tho, so more like CxxxE975). So I put up a breakpoint in the page fault handler.

Then tried again and it ran without any issue, being able to shut down Windows without visible issues (APM worked to power off the app's 'power supply' too (quitting the app once shutdown was complete))?

The RTC mode was set to realtime though? Perhaps related (clock ticking at realtime speeds instead of emulated speeds)?

Just fixed a i82347 bug where the NMIMASK register was set to mask the wrong causes and could cause an NMI in various cases (due to swapping reset state of register C3h and C4h (register C4h set to 84h and C3h set to 00h). They're now properly set to 84h(for register C3h) and 3Eh(for register C4h).

That's now fixed to work properly (with proper reset values for those register (executed during PCIRST#)).

Managed to fix an issue in the new SDL3 port of the common emulator framework. So now sound works properly again on SDL3.
Also went and fixed some issues in sound device connection/disconnection on SDL2/3.

OK. With the latest interrupt bugfixes and other CPU improvements (things like improved B-bit handling and D-bit based protected mode handling from the source segment of interrupts, faults and far jump/call/ret and iret instructions) Windows 95 goes wrong during any boot it seems?

It's trying to load an invalid (0004h) segment descriptor that isn't in the LDT now?
The LDT is probably correctly loaded from what I can see (at the 8xxxxxxxh range), so something related is probably going wrong?

Managed to fix one other bug exposed by SDL3 (SDL2 somehow doesn't seem to show the bug). There was an issue with multithreaded pointer registration and release that caused the memory allocations for disk write file structure allocations to fail, causing the disk write to fail, for example when an audio thread tries to log things at the same time as the opening of the file, in turn both threads opening a file at the same time, messing up allocation and missing pointer registration for the file closing call to operate correctly.

Just fixed an 'issue' where 80286+ GRP4/5 INC/DEC opcodes would check against read accesses first, then check against r/w accesses, instead of only checking against r/w accesses.
This was introduced with the new handling of the GRP4 opcodes (and already invalidly present on GRP5 opcodes).
That would affect the TLBs that are loaded into the CPUs when using paged memory (or protected memory in protected mode as well).

Moved both SMI and hardware interrupts(INTA to be exact) from (A)PIC (both use INTA timings right now) to be handled as special <SMI> and <INTA> instructions, instead of being fused into the first instruction after it. That simplifies handling both of them to be like normal instructions and improve searchability in logs.

And did the same to <NMI> handling.

Trap flag also now gets ignored if it detects a SMI at the same time, giving <SMI> priority and ignoring the trap flag handling.