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.
> Turns out xenix had a filename length limitation (I don't recall exactly, but maybe 12 or 15 characters?)
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.
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[104]; 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.
Likely, but the causality goes the other way. Sockets arrived in 4.2BSD on Sun and VAX, well after the world's attention had moved away from PDP-11 Unix.
Hah! I'd never noticed that it was actually defined that way on many systems (including GNU); POSIX says it should be declared as
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.
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?)
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 noticed you can also use the form below the window to mount various DOS floppies.
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.
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.
The model 16 was so much bigger and more powerful than the original TRS-80 that it included an entire original TRS-80, whose only job was to operate the keyboard and serial port.
No, the Model II had only a 4MHz Z-80. The Model 16 (and later the Model 6000) had a 68k-series coprocessor, and Xenix ran in that (using the Z-80 for I/O).
It's interesting how the "common history" of the IBM PC is often "The 8086 came into existence and then later the 386 was released" as if they somehow were only separated by a few years.
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 [1] 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[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.
The 97801 was only a - very nice and ergonomic - serial text terminal (some models were VT220 compatible), but it was commonly used with SINIX systems. It seems that Siemens provided a 97801 emulator for Collage (https://www.computerwoche.de/a/siemens-macht-sich-mit-collag...).
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).
Of course. I found some other stuff in the 1.2 kernel by the way, like the existence of (relatively smart, apparently) network and serial multiplexer cards for the PC-X.
I also reverse engineered how the NMI worked, details about the MMU etc.
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.
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.
The extra instructions were mostly fine, the NEC V20/V30 implemented them too, the 186 had built-in peripheral functions like timers and the interrupt controller that were different to those in a PC.
You couldn't use the array bound check instruction as it used the interrupt used by the PC BIOS for Print Screen.
That is a hilarious limitation. I can just see someone building a test program to try it out and wondering why his printer is suddenly spitting out screenshots.
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.
Exactly - the winning OS was MS-DOS and successors and so the 8086 went to the 80386 because nothing "famous" really used the 286 capabilities (Windows 286 aside).
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.
Well the first "PC-compatible" using a 386 came out only 5 years after the IBM PC. And the CPU itself came out only 7 years after the 8086. It really was only a few years!
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.
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.
Yes, it was the modern lab on a technical school for informatics, a mix of 286 and 386 models from Siemens-Nixdorf.
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.
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.
No way, first we are talking about a high school, not something with university resources.
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.
And basically for free, all those old OSes were hundreds or thousands of dollars in the 80s! I did projects in OS/2 1.x and Xenix as well as VMS but not on my own nickel.
It’s an interesting alternate universe. Microsoft building a graphical shell and easy to use object oriented development tools on top of Unix underpinnings to compete with the Mac.
Or the 2nd iteration of it, had Microsoft kept POSIX subsystem for NT properly updated with the same tooling support as Win32, Linux would never had taken off.
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.
The version if Xenix 286 we had at work came with a cc that was similar to M/S c 5.1. It had the various memory models.
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 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.
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.
>"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.[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."
>"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]"
Software was often much more expensive than hardware in the early days of computing - it was much later that the $100 or so “max limit” became relatively common.
We were a Victor dealer and couldn't get a demo copy. They went all in on full PC compatibility anyway, so it din't really matter. I just sold my last Victor keyboard this summer...
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.