Am Mittwoch, 29. September 2021, 20:39:25 EAT schrieb Zebediah Figura (she/ her):
On 9/28/21 21:59, Chip Davis wrote:
September 28, 2021 8:39 PM, "Zebediah Figura" zfigura@codeweavers.com
wrote:
The dedicated stack was introduced by 9d7ff6c85b0827b7f54989050b4c34f1f459e94d, in order to support potentially nested DPMI interrupts. DPMI support was removed by ed6bdb3c51cd4b8c94f9839806321703e7aa9765; hence there is no longer a reason to account for nested interrupts.
Isn't protected-mode Win16 a DPMI environment itself? In fact, it's why MS created DPMI in the first place.
On Windows, yes, but as far as I understand it is not on Wine. I believe that our protected mode tasks never ran in virtual-8086 mode, and the DPMI support we had for them was removed by commits at about the same time as ed6bdb3c5.
My understanding of this area is definitely fuzzy, though, so I might have things wrong.
I think Zeb's wording is slightly wrong. My understanding is that "DPMI" is sort of the syscall interface of Win3x / Win9x. A process can ask the kernel for certain changes to its "virtual machine". Wine implements a pile of those syscalls in dlls/krnl386.exe16/int31.c. I'd expect Win9x's kernel32.dll to use those kinds of calls to implement stuff like VirtualAlloc() and MapViewOfFile().
What ed6bdb3c51 removed is the ability to call real mode code from a DPMI client. I was expecting to see some vm86() call somewhere, but can't find it, so I probably misunderstand. I also don't know how Windows (9x, and even more so NT) handled this. It could be done via vm86 or by switching the CPU back into actual real mode. DOS programs would need to do this kind of real mode call to call DOS services. Windows brings its own so called dos extender with it that wraps DOS APIs for you, and you aren't supposed to use DOS APIs anyway.
Now does that mean Zeb's patch is right or wrong? I have no clue...