David Given writes:
>
> [...]
> >The Graphics Environment Manager was a simple,
> >but nice GUI for PC ( with 2 floppies
> >and 512 KB RAM at least ) and for the Atari ST.
> >Wouldnt it be a good idea to do a port to elks ?
> >To have the same GUI for DOS, ELKS and the Atari ST
> >would be a plus.
>
> I've played with GEM. Trust me, you don't want to have anything to do with the
> internals of this beast. It's written in a ghastly mixture of C and assembler,
> the API is foul and about as non-OO as you can get (and that comes as a
> horrible shock to today's generation of programmers), it contains no memory
> management code whatsoever (it's a TSR! Honestly! You load the TSR, then you
> load an ordinary executable on top of it that uses services provided by the
> TSR...) and it's full of arbitrary limits. It also relies on a segmented
> architecture a lot.
>
> We'd be a lot better off designing our own very-small-scale windowing system
> instead. Then we could backport it to DOS, possibly implementing it on top of
> GEM. But porting GEM to ELKS? No way.
>
I agree about GEM. The late ST version which were supposed to run on a
multitasking OS were not well suited to it.
One of the more promising possibilities is the nanogui project found at
http://www.linuxhacker.org/nanogui/
This is designed to be as small as possible, and it might well be possible
to modify it to run on a dummy localhost only socket layer. The code is
pretty small.
I am just about to try and upgrade to a 2.2 kernel so I can try this thing
out.
Al
