When we last left off, with the help of the excellent Michal Necasek of the OS/2 Museum, we had gotten the damaged Xenix 2.2.3c past the first hurdle of installation, and directly into a post-reboot crash, the cause of which (at the time) I suspected was another emulation failure.
Needless to say, I needed to get past this. At this point, I have been examining the raw images as best I can, and figuring out how the installer comes together. After a few experiments, I managed to determine a few basic facts about how Xenix is installed when booting from N1/N2:
- Coming out of reset, the Xenix kernel loads from N1, prompts for the "filesystem floppy" and starts /etc/init or /etc/inir coming out of IPL
- Init prints the "Entering System Maintenance Mode" line.
- Inir is used for running fsck, if necessary. Afterwards, it starts init.
- Initially, the system starts /usr/lib/mkdev/hd which does the following
- Format the Xenix partition, create slices, and mount the hard drive under /mnt
- Compile the keyboard configuration files so the language selection sticks past reboot
- Create a few device nodes manually
- Cpio is used to copy a list of files from N2 to the root partition.
- /profile.hd is copied to /mnt/.profile
- Install a boot sector to the MBR of the hard drive and configure the bootloader for HDD booting
- The hd script does the initial language selection, followed by fdisk
- After the completion of the script /.profile is run as the system tries to bring up the root prompt which reboots the system after prompting that N1 should be re-inserted after the boot prompt.
So with knowing what the installer is trying to do, it was time to try and get down and dirty with it.
Have /bin/sh, Will Travel
With a relatively complete understanding of the initial installation steps. I decided to create a boot floppy. By finding the initial strings for language selection, I was able to find where in the boot image the installer starts, and force it to pop open a dedicated shell with a hex editor. With that in place, I finally had a chance to explore the system somewhat. I learned a few interesting details while digging through this. There are references to 96 and 135 tpi media such as the following.
# We want to make the hard disk bootable in the 96 and 135 tpi # installations so that we don't need to re-insert N1 to re-boot
TPI refers to as "tracks per inch" and is a very old style way of referring to differing types of floppy disk medium. In this specific case, 96 TPI refers to low- (or double-) density 720 KiB 3.5-inch floppy disks, and 135 TPI refers to high-density 1.44 MiB floppies. This suggests that this version of Xenix was available in multiple types of media. This comment would help me immensely in trying to perform a manual install. As it turned out, much to my annoyance, the N2 file system was extremely lean overall. By using "echo *" as a poor-man's ls, I was able to get a list of what I did and didn't have, the /bin directory was rather ... empty.
I also found I had /etc/mount and /etc/mknod which helped, but not much overall. Deciding to charge ahead, I ran through the normal partitioning and formatting steps, and then rebooted again with N1, and my modified N2 boot floppy. As I got my hands dirty, I also began to unpack and explore the other disks. As I mentioned before, aside from the first two disks, all the other ones were simply tar archives written as raw files. Or more specifically:
$ file *.img Basic Utilities 1.img: tar archive Basic Utilities 2.img: tar archive Extended Utilities 1.img: tar archive ...
Each disk begins with a specific header with an empty file which identifies the disk number, product set, and machine set:
./tmp/_lbl/prd=xos/typ=386AT/rel=2.2.3c/vol=N03 ./tmp/_lbl/prd=xos/typ=386AT/rel=2.2.3c/vol=N05 ./tmp/_lbl/prd=xos/typ=386AT/rel=2.2.3c/vol=N04 ./tmp/_lbl/prd=xos/typ=386AT/rel=2.2.3c/vol=N06 ./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=B01 ./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=B02 ./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=X01 ./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=X02 ./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=X03 ./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=X04 ./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=X05
As one can plainly see, the B/X disks have a slightly different version, and identify themselves as n86, or generic x86. Furthermore, the N disks are the only ones that have "80386" binaries as defined by their headers. On top of that, investigating N1 I found a master manifest file that lists all the files on all the base installation disks, as well as special files, and mknod numbers. Bingo. Almost all the pieces I needed.
A quick check of the manifest file listings, and the contents of each disk confirmed that despite the differing version numbers, the media in and of itself belonged with each other; that is, these are the disks that correspond to Xenix 386 2.2.3c.
Dealing With Floppy Disk Controllers, Media Controllers, and More
My initial experiments taught me a few things about Xenix, chief of which it very much didn't like its root filesystem floppy removed. If I removed N2 from A: at any point, Bad Things™ would happen not long after. As such, if I wanted to successfully bypass the installer and extract things into a working system, I need to figure out how to talk to it.
On UNIX systems, for those less familiar with them, disk operations are handled by special files in the /dev directory, such as /dev/hd0 for the first hard drive, or /dev/fd0 for first floppy drive controller, and so on. In contrast to more modern Linux systems using udev, these nodes exist as a set of static "dummy" files, created via the mknod command — mknod takes four arguments; the file to create, whether the device is binary or character based, and a blank-separated major/minor number that associates it with a driver in the kernel. Combined with the manifest file, it should have been trivial to create /dev/fd1 if it weren't for two simple issues.
- It didn't work correctly
- Xenix and read-only root filesystems really hate each other
As far as I can tell, having a read-only root filesystem is a hack that essentially is in place for two things; checking the file system and installation. Under Xenix, when / is mounted read-only, write operations succeed, and for a brief moment, you'll see a file in place and can even interact with it for a time and then it vanishes. Hindsight being 20:20, I could have simply forced / to be mounted read-write, but at the time, the thought didn't occur to me.
Needless to say, this caused all amounts of fun. I eventually realized I could simply mount the root partition at /mnt, and create the device nodes I needed at /mnt/dev, and they would stick around. First hurdle passed!
The floppy issue was a bit more difficult to work out. During installation, the scripts read from the /dev/rinstall device. The manifest also listed /dev/rinstall1 file which also generated errors. The manifest listed several variations.
FD48 b666 bin/bin 3 ./dev/fd1 2/5 ./dev/fd148 ./dev/fd148ds9 FD96 b666 bin/bin 1 ./dev/fd196ds9 2/37 FD96 b666 bin/bin 2 ./dev/fd196ds15 2/53 ./dev/fd196 FD96 b666 bin/bin 1 ./dev/fd196ds18 2/61
In practice, the only node that would work correctly was /dev/(r)fd196ds9, which probably means nothing to most people. Broken down, it's a mode selection for fd1 (B:). 96 refers tracks-per-inch, ds for double sided, and 9 for tracks per side. AKA, mode geometry for low/double density 3.5-inch floppies. Having divined the correct setting, tar could now read the disks:
Feeding the disks through tar, and manually executing several of the installation steps gave me a reasonable approximation of what the installed system should look like. Testing many of the utilities confirmed my original suspicion that the vast majority of the data was intact. Furthermore, I managed to extract /usr/bin/chroot from the Extended Utilities disk.
To make a long story short, I successfully extracted all the base installation disks, and began to work out the necessary steps to boot from the root file system. The system was extremely unstable in this state, with several utilities causing immediate kernel panics on launch (most annoying, vi did this, forcing me to use ed for almost all file editing). After several attempts, using N1 as a boot floppy, and pointing the root argument to the HD, I got very close to a successful boot.
The important line to see here is *** cron started ***, which is one of the final steps listed in /etc/rc before bringing up the login prompt, and a very optimistic step at eventually getting this all working. At this point, I had also learned the existence of the /tmp/init.* files, special shell scripts run during installation. Through these, I managed to learn of the setperms command, which reads the master manifest files on N1 and other disks, and does final tweaking and configuration. I also learned that I needed to do a brand operation on /etc/getty to decrypt the file, and install a serial number in it. With chroot in hand, and fingers crossed, I ran setperms with each manifest, rebooted, and ...
30 Years of Copy Protection
Well isn't that an interesting problem? That's the type of message you'd expect if someone detonated a fork bomb on your system.
Another examination of the installation scripts revealed the problem. During installation, three files are personalized with the "brand" utility. In the case of /etc/getty and /usr/sys/lib/libmdep.a, these files are decrypted with a secret derived from the serial number, and activation key. It would also foreshadow the issues we ran into once we began trying to restore the media to near-mint condition. The brand utility is also used to write those values into the kernel binary image.
As I found out as part of debugging, Xenix has unique behavior in handling the validation of serial numbers depending on how it's started. By its nature of being essential boot code, the kernel, by definition, can not be encrypted. As such, the kernel has a runtime check to make sure it has correct information. When started from the hard drive, the kernel reports "Invalid Serial Number" if it gets a mismatched set of keys and subtly degrades behavior.
However, in my case, my frankensteined system was loading its kernel from the the floppy drive. In this case, Xenix suppresses the serial check and prevents the message from displaying, but doesn't prevent the tripwire from being activated.
The tripwire in question is drastically lowering the number of processes that can be run. As it turns out, the limit is reached when the system is brought up in multiuser mode. As I found out (much) later, this behavior is actually documented as a footnote in one of the Xenix 286 manuals. As such, I copied the kernel from N1 to the hard drive, personalized it with brand, and after a reboot ....
Victory.
With some more fiddling, I was able to run most of the post installation scripts, and even load the package manager, though it had some corruption issues.
Swiss-Cheese
Right about this time, Michal got back to me, and found that the reason the system hangs after reboot; N2 was missing two sectors in /bin/init. I was somewhat in disbelief, so I pulled out dosformat, made a DOS compatible disk, and copied out /etc/init from the booted system.
Sure enough ...
Ugh. So my frankensteined system was booting with half of its init binary missing. Awesome. At this point though, I had noticed something interesting on the international supplement, specifically, a /etc/init8 binary, one that had the same file size as the file on N2. When I compared them side by side...
Well isn't that interesting! A comparison of file-sizes show they're identical length, with similar (though not identical) modification dates. As far as I can tell, the only modification appears to be the time-stamp further in the binary. On a hunch, I compared the tail ends of the missing sectors, and they matched. So I simply copied the missing blocks from init8 to init, and then started a fresh new VM. After feeding floppies, this time, instead of the dreaded Z, I got something new.
It would die shortly afterwards, but now I was on a mission to try and see if I could restore the media to working state. I already proved to myself that enough data existed to at least make a restoration attempt viable. However, to rebuild the media, I needed to characterize the existing damage and find a way to rebuild or replace the missing sectors.
Next time, we dig into the world of teledisk, data reconstruction, and our first steps towards restoring the media.
~ NCommander
Related Stories
This is the third exciting installment of this ongoing saga of restoring Xenix 2.2.3c. When we last left off, we had discovered that it is possible for Xenix to boot with several sectors missing in /etc/init and that the vast majority of the data on the diskettes was intact — to the point that several more steps of the early installation completed.
The story thus far:
- Part 1: Introducing Xenix 2.2.3c
- Part 2: No Tools, No Problem
[Aside: Quite a while ago, I came across the excellent OS/2 Museum, run by Michal Necasek which helps categorize many of the more obscure bits of PC history, including a series of articles about Xenix, Microsoft’s version of SVR2 UNIX.]
If we were to get any further, Michal and I would have to dig deep into the world of teledisk, floppy disk formats, and perform some creative thinking.
Last time — with the help of the excellent Michal Necasek of the OS/2 Museum — we talked about mapping the damage within the existing Xenix 386 disks and successfully got the system to the end of installation.
For those new to the series, I recommend you catch up with the previous three articles:
- Restoring Xenix 386 2.2.3c, Part 1
- Xenix 2.2.3c Restoration: No Tools, No Problem (Part 2)
- Xenix 2.2.3c Restoration: Damage Mapping (Part 3)
Unfortunately, at this point we had exhausted the data we could successfully recover from the TeleDisk images, so now it was time to think laterally in our quest to restore viable installation media. Back in Part 2, I posted the disk headers from each disk indicating what it was and where it was in the set:
./tmp/_lbl/prd=xos/typ=386AT/rel=2.2.3c/vol=N03 ./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=B02 ./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=X01
And also noted that there was a slight version mismatch (2.2.3 vs 2.2.2). What I didn’t point out was the type was different: n86, vs 386AT; Xenix speak for “generic x86” vs. “386 AT”. As Michal and I discussed it, I realized there was another place we could go to find sectors.
(Score: 5, Insightful) by Unixnut on Wednesday March 08 2017, @04:40PM
Shame we can't upvote articles themselves, so I will just comment here and say thank you for the interesting trip through history. Looking forward to the next chapter :-)
(Score: 2) by jmorris on Wednesday March 08 2017, @04:47PM (3 children)
Wonder if Microsoft / SCO / Novell / Whoever owns it this week could be convinced to allow distribution and tinkering. It would be fun to be able to play with it. Would be interesting to see what would happen if work could be done to it, like say add in driver support for virtio. Somehow I suspect that on modern (even if virtual) hardware it would run pretty darned fast.
(Score: 3, Informative) by NCommander on Wednesday March 08 2017, @05:16PM (2 children)
It would be possible, the kernel is shipped as a set of object modules, and documentation exists on how to write and add new device drivers plus the linker used by this unique version of Xenix is present. I've worked with virtio professionally, and am somewhat familiar with it, though if I was to actually write that type of driver, I'd probably do it on the newer Xenix 386 2.3 release vs this one.
Ancient UNIXs have a serious bailywick of pain regarding redistribution since while the code was (eventually) open sourced, the agreements between AT&T, Microsoft and SCO would define different terms; I remember back in the OpenSolaris days that there were a few articles discussing the amount of legal work that went into open sourcing the vast majority of the SVR4 components in Solaris.
Still always moving
(Score: 2) by butthurt on Thursday March 09 2017, @08:29AM (1 child)
> [...] the code was (eventually) open sourced [...]
System V R4:
The unification of BSD, SunOS, and SVR3, SVR4 combined all the base UNIX systems in common use at the time. Included is compatibility with System V R3 (obviously), 4.3BSD, and Microsoft's Xenix. Source code is for i386 version.
-- https://archive.org/details/ATTUNIXSystemVRelease4Version2 [archive.org]
(Score: 3, Interesting) by NCommander on Thursday March 09 2017, @08:47AM
I checked some of the indexes on this, and I think this is leaked or otherwise not-intended-for redistribution code; due to reasons of taint, I didn't dig deeply into this. The SVR code was redistributed quite wildly, but OpenSolaris is the only SVR4 code base that actually got legitimately open sourced.
When I said Ancient UNIX, I was referring to the V7 releases and a few of the other early ones that were open sourced by Caledra. That act liberated the early BSD code, but the SysV stuff was basically what became commerical UNIX, and until OpenSolaris hadn't seen public distribution.
Still always moving
(Score: 2) by fishybell on Wednesday March 08 2017, @05:09PM (1 child)
I look forward to the point where the "games" disk is ran. This continues to be fantastic.
(Score: 2) by NCommander on Wednesday March 08 2017, @06:04PM
Amusingly, the Xenix manual lists the games disk as for your entertainment only, and that SCO provides no support for it.
Here's the file listing, let the nostalgia take you over.
Still always moving
(Score: 1) by marknmel on Wednesday March 08 2017, @05:41PM (1 child)
Not sure it helps - I have a box set (in unknown condition) of 2.3.4h with the Games floppy (and of course no license) - 3.5HD floppies.
Let me know if it can help out in anyway...
There is nothing that can't be solved with one more layer of indirection.
(Score: 2) by NCommander on Wednesday March 08 2017, @05:52PM
As far as I can tell, that version hasn't made it into preservation. It would be very good to get those scanned and archived. What I'm planning to with these images is send them to the Internet Archive both in unrestored and restored state, in the hope that if/when copyright law becomes more sane, or if it naturally expires 60 years from now (and I'm either very old, or dead), it will survive for future generations. I can get you in contact with people with the equipment to archive and generate images even if the media has gone a bit by now.
If you could screenshots and images of the disks though, I'd be curious what was in the box. If you have the International Supplement, I'd be very interested to see a copy of those disks as it would help me confirm my reconstruction on that. As far as official products, there was a development kit, and a text processing system, plus any SLSs SCO released.
As far as we can tell, Xenix's serial numbers are not super secure and there is some overlap over products; any Xenix 386 key should successfully allow installation and branding.
I do plan to publish the full methodology and work I did to restore these so if someone else wants to copy my work, and a delta with the manually restored sectors.
Still always moving
(Score: 2) by Entropy on Wednesday March 08 2017, @05:50PM (9 children)
As I recall Xenix came in a cube box about > 2 feet x >2 feet. The thing was HUGE with manuals, floppies, and such. I don't remember how it took up all that room but it sure did.
(Score: 2) by NCommander on Wednesday March 08 2017, @05:55PM (8 children)
Reminds me of the boxed set of OS/2 2.1 I had back in the day. 29 floppies + drivers, and enough books that it could flatten a small housepet if it fell on them.
Still always moving
(Score: 0) by Anonymous Coward on Wednesday March 08 2017, @08:25PM (1 child)
Corruption happened a couple of disks in back in the 90s so I never got around to reinstalling it (Plus 2.1 didn't come with network drivers or CD-ROM support, which made Win 3.1 far more desirable since I had access to network drivers AND both IPX and TCP/IP protocol support on it.)
A number of years later I even managed to pick up a copy of OS/2 Warp for some bargain basement price. I actually got it running in qemu a few years back, but it didn't have the same feel or nostalgia as 2.1 for me (My dad had used 1.3 then 2.0 as his main OS at work for a number of years, so we got 2.1 expecting more of the same. It turned out to be a mixed bag compared to what he used, and was a PITA to buy, since the shady local computer store first sold us a copy of 5 and 1/4 disks, then two boxes of bad 3.5" floppies before we got a good set. Given that we only had one hard disk at the time, it was a huge pain in the ass backing up important stuff to floppies to replace dos/windows with OS/2, then getting through 15-20 disks only to have it fail on one file and require you to start over from the beginning. Given that the same issue happened on that last set of disks the next time I tried to reinstall it looked like it might've been manufacturing defects on their mass production disks, or simply too much dust in the air where we lived.)
Having said that, it was an exciting time to be into computers, between the dozens of well stocked small computer shops in the area, to the variety of software and uniqueness in each versions. The DRM, while often a pain in the ass, was still far less invasive on average than the DRM of today, although it was just as likely to hamstring you at the most inconvenient of times.
(Score: 1) by yuhong on Thursday March 09 2017, @09:32PM
The OS/2 2.0 fiasco is so bad it is one of my favorite topics BTW.
(Score: 3, Interesting) by NotSanguine on Thursday March 09 2017, @02:46AM (5 children)
The bit about the manuals reminded me of this gem.
Most will find it quaint, but the bit about the VMS docs is (well, was) spot on:
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Interesting) by NCommander on Thursday March 09 2017, @06:13AM (4 children)
Honestly, given the era, that's actually pretty damn accurate. UNIX itself has a lot of pitfalls which becomes very evident when you run software of the era; flakey filesystems, networking issues with NFS, lack of finegranded controls, etc. If large multiuser systems with thin clients/dumb clients was still common place, VMS would likely still be considerably more relevant in our lives.
When dealing with true multiuser systems such as minicomputers of the time, VMS would essentially run circles around UNIXes of the era, since it had superior support for batch processing, a much more robust filesystem complete with versioning, and better development tools. Support for Ada, Fortran, PL/1, and a few others. OpenVMS eventually fell to the wayside due to being tied to the VAX platform and the AXP port came kinda late, followed by I64 port. If there was an Intel compatible port in the late 80s/early 90s VMS would be less likely to be heading towards a footnote in history. I actually have Itanium hardware here so if I can get a hobbyist PAK, I could do a series of articles on VMS.
Still always moving
(Score: 3, Informative) by NotSanguine on Thursday March 09 2017, @07:25AM (3 children)
onestly, given the era, that's actually pretty damn accurate. UNIX itself has a lot of pitfalls which becomes very evident when you run software of the era; flakey filesystems, networking issues with NFS, lack of finegranded controls, etc. If large multiuser systems with thin clients/dumb clients was still common place, VMS would likely still be considerably more relevant in our lives.
When dealing with true multiuser systems such as minicomputers of the time, VMS would essentially run circles around UNIXes of the era, since it had superior support for batch processing, a much more robust filesystem complete with versioning, and better development tools. Support for Ada, Fortran, PL/1, and a few others. OpenVMS eventually fell to the wayside due to being tied to the VAX platform and the AXP port came kinda late, followed by I64 port. If there was an Intel compatible port in the late 80s/early 90s VMS would be less likely to be heading towards a footnote in history. I actually have Itanium hardware here so if I can get a hobbyist PAK, I could do a series of articles on VMS.
You're absolutely right. I remember. Robust filesystems (the file versioning was, IMHO, better than anything I see even today in a basic filesystem), strong networking support (LAT/DECNet and TCP/IP), excellent SMP and clustering support, and a sophisticated security model. DCL was kind of clunky, but it made sense and was internally consistent. All in all, the PDP (RSX) and VAX (VMS) product lines were pretty darn good.
What's more, the DEC Fortran IV and F77 compilers were good. Really good. Better than just about any others.
DEC also had a really amazing service and support infrastructure (and it cost a pretty penny too!).
The "quaint" comment was for those who don't remember anything before, say, 1985. I cut my teeth on DEC systems (ah, the joys of RSX11m and VMS 4.7!) and was amazed at the newfangled PCs with 5.25" hard drives that stored 40MB (MFM) or 80MB (RLL) after installing 300MB drives that were about 2mX1.25mX1m and weighed 60Kg.
The DEC documentation was both voluminous and dense. Olsen wasn't kidding about it being "all there."
I do get a kick out of that quote, given where things went with both Unix (thanks to Sun, SGI, IBM and SCO), OS/2, Windows NT and eventually Linux.
Within ten years of that quote, DEC was on its way out even though they still had a huge installed base. The final ignominy was the sale to Compaq in 1998.
As for surviving with an Intel port, I'm not so sure about that. The thing about DEC was its vertical integration. And even with DECStations, their stuff was always going to be priced out of the commodity PC market, especially once ISA/EISA mobos were being mass produced in Asia.
A series like this on VMS would be pretty cool.
I almost wish I hadn't thrown away my old SPARCStations, I could do a series on SunOS 4. That would have been fun, although I have been playing around with Illumos/OpenIndiana [wikipedia.org] of late, but that's based on Solaris (SVr4) not BSD 4.2.
As an aside, If Novell had ported NCP/IPX to Unix, rather than relying on their bare metal/X86 assembler code base, they might have survived and even thrived. DEC failed to stay relevant too, although that was more of a corporate structure/business model issue than a platform issue, IMHO.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Interesting) by NCommander on Thursday March 09 2017, @08:19AM (2 children)
Well, Novell actually did do pretty much what you described; expect they did it with OS/2: http://www.os2museum.com/wp/netware-for-os2/. [os2museum.com] I've always been tempted to do *something* with NetWare as a retrocomputing project, but its just not that interesting unless I go dig out some token ring, or coax ethernet and go all in well ... *eh*. From what I know about DCL, it makes a heck of a lot more sense if you're familiar with mainframe systems of the era since as far as I know, it's essentially a mini-computer variant of JCL. The syntax is wonky only if you're expecting UNIX or DOS semantics, but isn't horrid after you get past that initial learning curve. At least if I do OpenVMS, I can talk about DECNet, and maybe even setup the old PATHWORKS stuff on Windows 3.1 to talk to a DEC system.
I'm not convinced that a port to Linux or a UNIX based platform would have saved NetWare, a dedicated "network" operating system made a lot less sense in a era where pre-emptive multitasking was a thing, and a server could do more than one dedicated operation. IPX was difficult to route in networks that needed to also talk to TCP/IP since you needed switches that could handle both protocols if you did any layer 3 routing, and that PDC and later AD basically did everything NDS did, and could do them both with NetBIOS or over TCP/IP which drastically simplified pain. AppleTalk was the only real survivor of the LAN battles, and that was mostly up until Mac OS X, talking to CIFS file shares was a nightmare out of the box; it was usually far easier to install AppleTalk for Windows 2000 then get classic Mac OS to play ball with Windows file sharing in a domain situation.
On VMS, it should have taken over the niche currently held onto by IBM pSeries and some of the higher end AIX stuff, and competed well on multi-user shared VPSes in the era before virtualization. If it wasn't for the fact that Itanium hardware is both hideously expensive, and has horrid performance on most generic workloads, I would have probably recommended a VMS solution even in this day to some customers where it was very well suited for (high reliability/availability requirements, combined with extremely "robust" documentation). The current x86_64 platform port of OpenVMS though might put some life back into the system and I might re-evaluate as a choice for folks where standard Linux/*NIX isn't a great fit.
Unfortunately, DEC went bust, Compaq gutted the corpse, and killed it, Alpha, and Tru64 when it jumped into bed with Intel on the Itantic. Then the POWER house of cards collapsed, and essentially killed any real competition to Intel in almost every market expect the low end, and the very high end.
Still always moving
(Score: 2) by NotSanguine on Friday March 10 2017, @12:20AM (1 child)
I didn't say DCL's syntax was *wonky*, I said DCL was *clunky*. As is JCL. In fact, I pointed out that it was internally consistent and quite powerful. Much more so than just about anything else at the time. Even now it stands up pretty well.
I think you misunderstood my point of view. I can certainly see applications for VMS today, and it provided (and still does, in some places) quite a lot of value.
Initially, I just wanted to share what is, now, an amusing anecdote from the era of Xenix, not shit on DEC or VMS.
DEC tried (with Ultrix) to get into the p-series/AIX space, but Sun, SGI and even IBM ate their lunch pretty effectively. The standardization and economies of scale for ISA/EISA (and then PCI) killed those guys too. Intel was helped along by players like Apple (moving to the x86 platform) and Microsoft (dropping support for alternative architectures).
I kind of wish there was a more varied ecosystem for microprocessors. I think we'd get a lot more innovation that way.
I'd forgotten about Netware for OS/2. Given what happened to OS/2, it probably wouldn't have made much of a difference. My thought WRT porting NCP/IPX to Unix had more to do with creating an environment where development could be done on the same platform as production. With the implication that Novell moved to a model which didn't require NLMs, and used standard IPC and sockets to integrate functionality -- making NCP (which could have run on top of IP too) a much better competitor to (Blecch!) LANMAN.
IIRC, in the early to mid 90s, most routers had both IP and IPX support standard, so I don't think that would have been much of an issue.
I'd also point out that if it weren't for Phil Karn (KA9Q), Russell Nelson and the PC/TCP packet driver spec, Microsoft might still be using NetBIOS/NetBeui.
Actually, implementing KA9Q would be a great retro project. I haven't messed with it since 1991, but I think I'll download it and see what I can do.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by NCommander on Friday March 10 2017, @02:20AM
If I ever upgrade my ham ticket to General class, I fully intend to do AX.25 (which KA9Q also supported) over HF, and then port UUCP to work over that type of link for downloading USENET groups over ham, would be nice if I'm backpacking in Africa and have a portable rig I could use to always get connectivity. I used a fairly ghetto UUCP setup to download mail when I lived in China because the worksite, and if I did it now, I'd probably also setup netnews and download a fair bit of GMANE RSS feeds and possibly a group or two, though a lot of USENET seems dead these days; I dusted off my eternal-september account but I can't find any groups that have a pulse.
Still always moving
(Score: 2) by SomeGuy on Wednesday March 08 2017, @05:55PM (1 child)
Eagerly awaiting to hear more. Took a quick look at those Teledisk images for myself, and wow there are a bunch of missing sectors.
Oddly most of the errors on each disk are in about the same place (~track 30 and ~track 60) which makes me think whoever dumped these may have had a serious problem with their floppy drive.
Unfortunately, that is one of the big problems with archiving random floppy disks. There is no way to be absolutely sure the disk copied properly unless one can run and throughly test the software from the copies.
Many copy protected disks will look like they read and copied perfectly until the software fails its protection check. And on the flip side, many obscure disks may have odd formats that may look like errors, but are actually fine.
(Score: 2) by NCommander on Wednesday March 08 2017, @06:02PM
Having gotten the system mostly working, I can confirm for a fact that Xenix uses standard 9 track alignment for DS media, and it was a bad read. The first two disks use the standard filesystem (the missing sectors at the start of N1/N2 is just unused or not present boot sectors), while the rest are linear tarballs. Furthermore, as far as I can tell /dev/rinstall doesn't do anything special w.r.t track read/writing though without having original media to confirm it, I can't say for sure there wasn't something in place on the original disks and its impossible to know for sure what exactly went wrong, but given its pretty much the same error on each disk ...
This will come up in the next article, but the damage isn't quite as bad as it looks, partially due to luck, and partially because I found a way to replace most of the missing sectors with valid data :)
Still always moving
(Score: 2) by DeathMonkey on Wednesday March 08 2017, @06:29PM (5 children)
How do you insert pictures into a submission?
(Score: 2) by NCommander on Wednesday March 08 2017, @06:46PM (4 children)
Simply put the link in the submission with a remark its supposed to be an inline image. That being said, we'll probably only put content up that's either public domain or the copyright holder gives his permission.
Still always moving
(Score: 2) by takyon on Wednesday March 08 2017, @06:55PM (3 children)
I was sure that our standards for inline images were even stricter than that and that images will only appear in the most unusual circumstances... such as your original content. They will also likely be tiny file size PNG images.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 2) by NCommander on Wednesday March 08 2017, @06:58PM (2 children)
We don't have a formal policy on it. Might be worth popping a meta article on it for submissions. I'm OK with it either way TBH.
Still always moving
(Score: 2) by DeathMonkey on Wednesday March 08 2017, @07:14PM (1 child)
I was thinking for original content.
I am in the middle of a 3d printer build and have been taking pictures...
(Score: 2) by NCommander on Wednesday March 08 2017, @07:41PM
I would have no problem with this, though I'd like to get written permission as part of your writeup and such to rehost the images so we don't have to hotlink to a third-party domain. Drop by in #editoral in IRC and we can discuss the specifics.
Still always moving
(Score: 5, Interesting) by goodie on Wednesday March 08 2017, @06:58PM
I care not about Xenix but I love the adventure! Can't wait to read more. Seriously, this is exactly the type of thing that I think makes for great SN content "beyond" news items (which are very valuable).
(Score: 2) by drussell on Wednesday March 08 2017, @10:27PM (2 children)
That reminds me....
SOMEWHERE around here I have a program which, of course, I cannot even recall the name of, which did an amazing job of recovering floppy disks by repeatedly reading any unreadable sectors in some raw mode on the WDC floppy controllers where it could see the ECC data as it went along and manage to recover the missing bits and re-assemble entire unreadable sectors. It only worked on some of the older, real, true, discrete WDC chips, not most of the later clone floppy controllers but I have plenty of old controllers around on old MFM/RLL cards, etc.
Does anyone recall what it might have been called or, better yet, a copy of the thing?
I seem to recall that it was something simple like "fdrestor," "fdrecovr" or somesuch. I think it had a blue background on the text when you ran it, and no I am not thinking of the later versions of SpinRite that had some floppy disk features in it. This was a simple, standalone utility and it worked INCREDIBLY well.
I have hundreds of (mostly 5.25", some 3.5" and a few 8" 256b sectored) floppies to archive at some point and I would dearly love to have that utility available to help do it since many of those disks are getting very, very weak but I can't even remember what the name of the dang thing was... :(
(Score: 2) by NCommander on Wednesday March 08 2017, @10:46PM
There are special USB hardware devices such as Kyroflux that let you plug in almost any floppy drive, and recover data in a lot for formats including non-PC stuff. LGR's Clint did an amazing review on this product: https://www.youtube.com/watch?v=CqLv8d-W-9c [youtube.com]
Programs that work via a FDC directly are sometimes limited by the controller as it can't control the drive's stepping/motor/etc. I may have some contacts for getting someone with one of these devices in touch w/ you for data recovery.
Still always moving
(Score: 2) by drussell on Wednesday March 08 2017, @10:50PM
Edit:
I suppose I mean CRC, not ECC... :)
Looking at the WD chip programming docs, I'm sure it was the "Read Track" command that it used somehow. It would sit there and read and read and read with differing offsets from any detected index pulse (or address mark or something) in some way until it somehow managed to compute the original data, reformat the track and write the whole thing back out properly. (!!!)
It was obviously written by someone who knew those floppy disk controllers one heck of a lot better than I ever did. :)
Upon receipt of the Read Track Command, the head is loaded and the Busy Status bit is set. Reading starts with the leading edge of the first encountered index pulse and continues until the next index pulse. All Gap, Header, and data bytes are assembled and transferred to the data register and DRQ's are generated for each byte. The accumulation of bytes is synchronized to each Address Mark encountered. An interrupt is generated at the completion of the command.
This command has several characteristics which make it suitable for diagnostic purposes. They are: no CRC checking is performed; gap information is included in the data stream; and the Address Mark Detector is on for the duration of the command. Because the AM detector is always on, write-splices or noise may cause the chip to look for an AM.
(Score: 2) by turgid on Wednesday March 08 2017, @10:48PM (2 children)
I'm continuing to be impressed by the quality of the stories here but I don't have much free time these days to comment.
I'm not keen on the recent modification that makes comments pale after you've read them. The low contrast is uncomfortable.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Informative) by drussell on Wednesday March 08 2017, @11:14PM (1 child)
I'm not keen on the recent modification that makes comments pale after you've read them. The low contrast is uncomfortable.
See "Dim Read Comments" on your https://soylentnews.org/my/comments [soylentnews.org] page.
(Score: 2) by turgid on Thursday March 09 2017, @07:57AM
Thanks
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Marand on Thursday March 09 2017, @05:42AM (1 child)
several utilities causing immediate kernel panics on launch (most annoying, vi did this, forcing me to use ed for almost all file editing)
See, this is why ed is the standard text editor. [gnu.org]
(Fun articles, by the way.)
(Score: 2) by NCommander on Thursday March 09 2017, @06:05AM
I think the best part is that directly references Xenix at the top:
Still always moving
(Score: 0) by Anonymous Coward on Monday March 13 2017, @11:19AM (1 child)
Is there a deeper reason why this is in Meta? I thought that section is only for stuff about the site and its software (topics "soylent news" and "rehash"). I was visiting Meta to find the latest of those, and was quite disturbed to find this story there.
(Score: 2) by martyb on Monday March 13 2017, @07:02PM
I cannot think of a good reason for this article to be in meta — thank-you for commenting in part 3 of this story series to bring my attention to this comment.
I concur with your assessment that this series does NOT belong in the "Meta" Nexus (aka Section). Will change, may take a few minutes for things to percolate through the site cache.
Thank you!
Wit is intellect, dancing.