material and documents to develop wimlib

[farmerspring]

i'm curious about how Eric Biggers(the main author of wimlib) collect materials(such as documents) to develop wimlib.

when I tried to write a simple program deal with wim file, the most detailed document I could find was the white paper(Windows Imaging File Format.rtf,https://www.microsoft.com/en-us/downloa ... x?id=13096). Actually, it doesn't cover enough detail to help me

fully understand wim file, for example the 32bits unknow field after sha1 hash in directory entry structure(i find this by read wimlib source code).

another example is .esd image file, i simplely searched online and i found nothing about this file format.

So i'm so curious about how Eric Biggers had written a so powerful wimlib? Is he collect more documents than me or he dived into the image file and found

details by himself?

[synchronicity]

There are some links in the "REFERENCES" section of the README file. But, like you I don't have access to any non-public information, so I've just had to figure out things myself where there are gaps. For example, when I heard that DISM had added support for extended attributes, I just captured a WIM image with 'DISM /EA' and checked where it stored the extended attributes and in what format. Then I made wimlib store them the same way. And I test creating archives with wimlib-imagex and extracting them with DISM, and vice-versa.

The "ESD" format is basically WIM with solid (multi-file) compression support; I had to figure it out likewise by inspecting the data, and trial and error. I don't know of any formal documentation for it, sorry. You can check the wimlib source code though... I've tried to mention important information in comments.

fully understand wim file, for example the 32bits unknow field after sha1 hash in directory entry structure(i find this by read wimlib source code).

I'm afraid I still don't know for sure what that field is either; that's why I called it "unknown". But I suspect it's just padding. Looking at 'struct _DIRENTRY' in Microsoft's WIM "documentation", the struct is not marked as packed. Assuming that's correct, the 'LARGE_INTEGER liHardLink' field must be aligned to an 8-byte boundary as per the ABI. That implies there are 4 bytes of implicit padding after the preceding field 'bHash', as 'bHash' already happens to be 8-byte aligned, but is only 20 bytes in size.

[farmerspring]

Thanks very much for your reply and extraordinary work on wimlib. It costed me so much time to just figure out wim file format........