DOS ain't dead

As I announced cca 1 month ago, I have some ideas how to improve HX GUI. My questions got answered partially only then, so I hope there is not too much nonsense in this post. As I also revealed, this doesn't have to do with speed, the speed has low priority for me now, and the only remarkably slow application is MPLAYER.

1. Add support for VGA 640x480x4bpp mode, besides linear VESA. Intentionally suggesting this VGA mode, banked VESA sucks YES, this is related to the "CPUID" thread on FASM forum I am aware this mode uses silly "planes", also 16 colours is not the best, OTOH even original Windaube uses it - it is the only available mode unless you successfully install a driver, and tends to re-appear when the great driver gets wrecked Support of this mode would improve compatibility with older hardware (very important for DOS ), and allow to bypass an unusably buggy VESA, or verify origin of problems suspected to come from the VESA

2. This is the bigger one, OTOH should not require coding any additional sophisticated / expensive functionality , consists mostly of "change behavior" adjustments

Issues to get fixed:

- MPLAYER instability
- MPLAYER messing text into GUI screen
- Colour translation problems
- Console vs GUI issues, bad experience with "being smart" in HX 2.11 that got reverted very soon
- Difficulty to use BOCHS (use console based menus, start emulation -> failure )
- Screenshooting "console" stuff (needs 2 instances of DOS and HX now)
- Difficult-to-debug problems with apps changing screen resolution while running
- Buggy mouse cursor (?) blinking and leaving traces

The idea: implement 2 additional buffers, could be used as "parallel buffers" (brew screen in the parallel buffer, copy complete screen into the LFB, especially useful with the VGA mode) as well as backup buffers (write all directly into the LFB as-is).

Detail changes:

- Define 2 strictly separated HX modes, console and GUI. Console is default, GUI can be set up by:
- - Env. variable
- - DPMILD32 -g
- - Very first loaded executable is "subsystem GUI"
but not later / otherwise. In console mode, only console apps work, in GUI mode, console, GUI and mixed are supported. If GUI access occurs in console mode, abort with informative error then:
- - "XYZ.EXE attempted to start FIREFOX.EXE GUI executable while HX is in console mode"
- - "BOCHS.EXE declared as console in the header tried to use GUI API call CreateWindowEx while HX is in console mode"

- Prohibit changing screen resolution while program is running, let request pass if requested resolution matches the existing one, abort otherwise:
- - "OGLTEST.EXE requested 640x480x16bpp screen resolution, while it is 800x600x32bpp now, don't use "fullscreen" or adjust HXGUIHLP.INI next time"
"xmax" and "ymax" would be obsolete in HXGUIHLP.INI then

- As-is in console mode, write to standard screen using DOS or BIOS INT's

- Completely new in GUI mode:

- Set up 2 buffers of same size as the LFB is, one for the console "Window" and one for the GUI "Window"

- Translate console writes into pixels (routines already present in HX GUI), somewhat similar to the "unfullscreen" NT-consoles or "DOS"-BOXes, and output to the console "Window", allow to redirect the writes additionally to a file like "HXSTDERR.LOG", and allow to specify whether to redirect STDOUT, STDERR or both (new).

- New item in screenshooting menu: Switch screen - switch console <-> GUI "Window" (use the 2 buffers then, exchange them (if used as "backup") or copy "new" buffer->LFB if used as "parallel")

- Allow to screenshoot both of them (not at same time ) ... also my older requests about more informations "Saving screenshot into H:\DOS\HX001.BMP" , "Saved" , "Not saved, disk full" might become more accessible having these 2 buffers available

And NO, this is not the request or start of a request to implement a " 100%-AERO-compatible Window manager " in HX OTOH the impossibility to switch 2 buffers ("Windows") is IMHO a serious weakness of HX, several useful apps use such 2 "Windows" (BOCHS, QEMU, MPLAYER, GNASH) and something should be done here ... so I present this easy (?) solution.

PS: The HXRTD thread is good please keep it up-to-date ... any way to make it "sticky" ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Well, I don't agree with these points. Support for 640x480x4bit is not trivial at all, is obsolete, and ugly.
Furthermore Unirefresh nor VBEhz don't support it so looking at monitor (at least CRT monitor) is paintful for my eyes.

