About  

 Press  

 Marketing  

 Technology  

 Purchase  

 About  

 Press 

 Marketing 

 Technology 

 Purchase  

eDisk™    
 About   
 Press  
 Marketing  
 Technology  
 Purchase   
    

Resource Compression : What it is and how it works. 
With the release of its System 7, Apple Computer quietly introduced a powerful means of applying transparent compression to applications and other resource files that has yet to be matched by third-party schemes.  While System 7 features like AppleEvents and Balloon help were highly-touted and well-documented, Apple’s Resource compression scheme remains a tantalizing mystery to most Macintosh developers.   In this article, we’ll explore exactly what resource compression is, how it works, and how to apply it to your own software. 

What Resource Compression is: 
To deliver on the promise of System 7’s remarkable new features, Apple programmers had to write a significant volume of new code for both the Finder and System files.  During the course of development, it became clear that the system and Finder would not be able to fit on a single high-density diskette without the application of some sort of compression.  The compression applications available at the time could not be applied since they would only create archives, not compressed files that could be used in compressed form.  What was needed was a compression/decompression scheme that would allow compressed files to operate while still compressed on disk, without decompressing entirely into memory, and without degrading system performance.  The solution was the resource compression system employed in the System File, the Finder, ResEdit, and TeachText. 

Like any other coding - decoding system, resource compression consists of two basic components, a tool for compressing data and decompression code which decodes the compressed data.  While most third-party compression software comes in application form, resource compression exists in the form of an enhancement to the Resource Manager supported by decompression resources of type ‘dcmp’.  After compiling the final version of his software, a developer uses a resource compressing application to shrink the individual resources in the application and paste in his ‘dcmp’ resource.  When the end user launches the application,  the Resource Manager handles the parsing of compressed resources and calls the appropriate decoders to transparently expand the compressed resources that it encounters. 

The significant advantages to this approach are speed and compatibility.  Since resources are decompressed into memory rather than to disk, their compressed contents can be accessed in a fraction of the time required by a system that decompresses to disk.   Because the resources are compressed and decompressed individually, they can be accessed much more rapidly than if the entire file was expanded into memory.  An application which takes up half the space on disk will require only half as much disk access to load into memory.  If the decoding software can expand the compressed data more rapidly than the SCSI bus can transfer the same number of bytes, the application will actually launch faster in compressed form. 

Since the decompression is done automatically by the Resource Manager and the appropriate ‘dcmp’ resource, compressed data can be accessed transparently by software that is unaware of compressed resources:  the same trap calls that access ordinary resources also access compressed resources with no difference in passed parameters.  Applications written before resource compression was made available will launch and run after being made smaller through resource compression.  Adobe Photoshop and Aldus PageMaker 4 will each fit on and execute from 800K diskettes after being compressed by software from Alysis.