Created attachment 2375 [details]
+relay

Created attachment 2381 [details]
dump of console text

Duplicate of bug 4517

Yup. Its a Dup.

*** This bug has been marked as a duplicate of 4517 ***

Re-open as the installer will not work in CVS and is no longer related to bug 4517.

Created attachment 3647 [details]
+msi log

*** Bug 6809 has been marked as a duplicate of this bug. ***

i did not succeed even in running office XP installed on windows partition using
wine (approx. 0.9.2) - installation under linux was also not possible..
installation of microsoft office 2003 results in a message telling unknown error
and no installation occurs..
running office 2003 installed on windows partition results a message telling
IOPL not enabled

It looks like the problem from EA Durbin's log might be:
err:msi:ITERATE_Actions Execution halted, action L"CAGetDPCOEMData" returned 1603

on my machine I get something like:
err:msi:ITERATE_Actions Execution halted, action L"CADpc" returned 1603

*** Bug 5647 has been marked as a duplicate of this bug. ***

*** Bug 5290 has been marked as a duplicate of this bug. ***

*** Bug 5257 has been marked as a duplicate of this bug. ***

Created attachment 5474 [details]
Outlook 2002 install failure vs wine 0.9.33

I have a standalone Outlook XP CD which came with my smartphone (a Qtek 9090
aka HTC Blue Angel for the record), which I am using to test against wine.

Created attachment 5718 [details]
msi file

Created attachment 5719 [details]
Verbose msi log from windows msi

Created attachment 6027 [details]
Picture showing InstallExecuteSequence  for CustomAction CAGetDPCOEMData

Picture of ORCA showing our CustomAction that is failing refers to properties
in its query in InstallExecuteSequence (ReleaseType and ENTERPRISE_IMAGE) that
should be set by the SecureCustomProperties Property.

http://msdn2.microsoft.com/en-us/library/aa371571.aspx

SecureCustomProperties is separated by semicolons, it appears it gets cut off in
the middle of DISABLEROLLBACK in the INSERT statement of our log and doesn't
enter the entire thing. 

I'm not terribly familiar with MSI but it seems like maybe this list separated
by semicolons should be iterated through and added to the Property table as
public properties?

Created attachment 6049 [details]
+msi,+msidb

Created attachment 6099 [details]
windows log

I've just tried it with wine 0.9.36, and it still crashes, despite the msi
fixes, with the same console logs as everyone else here.

However, I noticed that office dumps two log files into C:/windows/tmp, I will
attach them. A description of them is at http://support.microsoft.com/kb/826511


The last few relevant lines in the first file are:
Successfully launched MsiExec....
5/2/2007 10:51:35 PM  Chained install return code: 1603

The last lines in the other file are related to dw.exe, another file on the
office CD in the msshared folder. I get a message 'fixme:imm:ImmDisableIME
(-1): stub' when I run this file, but nothing else and it returns.

Also, the files mention the possibility of verbose output - I tried this, but
the logs were the same.

Created attachment 6100 [details]
windows log 2

Uh ... me too, with Ubuntu 7.04 , winw 0.9.37 and Office XP

It's a blocker for me, because that's a major app with no Linux evuivalent for
some of the features.

Is this still happening with wine-0.9.40 or later?

Yes, it's still occuring.

since 0.9.41 (also 0.9.42) things have changed. Instead of crashing, it now says
"You have not entered a valid Product Key" when I press 'next', after entering
my key. This is the point at which it used to crash. In the windows log file, it
also returns a different error:
7/31/2007 9:20:12 PM  Chained install return code: 1602
(instead of 1603 as before).
Lastly, there are now many binary files with names of form msi####.tmp that are
created in the windows temp directory.

the msi tmp files have always been in the temp directory, if you do not enter a
key it should still install as it does in windows, if you just press next past
the key boxes it still gives the 1603 error the same as before with current wine
from git.

