Aduke.1710 net.eunice utcsrgv!utzoo!decvax!duke!bcw Mon Feb 1 00:45:41 1982 Kashtan's Eunice article 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@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 ------- ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.