Stac Electronics Stacker for OS/2

Once upon a time hard disks were expensive.  A device that could hold a terrabyte would cost hundreds of thousands in the late 1990’s!  I remember Windows NT 3.51 taking 3 days to format 890GB!!!

Even when I got my first 20MB hard disk, it along with the controller cost several hundred dollars.  I had upgraded to a 286 from a Commodore 64, and even a 720kb floppy felt massive!  I figured it’d take a long while to fill 20MB so I was set.  Well needless to say I was so wrong!  Not to mention there was no way I could afford a 30MB disk, I wasn’t looking for a questionable used 10MB disk, and a 40MB disk was just out of the question!

Until I saw this:

Stacker 2.0

Stacker changed everything for me, now via software compression not only could I fit 40+MB worth of crap on my 20MB disk, but I could even get more data on my floppies!  The best part about stacker, unlike pack/zoo/pkzip and friends is that the compression was transparent.  Meaning you load the driver, and pickup a new driver letter for the compressed volume, and from that point onward everything you do to that disk is compressed.  All MS-DOS programs work with it.  Yes really from Windows 3.0, to dbase, BBS packages, even pkzip (although it’ll get a 1:1 compression)

Stacker for OS/2

So for a long while life was good with Stacker although like everything else, things changed.  I wasn’t going to run MS-DOS forever, and when I switched to OS/2 I was saddened to find out that there was no support for OS/2. Also Linux support was not going to happen either.  Although they did eventually bring out a version for OS/2 it did not support HPFS volumes, only FAT.

And as you can see while Warp was the main target it could function with OS/2 2.0 and 2.1 as long as you had updated them to the latest fixpacks.  And preferably installed the OS onto a FAT partition as the setup process hinges on it being able to modify the config.sys & boot directories from a DR-DOS boot floppy included in the package.

One of those funny things about disk compression is that for very heavy disk access programs that tend to compress pretty good (say databases with lots of text records) is that compression can greatly speed them up.  If you are getting 16:1 compression (ie you have LOTS of spaces…) you only have to read the hard disk 1/16th as you would on an uncompressed volume.  It’s still true to this day, although people tend to think disk compression added a significant amount of overhead to your computer (I never noticed) it can make some things faster.

Another thing that STAC was involved in was selling compression coprocessors.

Stac co-processor ad

While I’m not aware of these cards being that big of a seller, It is interesting to note that these co-processors were also available for other platforms namely the cisco router platform.  Since people were using 56kb or less links, the idea of taking STAC’s LZS compression and applying it to the WAN was incredible!  Imagine if you were printing remotely and suddenly if you got even a 4:1 boost in speed, suddenly things are usable!  The best part is that while there were co-processors cisco also supplied the software engine in the IOS.  Enabling it was incredibly easy too:

interface serial0/0


And you were good to go.  The real shame today is that hardly anyone uses serial interfaces so the compression has basically ‘gone away’.  Cisco did not enable it for Ethernet interfaces as those are ‘high speed’… Clearly they didn’t foresee that people would one day get these infuriating slow “high speed” internet connections being handed off on Ethernet and how compressing them would make things all the better.

I think the general thrust has been to a ‘black box’ approach that can cache files in the data stream, provide compression and QoS all in one.

So until I re-install OS/2 on a FAT disk, let’s run this through the Windows 3.0 Synchronet BBS I was playing with.


Stacker starts up with some ascii art of a growing hard disk.  Maybe one day I’ll figure out how to dump Qemu’s video into something to make animated GIFs with.  Until then… well.

Setup is pretty straight forward, pick a disk to compress, then decide if you’ll do the whole disk and incorporate the drive swapping fun, or just do the free space to create a sub volume, and manually manage it.  I’m not in the mood to reconfigure anything so I’ll do what most people did and compress the whole drive.  What is kind of fun to note, is that in modern implementations of compress & encryption you have to select one or the other you cannot do both.  However using emulators that can support encrypted disks, you *could* then compress from within.  I don’t know why the new stuff doesn’t let you, maybe the layered containers gets too much.  But I do bet there is something out there for Windows that’ll mount a file as a disk image (like Windows 7 can mount VHD’s) on an encrypted volume, then turn on compression…….

Anyways with the target selected, it will then copy the files, then create the volume…

Which took a minute, then it’ll defrag the disk using Norton Speed disk (from that point onward it seems that speed disk disappears..?)

And once that is done, we are basically good to go.  So how did it do on my 80MB ‘test’ disk?

I’d have to say pretty good, 2.5:1 is pretty snazzy!  And my BBS is working, I didn’t have to change a single line, it’s 100% transparent.

Eventually IDE hard disks took over the world, and got larger capacities, faster and cheaper.  Not to mention the world was switching operating systems from MS-DOS to Windows 95, or Windows NT and STAC just got out of the market after the big lawsuit.

But it’s funny looking at old disk ads…  And what a catastrophic thing it was to fill the things up.

But before then, we had stacker…

This entry was posted in MS-DOS by neozeed. Bookmark the permalink.

About neozeed

What is there to tell? I've loved UNIX like things since I was first exposed to QNX in highschool (we had the Unisys ICONS!), and spent the better time of my teenage years trying to get my own UNIX... I should have bought Coherent in retrospect.. Anyways latched onto Linux in 1992, and then got some old BSD admin books and have been hooked on the VAX BSD & other big/ancient things since...!

