Kashtan's Eunice article

[utzoo!decvax!duke!bcw]

Re: Kashtan's Eunice remarks

The following article is the complete text of the remarks that Kashtan
made about Eunice.  This was on the fa.info-vax mailing list rather
than the Eunice mailing list because it came out as part of a long
discussion about the merits of Unix versus VMS.  This explains some
of the topics mentioned in the article which may not seem germane
to Eunice.

				Bruce C. Wright @ Duke University

>From decvax!ucbvax!info-vax Sat Jan 16 14:08:20 1982
(ucbvax.5812)  fa.info-vax         : finally roped in (Long Message)
>From KASHTAN at SRI-AI Sat Jan 16 13:50:05 1982
I have resisted entering the fray on this list for a long time -- but the
time has come....

I would like to respond to some of the points brought up about EMACS running
under both VMS and UNIX, in particular the issue of interaction windows. It
is true that I did not implement mpxio under EUNICE -- not because it is hard
to emulate under VMS but because it is used so infrequently by UNIX programs
that it did not pay to spend time on implementing the emulation for mpxio.
It was also my feeling the mpxio in Berkeley UNIX was going to be functionally
replaced by a new Interprocess Communication Facility in the not too distant
future.  When that facility is announced I will invest the effort to emulate
it.  Since EMACS is the ONLY place I have ever seen mpxio used (and there are
some bugs in the state of the world that cause things to not work quite as
well as one would like) I made the decision to invest my effort instead in
doing a VMS version of the EMACS facility spoken of.  Although not complete
at this moment it already has considerably more functionality than the original
UNIX implementation.  The main problem arises in the fact that I have been
using MailBoxes for the communication channels.  This is fine when
communicating with UNIX programs under VMS but has some non-terminal properties
to VMS programs.  This will be fixed when I finish up the Pseudo-Teletype
Driver.  There are also currently some features in the VMS version of EMACS
that have not found their way into the UNIX version of EMACS:
	Lambda Binding in Mlisp functions (this just awaits some integration
						efforts on the part of Jim
						Gosling).
	A top-level scheduler to make make EMACS asynchronous.  This allows
	some trivial things like "schedule-mlisp-procedure" to be implemented
	and makes a multi-window, user-programmable shell feasable in EMACS.


As for INTERLISP, Dave Dyer paid me a visit some time ago and in 3 days we had
it running on VMS (It would have been sooner had there not been a very weird
bug in VMS and had the new version of EUNICE been closer to completion).  When
he left I was under the impression that the only thing that still required work
was the INTERLISP code that dealt with file version numbers.  Since UNIX did
not have version numbers, a rather clever scheme was deviced to use some 8-bit
binary data in file names to record INTERLISP version numbers.  Since VMS does
have version numbers this code is not reasonable for VMS.  I had hoped that
someone else would have invested the time in fixing this problem -- I have not
had any time at all to look at it.

Finally, I would like to mention the current state of EUNICE since the latest
version (not yet released) is VERY DIFFERENT from the one currently in the
field.  The old version was originally written in assembler (since there was
no "C" compiler available when I started and the initial portings of the UNIX
"C" compiler did not work well enough to use as the development language) and
was originally designed merely to allow UNIX programs to run on VMS with only
minor modifications to the source files but with some VMS wizardry required
to figure out what those modifications should be.  This obviously caused some
problems for people who knew little of VMS (and were not inclined to learn
about the innards of yet another O/S).  The largest headache was the fact that
the linker you had to use was the VMS linker and the debugger you had to use
was the VMS debugger.  The new version of EUNICE is now entirely in "C" except
for 2 assembler "assist" files.  It is also internally VERY DIFFERENT from the
old assembler version of EUNICE.  I have spent much effort in squeezing out
the differences in system call semantics between the UNIX and EUNICE worlds.
In fact, as of last night, the emulation of the Berkeley Job Control system
was working.  The new EUNICE will be able to use the UNIX "ld" linker and
produce UNIX-style a.out files which will enable the UNIX symbolic debugger
to work.  This should iron out almost all the difficulties that people are
having.  The one remaining problem is that of filenames.  This will be
completely resolved once the VMS release with long filenames occurs (something
entirely dependent on DEC).  Once that occurs, VMS will support all possible
UNIX filenames including upper/lower case distinctions and non-alphanumeric
characters in file names.  It is my intention that when all is complete a
user can log in to a VMS system running EUNICE and, aside from some control
character mappings which cannot be changed, be unaware that it is not a
UNIX system.

David
-------