http://bugs.winehq.org/show_bug.cgi?id=8945
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #8130 is|0 |1 obsolete| |
--- Comment #4 from Anastasius Focht focht@gmx.net 2007-09-19 13:21:19 --- Created an attachment (id=8145) --> (http://bugs.winehq.org/attachment.cgi?id=8145) WINEDEBUG=+loaddll,+msi,+msidb,+seh,+tid wine Setup.exe
Hello,
following are some information collected so far that might be of interest to get rid of native stuff and resolve some adobe installer issues ... Not complete yet.
============ JScript / scripting host ============
Not much to say. Native is currently needed until wine implements this.
============ shell ui interfaces (process dialog box - browseui) ============
The explorer style progress dialog box object which the setup uses is implemented and exposed in BrowseUI.dll (windows shell interfaces ui).
CLSID_ProgressDialog -> {F8383852-FCD3-11D1-A6B9-006097DF5BD4} IProgressDialog -> {EBBC7C04-315E-11d2-B62F-006097DF5BD4}
(defined in Platform SDK "ShlGuid.h")
The embedded typelib doesn't contain the CLSID - so self-register dll wont help here. The registry entries are created by windows installation. You have to create the CLSID entry manually as pointed out by comment #1
The interface is well documented in MSDN and the implementation should be straight forward.
============ msxml ============
I dual debugged this on windows and wine (with builtin first) to get some more info.
The first thing i noticed is that wine's msi product installation was missing a command line parameter:
--- snip windows msi --- MSI (c) (98:28) [11:04:54:500]: ******* RunEngine: ******* Product: Z:\mnt\iso\Adobe CS3\WinMediaBootstrapper.msi ******* Action: ******* CommandLine: ADOBE_SETUP=1 MSIRESTARTMANAGERCONTROL=Disable PROPERTY_FILE="d:\Temp\adb9C.tmp" --- snip windows msi ---
--- snip wine trace --- 0017:Call msi.MsiInstallProductW(007f07c0 L"Z:\mnt\iso\Adobe CS3\WinMediaBootstrapper.msi",007f01e8 L" ADOBE_SETUP=1 MSIRESTARTMANAGERCONTROL=Disable ") ret=004340ab 0017:trace:msi:MsiInstallProductW L"Z:\mnt\iso\Adobe CS3\WinMediaBootstrapper.msi" L" ADOBE_SETUP=1 MSIRESTARTMANAGERCONTROL=Disable " 0017:trace:msi:MSI_OpenPackageW L"Z:\mnt\iso\Adobe CS3\WinMediaBootstrapper.msi" 0x61a8d0f8 --- snip wine trace ---
"PROPERTY_FILE" is a path to a temporary xml file that gets supplied as parameter (xml dynamically built by setup).
--- snip xml db --- <?xml version="1.0" encoding="UTF-8"?> <Properties><Property name="AddRemoveInfoDisplayName">Adobe Creative Suite 3 Master Collection</Property><Property name="AddRemoveInfoDisplayVersion">1.0</Property><Property .. name="defaultLanguage">en_US</Property><Property name="installSourcePath">z:\mnt\iso\Adobe CS3</Property><Property name="platform">Win32</Property><Property name="productName">Adobe Creative Suite 3 Master Collection</Property><Property name="setupVersion">1.1.8.0</Property><Property name="suppressUninstaller">0</Property></Properties> .. </Properties> --- snip xml db ---
Wine's builtin msxml3 is used to create the xml file:
--- snip wine trace (condensed) --- .. 0017:Call ole32.CoCreateInstance(61a8d400,00000000,00000017,005b0bbc,007efd88) ret=00421431 0017:Call KERNEL32.MultiByteToWideChar(00000000,00000000,61a8d1b0 "{F5078F32-C551-11D3-89B9-0000F81FE221}",ffffffff,61a8d23a,00000027) ret=6072c06d 0017:Call KERNEL32.LoadLibraryExW(61a8d066 L"msxml3.dll",00000000,00000008) ret=6072b757 0017:Ret ole32.CoCreateInstance() retval=00000000 ret=00421431 0017:Call oleaut32.SysAllocString(005b12e0 L"xml") ret=0041bc9e 0017:Call oleaut32.SysAllocString(005b12a0 L"version='1.0' encoding='UTF-8'") ret=0041bc9e 0017:Call oleaut32.SysAllocString(007efdd0 L"Properties") ret=0041bc9e 0017:fixme:msxml:domdoc_documentElement .. 0017:Call oleaut32.SysFreeString(00143c6c L"Properties") ret=00423095 .. 0017:Call ole32.CoUninitialize() ret=004379d4 0017:Call msxml3.DllCanUnloadNow() ret=6072bb52 0017:fixme:msxml:DllCanUnloadNow 0017:Ret msxml3.DllCanUnloadNow() retval=00000001 ret=6072bb52 0017:Ret ole32.CoUninitialize() retval=00000002 ret=004379d4 --- snip wine trace (condensed) ---
The FIXME should be the culprit. Due to missing implementation bits the xml file can't be properly constructed. Later the missing file leads to empty PROPERTY_FILE parameter which finally leads to the custom action error code 1603 (after lots of msi processing -> missing properties).
After switching to native msxml3 (winetricks), the xml file is constructed. It matches the one from windows. Good.
The custom action dll then tries to load it. There is an interesting jscript snippet in several *.msi databases (not visible with ORCA, use hex editor) that shows how this stuff might be loaded from within custom action dlls. Basically it instanciates MSXML document object and reads the xml file back into a property map.
--- snip wine trace (condensed) --- 0017:trace:msi:MSI_DatabaseOpenViewW L"SELECT `Value` FROM `_Property` WHERE `_Property`='PROPERTY_FILE'" 0x61b62df4 .. 0017:Call msi.MsiRecordSetStringW(00000003,00000000,015ea5a0 L"11:10:24:990 -(Adobe)- Value C:\windows\temp\adb4eef.tmp ") ret=100030cc .. 0017:Call shlwapi.PathFileExistsW(015ea000 L"C:\windows\temp\adb4eef.tmp") ret=10048958 0017:Call msi.MsiRecordSetStringW(00000003,00000000,015e9d98 L"11:10:24:992 -(Adobe)- Processing property file ") ret=100030cc .. 0017:Call ole32.CLSIDFromProgID(015e9d20 L"MSXML2.DOMDocument.6.0",61b62f54) ret=1007cff1 0017:Call advapi32.RegOpenKeyW(80000000,00179fa8 L"MSXML2.DOMDocument.6.0\CLSID",61b62eb4) ret=607d6988 0017:Ret advapi32.RegOpenKeyW() retval=00000002 ret=607d6988 0017:Ret ole32.CLSIDFromProgID() retval=800401f3 ret=1007cff1 0017:Call ole32.CLSIDFromProgID(015e9fb8 L"MSXML2.DOMDocument.5.0",61b62f54) ret=1007cff1 0017:Call advapi32.RegOpenKeyW(80000000,00179fa8 L"MSXML2.DOMDocument.5.0\CLSID",61b62eb4) ret=607d6988 0017:Ret advapi32.RegOpenKeyW() retval=00000002 ret=607d6988 0017:Ret ole32.CLSIDFromProgID() retval=800401f3 ret=1007cff1 0017:Call ole32.CLSIDFromProgID(015e9e30 L"MSXML2.DOMDocument.4.0",61b62f54) ret=1007cff1 0017:Call advapi32.RegOpenKeyW(80000000,00179fa8 L"MSXML2.DOMDocument.4.0\CLSID",61b62eb4) ret=607d6988 0017:Ret advapi32.RegOpenKeyW() retval=00000002 ret=607d6988 0017:Ret ole32.CLSIDFromProgID() retval=800401f3 ret=1007cff1 0017:Call ole32.CLSIDFromProgID(015e9e68 L"MSXML2.DOMDocument.3.0",61b62f54) ret=1007cff1 0017:Call advapi32.RegOpenKeyW(80000000,00179fa8 L"MSXML2.DOMDocument.3.0\CLSID",61b62eb4) ret=607d6988 0017:Ret advapi32.RegOpenKeyW() retval=00000000 ret=607d6988 0017:Call advapi32.RegQueryValueW(00000158,00000000,61b62e66,61b62eb8) ret=607d69d4 0017:Ret advapi32.RegQueryValueW() retval=00000000 ret=607d69d4 0017:Ret ole32.CLSIDFromProgID() retval=00000000 ret=1007cff1 0017:Call ole32.CoCreateInstance(61b62f54,00000000,00000017,1010e84c,015e5290) ret=1007d015 0017:err:ole:CoCreateInstance apartment not initialised 0017:Ret ole32.CoCreateInstance() retval=800401f0 ret=1007d015 0017:Call ole32.CLSIDFromProgID(015ea538 L"MSXML.DOMDocument",61b62f54) ret=1007cff1 0017:Call advapi32.RegOpenKeyW(80000000,00179fe0 L"MSXML.DOMDocument\CLSID",61b62eb4) ret=607d6988 0017:Ret advapi32.RegOpenKeyW() retval=00000000 ret=607d6988 0017:Ret ole32.CLSIDFromProgID() retval=00000000 ret=1007cff1 0017:Call ole32.CoCreateInstance(61b62f54,00000000,00000017,1010e84c,015e5290) ret=1007d015 0017:err:ole:CoCreateInstance apartment not initialised 0017:Ret ole32.CoCreateInstance() retval=800401f0 ret=1007d015 .. 0017:Call msi.MsiRecordSetStringW(00000003,00000000,015ea3f0 L"11:10:24:995 -(Adobe)- Unable to load file: C:\windows\temp\adb4eef.tmp ") ret=100030cc .. --- snip wine trace (condensed) ---
"err:ole:CoCreateInstance apartment not initialised" -> "ole32.CoCreateInstance() retval=800401f0" is is the culprit. It fails here because the msi custom action thread does not provide an ole apartment by default. Much later the custom action returns with 1603 - after processing database with the properties from xml file missing.
To fix this, call CoInitialize() on entry and CoUninitialize() on exit. e.g. something like this (quick shot):
--- snip dlls/msi/custom.c --- static DWORD WINAPI DllThread( LPVOID arg ) { LPGUID guid = arg; DWORD rc = 0;
TRACE("custom action (%x) started\n", GetCurrentThreadId() );
CoInitialize(NULL);
rc = ACTION_CallDllFunction( guid );
TRACE("custom action (%x) returned %i\n", GetCurrentThreadId(), rc );
CoUninitialize();
MsiCloseAllHandles(); return rc; } --- snip dlls/msi/custom.c ---
I suspect this default ole apartment issue affects other adobe installers too. I'm not aware of a mechanism like shlwapi's SHCreateThread() with CTF_COINIT flags to control default/implicit ole apartment creation. So i would stick to default apartment creation for custom action threads until proven otherwise.
It now gets further - only to barf at:
--- snip --- wine: Call from 0x7b840aa0 to unimplemented function msi.dll.MsiSourceListSetInfoW, aborting --- snip ---
"MsiSourceListSetInfoW" is implemented but the msi.spec lists it as stub. Changing to "268 stdcall MsiSourceListSetInfoW(wstr wstr long long wstr wstr)" works around this.
Now it goes further, spawning installer instance with additional parameters that later dies due to non obvious errors. Exact cause unknown yet (Adobe Setup Exit code: 4). Could be either msi or scripting engine or msxml3 related.
Attached is latest log created with: WINEDEBUG=+loaddll,+msi,+msidb,+seh,+tid wine Setup.exe
Regards
-
wine-bugs＠winehq.org