Now when reinstalling 95 it seems to go a lot faster than before the POP r/m16/32 bugfix? Although the Pentium still crashes setup with the VU-(somenumberhere) error after the input of the name and organisation and clicking next.
The 80486 emulation and 80386 chips don't show any problems, though?

The pop r/m16/32 now first checks the stack access against segmentation&paging, then pops into an immediate buffer(affecting paging tables accordingly), then after that recalculates the modr/m from loaded parameters(making the esp+2or4 become the esp base address when used as the destination), then checks against the r/m16/32 write(segmentation and paging) and finally(if not faulted) write the data to register/memory of the destination.

Usually with POP it would check against both the stack and memory access before performing the pop and memory access, but that can't be done due to the [(E)SP(+*)] addressing method exception to the rule.

Looking at the detlog.txt, the detection was successfully done, but two things occurred:
- I forgot to check the media stuff, so no Sound Blaster 1.0 and MIDI support had been detected or probably installed.
- I don't see the CD-ROM drives reported as 'CD-ROM drives' or anything like that? I do see the CD-ROM drives reported as the Standard IDE/EIDE Hard Disk Controller?

1Detected: *PNP0600\0001 = [15] Standard IDE/ESDI Hard Disk Controller
2	IO=170-177,376-376
3	IRQ=15

Why isn't it detecting it as a CD-ROM drive?

Edit: Also, I get a WIndows Protection Error on the second esdi_506.pdr when there's no second HDD at the primary slave(CD-ROMs are always at the secondary master&slave(primary master&slave when without harddisks))?

Improving the IDE controller emulation now properly(based on Bochs' harddrv.cpp's handling of them) makes Windows 95A not crash anymore without a second harddisk installed(primary slave being unmounted).

It still doesn't see any CD-ROM drives, though. Harddisks seems to work without issues.

Strange that I keep getting a (general protection as far as I remember) fault for some REP instruction within rundll32.exe when clicking on the properties button within the System properties(This computer > Control panel > System, tab for the hardware devices)?

After running the Add hardware device wizard and adding the sound drivers(MPU-401, Joystick and Sound Blaster), the mouse somehow stopped working properly?

So reverting back to pre-add-new-hardware was the only option there(saw no errors otherwise during boot). Did notice that stuff previously working correctly like the System Properties page would crash every time it was opened from the Control Panel. That means that somehow those files or systems got corrupted with the new devices being added or installed?
Since the CD-ROM devices are still not working, I had copied the WIN95 folder from the CD-ROM to the harddisk using WinImage. Perhaps that's part of the problem?

I did mess with the hard disk emulation a little(for the second hard disk to work properly, adding the Bochs information and mechanics to the port reads and writes)... Perhaps a problem with it occurred somehow?

Hmmmm... Taking into account that opcode 8F POP r/m16/32 checks against memory in two ways, what is the ordering of checks?
Currently UniPCemu(with my latest commits):
1. Checks against (d)word read at SS:(E)SP with segmentation and debugger.
2. Checks against (d)word read at SS:(E)SP with paging(loading TLB if valid and not in TLB yet).
3. Increases (E)SP temporarily for the next check.
4. Checks against the modr/m (d)word address/register for a write with segmentation and debugger.
5. Checks against the modr/m (d)word address/register for a write with paging(loading the TLB if valid and not in TLB yet).
6. Increases (E)SP to reverse step 3 for execution.
7. Starts normal delay,pop from stack(increasing (E)SP),r/m write. During this step, page faults/segfaults shouldn't occur.

The segmentation and paging checks each 4 of them can throw their respective faults.

Normally, you would first check all against segmentation, then against paging. But in this case the logic changes after popping to an (E)SP-relative address? What ordering happens then?

This is the Rundll32 crash that's occurring:

Weird... The Rundll32.exe crash in the System Properties clicking the Properties button for more settings doesn't crash when running in safe mode(after normal mode couldn't start anymore due to the improved CD-ROM controller behaviour)?

Edit: Managed to remove the erroring device in Safe mode(since everything seems to work properly there).
Running the hardware detection again(Add new hardware wizard) seems to complain about not having enough memory. So I enabled Virtual Memory to it's default(let Windows manage it) again(disabled for mobile due to flash memory issues with virtual memory).

Edit: Hmmmm.... The weird mouse behaviour introduced by the "Add new hardware"-wizard might be that it tries to use a PS/2 mouse? I see, after the detection and before clicking the finish button there being an entry for "Standard PS/2 Port Mouse"... Even though the used architecture doesn't have a PS/2 port mouse?

One thing I do notice now on WIndows 95 is that all the hardware detection doesn't seem to detect the Sound Blaster IRQ? The detection correctly identifies the I/O ports, but no IRQ is listed?

