DOS ain't dead

I wrote:

> I have some ideas how to improve HX GUI (for HX 2.13, 2.20 or 3.0, not 2.12 ).

> But to avoid writing too much potential nonsense, I have to ask a few things first:

- Do you plan some major changes in the GUI ?

- How is the GUI screen buffering done ? Parallel buffer ? Double/Triple/Quad buffering ? Where do the screenshots come from ( Screen / "ordinary" RAM - when saving works ) ?

- How does HX write to the text screen: INT $21/9 ? Only ?

- How are the "fullscreen" features (like in OGLTEST) implemented: well or dummy/hack ? Are they absolutely required to work or can the "kernel"/"driver" always refuse them ? For me they usually don't work: Tested on some "ME"-based systems, attempt to switch to fullscreen usually ends up in a violent program termination and broken screen with a offense box: " ATI#!?@@}@#$!.DLL caused a Criminal Page Fault at 3Y2F:5FGH4533 "

Japheth answered:

> > - Do you plan some major changes in the GUI ?

> No.

> > - How is the GUI screen buffering done ? Parallel buffer ?
> > Double/Triple/Quad buffering ?

> there is no buffering at all for the GDI functions.

> > Where do the screenshots come from ( Screen / "ordinary" RAM - when saving works ) ?

> it's done with the ordinary Win32 GDI API

> > - How does HX write to the text screen: INT $21/9 ? Only ?

> int 21h, ah=9 is never used. The text screen is either accessed directly (for low-level console functions) or via DOS ah=02h/ah=40h.

> > - How are the "fullscreen" features (like in OGLTEST) implemented: well or
> > dummy/hack ? Are they absolutely required to work or can the
> > "kernel"/"driver" always refuse them ?

> all graphics access goes throu vesa32.dll, both for directx/opengl and gdi. dkrnl32 is not involved.

> > Tested on some "ME"-based systems, attempt to switch to fullscreen usually
> > ends up in a violent program termination and broken screen with a offense
> > box: " ATI#!?@@}@#$!.DLL caused a Criminal Page Fault at 3Y2F:5FGH4533 "

> What is a "ME"-based system? A DosBox opened in Windows ME? Or HX running on Windows ME pure DOS v8.0?

I wrote:

> Laaca wrote:

> > It is unbeliveable how much slower the VRAM than normal RAM is.

> ( + much more )

> Thanks. For writing also ? It should be write-fast and read-slow

> Hanzac wrote:

> > Maybe it needs 2D accelerated driver, so it will be much faster in VRAM.

OK ... this has been discussed several times recently, there is no really usable acceleration for DOS available ( or will FreeDOS-32 1.0 come with such ? ), so, unless someone with *big* motivation and *much* free time comes to port all or at least most of Loonix "drivers" to DOS, VESA based work of Japheth, Laaca, FFK, Rayer, ... might be more productive than dreaming of "acceleration". Finally, it is sufficiently fast for me, I don't see the most horrible problem of DOS here

Japheth wrote:

> > - Do you plan some major changes in the GUI ?

> No.

But my suggestions ( hope for major effect with minor efforts ) will be taken serious ?

> there is no buffering at all for the GDI functions.

Writing all directly to VRAM ?

> > Where do the screenshots come from ( Screen / "ordinary" RAM - when saving works ) ?

> it's done with the ordinary Win32 GDI API

This doesn't really answer my question, but from previous answer, it comes \"obviously\" from VRAM ?

> int 21h, ah=9 is never used. The text screen is either accessed directly (for low-level console functions)

Writing at $B8000+x ?

> or via DOS ah=02h/ah=40h.

2 for screen and $40 for redirection to file ?

> all graphics access goes throu vesa32.dll, both for directx/opengl and gdi. dkrnl32 is not involved.

SORRY my question was confusing - 2nd part refered to "original" Win32 behaviour, not HX ... the question is whether fullscreen requests can be rejected in Win32 (well, then in HX also) ?

> What is a "ME"-based system? A DosBox opened in Windows ME? Or HX running on Windows ME pure DOS v8

Win32 apps (like OGLTEST) running in Windows ME ... no HX directly involved in my test ... obviously the great ATI driver prefers to run into a PF from rejecting fullscreen

Laaca wrote:

> Except FreeBE/AF could be very interresting source
> accelerants from BEOS. Look here:
> http://svn.berlios.de/viewcvs/haiku/haiku/trunk/src/add-ons/accelerants/

I wrote:

Thanks. But my ideas don't deal with speed.