[aniperleo]

Hi all,

I'm desperately trying to understand cabinet.dll so that I can write my own cabinet.dll replacement. My first step would be to use CABINET.DLL with RUNDLL32 so that I can know how to structure my new file, for instance:

I tried running this command: RUNDLL32 CABINET.DLL,Extract FOO.CAB

That will not work, however I know that Extract is a valid command, I just don't know the correct syntax for using it. At support.microsoft I found these commands...

http://support.microsoft.com/dllhelp/?fid=...;l=55&det=1

DeleteExtractedFiles
DllGetVersion
Extract
FCIAddFile
FCICreate
FCIDestroy
FCIFlushCabinet
FCIFlushFolder
FDICopy
FDICreate
FDIDestroy
FDIIsCabinet
FDITruncateCabinet
GetDllVersion

Can anyone help me out?

This post has been edited by aniperleo: 25 June 2006 - 07:07 PM

[RogueSpear]

I'm not sure what your level of expertise is, but interfacing to cabinet.dll is a bit more complicated than one would first imagine. First, you're going to want to download the CAB SDK from Microsoft and give it a read. Just make sure you have lots of coffee (or some uppers) as this is not an exiting read.

If you're interested in something .NET, there's a fellow who managed to write a class in C# that is essentially a wrapper for cabinet.dll:

http://www.devsource...,1731188,00.asp

[aniperleo]

Thanks for your help. My goal is to create my own cabinet.dll which uses 7z compression instead of cab compression. Imagine the size of your windows discs after that

Also, is there anyway to interface with the dll using rundll32?

This post has been edited by aniperleo: 25 June 2006 - 08:12 PM

[RogueSpear]

Indeed that would be an awesome creation. It has been discussed here before, but nobody has yet taken up the task. It's way way above and beyond my expertise, but I wish you the best in your efforts.

[aniperleo]

Is anyone here skilled in making DLLs or playing with Windows or have an interest in joinging me on my venture? I can devote a lot of time and energy to this project.

[Wraith]

The only files that would end up being substantially smaller would be the CAB files - when compressing single files with 7z(LZMA) and single files with CAB(LZO) is minimal.
Compressing multiple files is where the compression ratios increase.

A bunch of tests I just did:

shell32.dll, 7z: 2,234kB
oembios.bin, 7z: 12,975kB
webfldrs.msi, 7z: 1,681kB

shell32.dll, cab: 3,134kB
oembios.bin, cab: 12,806kB
webfldrs.msi, cab: 1,681kB

shell32.dll, slim: 1,928kB
oembios.bin, slim: 12,872kB
webfldrs.msi, slim: 1,660kB

So you can see, some files are compressed nicely with 7z, some are bigger, and some just don't change. (Slim ones are there for comparison only)


The only problem I can see with redoing cabinet.dll is that functions WILL need to pass through to the original cabinet.dll if they find something that it needs to extract normally. A lot of programs rely on the cab format, and you'll find that certain things will not function unless it can cope with normal LZO cab format. (I think MSI acts that way...)

And in case you were wondering, here was the batch files that I used to test with:

copy c:\windows\system32\shell32.dll .
copy c:\windows\system32\oembios.bin .
copy c:\windows\system32\webfldrs.msi .

makecab c:\WINDOWS\system32\shell32.dll
makecab c:\WINDOWS\system32\oembios.bin
makecab c:\WINDOWS\system32\webfldrs.msi

"C:\Program Files\7-zip\7z.exe" a -t7z -m0=BCJ2 -m1=LZMA:d=23:fb=64:a=2:lc=7:mf=bt3 -m2=LZMA:d=18:fb=66:a=2:lc=8:lp=2:mf=bt2 -m3=LZMA:d=18:fb=81:a=2:lc=0:lp=2:mf=bt2 -mb0:1 -mb0s1:2 -mb0s2:3 shell32.dll.7z shell32.dll
"C:\Program Files\7-zip\7z.exe" a -t7z -m0=BCJ2 -m1=LZMA:d=23:fb=64:a=2:lc=7:mf=bt3 -m2=LZMA:d=18:fb=66:a=2:lc=8:lp=2:mf=bt2 -m3=LZMA:d=18:fb=81:a=2:lc=0:lp=2:mf=bt2 -mb0:1 -mb0s1:2 -mb0s2:3 oembios.bin.7z oembios.bin
"C:\Program Files\7-zip\7z.exe" a -t7z -m0=BCJ2 -m1=LZMA:d=23:fb=64:a=2:lc=7:mf=bt3 -m2=LZMA:d=18:fb=66:a=2:lc=8:lp=2:mf=bt2 -m3=LZMA:d=18:fb=81:a=2:lc=0:lp=2:mf=bt2 -mb0:1 -mb0s1:2 -mb0s2:3 webfldrs.msi.7z webfldrs.msi

slim23d.exe a -v -o218 -m912 -- shell32.dll.slim shell32.dll
slim23d.exe a -v -o218 -m912 -- oembios.bin.slim oembios.bin
slim23d.exe a -v -o218 -m912 -- webfldrs.msi.slim webfldrs.msi

You may be able to tweak the ratios a bit - the 7z flags I was using were geared for executable compression.
slim can be found at: http://www.bars-trade.com/slim/ - unfortunately it takes AGES to compress with it, so it's listed for comparison purposes only.

This post has been edited by Wraith: 26 June 2006 - 05:09 AM

