[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Using Symbolics C with DOS/Unix targets
Date: Sun, 17 Nov 1991 04:59 EST
From: email@example.com (Barry Margolin)
Date: Thu, 14 Nov 1991 14:38-0600
From: gooch@TIJERAS.SW-SW.Dialnet.Symbolics.COM (William D. Gooch)
Has anyone thought about using (or better yet, used) Symbolics C to hack
existing programs for portability? I'm thinking of an arrangement along
the lines of CLOE, where the Symbolics machine is the network master for
development and debugging, and combat-ready code is spat toward target
machines using IP/TCP. Final testing, possibly tuning, etc. happens on
the target system. You could even think of producing system .make files
and so forth automatically when appropriate, also per CLOE. (Come to
think of it, it's quite possible that the CLOE Developer could be
adapted for this purpose fairly easily.)
The most significant problem with using Symbolics C to develop programs
intended for Unix or DOS is the limited C library available in Genera.
Many Unix and DOS programs make use of Unix system calls (most of the file
system interface functions are emulated on DOS, but not Genera),
screen-handling libraries (e.g. curses), networking interfaces (e.g.
sockets), databases (e.g. dbm), etc. Symbolics C provides nothing but the
ANSI C library.
It's also not clear how much advantage it has over such things
as Saber C (recently renamed due to company name conflict to
something boring that I can't remember), or even Lightspeed C
These are very graphicly-oriented incremental, dynamic C environments
with such things as unbound-variable detection, etc. that give
you most, if not all, of the advantages of Symbolics C.
Also, developing portable C code is harder than you think. It's
not just a matter of having a strict ANSI compiler. You have to
contend with non-ANSI compilers, compilers with bugs, compilers
with a whole slew of ANSI-sanctioned variations (like the length
of 'int'). Adding one more compiler to this mix is likely to
cause you more problems than it solves.
The problem gets exponentially worse when you have to deal with
the variations in libraries that Barry mentions. We have it
good in the Lisp world, portability wise.