I just remember using xenix, and the trouble we had porting some software to run on it.
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.
I got into Linux just when the ext fs became a thing. Or maybe it was ext2 already, but in any case, there were a lot of remnants of when it used the Minix filesystem, which as I recall was limited to 14 characters as well.
No, sa_data is a minimum size, not a maximum. For unix domain sockets you should look at the definition of sockaddr_un which has char sun_path; but again, that's a minimum reserved size and if you allocate a larger size you can use sockets with longer names.
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.
Hah! I'd never noticed that it was actually defined that way on many systems (including GNU); POSIX says it should be declared as
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.
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 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?)
I would guess there was a wave of folks that started using the extra room when 4BSD was released, and forgetting their peers on Xenix, Unix V7, etc. I remember some popular software (rrn or trn maybe?) had a file called environment.sh in it that got truncated with SCCS on some unix limited to 14 chars.
DOS programs could run in protected mode by using a DOS extender. There were also quasi-standard interfaces that enabled programs so written to interoperate with environments that might use protected mode for their own operation and run DOS programs in VM86 mode. This support could also be extended to TSR's (background services) or device drivers.
Of course this was also problematic in that it could make some DOS software incompatible with earlier 8086-based hardware.
Xenix was weirdly one of the first OSes I was ever exposed to. In the early 90s I got my hands on a trash-picked TRS-80 Model 12 that was fully upgraded to a Model 16 - along with a 15MB Hard disk that booted Xenix. Its previous owner gave me its root password. Technically, this was my first computer. I checked out "Understanding Unix A Conceptual Guide" from the library to try stuff out and immediately became obsessed with Unix. Sadly it was not long for this world and died from a power surge just 3 months later :(
A few years later when I we finally got a modern family PC I immediately decided to dual-boot Linux.
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.
Good memories. My first job at age 14 was working on Xenix boxes (386es) with a bunch of Wyse terminals connected to serial port multiplex cards customizing and configuring medical/dental software for local practitioners. Created my muscle memory for vi on Xenix as well. It was mind-blowing how well it ran on such limited horsepower back in the day.
In the mid 80s, my high school used a similar setup on a TRS-80 with I think 8 serial terminals for their COBOL classes, replacing a Burroughs minicomputer with an actual cardpunch and card reader.
It was cool hitting college already knowing vi, a shell, and how to write crap to other student's ttys.
As a 13 year old longhaired wardialer in a not-so-privileged neighborhood in regular contact with a group of same, Xenix was something we commonly encountered. High schools tended to mistrust, rather than encourage computer enthusiasts, and the nearest public library only had a couple elementary books on Unix. I recall feeling like the richest man in the world when a friend got his first job as a night watchman and told me not to ask any questions about where this complete set of Xenix manuals came from. Good ole Xenix on other people's computers became where I honed my shell-scripting abilities at a time when documentation just wasn't so easy to come by.
I remember sitting in a RadioShack as a kid poking at Xenix on a Model 16 and trying to figure out how to use it. I never made any progress as it took a long time to boot whereas the adjacent Color Computers and most other TRS-80 models booted instantly into BASIC.
Another operating system for Model 16s was RM/COS- a COBOL operating system. This was popular because it was smaller than Xenix on your 8 MB hard drive. There is not much information about it, but check out this cool catalog from 1986 (Model-II was "Tandy-6000" by this point- I see there is a punch card reader available..):
It's not so crazy when you consider the specs of the machines Unix was developed on. A PDP-11/20 comes with 24k of memory (16k 18bit words) and 500k of drive space and was shared between an entire department full of people.
The reason Unix exists is because they couldn't afford a machine big enough to run Multics.
While we are talking about that, I actually have a PC running on an 80186 (rather uncommon, as it has peripherals built in that are not IBM PC compatible), running a XENIX descendant: SINIX.
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!
This seems interesting. I couldn't find anything on Collage, other than a note in a German SINIX manual  to the extent that this was a GUI used by Siemens before they switched to X Windows and OSF/Motif.
Does anyone know, if there is any documentation out there, or maybe even screenshots?
I never knew this was a thing. I compared the kernel (like, actually reading and comparing the disassembly) between SINIX 1.0 and SINIX 1.2, and I noticed that in 1.2 a significant amount of kernel code for graphics support was added. I did wonder what that was for.
Now I'm super intrigued that there may actually be a GUI for the PC-D/X 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.
 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.
If I understand correctly the docs we found, there were 3 "flavors": "Grafik-COLLAGE", "Alpha-COLLAGE", and "X-COLLAGE". I assume the first would be for some sort of clever terminal, the second for non-graphical terminals, and the last one for X servers.
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.
No, thank you! This is something I didn't even know existed, and now I'm very curious to find out more. Although chances are slim, maybe that software turns up somewhere someday (it would be brilliant if it's on one of the machines I got, since except for the one that was my own in the 80s, I did not get to even see them yet--shipping them over the ocean would not just have been expensive, but risky, too).
I have at least two, actually. Hopefully additionally the one that I originally used in the 80s (the other two are much more recent acquisitions) still exists in my parent's basement somewhere.
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.
What you are saying is true, but it's also worth keeping in mind that the 8086 was already three years old by the time the first IBM showed up, and the 286 was launched only a few months after the IBM PC.
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.
I think what people tend to miss is that it took a very long time for that to happen. It took until the early 90s for the 386 to get cheap enough to start outselling the 286. Even after Intel dropped it, AMD and Harris kept releasing versions that were faster and cheaper than the low-end 386es.
Same machine, investment was so big that my dad had to ask for a payroll advance from his boss, given I was struggling with Pascal (and my then computer was a Vic20). Turns out the boss had studied in the same college I was in, his answer was: "Whatever your kid need".
And that's how I got my hands on a 386sx. Around 1992 I installed Xenix and became a Unix nerd.
Ooh. This sounds a lot like University of Portsmouth (in the UK), as they had 3 DEC VAX minicomputers running VMS supporting quite a lot of terminals across campus during the early 90s. The terminals were VT220 though. VMS Phone was useful for annoying other students.
Did the PCs have ethernet? Our campus network had a lot of DOS PCs but they ran a bunch of DEC Pathworks stuff to turn them into terminals to the VAX. We also had some PCs with a DOS telnet client to telnet directly to the Unix machines.
Just wondering why they didn't turn the DOS machines into terminals or ethernet / network to connect to the Xenix PC tower.
Fascinating. I wonder if MS had made more of internal use of Xenix, it would have had a better fate? The side effect of dogfooding one product and ignoring another can be strong.
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 remember reading somewhere that MS-DOS was actually developed on Xenix and cross compiled, but I don't know how much of that is actually true, although they hint at it on the article (MS-DOS tooling appeared first on Xenix).
A/UX was interesting and I only saw it once at one computer fair in Lisbon in 1995, it never had much uptake.
When I worked at Radio Shack in the late 90s, the entire POS was running as a main Xenix server and the terminals connecting to it. Backups were done on tape. Updates would come in over night and usually required a reboot at the worst times.
Fun times was one they sent a tape to do major upgrades.
Ha, yea good memories... well sort of. I only worked there for a few months but my manager wouldn't let me near the Xenix main terminal in the back as he knew I was a little familiar and didn't want me messing with it. He assured me that Tandy had the tape backup drive custom made for them, lol. Still, he was a nice guy.
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.
It was the first Unix I encountered. This was on a 32-processor 80286 Intel iPSC that was obsolete, but one of the university professors either knew someone, or wrote a good enough proposal that they were grateful to unload it on him.
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.
Brings back some memories. First UNIX I worked on was, IIRC, was System III on a Pixel Machines box. We ported a management tool for Dept of Transporation that had been running on an IBM TSO system. Deployed 5 of these around the country, setup uucp to send data back to home base. Xenix came along a few years later and, if memory serves, it's what we ran on some Altos machines. Fun times.
I've spent a lot of time porting many Unix tools to Xenix 286 for internal use. It was a paintful process. Assumptions of 32-bit size of integers were common, build tools (make, C compiler) differ in subtle ways from common Unix ones, etc.
A weird thing about Xenix is that it used the Microsoft C compiler, including COFF format object files. I didn't try it, but I'm pretty sure you could cross compile to MS-DOS with it.
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.
> "People forget, but a big reason for early Linux success was addressing issues like this."
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.
I had heard of Xenix over the years, but I hadn't realized they essentially upstreamed to the x86 port of SysV and continued to receive royalties for it, which it says very briefly at the end of this article.
I think that it was v7, I remember that it was SCO who did the SystemV 286 port (I know this because SCO brought the company in that I worked for when they got stuck working on the MMU, .... and then screwed us over .... long before the whole Linux legal kerfuffle).
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
I think SCO (SCOC not SCOX) ported so much of their own and MS stuff from Xenix 2.3.2 to 2.3.4 over to SCO UNIX SysV 3.2v2.0 to keep MS Word working I can well imagine (and I think I recall) that MS got royalty kick for every SysV Release 3.2 x86 install.
I remember finding Microsoft copyright statements in some programs on a Solaris 7 box in 2000 (my memory says /bin/true but some googling reveals it was probably /usr/bin/clear). Some of these programs were implemented as shell scripts and had copyrights from SysV, some of which had come from Xenix.
>"The final Xenix work at Microsoft was an effort with AT&T to integrate Xenix support into the main System V.3 source code, producing what we unimaginatively called the “Merged Product” (noted by the official name of
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. 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.
IBM's AIX operating system is an SVR3 derivative."
>"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. 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."