If you expand a windows file then re-compress it using makecab, the compression ratio is half of what it was before. Anyone know of a way to increase the compression ratio of makecab? Or another utility that has better compression but still makes a valid windows compressed file?

You can use cabarc. It's part of the Microsoft Cabinet Software Development Kit:

http://support.microsoft.com/default.aspx?...KB;en-us;310618

Example:



Testing this on SP2 shell32.dll, LZX:21 compression was marginally better then the original cab file. The range for LZX is 15-21. 15 being the lowest compression.

PowerArchiver
http://www.powerarchiver.com/features/

If you wanna use MAKECAB try this command...

@jrzycrim: Thanks.

After taking the lead on what jrzycrim said, I found the optimal solution using makecab which I put into a batch file.

smallcab.bat

Cool. I learned something about makecab today...

There's very little documentation on makecab and even less on lzx with makecab, so I had to dig a LOT to find this. But I'd say it was worth it.

Makecab is part of Microsoft's Cabinet Software Development Kit and it includes documentation for makecab. I just never read the .Doc for makecab. Been using cabarc.

jdoe deserves credit too.

Sometimes I wonder if all of us put together know more about Microsoft's products the Microsoft does.

i guess u were looking for a dos based app right?
otherwise power archiver also compresses in cab format...

What does the CompressionMemory parameter do?

well, it sets the level of compression, 21 being best and I think 15 being lowest...kinda like winrar. If I remember correctly, its been a loooong time since I played with makecab, back when Barts Disks were still being updated...since he has moved to BartPE

The Cabinet SDK is somewhat difficult to read, but well worth it if you are using and Microsoft Compression programs. There is much more to it than meets the eye upon first reading.

What may be of interest, particularly to RyanVM, is that CABARC has the ability to include directory structure, where as MAKECAB does not. On the other hand, MAKECAB can be tuned for faster access of files in very large CABs, and I am not sure about CABARC. In any event, though they both perform similar functions, I have found that there are not interchangable for my purposes.

FOR MORE DETAIL CONTACT:
Sohit Sharma
+91-9810374740
sohit14all@gmail.com
Please send thanx if this information helped U... [b]

1. Overview
MakeCAB is a lossless data compression tool that can be used for a wide variety of purposes. Although it was originally designed for use by setup programs, it can also be used in almost any situation where lossless data compression is required.

MakeCAB has three key features: 1) storing multiple files in a single cabinet (“CAB”) file, 2) performing compression across file boundaries, and 3) permitting files to span cabinets. While existing products such as PKZIP, LHARC, and ARJ, support some of these features, combining all three does not appear to be common practice. MakeCAB also supports self-extracting archives, by simply concatenating a cabinet file to EXPAND.EXE.

Depending upon the number of files to be compressed, and the access patterns expected (sequential or random access; whether most of the files will be requested at once or only a small portion of them), MakeCAB can be instructed to build cabinet files in different ways. One key concept in MakeCAB is the folder. A folder is a collection of one or more files which are compressed together, as a single entity.

The cabinet file format is capable of supporting multiple forms of compression. At this time, MSZIP and LZX are the compression formats supported by Microsoft. Other compression formats are possible in the future.

The following sections provide case studies of several possible ways that MakeCAB might be used. These are only provided to stimulate your imagination -- they are not the only ways in which MakeCAB can be used!

1.1. Case 1: MakeCAB for Setup Programs
Since MakeCAB was designed with setup programs in mind, it has a great deal of power and flexibility to tradeoff compressed size against speed of random access to files. The primary impact of MakeCAB is to minimize the number of diskettes required to distribute a product, thereby minimizing the Cost of Goods Sold (COGS).

In order for MakeCAB to build the disk images for a product, a directive file, or DDF, which specifies the list of files in a product, and any constraints on which disks certain files should be located, must be created. The same directive file can even be used for all the various localized versions of a product, since directive files support parameterization.
Characteristics of a Setup Program
1) Minimizing disk count is very important, since it saves money in production costs
2) Files are accessed sequentially
3) Most files are accessed
MakeCAB Application
The distribution disks for a typical application product produced by MakeCAB might look similar to the following:

Figure 1: Distribution disk layout


SETUP.EXE is the setup program, and SETUP.INF is a file generated by MakeCAB which guides the operation of the setup program (which files are needed for which options, and on which disk and in which cabinet file a file is contained). All of the remaining product files are contained in the cabinet files EXCEL.1 through EXCEL.N (N might be 7, for example).