10 thoughts on “Stac Electronics Stacker for OS/2

  1. Yeah, was unfortunate what happened with Stac Electronics, but they don´t had good options… at time they owned the best compression algorithm, i guess that they think something like Microsoft DOS wouldn´t survive without their tech stuff, but they did wrong: Microsoft buy a lot of Vertisoft and they enhanced the acquired tech to integrate them seamlessly with his OS products in the form of DriveSpace (And the related compression algorithm used to compress the VMM32 VXD file in Win4x), and in concept and integration related aspects of FBWF/EWF, VHD Boot Support and ImageX tool… the thing is that Vertisoft is dead and Stac Tech survived in the form of HiFN accelerator cards and now integrated in security chips of Exar:

    Is good thing that we have very good OpenSource compression algoritmhs, that fixes some issues with the old LZS and enhance others aspects, like LZO and LZMA ones


    PD: is your nick Neozeed common in the Internetz? because i found some posts with your nick in some non-tech places around the web 🙂

  2. I think the thing I miss the most is the seamless aspect of it, in the OS… I know windows pretty much has this on NTFS v3 with the compressed folders. But I haven’t seen it on OS X, *BSD, or Linux.. maybe I’m wrong?

    Oh and I’ve used neozeed for ages, but it appears that I’m not the only one who liked the SEGA Genesis, & Shinobi. I’ve seen plenty of others, even back in the 1990’s that had all kinds of other stuff. One of them even collects old video games…

    But no, they are not all me.

  3. No, no other OS features transparent on-disk compression like Stac did with Stacker and Microsoft did with Vertisoft DriveSpace and now with NTFS folder compression…

    We know that with Linux nothing is seamlessly… and yes, Linux can boot from compressed volumes and mount LZO modules with the help of FUSE, but them are read only, and need of things like UNIOFS to be somewhat useful :-/

    The last attempts to build something like Stacker or DriveSpace are, in the UX world, the ZFS and Btrfs on-disk formats, but they are not finished… and in the Windows world with the new Win7 feature to boot from VHD files, and some opensource efforts like this:

    To bring that feature to Windows XP… but they don´t even support compression in their actual state.

    Microsoft have tech to support on-disk compression in the way that DriveSpace did, even in FASTFAT NT sources we can see the complete DriveSpace compression engine ported to NT arch, but they don´t want by lack of interest, in the same manner that they abandon they efforts to update NTVDM and killed it in 64Bits platform.

    But maybe some day….

    And about nicks, yeah, hehehe, now all makes sense… btw, for sure i´m the only Hyoenmadan and Raijinzrael of all the Internetz :-).

  4. Regarding capturing video from QEMU, I usually use VirtualDub (it’s got screen capture as a built-in capture driver, though it’s a bit non-intuitive to set up – you’ll need Set custom format to change capture resolution, and on Vista/7 you’ll probably have to disable OpenGL acceleration). My codec of choice for screen captures is ZMBV from DosBox, since it can do 30FPS at a very low CPU usage (just make sure you set the video format to 32-bit ARGB).

    And once you have the video, you can use VirtualDub to directly export an animated GIF (one thing I noticed about GIFs VirtualDub produces from screen captures is that they can be they can often be optimized a lot with tools such as gifsicle).

  5. I used to work for Stac. I wrote some support software, and saw the whole breakup take place. With the writing on the wall, I took a job developing business intelligence applications in a whole new multidimensional database package that went on to reach its own successes (Essbase).

    The compression co-processors for Stacker were a dud, sadly. What can you expect from a $90 chip in terms of performance anyway? It was roughly equivalent to the 386/33, which was typically what most users had at the time. It essentially shifted the processing from a near equivalent CPU to an application specific processor, and the CPU would sit mostly idle while the co-processor did the I/O. In may systems, it actually slowed things down (relative to the software version, not relative to an uncompressed drive).

    However, it’s nice to revisit the old school stuff, maybe I can find my old Stacker 3.0 box around here somewhere… The software may still be in it, even.

    • the coprocessors rocked in 2500 cisco routers, even the early 7000 class stuff as well.. Its just a shame that cisco won’t let you compress any random interface… but I can see how custom logic always falls victim to CPUs getting faster all the time..

      One day I should see if I can get apache to compress some, and see if it makes any difference in site bw speeds… but I know compress-stac saved my life back when we used leased lines…

    • Dougals: I still have my old “486” computer that I had used “Stacker” on to increase the hard-disk size. Somehow one of the “Stacker” drivers either became corrupted or missing and now I cannot boot-up my “486” computer. The sad part of this is…..I have some electronic design files on this computer that I need to occasionally make use of, but now I cannot access them!!! HELP!!!

      Is there a company, someone or anything that can help me get my old hard-disk working well enough to boot-up, so I can access and off-load all of my electronic design files to a 3-1/2″ floppy disk? If you or anyone reading this knows how to help me fix this problem, please feel free to contact me. HELP!!! You can reach me at:

      THANK YOU!!!


  6. Wow. Thanks for the blast from the past. I ported Stacker to OS/2 at STAC. Lots of 80 hr weeks. I left an easter egg is Stacker OS/2 though cant remember the key sequence now. It displayed a developer credits list.

    It was sad to see the company flown straight into the ground by T. D.

    T.D was the dir of eng before being promoted eventually to a position to destroy the company. He referred to Stacker’s data compression ratio as “The Lie”.

    The release of Stacker 3.0 improved on Stacker’s compression ratio.

    At an internal meeting celebrating the 3.0 release, T.D proudly announced “With Stacker 3.0, ‘The Lie’ is now less untrue than it has ever been before.” He had s smug little smile betraying how clever he thought he was with this.

    It was one of those odd experiences you remember all your life.

Leave a Reply

Your email address will not be published.

Notify me of followup comments via e-mail. You can also subscribe without commenting.