> And the idea of having accelerated ProWesS > drivers etc. has been in my head for a long time, too. Well Marcel, this could be done if you allow switching between native code and back. Then recompile ProWesS with some glue code and... If we first handle the screen update thingies I suggest, we could do this very easy... (under some conditions).
> And the problem might be that this needs to be sorted out right now. > Because the basic problem will be: how can I know in what colour depth > an application runs? With the new WMAN old applications can be forced > to use the new colours just by patching the colour codes in the window > definition data structures (which is GOOD thing). So even the > applications themselves might not know that they're high colour now! > But I need to know how much save area to allocate beforehand. What > happens if an application is considered 2bit only and all of a sudden > it issues an iow.papt (true colour paper trap) call with some exotic > colour? In part, this can be solved using the approach I mentioned. The save area already includes a window mode. Applications should "choose" their default window mode when they start. If necessary a simple loader could set it for them. In practise, you can assume four colour mode and newer application could call the appropriate trap when they start. Or you could change the job header with a special code after the job name to indicate that the window mode follows. Or even go for a completely dynamic approach. Start in four colour mode and convert the save area when more colours are requested. Joachim