you're right on both counts, I hadn't noticed the earlier tmp file. However, as
I said, when a product key is entered, it now has an error dialog where there
was none before. Also, the 1603 when no key is entered seems different, before,
the last lines of the console output were:
err:msi:ITERATE_Actions Execution halted, action L"CAGetDPCOEMData" returned 1603
err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603

but now, we get

err:msi:ITERATE_Actions Execution halted, action L"CADpc" returned 1603
err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603
fixme:imm:ImmDisableIME (-1): stub
fixme:wininet:InternetGetConnectedState always returning LAN connection.

maybe it's just a rename... 

I'm still getting 
err:msi:ITERATE_Actions Execution halted, action L"CAGetDPCOEMData" returned 1603
err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603

Ah, maybe that is just my computer. I just noticed another user commented they
also had 'CADpc' rather than 'CAGetDPCOEMData', like mine. So it looks like
nothing is really different, except that entering my product key gives an error
now. Sorry for the false alarm.

Created attachment 7598 [details]
+msi,+text log, plus two log files from c:\windows\temp

With yesterday's git, I'm also getting the
err:msi:ITERATE_Actions Execution halted, action L"CADpc" returned 1603
error.  The attached tarball has a +msi log as well as the
two .txt files left in \windows\temp.

I reproduced this using the Office XP trial disc that can
be bought really cheap, $3, on ebay.
(Note: typing in the license key
from the envelope didn't work, but looking at the log, I saw
that there was a special case for a blank key, and sure enough,
if you don't type in any license key, it goes into 30 day trial
mode, and lets you try to install.)

In Windows CADpc is skipped because the condition resolves to false, as noted in verbose log from msi.

MSI (s) (18:08) [18:38:30:421]: Skipping action: CADpc (condition is false)
MSI (s) (18:08) [18:38:30:421]: Skipping action: CADpcPatch (condition is false)

Created attachment 8525 [details]
CAGetDPCOEMData verbose log from windows

Please attach the log in a plain text format, not rtf.

Created attachment 8526 [details]
CAGetDPCOEMData verbose log from windows, .txt format

Office XP trial still crashes as it did two months ago.

OfficeXP contnues to fail setup in 0.9.54.  Will try to attach log (OfficeXP_54.log.bz2)

Created attachment 10457 [details]
Log of failing OfficeXP Professional setup

Logged with WINEDEBUG=warn+all environment.  Command line was:

        wine setup.exe 2> my.log

This run was with typical install and valid key.  The setup crashed after all options were accepted & while it was preparing to install files.

This continues to fail on .56 -- I believe same warnings as before -- see log attached on 1/26/2008.  Here is a snippet of what happened when I ran today:

fixme:imm:ImmDisableIME (-1): stub
fixme:wininet:InternetGetConnectedState always returning LAN connection.

Continues to fail in the same way in .57

Fails in same way in .58 -- another snippet of the failure:

fixme:msi:ACTION_HandleStandardAction unhandled standard action L"SetODBCFolders"
err:msi:ITERATE_Actions Execution halted, action L"CADpc" returned 1603
err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603
$ fixme:imm:ImmDisableIME (-1): stub
fixme:wininet:InternetGetConnectedState always returning LAN connection.

In the log from windows msi it runs CAGetDPCOEMData from C:\WINDOWS\Installer\ and this directory doesn't exist at this point of execution in wine.

Action start 18:38:30: CAGetDPCOEMData.
MSI (s) (18:08) [18:38:30:421]: Creating MSIHANDLE (314) of type 790542 for thread 520
MSI (s) (18:0C) [18:38:30:421]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI53.tmp, Entrypoint: CAGetDPCOEMData

Created attachment 11836 [details]
hack to install office 2002 XP

