A bit of XENIX history (2014)
seefigure1.com
seefigure1.com
We were using SCCS, and when we would check in foo.c it would become s.foo.c
Then trying to build with make, it wouldn't find some file or wouldn't apply a c compile rule and nothing would work.
Turns out xenix had a filename length limitation (I don't recall exactly, but maybe 12 or 15 characters?)
So files like longfilename.c would hit the length limitatation and when checked into sccs would become s.longfilename. and truncate away the filetype. and since it wasn't a c file anymore...
But I do remember it was an operating system that might actually use protected mode and extra memory of the 286 - without EMS or XMS shenanigans that came to the dos world.
A lot of early PC & DOS development was shackled by silly limitations. You couldn't write a program that didn't do all kinds of checks to make sure you didn't use more than 64k because of the real mode segmented memory. Same with filenames, or linking+overlays or any number of things.
We take all that stuff for granted now. I write scripts that read an entire file into memory, do things and write it back out. Those things were a real headache back then.
Fourteen. A Bell Labs Unix directory entry was 16 bytes: a 2-byte inode number followed by the file name. You read the directory by opening it as a file and reading it as an array of these.
It wasn't until 4BSD/SunOS and System V needed multi-filesystem support that this was changed and what became the POSIX struct dirent replaced it.
char sa_data[14];
in struct sockaddr. char sa_data[];
So thanks for that! However, I don't think your suggestion as to the reasoning passes muster; (1) the socket interface originated in BSD, where longer filenames already existed, and (2) for AF_UNIX sockets, the data is the full path including directories, not just the base filename.My guess is that sockaddr was originally defined as 16 bytes (2 bytes type, 14 bytes data) just because someone thought it was a nice round number, and that GNU and other systems have kept the "14" to establish a minimum size for the struct, and that in order to avoid breaking historical code that uses sockaddr instead of sockaddr_storage.
https://github.com/dspinellis/unix-history-repo/commit/3573c...
And we have a better clue as to why: there was a separate "sockaddri" that allowed for indirect references for address sizes > 14 bytes.
So the sa_data[14] comes from 16 bytes being the maximum amount of data that Bill Joy was willing to pass around by value instead of by reference.
(Actually, that was probably modeled after the older `struct in_addr`, but the headers for that are missing--so I can't tell. Perhaps it was a design decision carried forward from someone else; perhaps someone from BBN?)
And, the 14 character limit in old unix was for individual path components, whereas unix domain sockets contain complete paths, so the 14 character limit was never relevant for unix domain socket addresses.
Of course this was also problematic in that it could make some DOS software incompatible with earlier 8086-based hardware.
A few years later when I we finally got a modern family PC I immediately decided to dual-boot Linux.
Texas Instruments was the supplier, and the first round of TI 1300 series were 386s.
https://techmonitor.ai/techonology/texas_instruments_adds_lo...
This series was upgraded to the TI 1500 class on Motorola 68000 nu-bus, running a real UNIX port.
I installed terminals, ran RS232 lines, and did basic admin work (mostly enabling ttys). The app software was mostly written in COBOL, and Ryan McFarland was the compiler at home base; using built-in ISAM (no formal database, AFAIK).
I was putting these into dealerships with dirt floors. It was an interesting time in my youth.
Edit: the "GOSUB STARTGAME" on their intro cover fills me with confidence in their port of the development tools.
Click in the window and hit <enter> when you see the word "Boot".
Can't find the password for xenix though
Then, within xenix, do: dosls /dev/fd096 and you can see what's on the floppy. There's other dos* commands that do what you would imagine they do, like doscat, doscp, etc.
The reason Unix exists is because they couldn't afford a machine big enough to run Multics.
So true, just imagine a world where multics and some unix spice would be the to-go system....like linux is today.
Seriously 100x as much CPU power
https://www.thecomputerarchive.com/Catalogs%20and%20Price%20...
That was part of the reason why the 286 ended up with the "braindead chip" reputation - it was designed before the IBM PC and DOS showed up, and thus the inability to easily switch between real and protected mode was not seen as a big problem at the time it was designed.
It was bought via credit and if I make the inflation calculation for today's money it would be a big pile of notes.
And that's how I got my hands on a 386sx. Around 1992 I installed Xenix and became a Unix nerd.
I love you, dad.
It's a Siemens PC-D and it was a marvelous machine. Again, not fully compatible with IBM PCs, but often for good reason. The 640k barrier was not a thing on a PC-D for example. And it has its own MMU made of discrete logic chips for real process separation on SINIX!
You couldn't use the array bound check instruction as it used the interrupt used by the PC BIOS for Print Screen.
The machines are all in Europe and I'm currently in the US. Where are you based? I might be willing to part with one of the three machines, but only after I've gotten an extensive look at it (and it will likely be a significant while before that, especially with not being able to travel right now and all).
What's the Collage GUI?
EDIT: The GUIs I'm aware of are Digital Research GEM and Windows, I think up to Windows 2.11 or something. Obviously, that's for DOS. If there was a GUI for SINIX, I'd be extremely interested? I noticed that the SINIX 1.2 kernel added graphics support.
Collage was a GUI I used a little that ran on SINIX. It wasn’t as nice as GEM but I could run programs and browse files. I think I could run a windowed terminal.
Does anyone know, if there is any documentation out there, or maybe even screenshots?
[1] "UNIX für den kommerziellen Einsatz: Die SINIX-Anwendungsumgebung" ed. John J. Abbott (Carl Hanser Verlag München Wien, 1993), PDF-copy: http://oldcomputers-ddns.org/public/pub/rechner/siemens/mx-r...
Now I'm super intrigued that there may actually be a GUI for the PC-D/X[1] out there!
I'm pretty sure the installation of SINIX 1.2 does not have that, it probably came on extra diskettes, but now I really want to double check.
[1] The machine was basically called PC-D when running DOS, and PC-X when running SINIX. That's not technically true for the first revisions of the boards (where e.g. the MMU was an optional card), but all PC-Ds I remember seeing even had "PC-D/X" written on their backside already.
EDIT: That book you linked seems to be for the SVR4 SINIX that came after the XENIX-based PC-D SINIX. By that time, from what I could tell from other research so far, SINIX was running on NS32032, not on 186.
http://oldcomputers.dyndns.org/public/pub/rechner/siemens/mx...
I think Siemens 97801 is another moniker for Siemens PC-X (at least the SINIX kernel also calls it 9780).
Thank you!
I also reverse engineered how the NMI worked, details about the MMU etc.
At the time I thought it was odd that the windows ended up aligning at character cell borders, which would indicate a terminal with some form of redefinable character set.
Our OS teacher would bring in a PC tower with it on the days we had lab classes, and then each group would take 15m turns at it.
Why only 15m? We were supposed to have already prepared the exercises in MS-DOS/Turbo C 2.0, using stubs for the respective syscalls.
When ready we would be given a slot to put a floppy in, copy the stuff into HOME, disable the stubs and have a go at it.
Like on the card deck days, either it worked, if not or if a short VI session couldn't fix the issue, it was time to go back into MS-DOS PC and free the computer for the next group.
My first programming class was in 1991 on a DEC VAX running VMS. We had a room with 30 VT100 style terminals so everyone at least had their own display and keyboard.
The Xenix PC tower was brought from the teacher's research lab, he was usually on a motorbike, but on labs day we would bring his car with the tower in it.
By the way, we had two labs, the older one was full of 8086 and 8088 models, without hard disk, using 8" floppies.
My typing skills exam was done editing a document with edlin.
Just wondering why they didn't turn the DOS machines into terminals or ethernet / network to connect to the Xenix PC tower.
Then those were the days of Novell NetWare, and yes one of the labs did had a couple of them, not all, connect via Novell.
As for the Xenix tower, as mentioned, it did not belong to the high school, rather the teacher would bring it along with him from his main job, kind of renting it for the lab classes.
So nothing that could ever work in a permanent setting.
Santa Cruz Org is not one of the favourite companies these days. I ran a SCO unix system, it was ok (it was on Compaq multi-CPU hardware, donated, and it worked ok but was a bit of a big to cross-port stuff to, odd compiler options, odd -llib things) But I wouldn't want to pay money for it.
It was often said Apple had a Cray, and used it to do things which informed what happened in their mainline product. I can't imagine what it was they did. I am pretty sure Apple engineers used UNIX a lot. Even before Jobs came back from NeXT there would have been a hardcore of Apple people doing A/UX, but I really do mean aside from that there would be people in the complex using mainstreain V7/BSD systems to do things.
I wonder who the last holdouts were, for a sendmail.cf world.
(there was a port to Windows, maybe they uplifted sendmail as-is?)
A/UX was interesting and I only saw it once at one computer fair in Lisbon in 1995, it never had much uptake.
Fun times was one they sent a tape to do major upgrades.
I remember discovering that we could generate reports of all clearance items in the store, led me to tracking down stuff I had no idea was hiding in there like ISA slots and various other parts already antiquated by the late 90's.
https://en.wikipedia.org/wiki/Intel_iPSC
The processor cards were arranged in a hypercube configuration, and you had a manager computer that would load operating system images onto them at boot time. They had libraries that gave you messaging capabilities, and I somehow managed to get it to sort strings in parallel across them. Badly, I'm sure. But hey, college student.
https://archive.org/details/Unix_World_Vol02_10.pdf/mode/1up
Note: There is a button to export it as a pdf.
https://archive.org/details/Unix_World_Vol02_10.pdf/page/n22...
And downloading a PDF is great, but I've always found the in-page reader pleasant enough.
I do not know what your tools were like, but for me it was rather easy except for the usually issues with includes and Libs (assuming I remember correctly) :)
I wish I could have kept a copy for home use when I left the company. I remember it being rather nice
I'm also skeptical of the comment at the end about MS getting paid for all x86 Unixes, I'm sure that was true for anything labelled "Xenix" probably not true for 286 and later SysV ports which were done outside of MS
Where are my rose tinted glasses...
Anonther thing I remember is that floppy driver was terrible- the interleave was incorrect for it, so pretty much one block per disk rotation. People forget, but a big reason for early Linux success was addressing issues like this.
Oh, and the filesystem used a linked-list for the free blocks. Basically you had instant fragmentation.
Xenix wasn't even something people cared about anymore when Linux 0.0.1 came out, aside from legacy installations. The big commercial UNIXes like SunOS (the Solaris rebranding hadn't occurred yet), HP-UX, AIX, etc. were what Linux was competing against.
“UNIX System V, r3.2”
in the timeline above)."
https://en.wikipedia.org/wiki/UNIX_System_V
>"SVR3
AT&T's UNIX System Development Laboratory (USDL) was succeeded by AT&T Information Systems (ATTIS), which distributed UNIX System V, Release 3, in 1987.[12] SVR3 included STREAMS, Remote File Sharing (RFS), the File System Switch (FSS) virtual file system mechanism, a restricted form of shared libraries, and the Transport Layer Interface (TLI) network API.
The final version was Release 3.2 in 1988, which added binary compatibility to Xenix on Intel platforms (see Intel Binary Compatibility Standard).
[...]
SCO UNIX was based upon SVR3.2, as was ISC 386/ix. Among the more obscure distributions of SVR3.2 for the 386 were ESIX 3.2 by Everex and "System V, Release 3.2" sold by Intel themselves; these two shipped "plain vanilla" AT&T's codebase.[13]
IBM's AIX operating system is an SVR3 derivative."
https://en.wikipedia.org/wiki/Xenix
>"In 1987, SCO ported XENIX to the 386 processor, a 32-bit chip, after securing knowledge from Microsoft insiders that Microsoft was no longer developing XENIX.[40] XENIX System V Release 2.3.1 introduced support for i386, SCSI and TCP/IP. SCO's XENIX System V/386 was the first 32-bit operating system available on the market for the x86 CPU architecture.
[...]
SCO released its SCO UNIX as a higher-end product, based on System V R3 and offering a number of technical advances over XENIX; XENIX remained in the product line. In the meantime, AT&T and Sun Microsystems completed the merge of XENIX, BSD, SunOS and System V R3 into System V R4. The last version of SCO XENIX/386 itself was System V R2.3.4, released in 1991.[45]"
A bit of XENIX history - https://news.ycombinator.com/item?id=7604134 - April 2014 (35 comments, some by ex-SCO employees including cstross!)