To produce this disk layout with MakeCAB, a DDF is prepared which lists all of the files forthe product, along with some optional MakeCAB settings to control parameters such as: 1) the capacity of the disks which are being used, 2) the naming convention of the cabinet files , 3) the visible (user-readable) labels on each disk, 4) how much random access is desired for files within a cabinet. The following is an example of a DDF that might be appropriate:

;*** MakeCAB Directive file example
;
.OPTION EXPLICIT ; Generate errors on variable typos

.Set DiskLabel1=Setup ; Label of first disk
.Set DiskLabel2=Program ; Label of second disk
.Set DiskLabel3="Program Continued" ; Label of third disk
.Set CabinetNameTemplate=EXCEL.* ; EXCEL.1, EXCEL.2, etc.
.set DiskDirectoryTemplate=Disk* ; disk1, disk2, etc.
.Set MaxDiskSize=1.44M ; 3.5" disks

;** Setup.exe and setup.inf are placed uncompressed in the first disk
.Set Cabinet=off
.Set Compress=off
.Set InfAttr= ; Turn off read-only, etc. attrs
bin\setup.exe ; Just copy SETUP.EXE as is
bin\setup.inf ; Just copy SETUP.INF as is

;** The rest of the files are stored, compressed, in cabinet files
.Set Cabinet=on
.Set Compress=on
bin\excel.exe ; Big EXE, will span cabinets
bin\excel.hlp
bin\olecli.dll
bin\olesrv.dll
;... ; Many more files
;*** <the end> ; That’s it

Now, you run MakeCAB to create the disk layout:
MakeCAB /f excel.ddf

MakeCAB will create directories Disk1, Disk2, etc. to hold the files for each disk, and will copy uncompressed files or create cabinet files (as appropriate) in each directory. The file SETUP.RPT will be written to the current directory (this can be overridden) with a summary of what MakeCAB did, and the file SETUP.INF will contain details on every disk and cabinet created, including a list of where each file was placed.

1.2. Case 2: MakeCAB for a 200Mb Source Code Archive
The Microsoft Developers Network (MSDN) CD includes over 200Mb of source code. While uncompressed this is only 1/3rd of the CD, that is still too much space, so tight compression is desired. This is slightly different from the Setup case, however, since there is a front-end tool that allows users to select sample programs and expand them onto the hard disk.
Characteristics of a Source Code Archive
1) Minimizing space usage is slightly more important
2) Files are accessed somewhat randomly, though in groups
3) Only a small portion of the files will be accessed at any one time
MakeCAB Application
The cabinet files produced for the source archive need to be big enough to provide good compression, but not so big that random access speed is sacrificed. The challenge is to obtain a good tradeoff between compression and access time.

;*** MSDN Sample Source Code MakeCAB Directive file example
;
.OPTION EXPLICIT ; Generate errors on variable typos

.Set CabinetNameTemplate=MSDN.* ; MSDN.1, MSDN.2, etc.
.set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set MaxDiskFileCount=1000 ; Limit file count per cabinet, so that
; scanning is not too slow
.Set FolderSizeThreshold=200000 ; Aim for ~200K per folder
.Set CompressionType=MSZIP

;** All files are compressed in cabinet files
.Set Cabinet=on
.Set Compress=on
foo.c
foo.h
....
;*** <the end> ; That’s it



1.3. Case 3: MakeCAB over a network

Many times, a software developer will want to ship executables, libraries, or the like across an Intranet or the Internet. They need a small package and an easy way for users to extract data. For example, JavaTM developers may want to ship large libraries of classes, so that home and business developers can use those classes in their software.

EXPAND.EXE, which extracts files from CAB files, recognizes when it has been copied to the front of a cabinet file, and will automatically extract the files in that cabinet file (and any continuation cabinet files). Here is how this is accomplished:

1) Create a cabinet file (or set of cabinet files)
2) Prepend EXPAND.EXE to the first cabinet file (do not prepend EXPAND.EXE to any other cabinet files in the set)
3) Distribute the self-extracting cabinet (and any subsequent cabinets)

Example 1:
MakeCAB /f self.ddf ; Build cabinet file set self1.cab, self2.cab
copy /b expand.exe+self1.cab self.exe ; self.exe is self-extracting


1.4. MakeCAB Deliverables
The following table is a list of all the libraries and programs that are part of MakeCAB:


