http://bugs.winehq.org/show_bug.cgi?id=8222
------- Additional Comments From focht@gmx.net 2007-30-04 10:32 ------- Hello,
--- quote --- This might be a dup of bug 5348, ask James. --- quote ---
nope. After much investigation on my own, it actually turns out to be a dup of bug 5768
I couldnt believe the installer wont run on windows so i debugged msi installer service process itself, which loads and executes custom action dlls.
Basically the windows part itself is wrong due to an internal msi ansi<->unicode conversion bug (Windows XP SP2 with latest patches). It turns out this bug goes rather unnoticed without further damage due to the nature of returned data :)
I recorded all stack parameters before the call to windows msi.MsiGetPropertyA() and compared after. Same just like wine. First call is to determine buffer length.
--- snip analysis ---
009AF80C 00000042 hInstall 009AF810 003A21B0 Name -> ASCII "AUMUSEORIGINALAPPID" 009AF814 00000000 szValueBuf 009AF818 009AF830 pchValueBuf
pchValueBuf: 009AF830 -> 0x0
upon return:
pchValueBuf: 009AF830 -> 0x8 <--- bug!
second call:
009AF80C 00000042 hInstall 009AF810 003A21B0 Name -> ASCII "AUMUSEORIGINALAPPID" 009AF814 003A2200 szValueBuf 009AF818 009AF830 pchValueBuf
dump of szValueBuf (ANSI):
003A2200 54 72 75 65 00 00 00 00 08 00 02 00 EE 01 0C 00 True............ --- snip analysis ---
Remember, the property value to be retrieved is "True" (ANSI -> len = 4).
The first call returns: len = 8 This is indeed the ANSI version of msi.MsiGetProperty that returns this!
Windows internal API is unicode based. That's why all passed in parameters get converted to unicode and back upon return. E.g. for ANSI api function: ansi2unicode -> internal msi (rpc4) -> unicode2ansi. Thats the theory. Due to a bug in the "ERROR_MORE_DATA" case, the length parameter which was lstrlenW("True") == 4 upon return gets incorrectly doubled (2*len) - probably some "sizeof(WCHAR)*len" code.
Regards
-
Wine Bugs