GST C
GST C is the best 'real' application
software I have yet seen for the ST. By real I mean actually useful
to somebody other than selling the computer (i.e. demos). Best because
it actually makes good use of the GEM facilities, unlike all the
other ST compilers I have used.
A normal session starts by loading
the GST C 'shell' program. Using the drop-down menus the editor
can be called to create or edit your program files, then compile,
assemble, link them together and actually run the program. A complete
edit to run cycle can be done entirely with the mouse and, what
is more, without returning to the desktop. In comparison the Digital
Research compiler sold to software developers is awful, using batch
files and a lot of superfluous typing. Each part of GST C can be
used independently if you wish so I shall review each part in order
of use.
GST EDIT
A lot of editing goes into any
program, and the GST EDIT is wonderful to use. Most other editors
available (Metacomco, MicroEmacs, Mince) use the 'TOS' mode of the
ST, i.e. using the ST as a 80 by 25 terminal and not as a GEM computer.
Such editors are easier to write than GEM editors, and that is why
they were out first. GST show what can be done with GEM windowing,
allowing up to four files to be edited at once. With each in its
own window, life becomes so much easier. Development of a routine
is simplicity itself as it is now possible to load the file that
calls it, the file that the routine is in, a header file for external
definition editing and a GEM interface header for reference (or
whatever combination you require).
An editor is not much good unless
you can edit, and GST EDIT provides all the usual facilities in
an easy to use way. Single key edits like insert/delete word/line,
page up or down etc. are available from Function keys, and repeated
on a desktop icon 'function strip'. This allows you to select the
functions by clicking with the mouse. Cursor movement is just a
matter of pointing to the character and clicking, the cursor moves
straight there. The cursor keys are available as well of course.
Text is entered wherever you place the cursor, and can be in insert
or overwrite mode. Lines can be 160 characters long, and scroll
bars are used to see text currently off screen.
GST EDIT comes into its own when
you start working with blocks of text. Unlike the Metacomco editor
blocks, which only start and end at whole lines, EDIT allows you
to place the cursor on any character to mark the start and end of
the block, and when they are marked, the text is shown 'shaded'
.Having marked your block you can cut, paste or delete it. Cutting
takes a copy but does not delete the original and paste inserts
the cut block (usually used after moving the cursor). A facility
I miss is block move which saves cut, delete then paste time and
which surely can't be too difficult?
What really makes GST EDIT powerful
is that you can cut a block from one file, click on the window of
another file to edit it (to 'top' it), and then paste it there.
For similar texts this is a godsend. The last major function of
the editor is Search and Replace. This is very nicely done in EDIT,
allowing you to choose one, some or all occurrences of the chosen
text to be changed. When an occurrence is found in 'some' mode,
a little dialogue box is opened for you to say Yes, No or Cancel
to the change. Straight searches are there too. Once a search or
replace is specified it can be repeated without entering it again,
however this is one of the annoying points as the menu item to select
it is not at the top. If it had been it would have been so much
faster.
Another time waster is the way
the editor opens the windows on the screen. Each successive window
is created smaller and inside the previous one. The effect of this
is that when you want to edit the larger (bottom) window, all the
other small windows disappear underneath. To edit them, you must
first re-size or move the larger (now top) window. This is a good
lesson for other writers, in that it shows how not to do it. What
it should do is open the first in the top left corner, the second
a bit down and across, the third down and across and so on. All
should be the same size, and this method guarantees that at least
some part (the bottom left corner) is always visible, and therefore
selectable. That the windows also cover the function key strip thus
rendering it invisible (and thus useless) is another problem altogether.
This is actually due to a quirk in the developers tools (RCS) but
could be solved by putting them on the left vertically.
To sum up, GST EDIT has all you
need in an editor, is excellent value on its own, and makes the
whole package very useable.
GST C
When you are looking at a C compiler
there are two important parts to look at, the implementation and
the library. GST do not consider (or advertise) their compiler,
called CC.PRG, to be a 'full' implementation of the C language.
It lacks floating point arithmetic, multi dimensional arrays (although
they can be simulated), macro definitions with parameters (#define
A(x)), structures and #include "file" nesting. It may seem a big
list but there is a lot to the 'C' language, and there is plenty
left to play with. Apart from the omissions, CC.PRG compiles to
the Kernighan and Ritchie standard. There are many books on the
C language, but the book by Kernighan & Ritchie (who wrote the original
C) is the 'bible' to which compilers are written (hence you often
see the expression 'a full K & R C').
The C language has no facilities
whatsoever for input or output. This may seem stupid, but an integral
part of any C compiler is the STDIO library by which the I/O is
done. A library contains a large number of object code subroutines
which can be 'pulled out' and used in the final program if they
are needed (referenced or called). A C program is portable because
there is always a standard set of subroutines to call like putchar(),
getchar() and printf() (C is written in lowercase). The authors
of the different compilers implement these in the best way possible,
but they provide a machine independent interface for the programmer.
With GEM more libraries are needed, one for the Virtual Device Interface
(VDI) and one for the Application Environment Services (AES). Digital
Research specified a standard set of calls, and the libraries allow
the user to use them in his program. The AES is the part of GEM
that looks after all the menus, windows and dialog boxes, and the
VDI is the part that does all the writing and graphics in the windows.
GST ASSEMBLER AND LINKER
While there is a 68000 assembler
as part of the package, it is only used in this context to help
compile C code. The information you get is little more than how
to run it, so while it may be the same assembler as they sell separately
(I don't know), you will have to pay again for details. A pity.
The linker again is a vital part, but only sparse details are provided
as you don't need them. GST are trying to get their linker established
as a standard with Metacomco being the first company I know to produce
software that can use it. I don't know the merits of GSTs linker,
but I hope that a standard is found soon as it would make life so
much easier. IBM distribute a linker with every machine, thus ensuring
a standard, but not stopping others writing different versions.
CONCLUSION
As with all programs there are
a few things that could be improved, the editor window overlap for
example, but none are a major problem. It has its limitations, in
that a few of the more advanced C features are missing, but GST
realise this and are working on some of them. Structures, a facility
used a great deal in GEM is one such facility, but can be simulated
at the moment. The editor is superb, and is the basis of a word
processor to be launched soon. I am very impressed with GST C overall,
and would recommend it to anyone.
HIPPO C
Haba Hippo C is an interesting
beast. Essentially it seems to be a perfectly good C compiler, the
libraries are all there, it is a full K & R C (except floating point)
and it includes an editor. Strangely, it is the extras that make
me hesitate in recommending it.
Though your programs can use the
GM libraries, Hippo C is used in a UNIX look-alike manner. This
is achieved with a program called HOS (Hippo Operating System) from
which other command programs ( e.g. ED the editor) or batch files
(a list of commands in a text file) can be run. Note that TOS files
will not run, only programs written using Hippo C although Hippo
C programs can run as normal programs. All the commands are UNIX
based, such as LS for directory and CAT for displaying file contents,
and HOS behaves in a UNIX type way with standard I/O redirection
(though not piping) and if a command file is not found, it is looked
for in the BIN subdirectory.
Whilst the standard GEM interfaces
are not too bad to write for (compared with doing it all yourself
anyway), it is in the GEM area where GST play their joker and make
it easy to cheat. By using (yet) another library, you can do all
of your I/O to a fully implemented window without doing any more
programming than you might for a simple teletype screen. It's still
teletype output, but you can have more than one such window, and
then start into graphics in the same way. Unique to GST and a masterstroke
no less. Well, perhaps a bit less as you have to use nonstandard
calls which means a re-write if you buy a new compiler. It would
have been nicer if you just had to select a different library.
No matter how good a compiler is,
you won't be able to make much use of it unless the manual is good
too. The GST C manual covers everything I would expect it to. It
doesn't attempt to teach you C or GEM, but gives all the details
you need for reference. Use of the shell and editor, the compiler
specifications, all the libraries, details of the memory and stack
use, and a brief description of the assembler are all included.
A green A5 ring binder with matching box (normally associated with
higher priced products) rounds off a well thought out and useful
manual.
To me, as someone who has never
really used UNIX properly, it seemed a good imitation so I showed
it to an experienced UNIX user and he tried a few 'simple' commands.
It seemed that the similarity is very much skin deep, and many of
the options to commands are missing, so don't expect too much.
The editor is a reasonable TOS
screen mode editor. It makes much use of the function keys but is
nothing exceptional. A GEM window based editor would have been a
far better choice. It is common practice in UNIX systems to have
a standard editor, so that you can swap systems without re-learning
the editor. Considering the standard editor is line based, the Hippo
editor may be considered to be better, but not for someone who is
buying it for its UNIX simulation.
The C compiler is normally invoked
with a batch file, and is a two pass plus compile version. It seems
complete, but a few of the GEM portability files are lacking, though
the user can soon make these himself. A C compiler may define integers
as 8,16 or 32 bits long, whatever the authors decide, and the portability
definitions allow source code to be written for all compilers by
using BYTE WORD LONG instead of char, int, and long int et al to
get around this problem. The definitions are held in a file on each
system (PORTAB.H) ready for inclusion. The assembler and linker
are very basic, designed simply for compiling. If you want to write
68000 assembler you could use it, but a more powerful one (see issue
19) would be better.
The Hippo C manual is very smart
and comes in a nice ST grey box. Unfortunately, however, just about
everything is skimped, from loading the program through to the library
listings (which are simply the names of the supported routines).
All you probably need for reference is there, but it could have
been so much better and it spoils the appeal of, what appears from
the list of error code interpretations, a very capable compiler.
One thing that really put me off
was the copy protection. I am not against copy protection if it
is felt necessary, but it should not work against the legitimate
user. HOS was obviously written and tested with the first 'pack-out'
version of TOS. This version would boot from either drive A: or
B: but always load DESKTOP.INF (the file with system defaults) from
drive A:. The instruction was to put the Hippo disk in A:, your
TOS disk in B:, and boot. When the old TOS is used, everything is
fine and HOS loads with no problem. With the latest TOS, and the
fixing of the 'feature' so it loads DESKTOP.INF from the boot disk
(A: or B:), your own desktop is always used, not Habas. Try to load
HOS now and you are told by GEM that the disk is faulty and then
that you must have the original Hippo disk in drive A:, even though
that is just what you have! A pain in the neck and not how it should
be. As an alternative you can copy Hippo's DESKTOP.INF to your boot
disk but I don't recommend this. Each new version of TOS may save
different parameters in the desktop file, and if you copy a file
from another version, it may not operate correctly (as I have discovered).
While a solution to this was found (with help from an addendum slip
in the box) it was a big waste of time for me, and wasn't impressive.
The master disk can be removed once HOS is loaded to save wear and
tear, and all the files can be copied for backup and regular use.
CONCLUSION: What is generally a
good programming environment is spoilt by a poor manual and poor
copy protection. These though may be improved in time, especially
the latter as 3.5" disks develop. Comparing it with GST C and DRI
C as simply a C environment, I would rank it last. GST C is far
easier in use, and DRI C (the developers kit) has extensive GEM
documentation. However if you are interested in UNIX, then Hippo
C is certainly worth considering, especially as everything fits
on one disk. It is certainly quite useable.
(Editor's note: Since the review
was written, a revised version has been announced which, hopefully,
will take care of the 'copy protection' problem.)
top