Separate buffer for text window is useless I think - you can allways redirect output to file. And I don't like to run programs typing "DPMILD32 -g program.exe" - I like just clicking the PROGRAM.EXE in Volkov commander.

Only think which is bothering me is the still not perfect mouse cursor.
And many people are looking forward to support for AC97 soundcards.

> 1. Add support for VGA 640x480x4bpp mode, besides linear VESA.
> Intentionally suggesting this VGA mode, banked VESA sucks YES, this
> is related to the "CPUID" thread on FASM forum I am aware this mode
> uses silly "planes", also 16 colours is not the best, OTOH even original
> Windaube uses it - it is the only available mode unless you
> successfully install a driver, and tends to re-appear when the great
> driver gets wrecked Support of this mode would improve
> compatibility with older hardware (very important for DOS ), and allow
> to bypass an unusably buggy VESA, or verify origin of problems suspected to
> come from the VESA

very good idea ... if *you* implement these things and can provide a patch ... and please ensure that your extensions don't bloat the binaries by more than 2 kB, else they might be rejected.

> The idea: implement 2 additional buffers, could be used as "parallel
> buffers" (brew screen in the parallel buffer, copy complete screen into
> the LFB, especially useful with the VGA mode) as well as backup buffers
> (write all directly into the LFB as-is).

[snip]

your suggestions sound a bit too hackish for my taste. An additional menu entry which allows to view the contents written to stdout/stderr so far is possible, though.

---
MS-DOS forever!

> - New item in screenshooting menu: Switch screen - switch console
> <-> GUI "Window" (use the 2 buffers then, exchange them (if used as
> "backup") or copy "new" buffer->LFB if used as "parallel")
>
> - Allow to screenshoot both of them (not at same time ) ...
> also my older requests about more informations "Saving screenshot into
> H:\DOS\HX001.BMP" , "Saved" , "Not saved, disk full" might become more
> accessible having these 2 buffers available

BTW,Japheth, did you read my post at FASM's forum about asmfan's CPUID Win32 program?

* had to install UNIVBE 6.7 (since ATI Mach64 was VESA 1.2 only)
* needed save=0 in HXGUI*.INI(or whatever) b/c didn't redraw
* Ctrl-Break didn't work for menu (but right-click Win95 keyboard button did)
* (I forgot to mention) Screenshots saved in %TEMP% ?? Is this intentional?

---
Know your limits.h

> Well, I don't agree with these points.

Sorry but you missed the point completely

> Support for 640x480x4bit is not trivial at all

The plains are a bit silly but it's perfectly doable ... if even I got it

> is obsolete

NO. It's the safest mode, besides VGA 320x200x8bpp

> and ugly.

NO. 800x600x16bpp is nicer (unsurprisingly), OTOH this doesn't make all below crap

> Furthermore Unirefresh nor VBEhz don't support it so looking at monitor
> (at least CRT monitor) is paintful for my eyes.

But do the things support text modes ? What about your (text mode IIRC ) VC ? Isn't it painful for your eyes as well ? Also, I haven't suggested to remove VESA support - so you are not obligated to use the VGA even if available one day

> Separate buffer for text window is useless I think -
> you can allways redirect output to file.

YES. But:

- It's pretty pointless to redirect "text GUI" output (VirtualPASCAL IDE, Kinesics) this way
- One might have interest to see the text in real time instead of much later

> And I don't like to run programs typing "DPMILD32
> -g program.exe" -
> I like just clicking the PROGRAM.EXE in Volkov commander.

Me too, but you missed the point: my suggestion would fix this problem, not invent it

> Only think which is bothering me is the still not perfect mouse cursor.

Possibly my fix would help

> And many people are looking forward to support for AC97 soundcards.

And SB PCI 512 / Live / Audigy ... unrelated to my graph ideas

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> install UNIVBE 6.7 (since ATI Mach64 was VESA 1.2 only)

That's why (+ my troubles in the past) I suggested adding VGA

