DOS: silence some fixme's

[Ove Kaaven]

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.