http://bugs.winehq.org/show_bug.cgi?id=5163
Warren Dumortier kwixbit@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kwixbit@gmail.com
--- Comment #59 from Warren Dumortier kwixbit@gmail.com 2008-06-22 04:00:46 --- Any news for this bug? Please, can this bug be fixed? I try to run office 2002 since a long time... Would be nice to fix for next version though, as this suite is an important program, i think...
--- Comment #60 from Anastasius Focht focht@gmx.net 2008-06-23 14:34:15 --- Created an attachment (id=14308) --> (http://bugs.winehq.org/attachment.cgi?id=14308) hack/patch to let office xp install due to lack of variable elements handling in unicode collation
Hello,
--- quote --- Please, can this bug be fixed? I try to run office 2002 since a long time... Would be nice to fix for next version though, as this suite is an important program, i think... --- quote ---
Sure ... gentlemen, time for popcorn and cola.
The problematic stuff happens in a custom action dll. To bypass installer GUI and PID input, one can pass the following command line:
msiexec -i PROPLUS.MSI PIDKEY=<licensekey> /qb
Tracing reveals the following (condensed):
+tid,+seh,+msi,+relay
--- snip trace --- 002b:trace:msi:HANDLE_CustomType1 Calling function L"CASignDPCHWIDPair" from L"C:\windows\temp\msie7d.tmp" .. 000b:Call KERNEL32.LoadLibraryW(00cbfec4 L"C:\windows\temp\msie7d.tmp") ret=6035fc18 .. 000b:trace:msi:ACTION_CallDllFunction calling L"CASignDPCHWIDPair" .. 000b:Call msi.MsiSetPropertyA(00000002,35f1a81e "CAWriteSignatureFileRB",00cc2038 "C:\Program Files\Microsoft Office\Office10\1033\ID_028.DHS") ret=35f1a957 .. 000b:Call KERNEL32.CreateFileA(00cc1f70 "Z:\home\focht\work\officexp\install\Files\PFILES\MSOFFICE\Office10\1033\ID_028.DPC",80000000,00000001,00000000,00000003,00000000,00000000) ret=35f195bd 000b:Ret KERNEL32.CreateFileA() retval=00000754 ret=35f195bd .. 000b:Call setupapi.SetupIterateCabinetA(7ed45adc "Z:\home\focht\work\officexp\install\OFFICE1.CAB",00000000,35f18904,7ed45adc) ret=35f19044 000b:Call KERNEL32.LoadLibraryA(7333d76e "cabinet.dll") ret=73332866 000b:Ret KERNEL32.LoadLibraryA() retval=609b0000 ret=73332866 .. 000b:Call KERNEL32.GetFullPathNameA(7ed45adc "Z:\home\focht\work\officexp\install\OFFICE1.CAB",00000104,7ed457a4,7ed459b8) ret=73333afa 000b:Ret KERNEL32.GetFullPathNameA() retval=0000002f ret=73333afa 000b:Call cabinet.FDICreate(733339b0,73333980,73332dc0,73332d60,73332d10,73332cf0,73332c90,ffffffff,7ed459ac) ret=73333bcc .. 000b:Ret cabinet.FDICreate() retval=00cc25c8 ret=73333bcc 000b:Call cabinet.FDICopy(00cc25c8,7ed458a8,7ed457a4,00000000,73333cd0,00000000,7ed45690) ret=73333c1d 000b:Call KERNEL32.CreateFileA(7ed45418 "Z:\home\focht\work\officexp\install\OFFICE1.CAB",80000000,00000003,7ed2e400,00000003,00000080,00000000) ret=73332ea4 000b:Ret KERNEL32.CreateFileA() retval=00000758 ret=73332ea4 .. 000b:Ret cabinet.FDICopy() retval=00000001 ret=73333c1d .. 000b:Ret setupapi.SetupIterateCabinetA() retval=00000001 ret=35f19044 .. 000b:Call msi.MsiCreateRecord(00000001) ret=35f19cf6 .. 000b:Ret msi.MsiCreateRecord() retval=00000007 ret=35f19cf6 000b:Call msi.MsiRecordSetInteger(00000007,00000001,000061ab) ret=35f19d6c 000b:Ret msi.MsiRecordSetInteger() retval=00000000 ret=35f19d6c 000b:Call msi.MsiProcessMessage(00000002,01000000,00000007) ret=35f19d7b .. 000b:trace:msi:MSI_ProcessMessage ((nil) 0 2 L"25003") .. 000b:Call msi.MsiRecordSetStringA(00000006,00000000,35f41f78 "CADpc: SCC finished with status 1603") ret=35f348fe .. 000b:Call msi.MsiRecordSetStringA(00000006,00000000,35f41f78 "CADpc: failed with error 1603") ret=35f348fe .. 000b:trace:msi:DllThread custom action (b) returned 1603 --- snip trace ---
Error 1603/25003 sounds familar ...
--- http://support.microsoft.com/kb/324853
"Error 25003: Office setup cannot continue because the installation source has been corrupted" error message when you install Office XP"
http://support.microsoft.com/kb/300852
"You receive an "Error 25003" error message when you run the Setup program to upgrade your installation of Office XP"
http://support.microsoft.com/kb/827076
"You may receive the "Installation error 25003" error message when you install Visual Studio .NET" ---
The KB articles are pretty vague about this one. Internal error, likely corrupted media.
Down to the metal ... actually I'm very happy that James added MsiBreak upon my request one year ago .. can't count how may times this turned out to be a real timesaver ;-)
export MsiBreak=CASignDPCHWIDPair
As an interesting sidebit ... that CA dll is stuffed with lots of anti debugging traps to prevent/discourage debugging - which made the task of tracking the problem down a bit of nuisance. They really should focus on improving their products than doing such kinderkram.
The installer verifies the "integrity" (slightly exaggerated) of .cab files (OFFICE1.CAB) by iterating through the contents -> SetupIterateCabinetA().
Within the cab iteration callback, each entry is examined. Not all entries are taken, they are filtered against a matchlist to prevent any accidentally packaged files to be included in verification/copy process. If an entry successfully passed the criteria it is inserted into a sorted(!) list.
When the cab inspection is finished, all collected filenames(!) are used to build a hashcode. This hashcode is verified against a pre-built code, which comes from signature file. This fails for wine: the hash doesn't match.
There are 2500+ files in the package and manually debugging this would be really time consuming. No problem. Open the bag of tricks ;-) By using automated log breakpoints at appropriate places which dump data using expressions I was able to gather the whole list which finally revealed the problem ...
--- snip CA dll log windows --- .. filename = "msnbc.ico" hash = E9129601 ------------------------------------ problem ----------------------- filename = "mso.acl.d0df3458_a845_11d3_8d0a_0050046416b9" hash = 8C72A024 filename = "mso.acl_1036.d0df3458_a845_11d3_8d0a_0050046416b9" hash = 0CC2F85C filename = "mso.acl_3082.d0df3458_a845_11d3_8d0a_0050046416b9" hash = D238109D ------------------------------------ problem ----------------------- filename = "mso.dll" hash = 5433D3CB .. --- snip CA dll log windows ---
--- snip CA dll log wine --- .. filename = "msnbc.ico" hash = E9129601 ------------------------------------ problem ----------------------- filename = "mso.acl_1036.d0df3458_a845_11d3_8d0a_0050046416b9" hash = 7B6D32D6 filename = "mso.acl_3082.d0df3458_a845_11d3_8d0a_0050046416b9" hash = C1BB49B9 filename = "mso.acl.d0df3458_a845_11d3_8d0a_0050046416b9" hash = D000EF9B ------------------------------------ problem ----------------------- filename = "mso.dll" hash = 30488509 .. --- snip CA dll log wine ---
Notice the different order which subsequently leads to different hash code. The hash is reused as input between iterations.
The sort order of the list - built within the callback - is maintained using CompareStringA():
--- snip --- .. 0043:Call KERNEL32.CompareStringA(00000409,00000001,00c6f7d8 "mso.acl_1036.d0df3458_a845_11d3_8d0a_0050046416b9",ffffffff,00d83dc8 "mso.acl.d0df3458_a845_11d3_8d0a_0050046416b9",ffffffff) ret=35f18a68 0043:Ret KERNEL32.CompareStringA() retval=00000001 ret=35f18a68 .. --- snip ---
0x409 = MAKELCID(MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), SORT_DEFAULT ) 0x1 = NORM_IGNORECASE
This little but important snippet can be reduced further:
CompareStringA( 0x409, 0x1, "_", -1, ".", -1);
Guess what happens...
Wine: 0x1 (= CSTR_LESS_THAN) -> "_" < "." Windows: 0x3 (= CSTR_GREATER_THAN) -> "_" > "."
Lets look into default unicode collation element table (DUCET) ...
http://www.unicode.org/Public/UCA/latest/allkeys.txt (latest version)
--- snip --- .. 002E ; [*0255.0020.0002.002E] # FULL STOP .. 005F ; [*021B.0020.0002.005F] # LOW LINE .. --- snip ---
level 1 != 0, level 2 != 0, level 3 != 0 -> range: variable Applies to: whitespace, punctuation, symbols
Collation elements marked with an asterisk are "variable" elements.
See: http://unicode.org/reports/tr10/#3.2.2_Variable_Collation_Elements
--- snip --- 'Blanked' Variable elements are made ignorable at levels 1 through 3; considered at the 4th level.
'Non-Ignorable' Variable elements are not reset to ignorable.
'Shifted' Variable elements are made ignorable at levels 1 through 3 their level 4 weight is replaced by the old level 1 weight. Level 4 weight for Non-Variable elements is 0xFFFF.
'Shift-Trimmed' Same as 'shifted', but all FFFF's at the 4th level are trimmed. --- snip ---
Wine doesn't implement handling of such variable elements (level 4 evaluation). Instead the level 4 data is reduced to LSB (1 bit) of 32 bit compressed sortkey. This means "." will always have greater weighting in wine due to level 1 (primary) than "_".
It seems the standards group changes the level 1 weighting lots of times ...
--- snip --- @version 3.1.1
002E ; [*0255.0020.0002.002E] # FULL STOP 005F ; [*021B.0020.0002.005F] # LOW LINE
@version 5.0.0
002E ; [*0266.0020.0002.002E] # FULL STOP 005F ; [*021C.0020.0002.005F] # LOW LINE
@version 5.1.0
002E ; [*026A.0020.0002.002E] # FULL STOP 005F ; [*021C.0020.0002.005F] # LOW LINE --- snip ---
For the interested, the Mono project has some interesting info, how M$ implemented collation:
http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/Mono.Globaliz...
That's some serious brain damage ... wine doesn't want to do this :(
---
Coming back to Office XP ... now you ask for any proof of this? Sure, use attached patch to get Office XP successfully installed and run.
NOTE: This is a hack and not a proper patch! Just for demo.
It adjusts the level 1 weighting for "_" to be greater than l1 of "." A real fix (variable elements handling) needs more work.
Don't use this patch on recent wine GIT's, "msi" is currently "work in progress" which leads to problems after installation (see http://bugs.winehq.org/show_bug.cgi?id=9023). Use wine 1.0 whatever to test with.
Regards
-
wine-bugs＠winehq.org