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

Stefan Dösinger stefandoesinger at gmail.com
Wed Sep 29 13:25:19 CDT 2021


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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210929/2fee35e1/attachment-0001.sig>


More information about the wine-devel mailing list