For a long time, I have tried to find a GUI environment running on SCO XENIX (because, honestly, what could be more useless?). Back in the day, meaning late 1980s and early 1990s, SCO sold Xsight, which was an adaptation of (at least initially) X11R3 to SCO’s XENIX and UNIX SVR3.2 operating systems. But Xsight has proven remarkably elusive.
Various XENIX software like MS Word, SCO’s Lyrix, FoxBase+, random Microsoft compilers and SCO development kits, even TCP/IP, has been floating around for years.
The recent warez megadump turned out to include something probably even rarer, a Xsight development kit… but not Xsight itself!
Just recently I found an old set of warez CDs from ancient China, which in fact did contain Xsight… but wouldn’t you know it, the one CD that had Xsight on it is missing from the set! That’s just not fair.
And then I realized that I’d had Xsight in my hands all along. SCO Open Desktop (ODT) 1.0 floppy images have been around for years. ODT 1.0 was basically a bundle of a whole bunch of SCO products: SCO UNIX System V R3.2, basic and extended utilities,TCP/IP runtime, NFS runtime, LMX (LAN Manager client), Ingres database, Merge386 (virtual DOS machines) and finally Xsight. All in all, ODT 1.0 was quite impressive–in 1990, SCO had a 32-bit UNIX with TCP/IP and LAN Manager networking, X11 GUI, and a relational database, all running on relatively cheap 386/486 systems.
In the ODT 1.0 disk set, most disks are labeled P1, P2, and so on (in the 1.2M disk edition, these go up to P37). But on closer look, they’re just relabeled disks from separately installable products. And disks P31-P37 turned out to be Xsight 2.1 disks.
As an aside, ODT 2.0 and 3.0 also contain Xsight disks, but at that time (1992-1993) Xsight no longer supported XENIX at all. But the Xsight disks in ODT 1.0 are old enough (December 1989) that they do support XENIX. Well, almost.
Installing Xsight on XENIX
Setting up Xsight on XENIX turned out to be a little tricky. First of all, Xsight might perhaps run on XENIX 2.3.1, and 2.3.2, but it can’t be installed out of the box. Attempting to install via custom
seems to work at first, but then fixperm
spews a bunch of errors, claiming not to understand the format of executable files. As it turns out, the files on the Xsight distribution disks are compressed with the compress
utility and the old XENIX (and also SCO UNIX) versions don’t know what to do with that. Supposedly old Xsight versions came with supplemental disks for SCO UNIX and XENIX, updating the system tar
and compress
utilities to be able to handle the Xsight distribution media.
On XENIX 2.3.4, the archive utilities are new enough that this is not a problem. Trying to install Xsight kindly informs the system administrator that the SCO STREAMS Runtime has to be installed first for Xsight to work. Fortunately I had old enough STREAMS on hand. The installer also mentions that TCP/IP is supported if available, but not required for local operation.
So I installed STREAMS and Xsight, and the installation completed, although fixperm
complained that there’s no sys
account and group, and that the bin
gid is not right. I thought that was a big problem, but in hindsight it probably wasn’t.
In any case, startx
brought up the familiar checkered X11 background, and the mouse was happily moving… and that was it. I was able to switch virtual terminals (Alt-F1, Alt-F2 etc.) without any trouble, and I could cleanly exit Xsight with Alt-SysRq. But any and X11 clients just refused to connect.
In desperation, I tried installing TCP/IP, thinking that maybe it’s required after all. But no, that didn’t help. Then I tried reinstalling Xsight and watched the messages a little closer. There were complaints about ./configure
not being found, and lots of errors related to mkdev
.
So I took a closer look at the Xsight install script in /tmp/init.Xrun
(unpacked during installation and then removed again). Unsurprisingly, it has separate code paths for XENIX and SCO UNIX, in order to handle differences such as the kernel rebuild tools being in /usr/sys/conf
on XENIX and /etc/conf
on UNIX.
As I read through the script, the problem suddenly became obvious. The Xsight installer (in function mk_stream_pipe_xenix
) tries to configure the clone device /dev/spx
, and subsequently sets up stream pipe /dev/X0R
, /dev/X0S
, /dev/X1R
, /dev/X1S
, etc. devices. This is done from the /usr/sys/conf
directory where the configure
tool is located, but between the steps, the script calls the linkchk
function to verify that the XENIX link kit is installed (if not, the kernel can’t be relinked and the Xsight installation can’t succeed).
And… the linkchk
function does cd /
but never returns back to where it was. So the script fails to run ./configure
because it ends up in the wrong directory, fails to set up the required device nodes, and all X11 client/server communication subsequently breaks down.
I can only imagine that this is a testing failure—somehow the installation of this particular version (Xsight 2.1.0j) was not tested on a clean XENIX system. Then again, it is possible that it was only ever shipped as part of ODT 1.0, which is definitely not XENIX, so no one noticed.
The bottom line is that if the Xsight 2.1.0j installation script is corrected, or the missing kernel configuration steps are done manually, Xsight does in fact run on XENIX!
We’re still looking for Xsight 2.1 or 2.2 disks that can be installed on XENIX. They must be out there… somewhere. Maybe next year?
I think this China CD dump might be an expanded version of the “Chinese Warez CD” that surfaced some years ago. That one is also missing CD #12 but it only goes up to 16.
A list of its contents is here:
https://docs.google.com/spreadsheets/d/1VjRLbSqxbxRztCOo0bg1OdocRjPZMiEBAcR9F8Ilzcs
I can’t find the original URL right now though
“Just recently I found an old set of warez CDs from ancient China”
Was it from the Tang or Sui dynasty?
( Sorry, couldn’t resist 🙁 )
“Xsight might perhaps run on XENIX 3.2.1, and 3.2.2”
Surely you meant Xenix 2.3.1 and 2.3.2 ?
Yes, of course. Corrected, thanks.
Close. It’s from 1994, that’s pretty ancient in the world of computing.
It occurred to me that it could be the same thing, but I don’t think it is. There’s probably a lot of overlap but the CDs seem to be organized quite differently and contain a different (but similar!) set of products. The dates also look different, 1994 vs 1995.
Interesting… This X server is made by the same company who made Merge386 (basically DOSEMU for Unix), and which later was sold to TRELOS, which then became Transitive to make the first versions of Win4Lin supporting paravirtualization of Win95 and 98 on Linux (last versions were just rebranded QEMU running Win2k and WinXP).
Maybe someday you would like to test these old versions of Merge, and compare them against OS/2 MVDM support.
Side track: This is one of the posts where the comments doesn’t show up while viewing normally, while the comments are there in the RSS feed.
There must be some serious bug in whatever host is used, in that it forgets to propagate updates in the comment section to mirrors around the world.
For me http://www.os2museum.org resolves to 188.114.97.1.
If anyone sees this and can see more than my comment and one other comment, it would be nice if you tell what http://www.os2museum.org resolves to for you. Maybe I can force that IP in my hosts file or something similar.
(I assume that I’m one of few people who use RSS and thus actually notices “missing” comments).
I just felt a distinct smell of the XENIX floppies as I remove from the box and insert into the drive one by one. 🙂
The SCO Xsight 2.3 Server EFS (efs108) disk images are still available from https://ftp.sco.com/EFS/ – and XENIX 2.3.2 or later is a supported environment.
$ strings 31.IMD |grep -i xsight
./tmp/_lbl/prd=xsight/typ=n386/rel=2.2.0e/vol=01
#prd=xsight
#set=”ODT Xsight RTS”
#ser=”/usr/bin/X11/Xsight”
$ strings P31.IMD |grep -i xsight
./tmp/_lbl/prd=xsight/typ=n386/rel=2.1.0j/vol=01
#prd=xsight
#ser=”/usr/bin/X11/Xsight /usr/bin/X11/mwm /usr/bin/X11/xterm”
XRT F444 bin/bin 1 ./etc/copyrights/08.xsight 01
Version 2.0 on eBay https://www.ebay.com/itm/285662948626
Does anyone know where SCO Open Desktop 1.0 might be found?
Warez CDs from the 1990s. For example, within https://archive.org/details/ibm-wgam-wbiz-collection it’s on tapes wbiz0184 and wbiz0185.
Yes but no — that is the XSight development system, i.e. headers and libraries. It’s not the actual X server.
Yes, but since I only have Xsight 2.1 on hand, I don’t know just how relevant that is.
Saying that Merge386 is “basically DOSEMU for Unix” seems a bit funny given the chronology. It would be much more accurate to say that DOSEMU is “basically Merge386 for Linux”.
Yes, reviewing the old Merge386 versions would be interesting. There was also a competitor product, VP/ix from Interactive Systems, which offered similar capabilities. VP/ix was available for XENIX, but for ODT, SCO seems to have switched to Merge386. Interactive UNIX could also run VP/ix, unsurprisingly.
On a possibly unrelated note, the Wikipedia article on Merge claims that Merge/386 was already included with Microport Unix SVR3 in 1987, which is seriously early for a 80386 OS. Too bad that this Unix is nowhere to be found, for now, or for ever.
Check the Nov 10, 1986 issue of InfoWorld, page 74. This talks about Interactive and VP/ix, as well as Microport and Locus Merge 386. What was really released when is a little hard to pin down, but 1987 is very believable. According to my research, Microport had a 386 UNIX out in June 1987 and Microsoft/SCO had 386 XENIX out in July 1987. Whether Merge was in Microport’s version from the beginning I don’t know.
SCO produced VP/ix 1.1.0b in July 1988, which would make an initial release in 1987 plausible. Locus and Interactive were clearly working on DOS emulation in 1986 and were far enough along to publicly talk about it.
Ah yes, according to https://www.scosales.com/ta/kb/108405.html SCO had VP/ix 1.0 out just before the end of 1987. Interactive may well have had it available sooner. In any case, although 1987 is indeed early for a 386 OS, it did happen, and there was more than one such OS.