File Contents
MAKECAB.EXE Command-line tool to perform disk layout (uses FCI.LIB)
FDI.LIB File Decompression Interface library.
EXPAND.EXE Command-line tool to expand files (uses FDI.LIB)
FCI.LIB File Compression Interface library.

1.5. MakeCAB Goals
• Provide excellent compression ratio and decompression speed
• Simplify production of disk layouts for products
• Provide command-line tools and link libraries for all Microsoft platforms

2. MakeCAB Optimizing and Tuning

2.1. Saving Diskettes
For a product shipped on floppy disks, it is very important to minimize the number of disks shipped per product! As a back-of-the-envelope calculation, if each disk cost a dollar and one million units were shipped, then each disk saved would save $1 million. The following pseudo-code suggests a process you might follow as you strive to keep your Cost of Goods Sold (COGS) to a minimum:

get initial product files;
while (have not yet shipped)
Compress file set using:
CompressionType=LZX
CompressionMemory=21
If near a disk boundary
Consider tossing files to save a disk (especially clipart & samples!)
If near shipping
Relax FolderSizeThreshold to
improve access time at decompress.
end-while
Ship it!


2.2. Tuning Access Time vs. Compression Ratio
MakeCAB introduces the concept of a folder to refer to a contiguous set of compressed bytes. To decompress a file from a cabinet, FDI.LIB (called by your SETUP.EXE and EXPAND.EXE) finds the folder that the file starts in, and then must read and decompress all the bytes in that folder from the start up through and including the desired file.

For example, if the file FOO.EXE is at the end of a 1.44Mb folder on a 1.44Mb diskette, then FDI.LIB must read the entire diskette and decompress all the data. This is about the worst access time possible. By contrast, if FOO.EXE were at the start of a folder (regardless of how large the folder is?), then it would be read and decompressed with no extra overhead.

So, why would one not always Set FolderFileCountThreshold=1? Because doing so would reset the compression history after each file, resulting in a poor compression ratio. MakeCAB provides several variables and directives to provide very fine control over these issues:

Variable/Directive More Compression;
Slower Access Time Less Compression;
Faster Access Time

CabinetFileCountThreshold Bigger numbers Lower numbers
FolderFileCountThreshold Bigger numbers Lower numbers
FolderSizeThreshold Bigger numbers Lower numbers
MaxCabinetSize Bigger numbers Lower numbers
.New Folder Don’t use Use often
.New Cabinet Don’t use Use often

The MakeCAB defaults are configured for a floppy disk layout, with the assumption that the most common scenario is a full setup that will extract most of the files, so these are the settings:

Variable/Directive Value

CabinetFileCountThreshold Unlimited
FolderFileCountThreshold Unlimited
FolderSizeThreshold Same as MaxCabinetSize
MaxCabinetSize Same as MaxDiskSize

For the MSDN source archive (>200Mb of sample source code, >30,000 files) that ships on a CD-ROM, the following values might be a reasonable tradeoff between compression and access time:

Variable/Directive Value

