🚀 go-pugleaf

In article <1992Aug17.190209.8650@njitgw.njit.edu> dic5340@hertz.njit.edu (David Charlap) writes:
>In article <1992Aug17.093809.24122@Informatik.TU-Muenchen.DE> rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) writes:
>>Yes it looks like this. Remember, if OS/2 is ported to a RISC, it would
>>not have a concept like the PC screen buffer, so the VIO/MOU/KBD calls
>>are useless.
>>
>>Part of the work can be done with 32-bit IOCtl calls, for the rest you
>>have to call 16-bit API's on PC's.
>
>This is the way it's done under Unix and other systems, as well.
>That's why some enterprising programmers wrote the curses package.  I
>wonder when this'll be ported to OS/2.
>

Not entirely true, and RISC vs. CISC has nothing to do with it.  E.g.
on Sun hardware, you can open the device file i.e. "/dev/cgsix0", and memory
map the frame buffer memory into the process address space and twiddle bits
to your hearts desire.  That's how the MIT Sample X Server works on Suns
anyway, irregardless of whether they're RISC or CISC.

Never the less, the point should be emphasized, under any GUI, you don't
want to be twiddling bits in frame buffer memory.  If you've got an app
that wants to do it's own "drawing", convert it to the GUI.  If you've got
a text based app that bypassed the BIOS and/or OS for some reason and
writes directly to screen memory, my condolences.  Convert it.  

-- 

Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.


-- 

Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.