Results 1 to 3 of 3

Thread: DoubleSpace/DriveSpace algo differences and...would you use it again?

  1. #1
    Member JamesWasil's Avatar
    Join Date
    Dec 2017
    Thanked 19 Times in 18 Posts

    DoubleSpace/DriveSpace algo differences and...would you use it again?

    Years ago, Microsoft released DoubleSpace for MSDOS 6.0, but then later had to remove it due to a patent license issue with Stac Electronics and infringement upon Stacker. By DOS 6.22 (the last actual MSDOS that was able to run on a real 8086/8088 PC without needing other things to run), they had replaced DoubleSpace with DriveSpace which compressed mostly the same, but used an entirely different algorithm to do it.

    Later, Stac would sign an agreement with Microsoft to include the Stacker-based DoubleSpace and DriveSpace both with Windows 95 and later, and Windows would default to the DoubleSpace algorithm rather than DriveSpace thereafter.

    Does anyone know what those two algorithms were exactly?

    With all the talk about reverse-engineering on other threads, has anyone been known to have reverse-engineered Stacker or DriveSpace for DOS to know what these differences were and how the algorithm that was used worked?

    I'm sure it was a kind of LZ77, LZEXE or LZSS design, but did anyone here ever have code to work with Drivespace or Doublespace compressed volumes directly? Did it ever exist?

    I found an old file on a CD yesterday that was a DOS volume file for this and thought at first that it was a Drivespace file, but it turned out to be a DoubleSpace one. I had to fire up a virtual machine with DOS 6.0 instead of 6.22 to be able to read it. (I probably could have used a Windows 95 emu too, but wanted to see what it was in original form)

    During the early 90's, Doublespace corrupted an entire hard drive I had for a computer because of a program that used direct disk access and BIOS calls that DoubleSpace didn't support. I was livid about it for almost a year lol. I'm sure I wasn't the only one who had those issues, either. Whenever you compress an entire volume, there are risks introduced with that to where you can potentially lose all of the data if you're not careful with it.

    I saw about a year or two ago on here that DiskZIP was trying to bring that back. I wonder how many people would feel comfortable trusting entire drive compression or volume compression again, and if DiskZIP used any of the techniques done with DoubleSpace or if they managed to reverse-engineer some or all of it before doing that?

  2. #2
    Join Date
    Jun 2018
    Thanked 6 Times in 6 Posts
    I use partition compression but with btrfs
    ‚Äčit has deduplication too.

  3. #3
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Kharkov, Ukraine
    Thanked 1,397 Times in 802 Posts
    Here's source of the driver with support for both:
    dblspace_dec.c: ds_dec() jm_dec() sq_dec()
    dstacker_dec.c: sd3_decomp() sd4_decomp()
    Apparently there're multiple version-specific algorithms

    Also this:
    Attached Files Attached Files

  4. Thanks:

    JamesWasil (28th December 2019)

Similar Threads

  1. Mistery differences in RAR compression with same method?
    By anormal in forum The Off-Topic Lounge
    Replies: 0
    Last Post: 23rd May 2018, 21:34
  2. std::vector differences in g++ and VC++
    By Matt Mahoney in forum The Off-Topic Lounge
    Replies: 12
    Last Post: 25th July 2012, 00:55
  3. DoubleSpace/ DriveSpace drivers for eg Linux
    By Piotr Tarsa in forum The Off-Topic Lounge
    Replies: 1
    Last Post: 8th May 2012, 07:41
  4. Index-Compress-Update: parallel LZ match finder algo
    By Bulat Ziganshin in forum Data Compression
    Replies: 22
    Last Post: 10th January 2012, 20:36

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts