Hi,
I'm working on getting ie6 sp1 to install without using any native dlls. The install is fine until about 78% of the way through installing the files, the installer loads a native advapi32 that it downloaded to a temp directory and then the install seems to pause as this message is continuously printed:
fixme:thunk:CommonUnimpStub generic stub: ?
I used WINEDLLOVERRIDES="advapi32=b" WINEDEBUG=+loaddll, and it still shows the downloaded native advapi32.dll being loaded. Does WINEDLLOVERRIDES only take dll's that are in the windows\system directory into account? I have a feeling that the install would go smoother if the builtin advapi32 was loaded instead of the native one. I'm guessing that the installer is calling LoadLibary("path to native advapi32")...that's just a guess though.
On Tue, 2004-09-28 at 23:09, James Hawkins wrote:
I'm working on getting ie6 sp1 to install without using any native dlls. The install is fine until about 78% of the way through installing the files, the installer loads a native advapi32 that it downloaded to a temp directory and then the install seems to pause as this message is continuously printed:
fixme:thunk:CommonUnimpStub generic stub: ?
I used WINEDLLOVERRIDES="advapi32=b" WINEDEBUG=+loaddll, and it still shows the downloaded native advapi32.dll being loaded. Does WINEDLLOVERRIDES only take dll's that are in the windows\system directory into account? I have a feeling that the install would go smoother if the builtin advapi32 was loaded instead of the native one. I'm guessing that the installer is calling LoadLibary("path to native advapi32")...that's just a guess though.
What Windows version are you reporting? I sometimes test IE and it seems to be broken with win98 atm.
Thanks Steven
I used WINEDLLOVERRIDES="advapi32=b" WINEDEBUG=+loaddll, and it still shows the downloaded native advapi32.dll being loaded.
You need WINEDLLOVERRIDES="*advapi32=b"
Yes I know that isn't what I said before. I suck :)
Yes I know that isn't what I said before. I suck :)
It's ok don't worry about it... thanks for the tip Mike.
On Wed, 29 Sep 2004 09:37:49 +0100, Mike Hearn m.hearn@signal.qinetiq.com wrote:
I used WINEDLLOVERRIDES="advapi32=b" WINEDEBUG=+loaddll, and it still shows the downloaded native advapi32.dll being loaded.
You need WINEDLLOVERRIDES="*advapi32=b"
Yes I know that isn't what I said before. I suck :)
On Wed, 29 Sep 2004 09:28:46 -0400, James Hawkins truiken@gmail.com wrote:
Yes I know that isn't what I said before. I suck :)
It's ok don't worry about it... thanks for the tip Mike.
On Wed, 29 Sep 2004 09:37:49 +0100, Mike Hearn m.hearn@signal.qinetiq.com wrote:
I used WINEDLLOVERRIDES="advapi32=b" WINEDEBUG=+loaddll, and it still shows the downloaded native advapi32.dll being loaded.
You need WINEDLLOVERRIDES="*advapi32=b"
Yes I know that isn't what I said before. I suck :)
-- James Hawkins
I used WINEDLLOVERRIDES="*advapi32=b" and the installer got a little further. Not perfect, but better.
Back when I used no dll overrides (because I thought advapi32=b would work for all instances of an advapi32.dll) I got this error:
err:vxd:VMM_VxDCall Using the native Win95 advapi32.dll is no longer supported. err:vxd:VMM_VxDCall Please configure advapi32 to builtin.
If we don't want any user using a native advapi32.dll no matter what the circumstances, shouldn't the default override for advapi32 be *advapi32=b (no matter whether it's in a config file or the registry or whatever)? If the user is not using a config file, where are the default overrides stored btw?
If we don't want any user using a native advapi32.dll no matter what the circumstances, shouldn't the default override for advapi32 be *advapi32=b (no matter whether it's in a config file or the registry or whatever)? If the user is not using a config file, where are the default overrides stored btw?
Correct. There is a hardcoded list somewhere in the source. I forget where, I discovered it once. See if you can find it, and when you do, patch it to force advapi32 to be builtin.
thanks -mike
James Hawkins truiken@gmail.com writes:
err:vxd:VMM_VxDCall Using the native Win95 advapi32.dll is no longer supported. err:vxd:VMM_VxDCall Please configure advapi32 to builtin.
If we don't want any user using a native advapi32.dll no matter what the circumstances, shouldn't the default override for advapi32 be *advapi32=b (no matter whether it's in a config file or the registry or whatever)?
The Win95 advapi32 cannot work, but the NT one can.
The Win95 advapi32 cannot work, but the NT one can.
Is there ever a time when we would want to use the native NT advapi32? I just sent a patch to make sure only the builtin advapi32 gets loaded, so that probably won't be committed if this is the case.
On Thu, 30 Sep 2004 10:16:26 -0700, Alexandre Julliard julliard@winehq.org wrote:
James Hawkins truiken@gmail.com writes:
err:vxd:VMM_VxDCall Using the native Win95 advapi32.dll is no longer supported. err:vxd:VMM_VxDCall Please configure advapi32 to builtin.
If we don't want any user using a native advapi32.dll no matter what the circumstances, shouldn't the default override for advapi32 be *advapi32=b (no matter whether it's in a config file or the registry or whatever)?
The Win95 advapi32 cannot work, but the NT one can.
-- Alexandre Julliard julliard@winehq.org
James Hawkins truiken@gmail.com writes:
The Win95 advapi32 cannot work, but the NT one can.
Is there ever a time when we would want to use the native NT advapi32?
There might be, yes.
I just sent a patch to make sure only the builtin advapi32 gets loaded, so that probably won't be committed if this is the case.
No, unlike with kernel etc. there's no reason that native advapi32 cannot work, so it must not be added to that list.
-
Alexandre Julliard -
James Hawkins -
Mike Hearn -
Mike Hearn -
Steven Edwards