Re: Running dxdiag
--- Mike [EMAIL PROTECTED]: > Well, if the little stub is overwritten by a correct native DLDLLhen > there is no problem at all. If some install overwrites it with an older > version than what apps expect (or Wine provides) then that might be a > problem, but that's just the generic DLDLLell the windows library design > implies. Windows XPXPas this nice new feature of Side-by-Side AsAssemblieshat is a .Net concept. It combined with Windows File Protection has in effect ended DLDLLell. Maybe we should look at implementing some sort of side-by-side system in Wine. Thanks Steven __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
Re: Running dxdiag
Juan Lang wrote: This isn't enough for new installers, either :( I have an MSI-based InstallShield installer that's looking for shdocvw.dll to see if IE6 is installed. (It isn't, but that's how it's looking for it.) Trouble is, how would this work with the native/builtin thing? Right now all our builtins don't live in the system directory, so we can always override whatever native dll happens to get dropped there. If we put a little stub PE header in there, what's to stop an installer from overwriting it? Or, would this cause a problem? Well, if the little stub is overwritten by a correct native DLL then there is no problem at all. If some install overwrites it with an older version than what apps expect (or Wine provides) then that might be a problem, but that's just the generic DLL Hell the windows library design implies. thanka -mike
Re: Running dxdiag
Hi Mike, > Dumping the headers is necessary for stupid installers that map DLL files > manually and rummage around in the headers to figure out versions and > stuff ... simply having an empty file isn't enough for all of them I'm > afraid :( This isn't enough for new installers, either :( I have an MSI-based InstallShield installer that's looking for shdocvw.dll to see if IE6 is installed. (It isn't, but that's how it's looking for it.) Trouble is, how would this work with the native/builtin thing? Right now all our builtins don't live in the system directory, so we can always override whatever native dll happens to get dropped there. If we put a little stub PE header in there, what's to stop an installer from overwriting it? Or, would this cause a problem? --Juan __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
Re: Running dxdiag
Dumping the headers is necessary for stupid installers that map DLL files manually and rummage around in the headers to figure out versions and stuff ... simply having an empty file isn't enough for all of them I'm afraid :( I have some basic stuff for this (which I wrote for some other reasons quite long ago - support of debug information), so if someone is interested, drop me a note. A+ -- Eric Pouech
Re: Running dxdiag
On Fri, 14 Jan 2005 19:33:19 +0100, Ivan Leo Puoti wrote: > Why can't wineprefixcreate just make links to the dlls? Like I said originally: Dumping the headers is necessary for stupid installers that map DLL files manually and rummage around in the headers to figure out versions and stuff ... simply having an empty file isn't enough for all of them I'm afraid :( The DLLs wine ships aren't actually PE DLLs so symlinking to them directly won't do the trick.
Re: Running dxdiag
Somebody needs to write a program that dumps the NT headers of each winelib DLL to the appropriate place in the virtual drive C when it's first created (in wineprefixcreate). Why can't wineprefixcreate just make links to the dlls? Ivan.
Re: Running dxdiag
On Thu, 13 Jan 2005 19:56:45 +0100, Paul Vriens wrote: > How can we act on an app which checks for a 'physical' presence of a > dll? Somebody needs to write a program that dumps the NT headers of each winelib DLL to the appropriate place in the virtual drive C when it's first created (in wineprefixcreate). It's been talked about before, Andi even did it once but then his patch was eaten by wayward hardware before it could be submitted. So we really need somebody to pick this project up and run with it. Dumping the headers is necessary for stupid installers that map DLL files manually and rummage around in the headers to figure out versions and stuff ... simply having an empty file isn't enough for all of them I'm afraid :( thanks -mike
Running dxdiag
Hi, I was trying to run dxdiag (just for the fun of it). Dxdiag complains that it cannot find any dll. This is correct because what it does is check the directories in the "Path". The dll's are of course not present on a clean install as all are builtin. Loading a dll takes care of this by checking the DllOverrides and acts according to that if it cannot find the dll. How can we act on an app which checks for a 'physical' presence of a dll? For now I did 'ln -s /usr/local/lib/wine/ddraw.dll.so ddraw.dll' to get around this. This is of course not very flexible. Any ideas? Or will any solution yield in a performance drop as we have to do some extra checks? Paul.