@example12345678912345678 Morning, are you still on board with this tool? I'v managed to repack (without modification) to an 99.99% exact match. The only missing part left is 2 bytes that represents the cab ID, far as i'v learned from documentation this is only used by the extract process to identify that they belong together along with at 1 byte that represents the cab order. Anyway, i'm pretty satisfied but i will study the source code and see if i can determine exactly how cab ID is generated. Lemme know...
Oh, can you create split cab files with cabarc ? I remember trying with no luck. Also it looks like this version of cabarc cannot compress in Quantum mode. So how did you manage to create correct cab files ? So how did you do that ? Also thank you for the .bat files, that lists the files in the .cab archives in the correct order. I retried, my precopy2.cab file is even smaller, but still bigger than the original file. So for now I'm quite far from a perfect result.
This is fantastic ! So I was wrong, I probably missread the hex values as I was 100% sure they still used Quantum for Windows 98... I remember finding a PDF file about CAB fies header. I changed to LZX, still got a different file. But after adding .Set FolderSizeThreshold=1000000 It's much better. How did you find that value ? I also added these, indeed : .Set MaxDiskFileCount=69 .Set DiskLabel1=2 .Set DiskLabel2=3 Now I indeed only have 2 bytes of difference between the rebuilt files and the original files. I'll try figuring that out.
That would be awesome. Afaik 95 used it, changed to LZX in 98 Reading specifications, trial and error... nothing was given in clear txt from the good guys at Redmond
Fyi, makecab and legacy makecab deviates sligthly with LZX, suggesting that some data is changed/added/removed. Not necessarily the LZX compreesion itself changed in it's specs...
I also noticed something, while under 98+ the product type is in setupx.dll, but it looks like the one listed in setuppp.inf is also changed. Should it be changed too ? Or it has no impact ?
This was the document I found : download microsoft com/download/4/d/a/4da14f27-b4ef-4170-a6e6-5b1ef85b1baa/[ms-cab].pdf And this seems to be the ID in question, indeed stored on 2 bytes : Code: setID: Specifies an arbitrarily derived (random) value that binds a collection of linked cabinet files together. All cabinet files in a set will contain the same setID field value. This field is used by cabinet file extractors to ensure that cabinet files are not inadvertently mixed. This value has no meaning in a cabinet file that is not in a set. So if it's really random, then the best thing you can do is to find a way to read these 2 bytes, store them somewhere, rebuild the CAB and edit the header with the old ID. What is odd, I tried generating the CAB multiple times, I got the same ID.
That was my assumption too, but if it was truly random then we would get a unique id every time. Differnt OS and time/date is not a factor, file attributes is not a factor either far as I can tell (this is of course if files are not changed from initially) This is just to see if we could unpack/repack with 100% match for starter. There are lot's of commands to add to directive later. It's possible to add space for later signing but if that's a factor...? Atm it's mind-boggling but i'm pretty confident it's a simple thing...
Absolutely an opsjon. Then the question is, is this id really used other than identify cab's that are chained as one archive? It will for sure change the moment some files are patched.
Is it possible to make a patch for cab files after setupx.dll edited and cab created. Hex difference of previous cab and after cab difference should be 4 bytes (setupx.dll editing) probably/i think. I have searched, such a difference for win98. Can be done probably but same hex values not match for win98se because of new and different files. If Sajjo share hex difference before and after precopyx.cabs we can see.
No, CAB is compressed, so a tiny difference in a file will create a huge difference in the compressed archive.
Problem is that these cab's are not equaly maid (some have more files etc...) This is only a POC for cab's uploaded (from Win 98 FE internal) You can do a loop'ed script to read original cab's with cabarc, get file list, size, order and import these values to a directive file That's not to big of an job to make Possible changes "<--" in addition to file listing Code: Listing of cabinet file 'PRECOPY1.CAB' (size 1243136): 69 file(s), 2 folder(s), set ID 21648, cabinet #0 Code: ; Diamond Directive File .Option Explicit .Set SourceDir=".\PRECOPY1" .Set DiskDirectoryTemplate=".\" ;.Set DiskLabelTemplate=* .Set DiskLabel1=2 ;<-- (possible) .Set DiskLabel2=3 ;<-- (possible) .Set CabinetNameTemplate="PRECOPY*.CAB" .Set MaxDiskSize1=1243136 ;<-- (most likely) .Set MaxDiskFileCount=69 ;<-- (most likely) .Set CabinetFileCountThreshold=0 .Set FolderFileCountThreshold=0 .Set FolderSizeThreshold=1000000 .Set UniqueFiles=ON .Set RptFileName=nul .Set InfFileName=nul .Set Cabinet=ON .Set Compress=ON .Set CompressionType=lzx .Set CompressionMemory=21 This is an oddball ;.Set DiskLabelTemplate=* .Set DiskLabel1=2 .Set DiskLabel2=3 Normally you would expect 1/2 (not 2/3) and that would be covered with .Set DiskLabelTemplate=*
I think I noticed something similar with MSZIP while messing with some Windows NT files (most people think CAB came first with Windows 95, but they actually started using it with Windows NT 3.5). If I compress a file with a later version using MSZIP the output file differs. Thank you for the files !