
DriveSpace 3


  DriveSpace 3 - The Advanced File System for Windows 95

                                   Copyright 1995 by Jim Gunn

Okay, you were a Doublespaceaphobiac, and a Stack monster ate your disk - er...maybe, and DriveSpace brought aliens from the planet Gumupenderworks through a weird void and destroyed all your data!  I guess there are other popular myths about computers too.  But really, compression routines have matured.

We now have version three of the Microsoft compression gadget.  This new kid on the block is included with the PLUS! pack.  Its name is DriveSpace 3 and there is a lot to it - a whole lot!  Now before you yell compression - arrgh,  read on and feel free to try it a bit at a time until you have the security blanket comfy up under your chin.  Personally, I've been using this beastie for months, and would never go back to plain old FAT.

* First of all, a wonderful feature of DriveSpace 3 is that you don't have to compress any data at all to take advantage of its major but unpublished features. 
* Second, and very important, the old myth about slow performance has a number of new twists that are really worth looking into.
* Third, this is the advanced file system that Windows 95 deserved only the authors didn't realize it at the time. 
* Fourth, the hue and cry about the 110K driver business is easily rectified.

DriveSpace 3 requires that you put all of your data into a single file, known as a CVF, or Compressed Volume File, just like the DoubleSpace/DriveSpace shipped in the past.  If you lost the FAT entries on the host, or uncompressed volume, this file would be gone.  How often does that happen?  People who whoop and holler about that seldom seem to have remembered to make a backup.  Nor do they consider that if their FAT is destroyed, all their uncompressed files are gone bye-bye anyway.  The net result is the same.

This all in one basket CVF does buy us something extremely signi-ficant.  There is no longer a slack factor.  There are no such things as clusters, allocation units or even the simple minded old sector to deal with.  Once in a CVF, data is data, and all of that old DOS gibberish is history.  Data simply lives where it lands, and the old bugaboo about a 10 byte file taking up a whole allocation unit is totally history.  Even better, that ten byte file no longer even takes up even a single 512 byte sector, but now takes up simply 10 bytes, -period!  The whole mess about clusters is simply gone.

Now all of this part is strictly internal.  DOS, Windows, and every-thing external to the CVF swears that you have 32K clusters and all the slack overhead of the FAT system.  This is a pleasant lie and is simply for compatibility because the old FAT system requires it.  Rest assured, it is nothing more than humoring the old way of doing things.  And unlike previous versions of compression programs, this one deals with up to 2GB per CVF.  It has no 512KB limitations.

But now, let's look at the actual compression part. As mentioned earlier, you don't really have to compress anything in order to take 

advantage of the allocation units are history part of DriveSpace 3.  But what if you (shudder!) do?

Well, if you let it do what it calls normal compression you will achieve
something on the order of 1.9:1 compression.  That's way kewel, as my kids would say, but there is a significant performance enhancement to be had here, too.

It seems that if you are on a Pentium class machine, the processing overhead required to do the dreaded decompression/compression deed is way less than the physical transfer time of the uncompressed data through the normal system bus. The net result is improved through-put.  On a 486 class system, throughput is about the same.  But in either case you still get the space savings of both compression and the elimination of the FAT system allocation limitations.

Compression varies with the file type and content, of course.  A .ZIP file simply isn't going to compress as well as a text file. There are four classes of compression in DriveSpace 3 and the ratios are simply averages of testing with various file types:

1. None
 
2. The ever popular Normal (about 1.8 or 1.9:1)
 
3. Hi-pack (roughly 2:1)
 
4. Ultra-Pack (over 2:1)

A nice feature is that these can be mixed and matched.  Unlike prev-ious compression schemes, DriveSpace 3 comes with a gizmo called Compression Agent.  When you set it up, you can have a default compression scheme specified.  Then periodically, you can run Compression Agent and have it make adjustments.  A classic example is to have normal compression be your default and yet have Compression Agent detect any file that has not been accessed in
more than 30 days and compress those files using Ultra-Pack.  If one of those files eventually gets accessed, using this example, the next time Compression Agent is run, it will convert it back to Normal compression.  It displays a screen which keeps tabs on how much space is being compressed and how much is being uncompressed or altered to a different scheme.

