[GEM Development] Thank you all

[Shane Gough]

Hi all,

I'd just like to thank everyone who responded to my impromptu
questions. Your answers have given me a better understanding of how
and why people are using GEM.

I would like to clarify the meaning of question 1.2 'Do you *need* to
use GEM?'. In the industry I work in there is a very strong attitude
of 'if it ain't broke, don't fix it'. The company I work for at the
moment is using Watcom C to compile for MS-DOS targets. A company I
used to work for was actually using Commodore 64 machines to drive
public displays (the software was written in BASIC and got updated
data via the serial port - each machine drove up to 4 displays - all
showing the same thing - by using a splitter on the PAL output). It
would not have surprised me to find that a custom GEM application was
being used to display information in a control center somewhere - this
turns out not to be the case (for members of this list at least).

What did surprise me was the interest in a 32 bit (flat memory model)
version of GEM. My only exposure to GEM has been on i86 (segmented
memory architecture, 16 bit) based systems - I guess those using it on
the Atari ST systems are used to a 32 bit flat memory model
environment and want to use the same thing on emulators/etc under
Linux or Windows.

I guess it's only fair to let you know why I am interested in GEM -
I'm going to cheat and not follow my own set of questions :)

First up, I don't *need* to run GEM. Not a single company I have ever
worked for has ever used it to the best of my knowledge. So I'm not on
this list to scarf information to maintain some weird system I've been
put in charge of.

I am very interested in older GUI systems though - I think the first
GUI I ever saw in the wild was GEOS
(http://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)) on a
Commodore 128. GEM is probably the only widely distributed system
(outside of X11) that the source code is freely available for and it's
amazingly small. As a reference source on how these sort of things
work it's invaluable (has anyone had a look at the X11 source code?).

What I am working on is learning the internals of the system -
drivers, desktop accessories, applications, etc. I have a number of
goals I'm working towards ...

1/ Developing my own GEM API library for C (and another for Pascal)
using freely available 16 bit tools (The Borland tools for DOS - not
GPL but at least free). Given that all access to GEM is via a software
interrupt this shouldn't be too hard - although there are a lot of
functions and escapes to code for. This is my reason for asking about
function names (I *really* dislike the current set of function names -
wk_init() belongs in the 70's, these days we definitely should have a
WorkstationInit() function instead - all depends on the number of
significant characters in an identifier for the minimal target
compiler I guess).
2/ Developing an OO framework on top of that library to allow easy
development of applications. Think of it as GFC (GEM Foundation
Classes) as opposed to MFC (MIcrosoft Foundation Classes). At the
moment I'm just calling it ogem.
3/ Making sure both of the above work on PC GEM and ATARI GEM (I
haven't been able to track down a physical ST box yet - so most of my
testing in that regard will be done on emulators).
4/ Making a GEM compatible API for Linux using the framebuffer device
(/dev/fb) or VNC. Ideally any app written for (or converted to) the
API's in 1 & 2 should be compilable under Linux and use the GEM
desktop instead of X.

How long is this stuff going to take? Who knows - I have a hack at it
when I can. Once I get something going that is at least workable I'll
push it up to sourceforge and you are all welcome to play with it. Why
should there be a GEM on Unix systems? Because X11 is huge (even the
TinyX implementations), and there is no need for network transparency
if you use VNC or another virtual desktop protocol. This would satisfy
a lot of peoples desire for a flat model 32 bit version of GEM though
:)

Anyway - once again I thank you for your responses. Please respond to
my blurb above if you have any ideas about it (for or against).

Regards,
Shane