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.