> Ctrl-Break didn't work for menu (but right-click Win95 keyboard button did)

Had suggested additionally PrintKey but Japheth was not amused

> Screenshots saved in %TEMP% ?? Is this intentional?

YES. It leaves space for improvement: save text and screenshots at same place. BTW, screenshots will land in app dir if TEMP doesn't exist

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> very good idea ... if *you* implement these things

As you might know / suspect, I can't compile HX by now, and have some troubles to understand the coding syntax/style

I can provide a "patch" copying from a linear parallel buffer into the VGA planes - but doesn't connect to the OGL/DRDRAW/GDI stuff - if it helps

> don't bloat the binaries by more than 2 kB, else they might be rejected.

Sure. I won't code them in VB.NET

> your suggestions sound a bit too hackish for my taste.

Please think about it. It doesn't have to be in HX 2.13 ... but I still think it would be a big improvement ... maybe justifying version 3.0

> An additional menu entry which allows to view the contents written
> to stdout/stderr so far is possible, though.

COOL. Full "text GUI" support would be the preferred solution ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> BTW,Japheth, did you read my post at FASM's forum about
> asmfan's CPUID Win32 program?

Sorry, no [edit: after some hours of searching I found it in "projects and ideas". I must admit I'm usually not that curious to look voluntarily into this subforum].

> * had to install UNIVBE 6.7 (since ATI Mach64 was VESA 1.2 only)

Implementing something like VFlatD.VXD into VESA32.DLL would be good (VFlatD emulates a LFB for banked modes by modifying PTEs). But access to PTEs is not possible in all environments.

> * (I forgot to mention) Screenshots saved in %TEMP% ?? Is this
> intentional?

Yes, the current directory might be read-only.

---
MS-DOS forever!

> implement VFlatD.VXD into VESA32.DLL would be good (VFlatD
> emulates a LFB for banked modes by modifying PTEs

via Page Faults ? That's what I call a horrible hack

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> via Page Faults ? That's what I call a horrible hack

"horrible" hack, "serious" bug, "fundamendally" wrong, ...

why can't you use just the simple form?

---
MS-DOS forever!

> why can't you use just the simple form?

Maybe he's an extremist?

---
Forum admin

> Sorry, no [edit: after some hours of searching I found it in "projects and
> ideas". I must admit I'm usually not that curious to look voluntarily into
> this subforum].

For future reference, just click on a person's username, then click "Find all posts by", then scroll down (or search). It shouldn't take hours. :)

---
Know your limits.h

> As you might know / suspect, I can't compile HX by now, and have some
> troubles to understand the coding syntax/style

Noone claimed that the job will be easy :).

> I can provide a "patch" copying from a linear parallel buffer into the VGA
> planes - but doesn't connect to the OGL/DRDRAW/GDI stuff - if it helps

Not really. IIRC DDRAW has no support for 16 color modes at all, and for OGL this might be true as well. That's why IMO supporting the 640x400 VGA modeX instead of standard VGA mode 12h might be the better idea.

---
MS-DOS forever!

> IIRC DDRAW has no support for 16 color modes at all,
> and for OGL this might be true as well.

Unsurprisingly would have to truncate them down from 8 bpp ...

> That's why IMO supporting the 640x400 VGA modeX

Is it a linear 8 bpp mode ? The "ModeX" IIRC happens to work usually OTOH it's somewhat "undocumented" and not really required to work ... so it's not the safest mode

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Is it a linear 8 bpp mode ? The "ModeX" IIRC happens to work usually OTOH
> it's somewhat "undocumented" and not really required to work ... so it's
> not the safest mode

Yes, but even Win9x uses 640x400 modex for its "startup" logo. I've been told this mode works with 99.9% of VGAs.

---
MS-DOS forever!

> Yes, but even Win9x uses 640x400 modex for its "startup" logo. I've been
> told this mode works with 99.9% of VGAs.

COOL. Didn't know this But NT/XP uses VGA 640x480x4bpp for the logo and ME/9x uses it also if graph driver is not present/trashed instead of the ModeX

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***