On Thu, 22 Apr 1999, David Given wrote:
Ahem.
I know two things.
1. It can live on rather small resources in terms RAM and CPU.
> [...]
> >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.
~~~~~~~~~~~~ ~~~~~~~~~
2. It runs on MC68000, (atari) that is not segmented at all.
> 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.
Jakob
