[PATCH 1/3] krnl386: Call DOSVM_IntProcRelay() via the application stack.

[Zebediah Figura (she/her)]

On 9/29/21 13:25, Stefan Dösinger wrote:
> 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 at 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...
> 

Well, my wording was wrong, or my understanding was :-)

I've gone back and stared at the old code some more, and I think I have 
a better idea of how it's supposed to work now.

I believe that ed6bdb3c51 isn't the relevant commit at all, but rather 
5ec5449596 is. Trying to untangle how the IRQ code worked is difficult, 
but it doesn't particularly matter, because after 5ec5449596, we aren't 
triggering any DPMI IRQs anymore, so we can't get nested interrupts (not 
even with an STI with pending events). We can only get interrupts 
triggered by an INT instruction.

Wrt the vm86() call, I believe that DOSVM_CallRMProc()/DOSVM_CallRMInt() 
basically does a WOWCallback16Ex() with the VM86 flag set. Before 
5e0fd3403e, that would trigger a call to __wine_enter_vm86 in ntdll, 
which would perform the vm86() call.