Andreas Mohr wrote:
>> Out of interest, why do you want fake NE/PE DLLs? Is it because some programs
>> try to 'manually' parse the DLLs rather than using system routines?
>I thought that it's better to include a header (which would be small anyway)
>for these files instead of just "touch"ing them.
>
>And I previously thought of adding different VS_VERSION_INFO resources for
>different Windows versions to the fake DLLs.
>But this is not good, I think.
>...
This still doesn't tell me why you want to use NE/PE DLL stubs... Is it so
that you can find the resources easily? If so, would it be possible to tell
gcc to store the resources in a .rsrc section as MSDEV does, and then just
parse the ELF directly to find the resources.
> How do we implement the reading of the VERSION_INFO ?
> ...
> And a GetFileVersionInfo*() normally happens directly before a LoadLibrary()
> anyway.
> Hmm, a question about that:
> If we do the LoadLibrary() in GetFileVersionInfo*() and do a FreeLibrary()
> at the end (usage count down to 0 again ! -> removal),
I don't think you can make GetFileVersionInfo*() do LoadLibrary() as this will
need to drag in and initialise _all_ the dependency libraries too, which could
take nearly forever. Plus, I'm sure you can do this on EXE files as well as
DLL files.
I'd have thought your better off writing a simplified NE/PE parser that just
locates the resource block and pulls the version info out of it.
If you do this, then you can also use it to implement the convenience
functions for getting other resources, such as string tables, and also
implement the functions to _change_ those resources.
Also if you do a NE/PE parser as I've suggested, why not make it able to
handle ELF files too? :-)
David
