I first read "Alice in UNIX Land" (by Lincoln Spector, Texas Computer Currents, Sept. 1989), probably around the time when it was written — and at that time didn't understand very many of the jokes. Having gradually gained some experience (or at least age) I think I get nearly all of it now except this one passage:

"But then again," suggested the Woodpecker, "what about the shrinkwrap issue?"

Suddenly, everyone leaped up and started dashing about, waving their hands in the air and screaming. Just as suddenly, they all sat down again.

"Now that that's settled," said the Woodpecker, "let's go back to tasting flavors."

In context I get that the jokes are mostly about evaluating the various types ("flavors") of Unix and other operating systems at the time, generally to point out some sort of weakness. Apparently "the shrinkwrap issue" causes all the characters a lot of stress, so much so they just move on to the next topic without settling anything despite stating the contrary.

"Shrinkwrap" sounds like it refers to selling boxed software in a store. But at the time I thought commercial Unix was almost exclusively sold in conjunction with hardware generally from the same manufacturer (*). So I don't see how that would apply.

Were there Unix vendors trying to sell directly to the PC market at the time?

Or if not, what's the joke?

(* Maybe that was not true for something like BSD, but I didn't think BSD was sold on shelves anyway).

  • Microsoft and SCO were selling Xenix & Unix for PC's in the 1980s.
    – Brian H
    Commented Feb 7, 2021 at 16:34
  • 2
    Not sure enough to make it an answer, but I'd guess it's about UNIX application software, i.e. the impossibility to produce e.g. a shrink-wrapped word processor for UNIX, covering more than one UNIX flavor. Commented Feb 7, 2021 at 16:46
  • 2
    @RalfKleberhoff That would align with the complaint about how inconsistent the APIs are on page 12 of The UNIX-HATERS Handbook.
    – ssokolow
    Commented Feb 7, 2021 at 17:02
  • 1
    The whole document deserves a write-up detailing all the inside jokes, before their knowledge is lost in the shadows of time (although, some could argue it would be better to forget about that...)
    – Ángel
    Commented Feb 8, 2021 at 2:47
  • 1
    @Ángel I suppose you (or anyone I mean) could post both Q&A here simultaneously, for some of the the various jokes or underlying themes. That could actually be useful because we may not all have the same understanding of what the joke actually was! Commented Feb 8, 2021 at 17:23

1 Answer 1


The shrinkwrap issue was a vicious circle perceived by the computer industry in the late 1980s to early 1990s. In essence:

  1. With many different processors and binary formats, it was difficult for a commercial “killer app” to gain enough market share to bring users to Unix;

  2. Without the strong commercial user and software base, there was little incentive to develop software that would have become a huge commercial success.

Since commercial software of the era was sold on physical media, boxed and shrinkwrapped, this issue was seen as preventing the sale of Unix software in volume.

A fair summary is given in this case study from 1992: Operating RISC: Unix Standards in the 1990s. It includes discussion of two of the groups attempting to unify Unix, X/Open and Unix International. They eventually merged in 1996.

The rise of the 386 and 486 processors gave hope of a common application binary interface (ABI) that would have allowed the one compiled program to run on many platforms. SPARC, MIPS, PA-RISC and DEC Alpha were all contenders in the non-Intel workstation side. None of these initiatives foresaw the unexpected rise of Linux.

If you hadn't experienced it, the sheer number of API variants that passed as Unix-like systems before the rise of Linux was utterly bewildering. Look at all the options that mature packages like Kermit, Perl or Autoconf have to consider to support compilation, and you'll have just a glimpse of how ugly and complex maintaining a commercial Unix package used to be.

In a way, the shrinkwrap issue lives on in the very tired old question of “Is ____ the Year of Linux on the Desktop?” Shrinkwrap as a concept in software disappeared with fast internet for software distribution and the uptake of mobile devices.

  • 13
    I worked for a small software company in the mid 80’s, which had a commercial accounting software package for Unix. You could try to make your source portable, but every manufacturer’s Unix had its quirks. There generally were not backends to make binaries for other systems - you needed access to each different system. I would do some ports on customer systems. Others, I’d dial in (no Internet) to manufacturer’s systems and port. All a real PITA to keep all ports up to date with versions.
    – mannaggia
    Commented Feb 8, 2021 at 2:20
  • 6
    @nanoman: easier said than done. For a while in the mid 90s, a part of my job was to make certain packages compile in different Unix machines (Linux, Apollo, SGI, and a couple more). These packages were already conceived to be multi-platform, as I could see from the many options in their makefiles. Still, it would take me hours of tinkering with the makefiles to get the package to compile. Commented Feb 8, 2021 at 13:39
  • 5
    @MartinArgerami Anyone not fully appreciating this should spend some time on understanding why configure scripts exist and the "what hammer do we even have?" situation causing them. Commented Feb 8, 2021 at 14:45
  • 8
    @NotThatGuy: The way that consumer software used to be sold was on physical medium (floppy disks and later CD-ROMs) in a cardboard box, shrink-wrapped in clear polymer plastic. That's how you got games, office software, etc. for DOS, Windows, Amiga, Atari, etc. But there never was a similar industry for Unix, because you would have to produce a very large number of versions for every combination of CPU and OS, with only a very small number of users for each combination. Commented Feb 8, 2021 at 20:58
  • 6
    @nanoman, "portable source"? I've got the source code to a cross-platform compatibility library from that era. It contains, among other things, a near-complete re-implementation of the C standard library, because every platform's implementation of the standard library had some decidedly non-standard quirks.
    – Mark
    Commented Feb 9, 2021 at 3:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .