On Fri, 4 Jan 2002 ccrayne@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@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.