https://bugs.winehq.org/show_bug.cgi?id=56136
--- Comment #8 from Eric Pouech eric.pouech@gmail.com --- (In reply to Zeb Figura from comment #7)
Creating a test DLL isn't hard. We don't even need to do it manually like in kernel32:loader. Tests are compiled with mingw, and we have build system support for adding a custom DLL as a resource (cf. msi, setupapi for examples).
I'm just confused about why we need a dedicated test DLL. As far as I can tell the function just extracts imports and resources [which we could test against any system module, or the test exe itself] and debug info [which I don't think we can meaningfully test and probably don't even need to implement].
I does more than that. The callback is called with (each line = 1 call): - DOS header - PE header - PE sections (one call per section?) PE header (in callback) is modified from file version (eg zeroeing some fields). Still to be understood for the resources how many calls are generated. From Henrik's comments, it looks like the handling of this is not straightforward (didn't look into it). We also have to be sure if the passed data to the callback are the exact version of the image or a modified version thereof.
Note: in the context of #1, we may have to replicate the same number of callbacks with data (potentially modified) and size. If a digest is computed from the callback bits (and how the data are feed to the hash algo, and the hash algo itself), it may generate different results.
There's already a test in imagehlp/tests/image.c with a hand crafted generated DLL for ImageGetDigestStream. So that should be extended.