[GreenMachine]

OK, Who let the Cat (The Wraith) outta the bag?

I guess classes are out, and you have a little too much free time ... Sunny and warm on the Riviera, bet you cannot say that down under!

Good to see you around, Wraith!

[Wraith]

GreenMachine, on Jun 26 2006, 10:39 PM, said:

OK, Who let the Cat (The Wraith) outta the bag?

I guess classes are out, and you have a little too much free time ... Sunny and warm on the Riviera, bet you cannot say that down under!

Good to see you around, Wraith!

Haha, I've been around, just haven't bothered responding to anything.
Classes finished 8 months ago, full time work instead
Good to be back I suppose, slowly getting around to getting XPlode 5 (and the people wanting it) out of my hair

This post has been edited by Wraith: 26 June 2006 - 05:43 AM

[RogueSpear]

When this was discussed previously I did a test on compressing the contents of driver.cab with 7-Zip and it was a noticeable difference. Sure, nothing is ever the best all of the time, but the flexibility of having 7z as an option would be nice. Unfortunately I do see a ton of complications with this project - like the possibility of Windows rejecting the new cabinet.dll file because of a different MD5 or a number of other reasons.

[ibach]

aniperleo, on Jun 26 2006, 02:42 AM, said:

Is anyone here skilled in making DLLs or playing with Windows or have an interest in joinging me on my venture? I can devote a lot of time and energy to this project.

sure... love to help!

[Glenn9999]

Yes I know this is thread was started 5 years ago and the last response was 3 years ago, but I came across this and bookmarked it because I uncovered enough knowledge about the topic that I had the same thought as the original poster. I doubt any of the people in this thread are still here and obviously the interest in this wasn't too good for this to not be pursued then, but some thoughts and a question.

aniperleo, on 25 June 2006 - 08:07 PM, said:

Thanks for your help. My goal is to create my own cabinet.dll which uses 7z compression instead of cab compression. Imagine the size of your windows discs after that

Sounds okay (though this isn't quite accurate, CAB uses either MSZIP or LZX at the moment). Actually the CAB documentation is explicit enough. As I recall, the statement was even made in the docs that Microsoft intended the possibility of it being extended with different compression formats. That said, these functions use so many call backs that RUNDLL32 is not a possibility.

RogueSpear, on 26 June 2006 - 06:06 AM, said:

Unfortunately I do see a ton of complications with this project - like the possibility of Windows rejecting the new cabinet.dll file because of a different MD5 or a number of other reasons.

This was my question - what would be required to be able to have a full-on replacement of CAB compression in the OS? CABINET.DLL to be sure, but are there other files (probably CABARC.EXE and EXTRACT.EXE)? Would there be any complications with Windows itself, if I were to pursue this after my current project? The biggest complication that I see holding up such a project is getting good source for MSZIP and LZX to be able to support those (LZMA source is easy since the 7-zip source is out there). Otherwise, it would just be a matter of getting it done, along with making dead sure you call the proper callback functions in the right places and know the expected results. Lots of testing in different situations, including installs, would be required.

[jaclaz]

Glenn9999, on 05 August 2011 - 07:08 AM, said:

This was my question - what would be required to be able to have a full-on replacement of CAB compression in the OS? CABINET.DLL to be sure, but are there other files (probably CABARC.EXE and EXTRACT.EXE)? Would there be any complications with Windows itself, if I were to pursue this after my current project? The biggest complication that I see holding up such a project is getting good source for MSZIP and LZX to be able to support those (LZMA source is easy since the 7-zip source is out there). Otherwise, it would just be a matter of getting it done, along with making dead sure you call the proper callback functions in the right places and know the expected results. Lots of testing in different situations, including installs, would be required.

Let's make a deal.

• You write a CABINET.DLL replacement.
  
• You make sure it works as expected.
  
• You also fix SETUPLDR.BIN and NTLDR (if needed )
  
• I will take care of CABARC.EXE and EXTRACT.EXE, one way or the other.

The compression used is VERY SCARCELY documented AFAIK/AFAICR.

Maybe you can find something of use around here (and given links):
http://www.msfn.org/...ates-tools-etc/

jaclaz

[Glenn9999]

Still trying to get my current API implementation lined out, but I realized a couple of things that should really help:
1. There's an "Uncompressed" option in the CAB API, which should make it dead easy to get a CABINET.DLL framework going. The main problem in testing this is making sure it responds as the original CABINET.DLL does. Shouldn't be a problem after it gets written, whenever that might be. Compare the final files of each, compare the outputs from the macros and make sure they are the same.
2. Most of what happens is input buffer to output buffer kind of stuff so it should be easy to slot MSZIP, LZX, and anything else in that spot as long as one can find the straight buffer compress/decompress for each. That will be the main problem here past duplicating the original CABINET.DLL.

Question: How many things call DeleteExtractedFiles, DllGetVersion, Extract, and GetDllVersion ? These would probably be back-burner because Microsoft marks them as deprecated in the docs, but if it got that far, I wonder exactly how important implementations of those things would be... Edit: I just thought of something, if one wanted to, try implementing these functions and then throw up a big message box - that would reveal if these are necessary pretty quickly in testing.

We will see how things go, I'm sure. Other than those two things, it can be programmed however works best from an internal standpoint (depending on the target OS/machine. Therein would lie another question).

This post has been edited by Glenn9999: 02 September 2011 - 05:34 PM