This is S-on-the-NeXT in view mode; [Up]
Date: Sun 02-Nov-1989 19:43:55 From: Unknown Subject: S on the NeXT Ivo Welch tells me he is getting inquiries regarding his statement that S had been ported to the NeXT. I am the anonymous person who did the port. I'm a beta-test site coordinator for S so I have access to the source code and I also keep in close contact with the developers of S. I haven't received confirmation from Rick Becker, one of the developers of S at AT&T Bell Labs, on whether he will include the configuration in future releases of S. However, he and I exchanged a lot of mail while I was working on the port and that is the way we would usually work. The situation is - S has successfully been ported to the NeXT. It has passed the consistency tests for S. - I haven't written a Display PostScript device driver for S yet but I plan to. If anyone else wants to do it first, I would be happy to give advice (I wrote both the original PostScript device driver and the NeWS device driver). - The machine-specific files for the NeXT should be included in the next release of S but I don't know when that is to be expected. - I can make the machine-specific files and diffs available to anyone who wants them. If there is sufficient demand I will contribute them to the Purdue archive or put them up for anonymous ftp. Please note that S is proprietary software. Contact AT&T Software Sales, P.O. Box 25000, Greensboro, North Carolina 27420 (800)828-UNIX. Don't write to me and ask me to send you the sources for S. The reasons I was holding off announcing the port are: - I can't guarantee that AT&T will include the port to NeXT in a future release of S. I make the code available to them but it is their decision on whether to put it in. - I am working from a beta version of the source so my diff's may not correspond to the source as distributed by AT&T Software Sales. I would prefer not to get into the position of creating different versions of the diffs for different versions of the source. However, I think it is important that people reading this news group see that software really is being ported to the NeXT. What was involved in the port? The Absoft Fortran compiler worked fine for the parts of S that are written in Fortran. In the C code I had to work around many instances where #define F77_SUB(x) x/**/_ was assumed to transform F77_SUB(dsvdc) into dsvdc_ (in ANSI C, it produces dsvdc _). There were also problems with definitions like #define QUOTE(x) "x" which produces "x" from QUOTE(ttt) instead of "ttt". Solutions to both of these are well documented #define F77_SUB(x) x##_ #define QUOTE(x) #x but it requires a bit of time to track them all down. There are also definitions of library functions to reconcile and a few cases where constant strings were being re-written. Again, solutions to these problems are well documented. In the end these "problems" improve the code. The NeXT C compiler with its basis in gcc does a lot of type checking (I think it uncovered a bug today) that is left to "lint" on other systems. The biggest problem is that you end up with a lot of sections that read #ifdef __STDC__ new version #else old version #endif because you have to maintain compatibility with old compilers and old libraries. >From: mdeale@riglow.acs.calpoly.edu (Myron Deale)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.