Re: make builtin dlls visible for applications?
2) place dummy files for all builtin dlls in c:\windows\system32
I believe this is the correct approach. I know of at least one InstallShield installer (that uses MSI) that searches for IE by looking for the file shdocvw.dll and checking its version. Presumably we'd like our users to have the option of installing programs using all builtin DLLs, even with silly checks like this. Eric once mentioned he had some hacky program that parsed PE headers that we might be able to coerce into creating such dummy DLLs. What we're looking for (besides him posting the code) is a volunteer to work on it.
hmm I guess you would get into trouble if you use WINEDLLOVERRIDE. Wouldn't LoadLibrary try to load those dummy files?
Someone proposed a hack where the loader would know that these DLLs are dummies based on a wine-specific flag in the header. --Juan __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On Thu, 2005-11-17 at 17:05 -0800, Juan Lang wrote:
2) place dummy files for all builtin dlls in c:\windows\system32
I believe this is the correct approach. I know of at least one InstallShield installer (that uses MSI) that searches for IE by looking for the file shdocvw.dll and checking its version. Presumably we'd like our users to have the option of installing programs using all builtin DLLs, even with silly checks like this.
Eric once mentioned he had some hacky program that parsed PE headers that we might be able to coerce into creating such dummy DLLs. What we're looking for (besides him posting the code) is a volunteer to work on it.
hmm I guess you would get into trouble if you use WINEDLLOVERRIDE. Wouldn't LoadLibrary try to load those dummy files?
Someone proposed a hack where the loader would know that these DLLs are dummies based on a wine-specific flag in the header.
--Juan
Doesn't have to be a flag specifically... I have the PE documentation and there is allowance for hacky tricks in the PE loader from what I remember reading... Im also looking at porting wine to another platform as well so need such information myself... Jeremy Send instant messages to your online friends http://au.messenger.yahoo.com
On Friday 18 November 2005 02:05, Juan Lang wrote:
Someone proposed a hack where the loader would know that these DLLs are dummies based on a wine-specific flag in the header.
Why a dummy? Why not ship a full PE DLL with a flag saying it's a built-in? That way file existence checks, PE header checks, LOAD_LIBRARY_AS_DATA_FILE, resource scraping, even some copy protection checks, etc. could all work. -Hans
Hans Leidekker schrieb:
On Friday 18 November 2005 02:05, Juan Lang wrote:
Someone proposed a hack where the loader would know that these DLLs are dummies based on a wine-specific flag in the header.
Why a dummy? Why not ship a full PE DLL with a flag saying it's a built-in? That way file existence checks, PE header checks, LOAD_LIBRARY_AS_DATA_FILE, resource scraping, even some copy protection checks, etc. could all work.
Hmm I'm not sure if you could put the linux import dependencies(from other .so libs) into the PE header properly? So from that point of view you will never have a "fully working" DLL file.(At least not without adding hacks to wine again to recognize these dependencies, if put in the PE header.) Whats the problem with LOAD_LIBRARY_AS_DATAFILE? Otherwise I would agree with Juan that building some dummy files containing just PE header plus maybe some sort of version info would be enough. And iirc isn't the PE header also mapped into memory when a dll is loaded? In which case there must be already code for that in wine(though I haven't checked that yet).
-Hans
Hans Leidekker wrote: > On Friday 18 November 2005 02:05, Juan Lang wrote: > > >>Someone proposed a hack where the loader would know that these DLLs are >>dummies based on a wine-specific flag in the header. > > > Why a dummy? Why not ship a full PE DLL with a flag saying it's a built-in? > That way file existence checks, PE header checks, LOAD_LIBRARY_AS_DATA_FILE, > resource scraping, even some copy protection checks, etc. could all work. that's not that easy. using .so file allows you to (without pain): - handle relocation in memory - resolve dependencies to other .so libraries If you'd have to store the equivalent of the .so file as a binary array in a PE file, you'll have to sort this out by hand (so more or less write a full ELF loader). Last but not least, moving to a full PE file for our builtin DLLs is not easily possible, especially because of the way we handle NE modules. A+ -- Eric Pouech
participants (5)
-
Belxjander Serechai -
Eric Pouech -
Hans Leidekker -
Juan Lang -
Peter Beutner