Hello Rob,

 RL> Text output could be in a window, so you can't just 
 RL> write directly to the screen and assume you're in full 
 RL> screen text mode.  besides, what if your app is 
 RL> currently in the background, not being shown at all?  
Wouldn't matter, in the graphics mode necessary to use a window, video ram
at b800:0000 is not scanned/used anyways...
 RL> What if the number of rows/columns changes?
In graphics mode I can't believe that would be a problem, (I'll explain my
hunch below), and in text mode, how are they going to change it from within
your program, unless you've put that option in(in which case, your program
is aware of the row/column change)(yes there are several possible
row/column combinations in text mode).
What I mean about my (above mentioned) hunch is this... If through Vio you
can set where in memory your virtual buffer is located then you should be
able to make it point to the beginning of text memory b800:0000 (ega n'
up)_. If this is the case (it has to be for dos boxes to work) then this
sort of setup should be no problem.
I have not yet tried this... I am cleaning up a text-user-interface I wrote
in dos, and now I've got someone interested in it. There must also be a
native os/2 .lib for the sale. This is why I'm so interested in this
approach.

The way I see it is; if you have your vio handle point to b8000000, do your
"direct" screen writes, all I have to is use a VioShowBuff()...
        Wow, a lengthly reply to a simple message . I believe I
was forming a plan of attack for I'll be starting on the Os/2 version
shortly...

                Paul Rider.

--- Maximus/2 2.02