NeXTSTEP operating system source code has been leaked
The source code for the old NeXTSTEP operating system has just been leaked. This is a very old UNIX OS that was used to develop Doom in 1993. This would be very interesting for a fan of the OS to look through and learn from. This also includes a copy of Emacs for NeXTSTEP. But it is regrettable that this OS is no longer used. VMS could go toe to toe with Unix because it had a saner base, a lot of features integrated into the system from the ground up, and later additional features that most Unixes didn’t have for more than a decade after their adoption by VMS. Unix on the other hand always was hacky by nature, it was supposed to be a minimalist system that could run on small, 1960s minicomputer configurations, that was then promoted as a business-oriented system by assembling features that had to get around the systems’ limitations to work. To make things worse, the UNIX schism between the commercial, the research and the BSD UNIX and the endless forking of the 80s made having additional features in Unix a nightmare, since not all distributions would have them, and two distributions that had those features would not necessarily do it the same way. Sure, VMS had a hacker scene too, a pretty big one on top of that, but there was a single force behind it to update and make the system evolve. UNIX was AT&T, Berkeley and countless manufacturers battling to strap new stuff on their system, while claiming that it was a compatible system when there were in fact countless incompatibilities between them.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 | /* @(#)boot.c 1.0 10/16/86 (c) 1986 NeXT */ /* * History * * 09-Apr-90 Doug Mitchell at NeXT * Added floppy support. */ #include <sys/types.h> #include <mon/global.h> #include <mon/sio.h> #include <mon/nvram.h> #include <mon/monparam.h> #include <next/scb.h> #include <nextdev/dma.h> #include <nextdev/video.h> extern char od_icon[], od_icon2[], od_icon3[], od_arrow1[], od_arrow2[], od_arrow3[], od_flip[], od_bad[], sd_icon[], sd_icon2[], sd_icon3[], en_icon[], en_icon2[], en_icon3[]; struct animation animation[] = { #define OD_SPIN 0 /* 0 */ { TEXT_X, TEXT_Y3, "Loading\nfrom\ndisk ...", 1, 0 }, /* 1 */ { 640, 395+84, od_icon, 2, 68/12 }, /* 2 */ { 640, 423+41, od_icon2, 3, 68/12 }, /* 3 */ { 640, 423+41, od_icon3, 1, 68/12 }, #define OD_INSERT 4 /* 4 */ { TEXT_X, TEXT_Y3, "Please\ninsert\ndisk", 5, 0 }, /* 5 */ { 640, 395+84, od_icon, 6, 1 }, /* 6 */ { 672, 431+17, od_arrow1, 7, 68/2 }, /* 7 */ { 640, 395+84, od_icon, 8, 1 }, /* 8 */ { 672, 439+17, od_arrow2, 9, 68/2 }, /* 9 */ { 640, 395+84, od_icon, 10, 1 }, /* 10 */ { 672, 447+17, od_arrow3, 5, 68/2 }, #define OD_FLIP 11 /* 11 */ { TEXT_X, TEXT_Y3, "Please\nflip\ndisk", 12, 0 }, /* 12 */ { 640, 395+84, od_icon, 13, 68/2 }, /* 13 */ { 664, 437+20, od_flip, 12, 68/2 }, #define OD_BAD 14 /* 14 */ { TEXT_X, TEXT_Y2, "Bad\ndisk", 15, 0 }, /* 15 */ { 640, 395+84, od_icon, 16, 68/2 }, /* 16 */ { 640, 423+41, od_bad, 15, 68/2 }, #define SD_SPIN 17 /* 17 */ { TEXT_X, TEXT_Y3, "Loading\nfrom\ndisk ...", 18, 0 }, /* 18 */ { 640, 390+95, sd_icon, 19, 68/12 }, /* 19 */ { 640, 415+65, sd_icon2, 20, 68/12 }, /* 20 */ { 640, 415+65, sd_icon3, 18, 68/12 }, #define SD_BAD 21 /* 21 */ { TEXT_X, TEXT_Y2, "SCSI\nerror", 22, 0 }, /* 22 */ { 640, 390+95, sd_icon, 22, 68/1 }, #define EN_SPIN 23 /* 23 */ { TEXT_X, TEXT_Y3, "Loading\nfrom\nnetwork ...", 24, 0 }, /* 24 */ { 640, 395+84, en_icon, 25, 68/12 }, /* 25 */ { 640, 416+63, en_icon2, 26, 68/12 }, /* 26 */ { 640, 416+63, en_icon3, 24, 68/12 }, #define EN_BAD 27 /* 27 */ { TEXT_X, TEXT_Y2, "Bad\nnetwork", 28, 0 }, /* 28 */ { 640, 395+84, en_icon, 28, 68/1 }, #define FD_SPIN 29 /* FIXME : get real FD bitmaps */ /* 29 */ { TEXT_X, TEXT_Y3, "Loading\nfrom\nfloppy ...", 30, 68/1 }, /* 30 */ { 640, 395+84, od_icon, 31, 68/12 }, /* 31 */ { 640, 423+41, od_icon2, 32, 68/12 }, /* 32 */ { 640, 423+41, od_icon3, 30, 68/12 }, #define FD_BAD 33 /* 33 */ { TEXT_X, TEXT_Y2, "Bad\ndisk", 34, 0 }, /* 34 */ { 640, 395+84, od_icon, 35, 68/2 }, /* 35 */ { 640, 423+41, od_bad, 34, 68/2 }, #define FD_INSERT 36 /* 36 */ { TEXT_X, TEXT_Y3, "Please\ninsert\ndisk", 37, 0 }, /* 37 */ { 640, 395+84, od_icon, 38, 1 }, /* 38 */ { 672, 431+17, od_arrow1, 39, 68/2 }, /* 39 */ { 640, 395+84, od_icon, 40, 1 }, /* 40 */ { 672, 439+17, od_arrow2, 41, 68/2 }, /* 41 */ { 640, 395+84, od_icon, 42, 1 }, /* 42 */ { 672, 447+17, od_arrow3, 37, 68/2 }, }; |
The above screenshot shows NeXTSTEP running DoomEd. This was used to make Doom. I wonder if the original NeXT source code for Doom is out there somewhere. That would be fun to see. I mean the original Linux source code is available, but not the NeXTSTEP code.
Here is some more source code. Apparently, NeXT supports the a.out file format. This is interesting.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 | /* @(#)loader.c 1.0 05/09/89 (c) 1989 NeXT */ #define A_OUT_COMPAT 1 #include <sys/types.h> #include <sys/loader.h> #if A_OUT_COMPAT #include <mon/exec.h> #endif A_OUT_COMPAT /* loads both object file formats: a.out & mach.o */ loader (bp, len, entry, loadp) int *len; char *bp; char **entry, **loadp; { #if A_OUT_COMPAT struct exec *ap = (struct exec*) bp; #endif A_OUT_COMPAT struct mach_header *mh = (struct mach_header*) bp; struct segment_command *sc; int total_size, cmd, first_seg = 0; #if A_OUT_COMPAT if (ap->a_magic == OMAGIC) { total_size = ap->a_text + ap->a_data; *loadp = *entry = (char*) ap->a_entry; bp += sizeof (struct exec); *len -= sizeof (struct exec); } else #endif A_OUT_COMPAT if (mh->magic == MH_MAGIC && mh->filetype == MH_PRELOAD) { sc = (struct segment_command*) (bp + sizeof (struct mach_header)); first_seg = 1; total_size = 0; /* * Only look at the first two segments (assumes that text and data * sections will reside there). Can't look at all of them because * the header probably exceeds the buffer size. */ for (cmd = 0; cmd < 2; cmd++) { switch (sc->cmd) { case LC_SEGMENT: if (first_seg) { *entry = *loadp = (char*) sc->vmaddr; bp += sc->fileoff; *len -= sc->fileoff; first_seg = 0; } total_size += sc->filesize; break; } sc = (struct segment_command*) ((int)sc + sc->cmdsize); } } else goto bad; if (*len > 0) { bcopy (bp, *loadp, *len); *loadp += *len; total_size -= *len; } return (total_size); bad: printf ("unknown binary format\n"); return (0); } |
The source code leak comes with gcc 1.36. This is quite old, there is a README from 1989 in it.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 | Return-Path: <jkp@sauna.hut.fi> Date: Mon, 10 Apr 89 10:13:45 +0300 From: Jyrki Kuoppala <jkp@sauna.hut.fi> Sender: jkp@sauna.hut.fi To: info-gcc@prep.ai.mit.edu Subject: Kernel fix needed for Altos 3068 to get coff-encapsulation working right Organization: Helsinki University of Technology, Finland. Here's a description how to fix a kernel bug in Altos 3068 and get gcc-compiled programs working. Author: Jyrki Kuoppala ([email protected]) Last modified: Mon Apr 10 09:28:40 1989 There's a bug in the Altos 3068 kernel that causes gcc-compiled programs to fail in certain situations when the machine has a heavy load and also in some other situations. The bug exists at least in SVR 2.2 1.0gT1 and SVR 2.2 1.0e. If you have source code to your system, apply the following change to os/exec.c (function gethead): Change the lines containing u.u_exdata.ux_tstart = sizeof(struct naout) + sizeof(struct filhd) + (ep->ef.nscns * sizeof(struct scnhdr)); to u.u_exdata.ux_tstart = u.u_exdata.ux_txtorg; If you only have binary, use sdb to find out the address of the previous lines (on our system it's gethead+0x140) and use your favourite binary editor to change the bytes '3036 0162 fffc 0002 0280 0000' to '23f9 01fb f4ca 01fb f4c2 6016'. This may or may not work in your case, depending on the version of the operating system and the phase of the moon. Here's what is just before gethead+0x140 to ease finding out the right place: 0x9224 (gethead+0x122): 23f9 01fb f4ca 01fb f4ce mov.l &0x1fbf4ca.L,&0 x1fbf4ce.L [] 0x922e (gethead+0x12c): 23f9 01fb f4c6 01fb f4ca mov.l &0x1fbf4c6.L,&0 x1fbf4ca.L [] 0x9238 (gethead+0x136): 23f9 01fb f4c2 01fb f4c6 mov.l &0x1fbf4c2.L,&0 x1fbf4c6.L [] Good luck ! //Jyrki jkp@cs.hut.fi |
A fascinating part of computing history.
This is the NeXTSTEP Makefile for the NeXTROM section.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | SUBDIR= config loadice loadrom srec srec2crc loaddataIO conf SRCFILES= Makefile README bitmaps boot conf config dev diag loadice \ loadrom mon pot srec srec2crc subr sys loaddataIO all clean depend: @for i in ${SUBDIR}; \ do \ echo ================= make $@ for $$i =================; \ (cd $$i; ${MAKE} $@) || exit $?; \ done install: DSTROOT @CWD=`pwd`; cd ${DSTROOT}; DSTROOT=`pwd`; cd $$CWD; \ for i in ${SUBDIR}; \ do \ echo ================= make $@ for $$i =================; \ (cd $$i; ${MAKE} DSTROOT=$$DSTROOT $@) || exit $?; \ done installsrc: SRCROOT tar cf - ${SRCFILES} | (cd ${SRCROOT}; tar xfBp -) SRCROOT DSTROOT: @if [ -n "${$@}" ]; \ then \ exit 0; \ else \ echo Must define $@; \ exit 1; \ fi |
Finally, this is the RELEASE file from the conf folder in the source tree.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | # # NeXT ROM Monitor # machine "next" cpu "MC68030" ident GENERIC options "MAJOR=2" options "MINOR=0" options "SEQ=57" makeoptions "RELOC=0" #options DEBUG options NETBOOT #options SRECBOOT #options COMPBOOT options SCSIBOOT options ODBOOT #options FDBOOT options SUN_NFS #options ENETDIAG #options PPKT #options DBUG_DMA # # Work-arounds # makeoptions "CC=/bin/rm -f $@; cc" makeoptions "AS=/bin/rm -f $@; as" config mon swap generic |
And the README for the NeXT ROM Monitor. This is from 1988.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 | Changes on Release 0.8.31 ROM CRC 0xB52BF252 PROM Progammer Checksum 0x4777 Bassanio Law 02/16/89 ------------------------- How To Build The NeXT ROM Monitor From Sources Release 0.8.30 ROM CRC 0x75cb568c PROM Programmer Checksum 0x40f8 John Seamons 12/01/88 This note describes how to build a binary and S-record file of the NeXT ROM monitor from the golden master source media. Like any other application, you must build on a machine that contains the 0.8 release and the associated include files (in /usr/include). 1) Mount the golden master source media as a Unix filesystem on the machine you'll be building on (have to be superuser to do this). # mount /dev/od0a /mnt 2) Go to the ROM configuration directory. # cd /mnt/rom-0.8.30/conf NOTE: If you just want to build the ROM from sources without altering the basic configuration then skip the next two steps. 3) (optional) Inspect the configuration file "RELEASE" and make any required changes (like enabling certain options or changing the version numbers). # cd conf # <edit> RELEASE 4) (optional) Configure in the changes you have made. # config RELEASE # cd .. 5) Go to the build directory and start a build. # cd RELEASE # make clean # make 6) The "make" should complete without errors. Observe the size of the object file shown. The size under the "dec" column must be <= 65536 to fit in a 27C512 PROM. text data bss dec hex 38840 26588 12 65440 ffa0 7) Build the S-record files for the ROMulator and PROM programmer. The file "mon.srec" is used with the "load" command to download a ROMulator. The file "mon.prom" is an S-record file with shorter (2 byte) address fields required by the Data I/O PROM programmers. # ../srec/srec mon >mon.srec # ../srec/srec -2 mon >mon.prom 8) Use your local procedure to download the PROM programmer and burn PROM parts. The Data I/O programmer checksum should indicate 0x40f8 for this release. This checksum should not be confused with the ROM release CRC that the ROM computes and verifies internally at power on time. |
Download link.
https://www.securitronlinux.com/bejiitaswrath/another-look-at-the-nextstep-source-code/
Why not link to the actual source code:
https://news.ycombinator.com/item?id=35864380
In 1998, I saw the digital unix, cisco ios, and Sunos source code in an apache web directory “directory of /”, but I was not able to download it at the time. I saw the filenames on edonkey2000 but they never downloaded. But the source is out there.