Some time ago, I thought it would be useful to understand exactly what is the difference between CD-ROMs recorded in the old High Sierra format versus the ISO 9660 standard. This was in part spurred by the fact that I have a number of CD-ROMs/images that use the High Sierra format (Microsoft Programmer’s Library, some IBM Developer Connection issues, OS/2 Warp 4, and more) that both macOS and Windows 10 refuse to mount. The other part of my motivation was the usual insatiable curiosity.
Finding the actual text of the High Sierra Working Paper (also High Sierra Proposal, i.e. proposed standard) turned out to be rather unexpectedly difficult. I found a number of articles talking about the High Sierra Proposal (HSP) but not the actual HSP text.
The closest thing I could find was an article in the excellent PC Tech Journal in the July 1987 issue (Patterning CD-ROM by Peter Jansson, page 163). Said article recaps the HSP in very good detail but it’s not the actual text. But even that was enough to show that although the structure defined in the High Sierra format is not far from the ISO 9660 standard, the two data structures are just different enough to be mutually incompatible.
Even though the High Sierra Proposal is long obsolete, and it never even was an official standard, it was the de facto standard from mid-1986 until ISO 9660 was approved. In addition, it wasn’t about until July 1988 that MSCDEX 2.0 with ISO 9660 support started shipping, which means that until then CD-ROMs in ISO 9660 format would have been unusable in practice.
It was even worse than that. MSCDEX shipped with CD-ROM drives, and existing CD-ROM drive owners had MSCDEX 1.x which only supported the High Sierra format (HSF). MSCDEX 2.0 was not a free upgrade, which is why until about 1990, CD-ROMs in ISO 9660 format were exceedingly rare.
The same problem was presumably present on the mastering side: Existing CD-ROM publishers had software which supported only the High Sierra format and since it worked just fine, they weren’t motivated to spend money (probably quite a lot of it) on upgrades. Since ISO 9660 isn’t really any more capable than the original HSF, publishers had very little incentive to use ISO 9660 and a lot of good reasons to stick with HSF.
As a case in point, Microsoft’s C 6.0 (May 1990) or Programmer’s Library 1.4 (June 1991) CD-ROMs used the High Sierra format, not ISO 9660. That in turn meant that CD-ROM file system implementors were forced to support HSF for many years to come, otherwise users would rightfully complain that CD-ROMs that can be read just fine in DOS aren’t recognized. Sometimes CD-ROM publishers used HSF well into the 1990s for no apparent reason (e.g. IBM Warp 4 CD-ROM from 1996), but no one really noticed because everything worked just fine.
The High Sierra Working Paper (the actual title of the proposal) used to be available from NISO (National Information Standards Organization) in the late 1980s, but once ISO 9660 was approved, official standards bodies had no reason to distribute the obsolete proposal.
For the few people who needed the original text, the High Sierra proposal used to be available from Howard Kaikow, but he passed away in 2011.
The full text of the HSP was almost certainly published in the 1986 book CD-ROM Standards: The Book by Julie Schwerin, ISBN 0904933547. The book is long out of print and not available used. I would love to get a copy (it should contain several related articles) but I just can’t find any.
Okay, so there’s no way to get the HSP through the front door. But maybe an alternate route might work? Surely someone must still have the full text.
My research showed that the original HSP editor was Howard Kaikow, which is why he was able to offer copies years later. I contacted his sister Rita but she was unfortunately not able to help me (not for lack of trying).
The next name on my list was Bill Zoellick, former manager of software research at TMS, Inc. and not coincidentally, co-author of a 1987 book titled File Structures: A Conceptual Toolkit. In 1986-1987, he published several articles dealing with the technical details of the High Sierra Proposal. Tracking him down was not entirely easy but after piecing together the evidence from several sources, I concluded that the Bill Zoellick who now teaches marine biology really is the same Bill Zoellick who was involved in the High Sierra Group 35 years ago. I e-mailed him and not much later, I had a freshly scanned copy of the High Sierra Working Paper in my inbox.
The High Sierra Working Paper
I ran the scan through OCR, which as a side effect did a good job of straightening the text (the text of the original was impressively askew on many pages). The document is now available here, and as far as I know, not available anywhere else.
After actually looking over the HSP, it became clear that it really was a draft of ISO 9660. The two texts are rather similar, with many sentences and paragraphs entirely identical, and many others with just minor editorial differences. The true technical differences between the HSP and ISO 9660 are not many, but one is that the descriptor signature changed from ‘CDROM’ to ‘CD001’ and the general descriptor layout changed just enough that everything is at a different offset.
The upshot is that even though software supporting HSP can be easily adapted to support ISO 9660 and vice versa, since the overall structure is quite similar, it does require a couple of small but key changes. That’s exactly why software which only supports ISO 9660 (like the CD-ROM image mounting software in Windows or macOS) has no chance of reading High Sierra images (it is difficult to call them ISOs).
More or less for the heck of it, but also in order to get a plain-text-ish version of the document for easier comparisons and for easy navigation within the document, I also produced a HTML version of the High Sierra Working Paper. It looks somewhat like the original, but it’s deliberately not using any CSS, which means that it can be almost perfectly displayed by antique browsers, like this Netscape Communicator 4.61 in OS/2 Warp 4 Convenience Pack 2.
I’ve not been able to find how the original High Sierra Working Paper was produced, i.e. what word processing/document processing software was used. I am fairly certain that the serif font used for the body of the text is Palatino… which only narrows it down to “printed on a PostScript printer”, i.e. not much at all. I have no idea what kind of software would have been used at Digital Equipment Corporation (where Howard Kaikow worked at the time) for this purpose back in 1986.
I’m now working on a longer article which will deal with the history of the High Sierra Group, examine the rationale behind the HSP, and attempt to track how the High Sierra Working Paper morphed into ISO 9660 via ECMA-119. That will still take some work and it’ll be published when it’s ready.
I suspect the paper was typeset using an early version of VAX DOCUMENT, which DEC began to use to typeset documentation with in the mid-1980s.
IIRC, DOCUMENT mainly consists of a pipeline that transmogrifies DEC’s special SGML dialect (known as SDML) into TeX, from which it can then be output as either PostScript, DECW$BOOK (an online documentation format similar to IBM’s old BookManager), plain text, (or in later versions) HTML.
The earliest example of a DOCUMENT-generated manual I could find was this VAX/VMS 4.0 installation guide from 1984: http://bitsavers.org/pdf/dec/vax/vms/4.0/AA-Y514A-TE_Guide_to_VAX_VMS_4.0_Software_Installation_198409.pdf
The style sheets seem to have changed over the years, as I’m used to seeing DOCUMENT-generated manuals that look more like this: http://www.bitsavers.org/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-5281E-TC_Introduction_to_RT-11_Aug91.pdf
And for those curious, here is the SDML source for the set of manuals that last one came from: ftp://ftp.trailing-edge.com/pub/rt_dists/doc56/archive/rt-11/
(Note the use of EPS illustrations, too…)
BTW, if you’re wondering what HTML output from later versions of DOCUMENT looks like: https://www.hoffmanlabs.com/vmsfaq/vmsfaq.html
Another reason dos 6 was great, disk compression, high memory mapper and CD-ROM extensions v2! What a bargain
I had so many issues mounting that super old Microsoft reference cdrom, yet people say they could mount the image I made no problem
I wonder if some way of ripping it converted the format or maybe it was just physical
It amazes me that some people still hoards stuff that has been technically obsolete for near 40-50 years, and even has an idea of where it is as to be able to quickly locate it to give it away the day than THAT person comes asking for it. Reminds me of the famous scene in Indiana Jones and the Last Crusade where you have a Crusader guardian that waited more than half a millenia for someone to come looking for the Holy Grail.
Is like if these people has been conscious from the start than at some point their stuff was going to become some sort of museum piece…
And I believe that MSCDEX 2.1 introduced support for DOS 4.0, and the lack of adoption of it probably did not help either.
One of the earliest OSes that supported High Sierra out of the box was GS/OS for the Apple IIgs in 1988. Funny to think that the Apple II got native support before most computers of the day. Looking at the source for the High Sierra file system translator, ISO9660 support was added fairly earlier (Feb 1988). Apple Extensions to ISO9660 were also added at regular intervals.
Outside of newer ISO9660 revisions, GS/OS has read every CD I’ve thrown at it. Later ISO revisions usually got weird things like a semi-colon+digit appended to a file name, but usually worked fine.
Normally ripping doesn’t touch the format, although I think I’ve seen ripping programs shoving their signature in the ISO 9660 descriptor or some such nastiness. Microsoft definitely used High Sierra until at least 1991 and a lot of newer software can’t deal with it.
Yes, Apple was active in High Sierra and had very early CD-ROM support. Microsoft was also early, but their support was not exactly out of the box since they decided to go through CD-ROM drive vendors instead.
The semi-colon+digit is DEC style file versioning which normally stays hidden. DEC seems to have most influenced the ISO 9660 format, but Apple and Microsoft both made sure that it’d work well for them too.
Thanks for the tip, this sounds highly plausible. The 1984 document does appear to use the same Palatino font… but 1984 is kind of early for PostScript. Then again DEC appears to have been a very early PostScript supporter so maybe?
Pretty sure The Apple LaserWriter was the first PostScript printer and that came out in 1985. The typefaces included were much older though, so it wouldn’t be unusual to see those fonts being used in other typesetting applications.
The Apple LaserWriter was the first PostScript printer but Adobe had an add-on earlier that made other printers into PostScript printers. The following snippet is from Seybold’s World of Digital Typesetting 1985 supplement:
“Adobe
PostScript software raster image processor in C
(Unix) for 68000 or VAX to drive Xerox XP-
12 or other print engines (1983).”
Note VAX is DEC and DEC had a long history of supplying typesetting systems since the Typeset 8 of 1968.
Just to make sure this doesn’t get lost again, I put a copy up on IA at https://archive.org/details/cdrom-working-paper-1986
Hope that helps someone someday.
Yes. Reviewing the DEC documents that techfury90 pointed out, it sure looks like they used the same font (which I still think is Palatino) as far back as 1984.
The VAX DOCUMENT 1.0 manual from 1987 is clear that at that time, PostScript was supported, but it’s less obvious what exactly DEC used to typeset the earlier documents. Given that DEC was one of the first laser printer vendors (LN-01, LN-03) and that DEC was well aware of what Adobe was doing, it’s possible that they used PostScript in 1984.
But if VAX DOCUMENT and its predecessors used TeX as the typesetting engine, it’s also possible that they had fonts in the METAFONT format before PostScript was much of a thing. That’s just guesswork. There is a TeX DVI converter for the DEC LN-03 printer that was functional in 1985.
DEC had higher-end gear I’m sure, but since the High Sierra proposal was not an official document and would not need wide distribution, I’d think it was most likely printed on an office printer.
The Palatino font goes back to 1949 or so. An old Palatino .PFB file says “Copyright (c) 1985, 1987, 1989, 1990 Adobe Systems Incorporated.”, but also mentions “(c) 1981 Linotype AG”. I don’t know what the 1981 vs. 1985 copyright dates signify.
The DEC LN01 was based on the Xerox XP12 and thus one of the first printers to output Postscript documents. It doesn’t qualify as a Postscript printer since the Postscript board wasn’t internal to the printer.
1985 is when Linotype and Adobe made a cross licensing agreement. Adobe got rights to the fonts and modified the fonts for Postscript. Linotype made future Linotron machines into Postscript printers.
1981 is a bit of a mystery but Linotype did issue a new copyright every time a font was tweaked. In 1981, Linotype introduced the Graphics Subsystem for the Linotron 202. I can’t prove the two events are related. Linotype’s historical font development articles don’t mention anything about 1981 that I can find and the other font history sites take too long to locate information.
This document shows (page 4-1) that the Autologic APS-5 phototypesetter was able to print Palatino in 1983 and this was supported by troff. The APS-5 was introduced in 1980, but I can’t find enough detail to tell if the Palatino font was available straight in 1980s or only later. It sounds like the APS-5 had some kind of loadable font capability, but details are scarce.
I guess the point is that Linotype must have had non-PostScript versions of Palatino, perhaps in 1981. There appear to have been other phototypesetters capable of using Palatino circa 1980.
Bit more information on VAX DOCUMENT: It was later renamed DECdocument (sometime in the early 90s I’d guess based on the manuals I’ve seen) and eventually sold off to Touch Technologies Inc. I don’t think it was ever ported beyond OpenVMS for the Alpha processor.
Website and some documentation for DECdocument is here: http://www.ttinet.com/decdocument.html
Does this cover it:
https://www.ecma-international.org/wp-content/uploads/ECMA-119_1st_edition_december_1986.pdf
From what I can find, the second edition is ISO-9660, so thinkig this might be High Sierra?
Forgot to include the oringinal location of the file:
https://www.ecma-international.org/publications-and-standards/standards/ecma-119/
Thanks. It does look like it only ran on VMS, that’s too bad.
It is not High Sierra. The December 1986 edition of ECMA-119 is a step between High Sierra and ISO 9660, but it is a lot closer to ISO 9660 than to High Sierra. I believe the on-disc structures defined by the Dec ’86 ECMA-119 standard are the same as ISO 9660, but the text of the standard is not identical and there may be subtle differences. For example I noticed that the Dec ’86 edition of ECMA-119 defines the offset from GMT stored in timestamps in units of 30 minutes, whereas ISO 9660 defines the units as 15 minutes.
speaking MSCDEX, I wonder how many versions are produced before 2.0? as it seems to be hard to find either binary or information about them.
There is not a lot of detailed information, and it does not help that the term “MSCDEX” was initially not used at all.
Here’s MSCDEX 1.01 from 1987: https://archive.org/details/hitachi-cdrom-drivers-DOSPC There are quite possibly other old MSCDEX versions preserved alongside hardware specific CD-ROM drivers.
I’m guessing that MSCDEX 1.01 was followed by 2.0 (based on some old programming Q&A document). So most likely there was 1.00, 1.01, then 2.0.
Thanks for this! I was looking at ECMA-119 and it doesn’t make sense to me, so I went looking for earlier documents, found this blog post, and was happily surprised to find that you were able to find a copy.
Glad to hear that the High Sierra text helped.
As a note, I found that ECMA-119 makes a lot more sense when it’s read in the context of its forerunners, ECMA-107 (FAT file system) and ECMA-13 (files on tape cartridges).