(In reply to comment #40)
> In the log from windows msi it runs CAGetDPCOEMData from C:\WINDOWS\Installer\
> and this directory doesn't exist at this point of execution in wine.
> 
> Action start 18:38:30: CAGetDPCOEMData.
> MSI (s) (18:08) [18:38:30:421]: Creating MSIHANDLE (314) of type 790542 for
> thread 520
> MSI (s) (18:0C) [18:38:30:421]: Invoking remote custom action. DLL:
> C:\WINDOWS\Installer\MSI53.tmp, Entrypoint: CAGetDPCOEMData
> 

That makes no difference.  It's just the temporary directory where custom action dlls are extracted to.

(In reply to comment #42)
> (In reply to comment #40)
> > In the log from windows msi it runs CAGetDPCOEMData from C:\WINDOWS\Installer\
> > and this directory doesn't exist at this point of execution in wine.
> > 
> > Action start 18:38:30: CAGetDPCOEMData.
> > MSI (s) (18:08) [18:38:30:421]: Creating MSIHANDLE (314) of type 790542 for
> > thread 520
> > MSI (s) (18:0C) [18:38:30:421]: Invoking remote custom action. DLL:
> > C:\WINDOWS\Installer\MSI53.tmp, Entrypoint: CAGetDPCOEMData
> > 
> 
> That makes no difference.  It's just the temporary directory where custom
> action dlls are extracted to.
> 

This comment seems to be misplaced... I don't think it answers #40...  Which comment were you replying to?

(In reply to comment #43)
> (In reply to comment #42)
> > (In reply to comment #40)
> > > In the log from windows msi it runs CAGetDPCOEMData from C:\WINDOWS\Installer\
> > > and this directory doesn't exist at this point of execution in wine.
> > > 
> > > Action start 18:38:30: CAGetDPCOEMData.
> > > MSI (s) (18:08) [18:38:30:421]: Creating MSIHANDLE (314) of type 790542 for
> > > thread 520
> > > MSI (s) (18:0C) [18:38:30:421]: Invoking remote custom action. DLL:
> > > C:\WINDOWS\Installer\MSI53.tmp, Entrypoint: CAGetDPCOEMData
> > > 
> > 
> > That makes no difference.  It's just the temporary directory where custom
> > action dlls are extracted to.
> > 
> 
> This comment seems to be misplaced... I don't think it answers #40...  Which
> comment were you replying to?
> 

Sorry -- my eyes must be crossed this morning -- please ignore.

Ok, I know I got into it with Dmitry about when the patch keyword can be used...but that hack absolutely cannot be considered a patch, it just skips the specific custom actions and gets us no closer to understanding the problem.

Moreover the hack is using very strange C syntax and just can't work
as expected.

Continues to fail in the same way in 0.9.59.

Created attachment 12148 [details]
+msi,+text,+crypt,+process,+module,+file log of failing custom action

Trial still failing in same way with today's git.

Here's a log of the failing custom action.
(This was produced by
running the inner installer with the command indicated
by the log from the outer installer:

WINEDEBUG=+msi,+text,+crypt,+process,+module,+file wine msiexec /I D:\\PROTRI.MSI SKIPOSPCHECK=1 METRICSSOURCE=D:  LAUNCHEDFROMSETUP=1 SETUPEXEPATH=D:\\  /l*v "c:\\v_Task(0001).txt" LOGVERBOSE=1 DWSETUPLOGFILE=c:\\v.txt "DWMSILOGFILE=c:\\v_Task(0001).txt"

but just running the outer installer would have been fine.)

(Annoyingly, +relay seems to hang the installer, so I didn't use that.)

Aha.  Running with native cabinet shows a new line right
after the big run of reads:
fixme:setupapi:sc_FNNOTIFY_A Unknown notification type 5.
This was referred to also in
http://bugs.winehq.org/show_bug.cgi?id=3701#c8

So perhaps our cabinet isn't generating the proper FDICopy callback,
and our setupapi isn't handling it?

Setting category to setupapi.

5 is fdintENUMERATE, which is undocumented.  It's described a little bit
in our doc for FDICopy:
http://source.winehq.org/WineAPI/FDICopy.html

... but not in Microsoft's documentation, which is at http://msdn2.microsoft.com/en-us/library/ms974336.aspx

For fdintENUMERATE -- does this help?

http://read.pudn.com/downloads/sourcecode/windows/misc/7/Cabinet.cpp__.htm

That does look kind of helpful.

Created attachment 13082 [details]
OfficeXP Professional Install Failed 2 times

Install promped for Product Key and other information, but it did not reflect any of the disk space available-required.

Created attachment 13083 [details]
OfficeXP Professional Install Failed 2 times

Install promped for Product Key and other information, but it did not reflect any of the disk space available-required.

Created attachment 13728 [details]
Office XP install log

Office XP still will not install on 1.0 rc3

Please stop posting logs.  This isn't an issue that will get magically fixed by a random commit.

Not a regression, wine 1.0 in deep code freeze -> deferring

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...

Created attachment 14308 [details]
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

Anastasius, you are a scholar and a gentleman.  Thanks.

I'm not sure what the component would be for this, but it certainly isn't setupapi.

Wow Anastasius, thanks for the great analysis. Very thorough as always, looks like that one was a doozy :-P.

(In reply to comment #60)

Impressive analysis -- very thorough.  KUDOS.

I just tested with Wine 1.1.10 but unfortunately the Installer still crashes with the same console output as reported in January'08...

Hi!

Are there any work-arounds for those msi error?
Thanks in advance.

You can apply Anastasius's hack to the wine-1.0.1 sources.
Or if you have Office 2003, install that instead, we handle that better.

Is this still present in current (1.1.28 or newer) wine? According to AppDB, doesn't install, but not sure if it's this or another bug.

(In reply to comment #68)
> Is this still present in current (1.1.28 or newer) wine? According to AppDB,
> doesn't install, but not sure if it's this or another bug.

yes

In reply to comment #60 From Anastasius Focht:
| 
| 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 :(

The link has changed a bit:
http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/corlib/Mono.Globalization.Unicode/Collation-notes.txt?view=markup

But does someone know -- was this discussed on wine-devel or IRC?

*** Bug 21431 has been marked as a duplicate of this bug. ***

Would love some fix for this :D

bug is still present in wine 1.2rc2

(In reply to comment #60)
So we need to modify cpmap.pl to put more(all) info into collation.c and modify sortkeys.c to use an algorithm that uses that infos.
sounds easy but i just tried some things and i guess the algo is a bit hard...

PS: i am working on a fix and yes, i know i have to hurry up :)
my patch will take Level 4 of unicode collation into account.
the hard stuff is the compression, so it doesnt oversize the 32-bit array.

patch sent:http://www.winehq.org/pipermail/wine-patches/2010-June/089533.html

Thanks Anastasius Focht for the great analysis and sorry i just realized i forgot to mention that in the patch/email... :(

Won't be ready for 1.2.
As i am the only one trying to fix that.
And it is a hard Problem because with that, Windows behaves very different from unicode, so it is hard.
But i heard that unicode wants to get more Microsoft compatible, so we might have a chance which is easier.

I confirm that this continues to be a problem, using Wine 1.3.1 on Ubuntu 10.04.  The installer exits and offers to send information to Microsoft.  The only relevant content to that information that I could find was the following:

Executing Task:
Microsoft Office XP Professional
"C:\windows\system32\msiexec.exe"  /I Z:\home\buchs\Downloads\OfficeXP\PRO.MSI SKIPOSPCHECK=1 METRICSSOURCE="Z:\home\buchs\Downloads\OfficeXP"  LAUNCHEDFROMSETUP=1 SETUPEXEPATH=Z:\home\buchs\Downloads\OfficeXP\  /lvpiwaeo "C:\users\buchs\Temp\Office XP Professional Setup(0001)_Task(0001).txt" LOGVERBOSE=1 DWSETUPLOGFILE="C:\users\buchs\Temp\Office XP Professional Setup(0001).txt" DWMSILOGFILE="C:\users\buchs\Temp\Office XP Professional Setup(0001)_Task(0001).txt"
Type: msi
Ignore Return Values: False
Reboot: False

Successfully launched MsiExec....
9/6/2010 8:50:38 AM  Chained install return code: 1603
Shutting down chained setup processing.
Set Verbose logging for subsequent setup.


***** Setup exits 
9/6/2010 8:50:38 AM 
(return = 1603)

Created attachment 31025 [details]
Office XP install log in 1.3.3

This might be a wontfix as i think we wont be able to duplicate the windows behaviour.
I sent some patches, but it seems they broke other things.
It's just a bad situation.

So for now i think logs are not useful as the problem wont change in near future.

@Andre -- OK, so long as we can maintain a patch like Anastasius Focht's attachment in Comment 60 so that we can temporarily rebuild wine on our own to install OfficeXP and then back it out to run all our other stuff.

of course you can.
and i bet it doesnt hurt other apps if u let the patch in.

(In reply to comment #82)
> of course you can.
> and i bet it doesnt hurt other apps if u let the patch in.

Is this OK to everyone, because the guys don't think they should replicate MS particular version of brain damage in this case without breakage to other things?

1) Download wine source (can be your package maintainer's)
2) Patch Wine with Anastasius' patch:

   http://bugs.winehq.org/attachment.cgi?id=14308

3) make/Install from source
4) Run OfficeXP installation
5) Back out the patch & make/install, or reload your distribution's wine.

looks like http://source.winehq.org/git/wine.git/?a=commit;h=eaa57c5b7bdcc0fb5a2004a7e388ac5a1ed03ead has a very small chance of fixing this bug, so if someone could please retest in current git or next release?
As i said, the chance is very small, but at least it might help IIRC.

no luck here :(

Still not working as of wine 1.2.1 on ubuntu 10.10.  Everything in the installer works except no space used/available is calculated.  I deselected installing Access, outlook, and frontpage.  When it starts to copy files, the installer crashes (error log attached).  I have also attached the terminal output from running the setup using wine

Created attachment 31887 [details]
wine terminal output

Office XP installation is still not working as of wine 1.2.1 on ubuntu 10.10.  Everything in the installer works except no space used/available is calculated.  I deselected installing Access, outlook, and frontpage.  When it starts to copy files, the installer crashes (see attached, the error log starts on line 1).  I have also attached the terminal output from running the setup using wine (14 lines, starting on line 78).

have a try with wine-1.3.7, we now have unicode 6 so it might make a difference or it might not.
The bug is more or less a unicode problem, so changes to the unicode backend are always a hope for this bug

Got a few more fixmes on the end
fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub!
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do!
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do!
but still no joy!

Still present in 1.3.29?

I just tested with wine 1.3.31 and the installation fails after selecting the applications to install. Here is the console output:
--------------------
$wine setup.exe 
wine: created the configuration directory '/home/ronny/.wine'
fixme:storage:create_storagefile Storage share mode not implemented.
err:mscoree:LoadLibraryShim error reading registry key for installroot
err:mscoree:LoadLibraryShim error reading registry key for installroot
err:mscoree:LoadLibraryShim error reading registry key for installroot
err:mscoree:LoadLibraryShim error reading registry key for installroot
err:mscoree:LoadLibraryShim error reading registry key for installroot
err:mscoree:LoadLibraryShim error reading registry key for installroot
fixme:iphlpapi:NotifyAddrChange (Handle 0x10ae8fc, overlapped 0x10ae8e0): stub
wine: configuration in '/home/ronny/.wine' has been updated.
fixme:imm:ImmDisableIME (-1): stub
fixme:storage:create_storagefile Storage share mode not implemented.
err:ole:CoUninitialize Mismatched CoUninitialize
err:ole:CoUninitialize Mismatched CoUninitialize
fixme:msi:ControlEvent_SpawnWaitDialog Doing Nothing
err:richedit:ReadStyleSheet skipping optional destination
err:richedit:ReadStyleSheet skipping optional destination
fixme:msi:ControlEvent_SpawnWaitDialog Doing Nothing
err:msi:ITERATE_Actions Execution halted, action L"CADpc" returned 1603
err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603
fixme:imm:ImmDisableIME (-1): stub
--------------------

Created attachment 38058 [details]
Wine output in 1.3.35

The problem remains in 1.3.35 - I have attached the output.

because of the underlying problem there is still no hope for this bug, see Comment #60 for a hack and a explanation

This bug is still there in Wine 1.5.6

This has not been updated for two years. Is this still an issue in 1.5.22 or
beyond ? Or should this be closed as abandoned ?

(In reply to comment #95)
> This has not been updated for two years. Is this still an issue in 1.5.22 or
> beyond ? Or should this be closed as abandoned ?

This was updated 6 months ago saying it was still an issue as of 1.5.6. Analysis has been done and the bug is still present in wine, it's not abandoned.

I (for one) have subscribed to and continue to watch this bug.  It seems to be a well understood bug, but is not fixed.

Re: the workaround described in comment #60 ... it's not necessary to completely rebuild wine just to install Office XP.

I just built libwine.so.1.0 with the patch, then moved my system copy (in /usr/lib) out of the way temporarily, moved the patched version into my system directory, installed Office XP, then switched everything back.

Much easier than a full rebuild. :-)

Does the bug still occur with wine-5.12?

Hello folks,

--- quote ---
Does the bug still occur with wine-5.12?
--- quote ---

Sure. My analysis from 2008 still applies.

The unicode collation element table was updated/regenerated in 2010:

https://source.winehq.org/git/wine.git/commitdiff/388779e320b9dda0e9a3094459da6f4162976778 ("libwine: Update the character tables to Unicode 5.2.")

and introduced to kernelbase in 2019

https://source.winehq.org/git/wine.git/commitdiff/94a3add0ea7889dbd26a4ded60ace1c40b02ed89 ("kernel32: Move LCMapString functions to kernelbase.")

https://www.unicode.org/Public/UCA/5.2.0/allkeys.txt

--- snip ---
# unidata-5.2.0.txt
# Date: 2009-09-22, 16:23:42 PDT [KW]
#
# This file defines the Default Unicode Collation Element Table
#   (DUCET) for the Unicode Collation Algorithm
#
# Copyright (c) 2001-2009 Unicode, Inc.
# For terms of use, see http://www.unicode.org/terms_of_use.html
#
# See UTS #10, Unicode Collation Algorithm, for more information.
#
# Diagnostic weight ranges
# Primary weight range:   0200..3ACA (14539)
# Secondary weight range: 0020..0192 (371)
# Variant secondaries:    0159..015E (6)
# Digit secondaries:      015F..0192 (52)
# Tertiary weight range:  0002..001F (30)
#
@version 5.2.0
...
002E  ; [*0281.0020.0002.002E] # FULL STOP
...
005F  ; [*021D.0020.0002.005F] # LOW LINE
...
--- snip ---

Hence you need an adjustment for my hack (kernelbase only):

https://source.winehq.org/git/wine.git/blob/9d7a710fc0d1a0ecea17a68675d3899aff63ae0c:/dlls/kernelbase/collation.c#l153

--- snip ---
diff --git a/dlls/kernelbase/collation.c b/dlls/kernelbase/collation.c
index 22c35a4c21e..7bc724f0175 100644
--- a/dlls/kernelbase/collation.c
+++ b/dlls/kernelbase/collation.c
@@ -150,7 +150,7 @@ const unsigned int DECLSPEC_HIDDEN collation_table[11044] =
     0x0a290141, 0x0a3d0151, 0x0a490151, 0x0a650151, 0x0a910151, 0x0a990151, 0x0ab90151, 0x0ad30161,
     0x0ae70141, 0x0af70141, 0x0b030161, 0x0b2b0151, 0x0b330151, 0x0b4b0161, 0x0b670141, 0x0b730141,
     0x0b7f0141, 0x0ba70151, 0x0bbf0151, 0x0bd70141, 0x0bef0151, 0x0bfb0141, 0x0c030151, 0x0c070141,
-    0x0c130141, 0x027c0111, 0x02a60111, 0x027d0111, 0x020f0111, 0x021b0111, 0x020c0111, 0x0a150111,
+    0x0c130141, 0x027c0111, 0x02a60111, 0x027d0111, 0x020f0111, 0x02560111, 0x020c0111, 0x0a150111,
     0x0a290111, 0x0a3d0111, 0x0a490111, 0x0a650111, 0x0a910111, 0x0a990111, 0x0ab90111, 0x0ad30111,
     0x0ae70111, 0x0af70111, 0x0b030111, 0x0b2b0111, 0x0b330111, 0x0b4b0111, 0x0b670111, 0x0b730111,
     0x0b7f0111, 0x0ba70111, 0x0bbf0111, 0x0bd70111, 0x0bef0111, 0x0bfb0111, 0x0c030111, 0x0c070111,
--- snip ---

$ wine --version
wine-6.0-rc3-34-g9d7a710fc0d

Regards

This bug should be fixed by <https://github.com/wine-staging/wine-staging/tree/master/patches/libs-Unicode_Collation> then, right?

Hello Zeb,

--- quote ---
This bug should be fixed by <https://github.com/wine-staging/wine-staging/tree/master/patches/libs-Unicode_Collation> then, right
--- quote ---

oh yes. I totally missed bug 10767 and the Wine-Staging patchset for it.

I propose to keep this one still separate. End users have no clue what "lstrcmp and others do not compare punctuation characters correctly" means when they see it one day appearing in release notes for a Wine release. I'm not suggesting to reword bug 10767 either, it's technically as verbose as needed, with focus on the general problem "meta".

Regards

(In reply to Anastasius Focht from comment #102)
> I propose to keep this one still separate. End users have no clue what
> "lstrcmp and others do not compare punctuation characters correctly" means
> when they see it one day appearing in release notes for a Wine release. I'm
> not suggesting to reword bug 10767 either, it's technically as verbose as
> needed, with focus on the general problem "meta".

Yes, keeping the bugs separate seems quite reasonable to me.

@Anastasius Focht: This analysis from 2008 was a blast to read. Very educational.

Meanwhile, since the fix to this bug is in staging, I managed to install Office 2002 almost completely working with this method. I thought I might share it for others who stumble upon this, even though Office 2002 today has probably rather niche usecases.

1. I used a 32bit wineprefix with Wine 6.11-staging, without installing mono or gecko. I used PlayOnLinux for easy installation, but you could probably compile it yourself, too.

2. Install Access, Word, Excel and Powerpoint with the installer. De-select all autocorrection options in the installer. They won't install properly (probably another bug) and if you don't de-select them, Office keeps asking to insert the installation medium at every start.

3. I then copied the prefix in my default wine environment, which is currently 5.0-stable, ran winecfg and changed the mode to Windows XP. It probably runs in Windows 7 mode, to, but since it's Office XP you might as well put it to the proper OS version.

4. The installation is now complete. Finally, I manually created 4 launchers for the progams via alacarte (you can google that if you're unfamiliar with menu editing)

The launchers have to look similar to that:
env WINEPREFIX="/home/username/.wine-mso" wine-stable /home/username/.wine-mso/drive_c/Program\ Files/Microsoft\ Office/Office10/WINWORD.EXE

Hopefully fixed by d8c973ad95ba5e8a9a51df0dd9be587950179ec3.

Closing bugs fixed in 7.10.