So now autorun and CD-ROM support in Windows 95 is properly working(after fixing the ATAPI PACKET command to no longer raise an IRQ when progressing to the first stage(setting the error register for the IRQ information but not raising an IRQ when progressing to the ATAPI/SCSI command packet sending phase).

After said full reinstall of Windows 95 with the lastest CPU bugfixes, it now seems to run without crashing? I don't see errors at any of the locations that had crashes before? 😁

I did see that the automatic configuration of the Sound Blaster 1.0 card(it's the 1.0 DSP reporting 1.05 with Adlib and Game Blaster enabled as well) somehow trying to use IRQ 3? But the detlog.txt reported nothing about any IRQ(although the properties said it was conflicting with the UART).
The Sound Blaster is actually installed at IRQ 5 instead of IRQ 3, but somehow the setup didn't seem to properly detect that? Or is that a common issue with Windows 95A(4.00.0950)?

Edit: Hmmm... I hear a short sound during booting (just a fraction of the boot sound). Then, looking at the properties page of the Sound Blaster again, the rundll32.exe error occurred again.
So there's still a problem there?

Looking at it some more, I see the Sound Blaster IRQ raised, but never acnowledged by the PIC(by the PIC actually giving said interrupt to the CPU)? Hmmm...
Edit: Seems like the interrupt mask register is preventing it from delivering the interrupt, thus never notifying the Sound Blaster(using the shared IRQ handler) that it's acnowledged, thus the Sound Blaster never lowers the IRQ to make interrupts happen after it's initialization.

Edit: Modifying the IRQ lowering to happen when it's requested regardless of the interrupt being acnowledged, the sound in Windows 95 now properly seems to work! 😁
Still strange that the IRQ is disabled during the boot of Windows 95, only to be enabled after booting.

Just tried Rayman under Windows 95... Runs like a charm(although obviously slow, because it's only at 20% realtime speed):

I did need to change the emulated CPU from 80386 to 80486, though(requiring a reboot after the install on 80386 and trying to run, making it complain about the CPU not being a 486).

Also, looking at the last detlog.txt of when I ran the hardware detection(to make sure it had no more changes):

1Detected: *PNPB000\0000 = [17] Creative Labs Sound Blaster
2	IO=220-22f,388-389
3	IRQ=5
4	DMA=1

So it's now properly detecting the IRQ of the Sound Blaster, where it didn't do that before(just IO and DMA) 😁

I also managed to fix a little bug where the CD-ROM images weren't being ejected when requested by software(it was checking if the disk was unmounted to unmount it, instead of mounted when to unmount it)... Whoops.

But now things are at least working well enough to run at least some software 😁

Edit: OK, the rundll32.exe issue still shows up, but only at some places during a normal boot(nothing in Safe mode).
Edit: Nope: It now also shows up in Safe mode... Perhaps some kind of corruption?

Looking at what happens within the Windows executables after first reboot until reaching the desktop, I see one and only one non-data file having it's modified date being updated to the current date(installation's first part before the reboot was roughly 1-2 days ago): "windows\system\vmm32.vxd"!

Could it be a problem with those modifications that's causing issues?

Just checked Windows 95C. It's at least running properly in safe mode.

Hmmmm.... Whoops! Just took a look at the LAR/LSL instructions. Then I saw that they're checking against conforming segments incorrectly! It was checking the entire access rights byte against the type values that are only supposed to be in the lower 4-bits! So, since when reaching said point the higher bits are always set, it always detects them as non-conforming, even when they're conforming!

Hmmm... What privilege check(CPL/RPL) is done with the DPL of a conforming code segment that's higher than CPL and/or RPL? Do LSL/LAR fail on those? What about MOV to DS/ES/FS/GS?

Looking at various specs, loading conforming code segments into non-CS registers won't check privilege(DPL is ignored)? That counts for mov segreg, lds(etc.) and verr/w? So only during loading through CS it's checked(effective PL(max(cpl,rpl) or just rpl during retf(d)/iret(d) when <DPL(more/too privileged) causing a general protection fault)?

Edit: Fixing the conforming code segments to don't check CPL/RPL when loaded in data segment registers fixes Windows 95's rundll32's issue(so far checked at the system properties only)?

The device settings can now indeed be reached and changed without the rundll32 crash! 😁

Hmmm... Changing the display settings tab to the tab for display resolution, color depth etc. I see the display messing up.

Looking at the current state of the ET4000 registers, I see that the Attribute Controller register 16h bits 4&5 are both set, so the hardware is generating a 640x480x64K display instead of the 640x480x16 mode? The settings haven't been changed at said time? The DAC is still in 8-bit color mode?

Edit: Hmmm... Looking at the ET4000 documentation again, it says that for those hi-color modes using Attribute Controller register 16h, it also needs the MCLK/2 bit set to be effective?
Edit: Requiring said MCLK/2 to be set when bit 4 of attribute register 16h is set for the hi-color modes to activate seems to fix Windows 95 to behave properly during the changing of display settings. 😁

OK... Windows 95 is detecting the ET4000 as only supporting 640x480x16 and 800x600x16. But when I use the Windows 3.1 ET4000 drivers with it(Using the Have a supplier disk option), I can properly get it to use 640x480x64K 😁

Although I had to move the drivers from my floppy disk(from vogonsdrivers.com) to a ISO image to use with a CD-ROM driver, as Windows 95 doesn't seem to be able to read the floppy disks yet(drive not ready errors).

Hmmm.... One app went a bit crazy. When running Hover! from the Windows 95 CD-ROM, toggling it into fullscreen makes it incorrectly go into fullscreen mode(with just the window contents being in full screen, clipping at the edge of the window. So the contents become larger, while it's clipped off at the border of the window and the title bar disappearing(everything around it stays the usual Windows background(desktop and other running applications).

Then, once I tried to close the app, it 'closed', but when I looked at the task manager a bit later(Using Ctrl-Alt-Del), it was still there, somehow managing to make the desktop hang until I terminated the Hover! application using the task manager.

After that, I tried to install and run Pink Panther in Hocus Pocus Pink under Windows 95. It ran like a charm! (Although a bit slow, but what can you expect when it's running at 20-25% realtime speed?)

Didn't check what the other previously-crashing WFW 3.11 apps do atm(they might run fine now, seeing as at least one of them now runs without issue on Windows 95 RTM).