Andreas Mohr wrote:
>
> Yes, I know, using LoadLibrary() for the file instead of directly reading
> the VERSION_INFO from the file might be rather slow for big DLL files,
> but I think we don't really have an alternative here...
> (as this solves the loadorder problem that otherwise would be pretty hard
> to fix IMHO).
> And programs most probably will use GetFileVersionInfo*() only once anyway.
> And in some months there will be only builtin DLLs left for the
> core system DLLs that we *need* to LoadLibrary() in order to get
> their VERSION_INFO.
> So the situations where we can use direct VERSION_INFO access will decrease
> anyway.
>
> 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),
> then the LoadLibrary() of the same file probably done by the Windows
> program some lines later will need to load the whole library again, no ?
> Maybe we should use a service timer callback for doing the FreeLibrary()
> 2 minutes later in order to keep the usage count from going to 0 before
> the program has loaded the library ?
>
> If my thoughts so far are OK for you, then I'll go for implementing it :)
>
Wasn't there some discussion about a week ago regarding LOAD_AS_DATAFILE (or
something to that effect) which is supposed to load the library into memory so that
you can get at all the resources and such, but not actually load it and resolve
dependencies.
I don't think it's properly implemented in Wine, but if you implement it then you
can use it to get the version info without making wine take 3 years to start up
because it's resolving everything twice, and without the need for a bad
(IMHO) timeout hack.
-Dave
