--dll buggy behaviour ?
Hi, I think that I spot a bug in the way --dll command line behaves. When trying to install internet explorer 5.01 sp2 in a empty tree/fake windows (protected with WINEPREFIX), the IE 5 installer launchs: trace:process:CreateProcessA app (null) cmdline "acmsetup /T nashbase.stf /S C:\\windows\\msdownld.tmp\\AS00AA6F.tmp\\ /QT /g \"C:\\WINDOWS\\IE Setup Log.Txt\"" trace:process:find_exe_file looking for "acmsetup" trace:process:open_exe_file Trying native exe "C:\\windows\\msdownld.tmp\\AS00AA6F.tmp\\acmsetup.exe" trace:process:CreateProcessA starting "C:\\windows\\msdownld.tmp\\AS00AA6F.tmp\\acmsetup.exe" as Windows binary trace:process:PROCESS_InitWine starting process name="C:\\windows\\msdownld.tmp\\AS00AA6F.tmp\\acmsetup.exe" file=4 argv[0]="acmsetup" trace:process:PROCESS_InitWine starting Win32 binary "C:\\windows\\msdownld.tmp\\AS00AA6F.tmp\\acmsetup.exe" trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\kernel32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\msdownld.tmp\AS00AA6F.tmp\advapi32.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\user32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\rpcrt4.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\ole32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\mpr.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\lz32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\version.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\msdownld.tmp\AS00AA6F.tmp\mssetup.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\shlwapi.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\msdownld.tmp\AS00AA6F.tmp\comctl32.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\SHELL32.dll' : builtin err:thunk:_loadthunk (commctrl.dll, Cctl1632_ThunkData16, comctl32.dll): Unable to load 'commctrl.dll', error 2 Note that tm comctl32.dll is native. However I have launched the instller with: wine --dll comctl32,commctrl=b ie5setup.exe In my config file however, I have the load order as "native, builtin" for both dlls. Is it possible that the --dll command line argument is not valid for subprocess/forks from the lauched process? Or is it a feature ? []'s Raul Dias
Raul Dias a écrit :
Is it possible that the --dll command line argument is not valid for subprocess/forks from the lauched process?
Or is it a feature ?
it's aa feature the --dll option is likely to disapear (as is it for now), and will only be supported thru registry settings, on a per app basis (the --dll switch may remain as a temporary setting of those registry entries) what you're looking for is provided by setting the proper DllOverride information under HKLM\\Software\\Wine\\Wine\\Config\\AppDefaults\\<appname>\\DllOverrides where <appname> is the name of you app HTH A+
Eric Pouech <eric.pouech(a)wanadoo.fr> wrote:
Raul Dias a �crit :
Is it possible that the --dll command line argument is not valid for subprocess/forks from the lauched process?
Or is it a feature ?
it's aa feature the --dll option is likely to disapear (as is it for now), and will only be supported thru registry settings, on a per app basis (the --dll switch may remain as a temporary setting of those registry entries)
what you're looking for is provided by setting the proper DllOverride information under HKLM\\Software\\Wine\\Wine\\Config\\AppDefaults\\<appname>\\DllOverrides
where <appname> is the name of you app
HTH
A+
Ok, change everything in config: <...> [DllOverrides] "comctl32" = "builtin" "commctrl" = "builtin" <...> [AppDefaults\\acmsetup.exe\\DllOverrides] "comctl32" = "builtin" "commctrl" = "builtin" and I kept --dll commctrl,comctl32=b ie5setup.exe does load the builtin version of comctl32. Later on, ie5setup launchs acmesetup.exe. Now acmesetup.exe loads its own comctl32 no matter what. The problem is that I don't have commctrl.dll (native), so it will fail. []'s Raul Dias
the --dll option is likely to disapear (as is it for now), and will only be supported thru registry settings, on a per app basis (the --dll switch may remain as a temporary setting of those registry entries)
what you're looking for is provided by setting the proper DllOverride information under
HKLM\\Software\\Wine\\Wine\\Config\\AppDefaults\\<appname>\\DllOverrides
where <appname> is the name of you app
HTH
I agree, but what do you need to write in order to change the dlls for a built-in application ? A question was already asked on the list, but no valuable answer was found. The builtin application chosen was wcmd. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
I agree, but what do you need to write in order to change the dlls for a built-in application ? A question was already asked on the list, but no valuable answer was found. The builtin application chosen was wcmd. wcmd.exe should work. in fact, this should be inserted in the wine config file which will populate dynamically the registry (writting directly to the registry files won't work.
for example, add this to ~/.wine/config to run shell32/shell as native by default [AppDefaults\\wcmd.exe\\DllOverrides] "shell32"="n,b" "shell"="n,b" (see documentation/samples/config for more details and examples) A+
Oi, Eric Pouech <eric.pouech(a)wanadoo.fr> wrote:
I agree, but what do you need to write in order to change the dlls for a built-in application ? A question was already asked on the list, but no valuable answer was found. The builtin application chosen was wcmd. wcmd.exe should work. in fact, this should be inserted in the wine config file which will populate dynamically the registry (writting directly to the registry files won't work.
Why not? I was thinking that this would be a good way to add specific apps overrides to the global registry (thru regapi).
for example, add this to ~/.wine/config to run shell32/shell as native by default
[AppDefaults\\wcmd.exe\\DllOverrides] "shell32"="n,b" "shell"="n,b"
(see documentation/samples/config for more details and examples)
In my original issue (with IE 5 installer), I set the default DllOverrides and the AppDefaults\\acmesetup.exe\\DllOverrides to "comctl32"="builtin" "commctrl"="builtin" and --dll comctl32,commctrl=b acmesetup.exe still loads its own comctl32.dll The only way in this situation to get IE 5 installed is to use a native commctrl.dll. I don't know the win32 api too well. However if it is possible for an application to use its dll (and override the config) which debugmsg channel will show this?
A+
[]'s Raul Dias
Hi! Raul Dias wrote:
I set the default DllOverrides and the AppDefaults\\acmesetup.exe\\DllOverrides to "comctl32"="builtin" "commctrl"="builtin"
and --dll comctl32,commctrl=b
acmesetup.exe still loads its own comctl32.dll
Maybe it's just a typo, but isn't it "acmsetup.exe" and not "acmesetup.exe"? Looking in the cab-files of an IE6 setup cd, I only see "acmsetup"... Philipp
Raul Dias a écrit :
Oi,
Why not?
I was thinking that this would be a good way to add specific apps overrides to the global registry (thru regapi).
because this part of the registry (the HKLM\\Wine\\Wine\\Config) is never actually saved back at wine exit it's filled, at Wine startup, with the contents of the wine config file A+
works, thanks. (tested with Desktop property to have a seeable result ;))
wcmd.exe should work. in fact, this should be inserted in the wine config file which will populate dynamically the registry (writting directly to the registry files won't work.
for example, add this to ~/.wine/config to run shell32/shell as native by default
[AppDefaults\\wcmd.exe\\DllOverrides] "shell32"="n,b" "shell"="n,b"
(see documentation/samples/config for more details and examples)
A+
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
I have a problem with wcmd. I set "Desktop" to 640x480 for wcmd in .wine/config. wcmd should display its window in the desktop, for now it doesn't. Steps to reproduce it: set global "Desktop" to "N" in x11drv section. add a Appdefaults entry for wcmd.exe and set "Desktop" = N in x11drv section. launch wcmd: a desktop is opened but wcmd opens its own window. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Sylvain Petreolle a écrit :
I have a problem with wcmd.
I set "Desktop" to 640x480 for wcmd in .wine/config. wcmd should display its window in the desktop, for now it doesn't.
Steps to reproduce it: set global "Desktop" to "N" in x11drv section. add a Appdefaults entry for wcmd.exe and set "Desktop" = N in x11drv section.
launch wcmd: a desktop is opened but wcmd opens its own window.
you need to set the Desktop for wineconsole.exe not wcmd.exe (a CUI app doesn't have a window, so it doesn't use the Desktop option) A+
Eric Pouech a écrit :
Sylvain Petreolle a écrit :
I have a problem with wcmd.
I set "Desktop" to 640x480 for wcmd in .wine/config. wcmd should display its window in the desktop, for now it doesn't.
Steps to reproduce it: set global "Desktop" to "N" in x11drv section. add a Appdefaults entry for wcmd.exe and set "Desktop" = N in x11drv section.
launch wcmd: a desktop is opened but wcmd opens its own window.
you need to set the Desktop for wineconsole.exe not wcmd.exe (a CUI app doesn't have a window, so it doesn't use the Desktop option)
two more words : - this settings will be shared by all CUI programs (not so good) - but, I've started working on a per app (and in fact it's even a bit more complex than that) settings for wineconsole where you can decide size/colors...of the console window A+
Raul Dias <chaos(a)swi.com.br> writes:
However I have launched the instller with: wine --dll comctl32,commctrl=b ie5setup.exe
In my config file however, I have the load order as "native, builtin" for both dlls.
Is it possible that the --dll command line argument is not valid for subprocess/forks from the lauched process?
The -dll argument is passed to child processes. However the problem in your case is that the dll is not loaded from the standard directory, so it doesn't match the default loadorder. You should either specify the full dll path explicitly, or use a wildcard entry like this: "*comctl32" = "builtin" -- Alexandre Julliard julliard(a)winehq.com
participants (5)
-
Alexandre Julliard -
Eric Pouech -
Philipp Wollermann -
Raul Dias -
Sylvain Petreolle