UCBVAX:@sri-unix (09/11/82)
To: floyd!ucbvax!unix-wizards
Via: Ucb-C70; 9 Sep 82 15:01-PDT
Remailed-date: 11 Sep 1982 1500-PDT
Remailed-from: the tty of Geoffrey S. Goodfellow <Geoff5 at SRI-CSL>
Remailed-to: Unix-Wizards@SRI-CSL: ;
Via: Sri-Csl; 11 Sep 82 15:33-PDT
Date: Thu Sep 9 08:23:39 1982
Comments on EUNICE:
I have been a heavy EUNICE user since the earliest version of the
software appeared. My needs have been for a full UNIX implementation
running under VMS, not just the ability to run individual C programs.
Thus for example a properly working shell (sh,csh,) was essential.
EUNICE provided the working environment for a group of about 8 associates
at Courant Institute engaged in typical program development activities,
mostly for large numerical analysis and graphics codes. A similar
environment was being used by co-workers at Los Alamos and at Chevron
Oil Field Research.
The first version of EUNICE that I received was a disaster. There
was a reasonable C compiler plus fairly good I/O routines in libc, but
the rest of libc was a useless. There was no working shell. With
considerable effort I wrote my own libc, particularly those related to
process activation (fork,exec,signal,..). I was then able to compile
the shell and get a reasonable system running. This system was our
development system at the three sites mentioned until EUNICE Version 2
arrived after which I abandoned my system and switched to EUNICE.
(I believe Kashtan made a tactictal error in describing version 1
EUNICE as anything except a pre-release version)
EUNICE version 2 provides an excellent UNIX emulation for almost
any normal programming activity. There are a few esoteric features of
UNIX that are not emulated, but in my experience UNIX programs rarely
use these things - e.g. sharing of file-pointers across fork/exec .
Unfortunately there are some TRIVIAL changes to the system that would
make it far better. Let me mention a few:
1. There are a set of utilities where I believe one should run the
corresponding VMS program rather than its UNIX equivalent. Thus
it is reasonable (and the EUNICE default) to use the VMS LINKER
instead of UNIX ld. Similarly one would want to use
the VMS FORTRAN, PRINT, MAIL, LIBRARY etc. To achieve this all
that is required is to replace the corresponding UNIX program
by a shell script of the same name that coerces arguments to the
appropriate VMS form and then calls the VMS program. (The
true UNIX programs could always be used if a certain logical
name was set or the like). You can easily write the above
shell scripts yourself, but EUNICE would benefit considerably
if it supplied them.
2. UNIX filenames under EUNICE are restriced to be VMS filenames
which in VMS Version 2 was very restrictive. A future version of
VMS will increase filename length considerably. In the meantime
it is essential to provide a filename mapping routine which is
automatically called by open(), create() etc. I used such
a routine and found it solved all sorts of annoying headaches -
think of reading in a tar ta a routine and found it solved all sorts of annoying headaches -
think of reading in a tar tape from a UNIX site! As an example
one can map non-alphanumerics into the number 9, and truncape from a UNIX site! As an example
one can map non-alphanumerics into the number 9, and truncate parts
of filenames to match the 9.3 form of VMS names. In the absence
of this, importedte parts
of filenames to match the 9.3 form of VMS names. In the absence
of this, imported C programs typically need to be edited just to
modify the include <...> lines which may use invalid VMS filenames
such as a.out.h. In practice, name collisions are very rare.
3. There is a vms command in the shell (and a corresponding library
routine) that executes a VMS command. This routine is very
useful and can be used to implement the shell scripts I mentioned
in item 1. The current version of this routine is NOT
aceptable as it frequently bombs due to command lines that are
too long. VMS restricts the length of a command-line, but allows
substantially longer commands if one uses the hyphen continuation
character. Thus long commands should be placed in a temporary
.com file which is then executed.
There are other small problems here and there in EUNICE. Most are easy
to get around. I currently have large codes, (>= 50,000 lines of code)
that compile and run under VMS without modifying a line of source or