MSDOS Error Table Handling

ccrayne at crayne.org ccrayne at crayne.org
Fri Jan 4 17:39:07 CST 2002


In <Pine.LNX.4.21.0201040934240.4461-100000 at mizar.ping.uio.no>, on
01/04/02 
   at 09:46 AM, Ove Kaaven <ovehk at ping.uio.no> said:

:> -           INT (WINE-only interrupt)

:If that's what you need, I suggest allocating a DPMI Real-Mode Callback
:thunk using DPMI_AllocInternalRMCB(). (There's an example of how to use
:it in dosaspi.c... you give it a Wine-implemented function, and it
:returns a real-mode address that DOS apps can use to call it... the only
:thing to keep in mind is that it's the Wine function's responsibility to
:pop the real-mode stack)

Thank you for pointing out the DPMI function to me. However, before
discussing the advantages and disadvantages of your suggestion, I feel
obligated to point out that all I have done is to fix the existing broken
code, and therefore can not speak to what design alternatives the original
author may have considered. In fact, my search of the change logs has
failed to find any mention of DOSMEM_InitErrorTable whatsoever. If the
original author of this code still follows the wine-devl list, perhaps he
or she will enlighten us.

Speaking for myself, the phrase "WINE-only interrupt" is misleading. The
reality is that DOS uses int2f ax:0x122e for setting and getting the
address of various error tables. The specific routine is selected by the
value in dl, of which only the values 0-9 are defined. My fix adds dl:0x7f
as the wine routine which moves the requested error message to the real
mode buffer.

To me, it seems that the only advantage to using the DPMI callback
mechanism in this specific case, is that it would save nine bytes of real
mode memory, at a cost of degraded performance and increased code
complexity. However, if you feel strongly about it, I will defer to your
judgement.


-- Chuck Crayne
-----------------------------------------------------------
ccrayne at crayne.org
-----------------------------------------------------------





More information about the wine-devel mailing list