[Prev][Next][Index][Thread]

Re: executor & windows95



>>>>> "Georg" == Georg Bauer <Georg_Bauer@ms3.maus.westfalen.de> writes:

    Georg> Hi!
    >> Video should be faster (if you've got UniVBE) because we can
    >> directly access the linear frame buffer under DOS.  Still, I
    >> wouldn't think that the CPU number should slow down.

    Georg> Actually the Win95 does give you the same sort of penalty
    Georg> that EMM386 gives you, but worse. Every memory access runs
    Georg> through their paging code, so that is slowed down. Ok, most
    Georg> code is in the internal cache, but it's slow nonetheless. I
    Georg> found that I could even gain some more speed in the CPU
    Georg> benchmarks by just removing EMM386 and let the extender of
    Georg> Executor handle all the memory.

What's happening is that CWSDPMI implements the DPMI 1.0 extension
that lets us map physical memory into our address space.  Nearly all
other DPMI providers (Windows, Warp, EMM386) only implement DPMI 0.9,
and so they don't support this feature.  This requires us to use the
equivalent of a "far" pointer to access video memory.

Since Macs have no notion of "far" pointers, we can only let Mac apps
*directly* access the real video memory under CWSDPMI.  On nearly all
other setups they access a RAM frame buffer from which we periodically
transfer rectangles to the real screen.

There is actually a way around this in Win3.1, Win95, and Warp if
UniVBE is giving you a linear frame buffer but we haven't implemented
it as an option.  There are two big drawbacks:

1) You'd be stuck at 8 bpp graphics, unable to switch depths.

2) You'd lose memory protection, so a misbehaving Mac program could
   screw up your system, potentially corrupting other memory and even
   causing a reboot.

Reason (2) is the main reason we haven't added this option.  It might
be worth adding anyway.  Certain arcade games (those that bypass
QuickDraw) would be *much* faster under Win95 and Warp.

-Mat


References: