On Thu, 3 Jan 2002 ccrayne@crayne.org wrote:
/* We will use a snippet of real mode code that calls */ +/* We use a snippet of real mode code that calls */ /* a WINE-only interrupt to handle moving the requested */ - /* message into the buffer... */
/* message into the buffer...
...
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)
In Pine.LNX.4.21.0201040934240.4461-100000@mizar.ping.uio.no, on 01/04/02 at 09:46 AM, Ove Kaaven ovehk@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@crayne.org -----------------------------------------------------------
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.
In Pine.LNX.4.21.0201051112170.4461-100000@mizar.ping.uio.no, on 01/05/02 at 11:38 AM, Ove Kaaven ovehk@ping.uio.no said:
: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)
That being the case, what do you think about removing the DOSMEM_InitErrorTable function entirely, and letting int2f funcion 0x122e subfunction 8 allocate the RMCB, and the associated real mode message buffer, the first time it is called?
In addition to consolidating all of the error table handling in one place, it would mean that no real mode space would be reserved unless a program actually called the function.
-- Chuck Crayne ----------------------------------------------------------- ccrayne@crayne.org -----------------------------------------------------------
On Sat, 5 Jan 2002 ccrayne@crayne.org wrote:
That being the case, what do you think about removing the DOSMEM_InitErrorTable function entirely, and letting int2f funcion 0x122e subfunction 8 allocate the RMCB, and the associated real mode message buffer, the first time it is called?
Well, while good in theory, it won't currently always work too well with the current implementation, because DPMI_AllocRMCB allocates memory directly from the DOS memory pool, not from memory reserved for DPMI, which means that most executables, e.g. command.com, which by default allocate *all* available DOS memory, will cause such a DOS memory allocation to fail. So stuff like that must probably either be initialized before the executable is loaded, or DPMI must reserve some DOS memory for itself which it can allocate RMCBs from. (The latter may be a good idea anyway, it may even be in the DPMI spec)
In Pine.LNX.4.21.0201052317120.4461-100000@mizar.ping.uio.no, on 01/05/02 at 11:29 PM, Ove Kaaven ovehk@ping.uio.no said:
:So stuff like that must probably either be initialized :before the executable is loaded, or DPMI must reserve some DOS memory for :itself which it can allocate RMCBs from. (The latter may be a good idea :anyway, it may even be in the DPMI spec)
My documention says "DPMI must provide 16 callback addresses per client". However, since this has not yet been implemented in wine, and since I need to move on to finding out what change between the 20010822 and 20011226 versions of wine broke the last error handling logic for DOS, I will resubmit my patch with the minimal changes necessary to use an RMCB.
-- Chuck Crayne ----------------------------------------------------------- ccrayne@crayne.org -----------------------------------------------------------
-
ccrayne＠crayne.org -
Ove Kaaven