Hi,
On Sun, Sep 21, 2003 at 03:51:32PM +0200, Michael Stefaniuc wrote:
Hello,
The DOS32A extender checks if a dos32 extender is already installed. As we probably don't want to implement one silence this check.
License: LGPL, X11 Changelog: Michael Stefaniuc mstefani@redhat.com
- silence the FIXME's produced by a check for a dos32 extender
- silence the FIXME produced by an install check of MVSOUND.SYS
Sorry, that's incorrect.
Wine DOES have to implement a DOS extender. How would a DOS extender which does that check actually "extend" DOS under Wine? Answer: it wouldn't, since it can't, since it isn't able to establish protected mode, since it's already enabled.
Thus it's Wine which has to do it, since it has proper access to 32bit linear address and selector mapping functionsI (and the DOS extender querying that would gracefully step back from providing DPMI). And thus we also need to announce it. If Wine didn't do it, then nobody else could establish DOS extender functionality, and we'd lose some functionality here.
(that's also the reason why Windows has a DPMI extender since Windows 3.0, BTW...)
Hi,
On Sun, Sep 21, 2003 at 04:07:20PM +0200, Andreas Mohr wrote:
On Sun, Sep 21, 2003 at 03:51:32PM +0200, Michael Stefaniuc wrote:
The DOS32A extender checks if a dos32 extender is already installed. As we probably don't want to implement one silence this check.
License: LGPL, X11 Changelog: Michael Stefaniuc mstefani@redhat.com
- silence the FIXME's produced by a check for a dos32 extender
- silence the FIXME produced by an install check of MVSOUND.SYS
Sorry, that's incorrect.
My DOS knowledge is restricted and i still have to read a lot about it but i have to disagree with you.
Wine DOES have to implement a DOS extender.
No. int21 functions 0xff are the functions provided by dos4gw and other compatible extenders. My patch silences the FIXME's for that. DOS didn't came with dos4gw nor with an other extender compatible to dos4gw. dos4gw was delivered with the apps that needed it so we need to make wine to be able to run the dos4gw or a clone of it.
How would a DOS extender which does that check actually "extend" DOS under Wine?
Like the dos32a extender does it: using the DPMI host of wine and hooking itself into int21. And dos32a works with wine (well, not all dos32a test programs that come with the source code work, but most of them do) and can replace dos4gw (tested myself with the "Imperium Romanum" installer).
Answer: it wouldn't, since it can't, since it isn't able to establish protected mode, since it's already enabled.
It uses the DPMI mechanism already implemented in wine.
Thus it's Wine which has to do it, since it has proper access to 32bit linear address and selector mapping functionsI (and the DOS extender querying that would gracefully step back from providing DPMI).
Programs implementing DPMI functionality need to be able to work with an existing DPMI host and that is provided by wine.
And thus we also need to announce it.
The DPMI functionality is announced by wine.
If Wine didn't do it, then nobody else could establish DOS extender functionality, and we'd lose some functionality here.
(that's also the reason why Windows has a DPMI extender since Windows 3.0, BTW...)
Wine implements a DPMI host.
bye michael
søn, 21.09.2003 kl. 16.07 skrev Andreas Mohr:
Wine DOES have to implement a DOS extender.
I think you're wrong. Wine doesn't have to implement a DOS extender, it's much simpler and more useful to have Wine be able to run them rather then implement them all. After all, DOS extenders don't have standardized interfaces.
How would a DOS extender which does that check actually "extend" DOS under Wine?
By hooking interrupts. There's a lot of infrastructure in Wine for that.
Answer: it wouldn't, since it can't, since it isn't able to establish protected mode, since it's already enabled.
No. Protected mode is *not* really "enabled" when the DOS app runs in the vm86-simulated "real mode". It needs to call on DPMI to establish protected mode, and all known DOS extenders are able to do so (they couldn't run in a Windows 3.x DOS box otherwise), and that's what it will do. No problem.
Thus it's Wine which has to do it, since it has proper access to 32bit linear address and selector mapping functionsI (and the DOS extender querying that would gracefully step back from providing DPMI).
Why can't the DOS extender do it? The DOS extender *also* has proper access to 32bit linear address and selector mapping functions, since Wine provides DPMI to it. There's no reason the DOS extender can't do it instead of Wine.
And thus we also need to announce it. If Wine didn't do it, then nobody else could establish DOS extender functionality, and we'd lose some functionality here.
*Any* DPMI client can establish DOS extender functionality. It's what they do, and not something Wine has to do.
(that's also the reason why Windows has a DPMI extender since Windows 3.0, BTW...)
The reason Windows provides a DPMI host has more to do with *allowing* DOS extenders to work, not to reimplement and replace them. Pure DPMI (particularly not the v0.9 Windows implements) did not have a lot of things going for it as an API - it's a really poor and cumbersome one, incompatible with most DOS libcs at the time, and DPMI was of course not available when not running under Windows. DOS extenders gave application coders a much better deal - a much more friendly API, advanced interrupt hooks that did thunking and segment conversion automatically (with pure DPMI you had to do this manually, and most DOS libcs would obviously not do that), and backends for whatever protected-mode hosts existed (DPMI, VCPI, or the raw iron). Since they generally do work fine on top of DPMI, I see no reason Wine has to reimplement them. They're readily available on the Internet for whoever needs them, they don't have to be provided by Wine.
-
Andreas Mohr -
Michael Stefaniuc -
Ove Kaaven