--- 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
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
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
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 qui
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 ... sim
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.
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 wineprefi
