elianda wrote on 2020-06-04, 19:06:

Good memory managers had native support for the most common disk compression drivers and can load them nearly fully to XMS.

So the memory argument is only an issue if you have a game that requires real mode and that game was stored by yourself on the compressed disk.
And the solution to that is rather easy, just put the game on the uncompressed disk and don't load (or unload) the disk compression.

That I did not know. I'm not finding any reference to this after a quick search. Could you point me in the right direction?

In any case, I thought the whole purpose was to reduce needed space in order to keep people from having to buy a larger disk.

If they have to buy a second disk to use for non-compressible files or for games/programs that require a lot of free conventional memory, then again, what would the point be?
I guess partitioning would be useful here if you have only one disk, but it still seems like pretty useless feature just like it did back then.

I tried it more than once and each time it left me with not wanting to use it after a short while.

cyclone3d wrote on 2020-06-04, 19:50:

That I did not know. I'm not finding any reference to this after a quick search. Could you point me in the right direction? […]
Show full quote

That I did not know. I'm not finding any reference to this after a quick search. Could you point me in the right direction?

In any case, I thought the whole purpose was to reduce needed space in order to keep people from having to buy a larger disk.

If they have to buy a second disk to use for non-compressible files or for games/programs that require a lot of free conventional memory, then again, what would the point be?
I guess partitioning would be useful here if you have only one disk, but it still seems like pretty useless feature just like it did back then.

I tried it more than once and each time it left me with not wanting to use it after a short while.

Here from the QEMM97 tech notes for Stacker:

1 Q. What are the different sizes of the Stacker driver?
2
3 A. The size of the driver is strongly dependend on the size of
4    our hard drive and the size of Stacker's compressed clusters.
5    If you are using Stacker with DPMS.EXE and the /QD parameter,
6    the driver's resident size will be as little as 10K.  Without
7    the /QD parameter, the driver will typically be at least 8K
8    larger. If you are using Stacker's /EMS switch, the driver
9    should be at least 25K.  If you are not using DPMS.EXE or the
10    /EMS switch, the driver should be at least 44K.  The
11    initialization size, the size necessary to load the driver
12    before it shrinks down to its resident size, is 87K no matter
13    what parameters you use.

So the driver takes up 10 kB that can be loaded to UMBs.
If you don't use any memory manager or Novells Dos Protected Mode services then it takes 44kB.

Also the compressed drive is just a fixed file on the uncompressed disk. It is not required to set a whole partition as compressed drive.
For example if you have a single hard disk with a single primary partition you can create a compressed drive that is taking 50% capacity. The compressed drive is then a file on the partition with the size of 50% of the partitions size.
Then one can e.g. install windows in it and office etc., put TEMP and the swap file on the uncompressed disk. If the setup is good one can shrink the compressed drive to minimum size afterwards... This frees up space in the uncompressed part of the hdd again.

elianda wrote on 2020-06-04, 19:06:

Good memory managers had native support for the most common disk compression drivers and can load them nearly fully to XMS.

So the memory argument is only an issue if you have a game that requires real mode and that game was stored by yourself on the compressed disk.
And the solution to that is rather easy, just put the game on the uncompressed disk and don't load (or unload) the disk compression.

Back in those days I almost always used QEMM and I never had conventional memory issues with Drivespace.

Used Stacker and DBLspace on 286/16... not at the same time of course 🤣 40MB HDD was pretty small and giving around 20MB more was nice... but it took toll on the performance. I've only noticed that when I removed it. Later I used compressed files/directories on NT4 - mostly on system files.

kixs wrote on 2020-06-04, 22:57:

Used Stacker and DBLspace on 286/16... not at the same time of course 🤣 40MB HDD was pretty small and giving around 20MB more was nice... but it took toll on the performance. I've only noticed that when I removed it. Later I used compressed files/directories on NT4 - mostly on system files.

I guess it depends on the system in question. If the HDD is slow (say wrong interleave facor, 8-Bit IDE, 8-Bit BIOS/not shadowed etc), compression can have a positive effect also.
After all, it effectively causes less data to be read and written most of the time. Anyway, it also depends on other factors. Games are not good for compression,perhaps.
But if a lot of small text files, databases (dBase files) or source code (C, BASIC, Pascal) etc are being processed, compression isn't that bad, IMHO.
- Remember, even a small file (say an ASCII file containing "Hello World") wastes a lot of space in FAT12/FAT16..
In such a case, a compressed HDD makes better use of the free space than an uncompressed HDD. 😉
(By the way, DoubleDrive/Space also has a Defrag command. Shouldn't hurt using that from time to time, just like MS Defrag or PC-Tools' "Compress".)