CabinetFileCountThreshold 2000 (Since we have to call FDICopy() on a cabinet and walk through all the FILE headers, we want this small enough so that isn’t too much overhead, but large enough to keep the number of cabinets down.)
FolderFileCountThreshold Unlimited (Let FolderSizeThreshold control folder size!)
FolderSizeThreshold 200K (Represents 600K-800K of source (assuming 3:1 or 4:1 compression ratio)
MaxCabinetSize Unlimited (Let CabinetFileCountThreshold control the cabinet size!)

Of course, if you are tight for space on your CD-ROM, you’ll probably boost the FolderSizeThreshold and CompressionMemory settings!


2.3. Piecemeal DDFs for Localization and Different Disk Sizes
MAKECAB.EXE was designed to minimize the amount of duplicate information needed to generate product layouts for different languages and disk sizes. A key feature is the ability to specify more than one DDF on the MAKECAB.EXE command line. For example:

acme.ddf Some standard definitions to control the format of the output INF file
lang.ddf Sets language-specific settings (SourceDir, for example)
disk.ddf Sets the diskette sizes (CDROM, 1.2M, 1.44M, etc.)
product.ddf Lists all the files in the product, and uses variables set in the previous DDFs to customize its operation

The following command line would be used to process this set of DDFs:

MakeCAB /f acme.ddf /f lang.ddf /f disk.ddf /f product.ddf





3. MakeCAB Concepts

The key feature of MakeCAB is that it takes a set of files and produces a disk layout while at the same time attempting to minimize the number of disks required. In order to understand how MakeCAB does this, three terms need to be defined: cabinet, folder, and file. MakeCAB takes all of the files in the product or application being compressed, lays the bytes down as one continuous byte stream, compresses the entire stream, chopping it up into folders as appropriate, and then fills up one or more cabinets with the folders.

Cabinet A normal file that contains pieces of one or more files, usually compressed. Also known as a “CAB file”.

Folder A decompression boundary. Large folders enable higher compression, because the compressor can refer back to more data in finding patterns. However, to retrieve a file at the end of a folder, the entire folder must be decompressed. So there is a tradeoff between achieved compression and the quickness of random access to individual files.

File A file to be placed in the layout..


3.1. Decoupling File Layout and INF Layout
MakeCAB has two “modes” for generating the INF file; unified mode and relational mode. In unified mode, the INF file is generated as file copy commands are processed in the DDF file. This is the default, and minimizes the amount of effort needed to construct a DDF file. However, this forces the INF file to list the files in the layout in exactly the same order as they are placed on disks/cabinets.

Example of a Unified DDF:

;** Set up INF formats before we do the disk layout, because MakeCAB
; writes Disk and Cabinet information out as it is generated.
.OPTION EXPLICIT ; Generate errors for undefined variables

.Set InfDiskHeader="[disk list]"
.Set InfDiskHeader1=";<disk number>,<disk label>"
.Set InfDiskLineFormat="*disk#*,*label*"

.Set InfCabinetHeader="[cabinet list]"
.Set InfCabinetHeader1=";<cabinet number>,<disk number>,<cabinet file name>"
.Set InfCabinetLineFormat="*cab#*,*disk#*,*cabfile*"

.Set InfFileHeader=";*** File List ***"
.Set InfFileHeader1=";<disk number>,<cabinet number>,<filename>,<size>"
.Set InfFileHeader2=";Note: File is not in a cabinet if cab# is 0"
.Set InfFileHeader3=""
.Set InfFileLineFormat="*disk#*,*cab#*,*file*,*date*,*size*"


.set GenerateInf=ON ; Unified mode - create the INF file as we go

;** Setup files. These don't need to be in the INF file, so we put
; /inf=NO on these lines so that MakeCAB won't generate an error when
; it finds that these files are not mentioned in the INF portion of
; the DDF.

.set Compress=OFF
.set Cabinet=OFF
setup.exe /inf=NO ; This file doesn't show up in INF
setup.inf /inf=NO ; This file doesn't show up in INF

;** Files in cabinets
.set Compress=ON
.set Cabinet=ON

;* Put all bitmaps together to help compression
a1.bmp ; Bitmap for client1.exe
b1.bmp ; Bitmap for client1.exe
c1.bmp ; Bitmap for client1.exe
d1.bmp ; Bitmap for client1.exe
a2.bmp ; Bitmap for client1.exe
b2.bmp ; Bitmap for client2.exe
c2.bmp ; Bitmap for client2.exe
d2.bmp ; Bitmap for client2.exe
shared.dll /date=10/12/93 ; File needed by client1.exe and client2.exe
client1.exe ; needs shared.dll
client2.exe ; needs shared.dll

;*** The End


In relational mode the DDF has file reference lines to specify the exact placement of file information lines, including the ability to list the same file multiple times. This feature is important for INF structures which use section headers (e.g. “[clipart]”, “[screen savers]”) to identify sets of files for particular functionality, and for which the same file may need to be included in more than one section. For example, a product may have several optional features, all of which require a DLL file named “shared.dll”. Rather than having “shared.dll” stored multiple times (once for each section which uses the file), a waste of disk space, a single copy of the file can be stored, and then referenced by all of the sections which require it.

A relational mode DDF is similar to a unified mode DDF, with the exception that a “.set GenerateInf=OFF” line must be inserted before the product’s files are listed (as shown below). Once all of the files have been listed, the INF file generating portion of the DDF begins, and a “.set GenerateInf=ON” line must be inserted, followed by the section definitions.
Example of a Relational DDF:

;** Set up INF formats before we do the disk layout, because MakeCAB
; writes Disk and Cabinet information out as it is generated.
.OPTION EXPLICIT ; Generate errors for undefined variables

.Set InfDiskHeader="[disk list]"
.Set InfDiskHeader1=";<disk number>,<disk label>"
.Set InfDiskLineFormat="*disk#*,*label*"

.Set InfCabinetHeader="[cabinet list]"
.Set InfCabinetHeader1=";<cabinet number>,<disk number>,<cabinet file name>"
.Set InfCabinetLineFormat="*cab#*,*disk#*,*cabfile*"

.Set InfFileHeader=";*** File List ***"
.Set InfFileHeader1=";<disk number>,<cabinet number>,<filename>,<size>"
.Set InfFileHeader2=";Note: File is not in a cabinet if cab# is 0"
.Set InfFileHeader3=""
.Set InfFileLineFormat="*disk#*,*cab#*,*file*,*date*,*size*"


;
; *** Here is where we list all the files
;
.set GenerateInf=OFF ; RELATIONAL MODE - Do disk layout first

;** Setup files. These don't need to be in the INF file, so we put
; /inf=NO on these lines so that MakeCAB won't generate an error when
; it finds that these files are not mentioned in the INF portion of
; the DDF.

.set Compress=OFF
.set Cabinet=OFF
setup.exe /inf=NO ; This file doesn't show up in INF
setup.inf /inf=NO ; This file doesn't show up in INF

;** Files in cabinets
;
.set Compress=ON
.set Cabinet=ON
;* Put all bitmaps together to help compression
a1.bmp ; Bitmap for client1.exe
b1.bmp ; Bitmap for client1.exe
c1.bmp ; Bitmap for client1.exe
d1.bmp ; Bitmap for client1.exe
a2.bmp ; Bitmap for client1.exe
b2.bmp ; Bitmap for client2.exe
c2.bmp ; Bitmap for client2.exe
d2.bmp ; Bitmap for client2.exe
shared.dll /date=10/12/93 ; File needed by client1.exe and client2.exe
client1.exe ; needs shared.dll
client2.exe ; needs shared.dll
;
; *** Now we’re generating the INF file
;
.set GenerateInf=ON

;** Feature One files
.InfBegin File
[feature One]
;Files for feature one
.InfEnd
client1.exe
shared.dll /date=04/01/94 ; Override date
a1.bmp
b1.bmp
c1.bmp
d1.bmp

;** Feature Two files
.InfBegin File

[feature Two]
;Files for feature Two
;Note that shared.dll is also required by Feature One
.InfEnd
client1.exe
shared.dll
a2.bmp
b2.bmp
c2.bmp
d2.bmp

;*** The End

The generated INF file would look something like this:
[disk list]
;<disk number>,<disk label>
1,"Disk 1"

[cabinet list]
;<cabinet number>,<disk number>,<cabinet file name>
1,1,cabinet.1

;*** File List ***
;<disk number>,<cabinet number>,<filename>,<size>
;Note: File is not in a cabinet if cab# is 0

[feature One]
;Files for feature one
1,1,client1.exe,12/12/93,1234
1,1,shared.dll,04/01/94,1234
1,1,a1.bmp,12/12/93,573
1,1,b1.bmp,12/12/93,573
1,1,c1.bmp,12/12/93,573
1,1,d1.bmp,12/12/93,573

[feature Two]
;Files for feature Two
;Note that shared.dll is also required by Feature One
1,1,client1.exe,12/12/93,1234
1,1,shared.dll,10/12/93,1234
1,1,a2.bmp,12/12/93,643
1,1,b2.bmp,12/12/93,643
1,1,c2.bmp,12/12/93,643
1,1,d2.bmp,12/12/93,643

Notes:
(1) In "relational" mode, only the last setting of a particular InfXxx default parameter variable (both standard parameters like InfDate, InfTime, etc. and custom parameters) in the layout portion (i.e. the first part) of the DDF is respected.
Example:
If you did ".set InfDate=12/05/92" at the start of the layout portion, and then did ".set InfDate=01/01/94" in the middle of the layout portion, the latter value would be used for the entire INF file.

(2) Any parameters on a reference line will override parameters on the corresponding file copy line.
Example:
;* layout portion
bar /x=1
...
;* INF portion
bar /x=2 ; INF file will have value 2

(3) In "relational" mode, each file copy command in the layout portion of the DDF must be referenced at least once in a reference command in the INF portion of the DDF. Any files that are not referenced will cause an error during pass 1. The /inf=no parameter must be specified on any file copy commands for files which are going to be omitted from the INF file (such as SETUP.EXE and SETUP.INF).

(4) In "relational" mode, UniqueFiles must be ON, because the destination file name is used in the INF portion of the DDF to refer back to file information.

4. M