MSDOS Error Table Handling

[Ove Kaaven]

On Fri, 4 Jan 2002 ccrayne at crayne.org wrote:

> 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.

Seems to be in documentation/ChangeLog.OLD

Fri Aug 28 21:04:13 1998  Joseph Pranevich <knight at baltimore.wwaves.com>

        * [msdos/dosmem.c] [msdos/int2f.c]
        Added beginnings of DOS error table.

Nothing is done on those error tables since, and Joseph hasn't been active
for quite a while.

> 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.

I noticed.

> 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.

I'm not concerned about runtime technicalities in this case (this is not a
performance-critical operation by any means), what's important is code
clarity and maintainability. Adding all kinds of Wine-specific function
handlers and associated asm code all over the place doesn't help clarity,
maintainability, or modularity. (I feel it's already wrong for Wine's XMS
code to not use the RMCB facility... my excuse is that they didn't exist
when I wrote that XMS code... and probably not when Joseph started on the
DOS error tables either)

How are people going to know that dl=0x7f is wine-specific (you haven't
even marked it as such in the code), and what if it turns out that MS used
dl=0x7f for something after all, and someone decides to implement it? Then
they need to also find that asm code and figure out how to change it, or
break stuff. Using RMCBs, you don't need to hook into such handlers, the
thunking is all done for you, so code clarity and maintainability
increases.