[Bug 5163] Office XP 2002 crashes on installation

Mon Jun 23 14:34:18 CDT 2008

http://bugs.winehq.org/show_bug.cgi?id=5163

Warren Dumortier <kwixbit at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kwixbit at gmail.com

--- Comment #59 from Warren Dumortier <kwixbit at 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 at 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.Globalization.Unicode/Collation-notes.txt?view=markup

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

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.