Compression Agent is slow.  At its best, it can take an hour or so per
gigabyte just to do a scan, even if no real activity is required.  If there
are lots of changes to be made this can stretch out considerably.  Obviously, drive speed, controller type and throughput vary from system to system and affect this part significantly.  Another consider-ation is that every time anything at all changes on the disk, that Compression Agent itself didn't do, it starts over.  Therefore it is not suitable for running in any mode other than stand alone.

To the rescue comes another product included in the PLUS! pack.  This one is known as the System Agent.  Among other things, it can be used to schedule Compression Agent to run at off-peak times (computer jargon for the middle of the night).  This way, you can have it scheduled to do the compression thing at say, two AM on Saturday mornings and all you have to do is remember to leave the system running on Friday nights.  You pick the times that are
suitable for your usage.

A justifiable complaint about DriveSpace 3 is the amount of memory required in the lower 1MB to hold its real mode drivers.  Let me tell you how to avoid that problem all together.  It seems that the default installation updates your CONFIG.SYS file to include the line:

DEVICE=C:\WINDOWS\DRVSPACE.SYS /MOVE

This is a holdover from the original DoubleSpace/DriveSpace and is an oddball thing.  Even though the program is named with a .SYS extension, it really never was a driver.  All it ever did was determine the location of the DBLSPACE.BIN or DRVSPACE.BIN file in memory.  The /MOVE parameter told it to locate it in upper memory, if available.  After this statement is executed, DRVSPACE.SYS goes away and no longer exists.

But, what happens is that the .BIN file still exists, and so do the real mode drivers, until Windows 95 cranks up in GUI mode.  At that point, it replaces the real mode drivers with virtual equivalents.  This all sounds great in theory.  The problem is that since some or all of this stuff has been placed in upper memory (UMB space).  When the virtual drivers finally arrive on the scene, they can free up whatever portion was loaded in conventional memory but cannot touch the parts that made it to upper memory.  This then becomes wasted
space.

Another aspect of this problem is that when booting to the Command Prompt Only part of Windows 95, none of the replacement of real mode vs. virtual drivers has taken place yet.  You are out up to 110K of this precious limited lower 1MB memory.  In either case, some memory is totally wasted.  It simply depends on the particular configuration, what else is loaded in upper memory and all
that stuff.  But, this is not a desirable situation.

Once more, help is on the way, and you read it here.  The solution is to let the installation part do its thing.  Now edit CONFIG.SYS and (drum roll) comment out or remove the entire line referencing DRVSPACE.SYS.  Now reboot and that's all there is to it!

What now happens is that since you are no longer telling it to relocate the .BIN file into upper memory, none of that gets done.  Because of that, there is no need for the real mode drivers.  Instead, the common sense thing happens.  The virtual drivers load themselves into extend-ed memory  -where they belong and would end up anyway- at boot time.  You will find no trace of anything dealing with DriveSpace 3 in the first megabyte.

You can even dual boot to a previous version of DOS and it will be able to access your compressed volume with no trace of drivers.  The entire 110K is history as far as you are concerned.  True, it still exists somewhere in extended memory, but I'll guarantee that you have a whole lot more stuff loaded there than you would care to know about, so the 110K part enters the world of  who cares?  pretty quickly.  You can't see it, smell it or touch it and it just melts quietly into the swapfile somewhere or other.

This is a very flexible and functional product that reaches far beyond its original intent.  Even if you couldn't care less about compressing anything, in essence, it provides the advanced file system that every-one wishes Windows 95 had included, while still maintaining the complete FAT system compatibility that we all need.  I find it 


interesting that the compression part of a compression program is simply an added bonus to its otherwise unheralded features.

And don't forget to let it Ultra-Pack those files untouched in 30 days or more, no matter how much physical disk space you have.  It's the principle of the thing.

Jim Gunn is president of Sterling Consulting in Salt Lake City, Utah and a regular WindoWatch contributor. He publishes the Salt Puddle Pointless for those lucky enough to get on his list.  Jim can be reached at  72731,115 @compuserve.com


  
                         ww


