Hello again !
On Fri, Jul 21, 2000 at 01:12:21PM +0100, David Howells wrote:
> 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.
No, as I state above, I don't think any more that it's good to include
VERSION_INFO in the fake DLLs.
I didn't find a single program yet that tries to parse it directly,
and thus I don't think we should support it.
Wine is focussing on builtin DLLs after all, and that's a very good idea and
we should even "punish" programs that aren't programmed in a "portable" way
(i.e. they try to read the VERSION_INFO directly from the DLL file) IMHO.
I just want to make sure that programs that check for the presence
of a DLL file by means of OpenFile() find what they want.
And I think adding a small NE/PE header is good, too.
But don't let this get out of hand...
(sorry for not really explaining it before...)
> > 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.
Oh yes, that will be a real problem indeed.
So I'll have to do it the complicated way :-((
> 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.
Guess what we are already doing ?
The problem is that we don't support parsing of builtin DLLs yet.
And if we do, then we need to obey the loadorder in order to not deliver
wrong VERSION_INFO, which is a problem as the real DLL loading is also
determined by which DLL load fails due to e.g. *broken* DLLs and which one
succeeds (i.e. unknown failure factors play an important role here).
So the loadorder (and thus the decision of which file to parse
for VERSION_INFO) I figure out in the GetFileVersion*() functions will never
really be the same as the loading of the DLLs unfortunately.
But in most cases it'll be correct, of course.
> 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.
Yup.
I guess I'll write support for fake DLLs first.
The GetFileVersion*() thing will have to wait a bit, as it will require
massive support in the loader to figure out the loadorder correctly.
But maybe I'll forget about the loadorder for the beginning and try to
always parse the builtin DLL first and if that fails I branch to the old
NE/PE parser.
Of course that'll need a big FIXME "loadorder stuff missing" then ;-)
Andreas Mohr