Most people who used these seem to have used them on <100MB hard drives, which makes sense because a Windows 3.1 install on these took up substantial amount of space and it could be significantly compressed. The first time I used them was on my father's 386SX laptop and that thing had a 40MB HDD IIRC. Believe me, it really makes a life saving difference at that size. I later used it for a while with my desktop 486DX's 213MB HDD and found it to be of questionable worth. There was a window of time when hard drive capacity was scarce and very expensive and at the time these products had their value. It's hard to understand today, looking back..

Defragging a compressed volume was a two step process. You had to defrag the host drive to make sure the compressed volume was contiguous. Then you had to defrag within the compressed volume to make sure it was internally contiguous too, and in order. Only then did head movement decrease and access time improved. It didn't really matter which one you did first, the end result was the same. But I believe it was more time-efficient to do the host drive first.

At the time I liked using Norton Speedisk to do the job. I was learning Norton Utilities and I liked the interface. Made me feel super professional at the time.

appiah4 wrote on 2020-06-05, 06:37:

It's hard to understand today, looking back..

Yep.
I compressed a 420MB drive with the version that came with Win95 Plus! as an archive drive.
late 90's, High school student with no income, 1GB HDD primary drive. Disk space was always tight.

Performance hit was worth it.

Keatah wrote on 2020-06-03, 01:04:

Anyone ever use DoubleSpace or DriveSpace back in the day? […]
Show full quote

Anyone ever use DoubleSpace or DriveSpace back in the day?

Back then they were near godsends. Realtime disk compression seemed to work well and provided tangible benefits. Both then and now I was impressed with how transparent it all was despite the amount of convoluted shenanigans that went on "behind the scenes". Renaming and redirecting of drives. Hiding certain files. All that.

I found it particularly valuable in the 486 era. The DX2 processors were fast enough to decompress on-the-fly with power left over. These systems were often left waiting on disk transfers to finish. So the less data transferred the faster your system ran. And you got about 40% extra storage space, the main advertised benefit!

So what where your experiences with DoubleSpace & DriveSpace?
https://en.wikipedia.org/wiki/DriveSpace

I used it a lot. I had a 386SX 16Mhz 2Mb with 40Mb for several years. I didn't lose data, the computer was running MS-DOS 6.2 and Windows 3.1.

I was a teenager, used the PC to play graphic adventures and program in Turbo Pascal , the computer was slow with and without DoubleSpace 😀. For me it was really useful, I think that I was able to get more than 60Mb. I can not recall using it with my second PC (486DX2 66).

I never used it. Mainly, because I used my PC for playing games and most game files were already compressed and would have added very little benefit.
Also heard some stories about corrupt data, etc. so I decided to stay away from it.

jesolo wrote on 2020-06-13, 20:31:

Also heard some stories about corrupt data, etc. so I decided to stay away from it.

It was one of the "best" ways to end up with a system that needed a full reinstall after a lock-up. 😜

I did it once and found it was not worth the hassle of losing the data and I think it made things slower.
I did use a program called "FreeSpace" in Windows 95 and I liked it a lot at the time.
It basically shrank individual files and hardly added to the load time .
It caused problems on Windows 98 though so I stopped using it.

It was pretty much the same as the a feature that existed on Windows NT 4.0 I think.

I used a game called Freespace on Windows 98 too and it was awesome.

The more interesting aspect to me for filesystem compression was the speed boost. The CPU is usually waiting on the drive and compression can really boost the data rate of reads.

But I think fragmentation is even more of a problem with compressed volumes.

And it's probably not reliable enough until NTFS.

I did use both of them on a 386 which had a small 65M hard drive. It worked OK, but eventually I stripped back the files so I could get rid of it. Most annoying aspect was having 5M reported free, but running out of space adding a 100K file. Defragmenting the harddrive also took much longer.

I think it is a 'last resort' option, to be avoided until absolutely necessary. However, I use transparent file compression on BTRFS today with no problem.