Already Error while installing MS Office 2003

[Roland Kaeser]

Hello

Just tried to test install office 2003 on wine 0.9.21. But getting already errors. I read in C't (german it magazine) that office 2003 works on codeweavers. Can somebody declare me this? Does codeweavers voluntary not provide the corrections to wine to sell their product? Looks very strange to me.

Roland

Debug Output while installing office (breaks down when it trieds to start installation of the files (after setup configuration and serial number request)
---------------------------------------------------------------------------------------------------------

fixme:imm:ImmDisableIME (-1): stub
fixme:advapi:CheckTokenMembership ((nil) 0x190388 0x346d3c) stub!
err:ole:CoUninitialize Mismatched CoUninitialize
err:ole:CoUninitialize Mismatched CoUninitialize
fixme:advapi:CheckTokenMembership ((nil) 0x1ad6f8 0x7d3683b8) stub!
err:msidb:WHERE_VerifyCondition Couldn't find column L"Lock"
fixme:msi:msi_unimplemented_action_stub MigrateFeatureStates -> 67 ignored L"Upgrade" table values
err:msidb:WHERE_VerifyCondition Couldn't find column L"Lock"
err:msi:msi_dialog_set_font No font entry for L"52"
err:msi:msi_dialog_set_font No font entry for L"9"
err:msi:msi_dialog_set_font No font entry for L"52"
fixme:msi:ControlEvent_SpawnWaitDialog Doing Nothing
fixme:msi:ControlEvent_SpawnWaitDialog Doing Nothing
err:msi:msi_dialog_set_font No font entry for L"100"
err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x1ed990 next block has PREV_FREE flag
fixme:msi:msi_unimplemented_action_stub MigrateFeatureStates -> 67 ignored L"Upgrade" table values
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\1031\OFREADME.HTM")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\1031\OFREADME.HTM")
fixme:msi:ACTION_HandleStandardAction unhandled standard action L"SetODBCFolders"
fixme:msi:deformat_component component key L"HTM_Editor_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"HTM_Editor_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"Core_IDE_Resource_DLLs_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"Core_IDE_Resource_DLLs_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"Core_IDE_Cmd_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"Core_IDE_Cmd_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"VS_SCC_Core_TeamCore_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"VS_SCC_Core_TeamCore_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"CSS_Package_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"CSS_Package_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"_VS_Debugging_SDM2_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"_VS_Debugging_SDM2_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"_VS_Debugging_VSDebug_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"_VS_Debugging_VSDebug_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"WbBrwsrPckgRsrcDLLDEUX86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"WbBrwsrPckgRsrcDLLDEUX86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"URL_Font_Color_Picker_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
fixme:msi:deformat_component component key L"URL_Font_Color_Picker_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\CSSPKGUI.DLL")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\CSSPKGUI.DLL")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\HTMEDUI.DLL")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\HTMEDUI.DLL")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\htmdlgsUI.dll")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\htmdlgsUI.dll")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\vsdebugui.dll")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\vsdebugui.dll")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\MSDBGUI.DLL")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\MSDBGUI.DLL")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\MSENVUI.DLL")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\MSENVUI.DLL")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\vsbrowseUI.dll")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\vsbrowseUI.dll")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\VisualStudioTeamCoreUI.dll")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\VisualStudioTeamCoreUI.dll")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\CMDDEFUI.DLL")
err:msi:deformat_file Unable to get ShortPath size (L"c:\Programme\Microsoft Office\OFFICE11\VS Runtime\1031\CMDDEFUI.DLL")
err:msi:ITERATE_Actions Execution halted, action L"SKURED" returned 1603
err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603
fixme:msi:msi_dialog_set_control_condition Unhandled action L"Default"
fixme:msi:msi_dialog_set_control_condition Unhandled action L"Default"

[Vijay Kiran Kamuju]

May be Alexander might have rejected some patches on wine for MSI that
went to codeweavers.
A guess of course.

On 9/15/06, Roland Kaeser  wrote:
> Hello
>
> Just tried to test install office 2003 on wine 0.9.21. But getting already
> errors. I read in C't (german it magazine) that office 2003 works on
> codeweavers. Can somebody declare me this? Does codeweavers voluntary not
> provide the corrections to wine to sell their product? Looks very strange to
> me.
>
> Roland
>
> Debug Output while installing office (breaks down when it trieds to start
> installation of the files (after setup configuration and serial number
> request)
>
> fixme:imm:ImmDisableIME (-1): stub
> fixme:advapi:CheckTokenMembership ((nil) 0x190388 0x346d3c)
> stub!
> err:ole:CoUninitialize Mismatched CoUninitialize
> err:ole:CoUninitialize Mismatched CoUninitialize
> fixme:advapi:CheckTokenMembership ((nil) 0x1ad6f8
> 0x7d3683b8) stub!
> err:msidb:WHERE_VerifyCondition Couldn't find column L"Lock"
> fixme:msi:msi_unimplemented_action_stub
> MigrateFeatureStates -> 67 ignored L"Upgrade" table values
> err:msidb:WHERE_VerifyCondition Couldn't find column L"Lock"
> err:msi:msi_dialog_set_font No font entry for L"52"
> err:msi:msi_dialog_set_font No font entry for L"9"
> err:msi:msi_dialog_set_font No font entry for L"52"
> fixme:msi:ControlEvent_SpawnWaitDialog Doing Nothing
> fixme:msi:ControlEvent_SpawnWaitDialog Doing Nothing
> err:msi:msi_dialog_set_font No font entry for L"100"
> err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use
> arena 0x1ed990 next block has PREV_FREE flag
> fixme:msi:msi_unimplemented_action_stub
> MigrateFeatureStates -> 67 ignored L"Upgrade" table values
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft
> Office\OFFICE11\1031\OFREADME.HTM")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft
> Office\OFFICE11\1031\OFREADME.HTM")
> fixme:msi:ACTION_HandleStandardAction unhandled standard
> action L"SetODBCFolders"
> fixme:msi:deformat_component component key
> L"HTM_Editor_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"HTM_Editor_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"Core_IDE_Resource_DLLs_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"Core_IDE_Resource_DLLs_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"Core_IDE_Cmd_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"Core_IDE_Cmd_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"VS_SCC_Core_TeamCore_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"VS_SCC_Core_TeamCore_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"CSS_Package_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"CSS_Package_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"_VS_Debugging_SDM2_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"_VS_Debugging_SDM2_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"_VS_Debugging_VSDebug_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"_VS_Debugging_VSDebug_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"WbBrwsrPckgRsrcDLLDEUX86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"WbBrwsrPckgRsrcDLLDEUX86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"URL_Font_Color_Picker_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> fixme:msi:deformat_component component key
> L"URL_Font_Color_Picker_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8"
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\CSSPKGUI.DLL")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\CSSPKGUI.DLL")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\HTMEDUI.DLL")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\HTMEDUI.DLL")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\htmdlgsUI.dll")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\htmdlgsUI.dll")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\vsdebugui.dll")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\vsdebugui.dll")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\MSDBGUI.DLL")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\MSDBGUI.DLL")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\MSENVUI.DLL")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\MSENVUI.DLL")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\vsbrowseUI.dll")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\vsbrowseUI.dll")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\VisualStudioTeamCoreUI.dll")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\VisualStudioTeamCoreUI.dll")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\CMDDEFUI.DLL")
> err:msi:deformat_file Unable to get ShortPath size
> (L"c:\Programme\Microsoft Office\OFFICE11\VS
> Runtime\1031\CMDDEFUI.DLL")
> err:msi:ITERATE_Actions Execution halted, action L"SKURED" returned 1603
> err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned
> 1603
> fixme:msi:msi_dialog_set_control_condition Unhandled action
> L"Default"
> fixme:msi:msi_dialog_set_control_condition Unhandled action
> L"Default"

[Jim White]

Roland Kaeser wrote:
> Just tried to test install office 2003 on wine 0.9.21. But getting
> already errors. I read in C't (german it magazine) that office 2003
> works on codeweavers. Can somebody declare me this? Does codeweavers
> voluntary not provide the corrections to wine to sell their product?
> Looks very strange to me.
> ...

Codeweavers version of Wine has changes that Alexandre deems
unacceptable for the "clean" WineHQ tree.

The Codeweavers Wine source is here:

http://www.codeweavers.com/products/source/

Jim

AW: Already Error while installing MS Office 2003

[Roland Kaeser]

Hello
> Codeweavers version of Wine has changes that Alexandre deems
> unacceptable for the "clean" WineHQ tree.

If this is that way, it would be real a horror. Why are code patches which allows a huge major app (key application) to run on linux "unacceptable" (From point of view of the MS users). Do we here make trench warfares?  Or are there quality conceivabilities which are completely unrealistic? Shouldn't we not see the major goal of wine? To run windows apps on linux? Not to have a few lines code a bit better quality etc. I think we don't have the choice to reject code. Be very very thankful for each line which is checked in!! I think some responsible persons are to deep in the code.  They are looking just into the code but can't see the benefit of the code for the wine project itself. Why don't just accept the code? There is enough time later to make it more "beautiful" or correct it to a better quality. But for the moment, some of the code directly allows important apps to work.

Roland
> ----- Ursprüngliche Mail ----
> Von: Jim White 
> An: Roland Kaeser 
> CC: [e-mail]
> Gesendet: Freitag, den 15. September 2006, 19:41:45 Uhr
> Betreff: Re: Already Error while installing MS Office 2003
>
> Roland Kaeser wrote:
> > Just tried to test install office 2003 on wine 0.9.21. But getting
> > already errors. I read in C't (german it magazine) that office 2003
> > works on codeweavers. Can somebody declare me this? Does codeweavers
> > voluntary not provide the corrections to wine to sell their product?
> > Looks very strange to me.
> > ...
>
> Codeweavers version of Wine has changes that Alexandre deems
> unacceptable for the "clean" WineHQ tree.
>
> The Codeweavers Wine source is here:
>
> http://www.codeweavers.com/products/source/
>
> Jim

[James Hawkins]

On 9/15/06, Roland Kaeser  wrote:
> Hello
> > Codeweavers version of Wine has changes that Alexandre deems
> > unacceptable for the "clean" WineHQ tree.
>
> If this is that way, it would be real a horror. Why are code patches which
> allows a huge major app (key application) to run on linux "unacceptable"
> (From point of view of the MS users). Do we here make trench warfares?  Or
> are there quality conceivabilities which are completely unrealistic?
> Shouldn't we not see the major goal of wine? To run windows apps on linux?
> Not to have a few lines code a bit better quality etc. I think we don't have
> the choice to reject code. Be very very thankful for each line which is
> checked in!! I think some responsible persons are to deep in the code.  They
> are looking just into the code but can't see the benefit of the code for the
> wine project itself. Why don't just accept the code? There is enough time
> later to make it more "beautiful" or correct it to a better quality. But for
> the moment, some of the code directly allows important apps to work.

Are you a software developer of any kind?  This is a professional open
source product, and we only allow the cleanest code in our tree.  Wine
is one of the most impressive pieces of software I've ever had the
chance to work on.  I, and all the other developers of Wine, do not
want hacks in the code base, and am very thankful they are not
allowed.  If someone really wants an application to work, they can
spend time and effort on writing proper fixes for the Wine tree, as we
all do.

AW: Already Error while installing MS Office 2003

[Roland Kaeser]

> Are you a software developer of any kind?  This is a professional open
> source product, and we only allow the cleanest code in our tree.  Wine
> is one of the most impressive pieces of software I've ever had the
> chance to work on.  I, and all the other developers of Wine, do not
> want hacks in the code base, and am very thankful they are not
> allowed.  If someone really wants an application to work, they can
> spend time and effort on writing proper fixes for the Wine tree, as we
> all do.

Yes, I'm a software developer and I know from a uncountable amout of projects that perfect and absolute clean code is IMPOSSIBLE. Its always a calculation between the efforts and the expected results. Yes, You can write absolute (as far as this is generally possible) code but then wine will be arrive version 1.0 in 2020. Just think about the goal, users don't interst the coding quality of the sourcecode, they just want to run their windows apps on linux. I know a lot of people where have no idea about opensource. They just wan't to run their apps. And they wan't do it asap not after waiting 10 years. Look for all the alternate opensource project for properitary software, such as gimp,scribus,inkscape,openoffice,firefox,kdenlive,cinelerra,etc. Soon, the time will come where is no longer need for wine because the opensource apps are much better and more performant than actually the windows apps are. Don't You think wine (version 1.0) should be finished before this time?

Roland
> ----- Ursprüngliche Mail ----
> Von: James Hawkins 
> An: Roland Kaeser 
> CC: Jim White ; [e-mail]
> Gesendet: Samstag, den 16. September 2006, 09:47:27 Uhr
> Betreff: Re: Already Error while installing MS Office 2003
>
> On 9/15/06, Roland Kaeser  wrote:
> > Hello
> > > Codeweavers version of Wine has changes that Alexandre deems
> > > unacceptable for the "clean" WineHQ tree.
> >
> > If this is that way, it would be real a horror. Why are code patches which
> > allows a huge major app (key application) to run on linux "unacceptable"
> > (From point of view of the MS users). Do we here make trench warfares?  Or
> > are there quality conceivabilities which are completely unrealistic?
> > Shouldn't we not see the major goal of wine? To run windows apps on linux?
> > Not to have a few lines code a bit better quality etc. I think we don't have
> > the choice to reject code. Be very very thankful for each line which is
> > checked in!! I think some responsible persons are to deep in the code.  They
> > are looking just into the code but can't see the benefit of the code for the
> > wine project itself. Why don't just accept the code? There is enough time
> > later to make it more "beautiful" or correct it to a better quality. But for
> > the moment, some of the code directly allows important apps to work.
>
> Are you a software developer of any kind?  This is a professional open
> source product, and we only allow the cleanest code in our tree.  Wine
> is one of the most impressive pieces of software I've ever had the
> chance to work on.  I, and all the other developers of Wine, do not
> want hacks in the code base, and am very thankful they are not
> allowed.  If someone really wants an application to work, they can
> spend time and effort on writing proper fixes for the Wine tree, as we
> all do.
>
> -- 
> James Hawkins

[Michael [Plouj] Ploujnikov]

> Just think about the goal, users don't interst the coding quality of the sourcecode, they just want to run their windows apps on linux.

It might not be evident right away, but the fact is that the quality
of the code directly affects the usability of the resulting program.
You might think that writing hacky code to allow a small set of
applications (those that you are interested in) to run is the goal.
Let's pretend that I also want some games to run under Wine. However,
the current "quality-less" code that makes these games run, also
breaks MS Office under Wine. Who do you think the Wine developers are
trying to please, me or you? As you can see, that is being selfish,
and completely ignoring the fact that this hackish code prevents other
applications to run. Like you said somewhere else, "Wine's goal is to
allow Windows Applications to run on Linux." That is correct. The goal
is _not_ to allow only _some_ applications to run. You have to think
ahead, and about others when making such claims. If you are not
convinced that quality is important in the code, read some articles on
this site: www.thedailywtf.com
> They just wan't to run their apps. And they wan't do it asap not after waiting 10 years.

You have no right to be so demanding of an Open Source project unless
you are giving money to the developers for their work.

[Stephen Eilert]

On 9/16/06, Roland Kaeser  wrote:
> > Are you a software developer of any kind?  This is a professional open
> > source product, and we only allow the cleanest code in our tree.  Wine
> > is one of the most impressive pieces of software I've ever had the
> > chance to work on.  I, and all the other developers of Wine, do not
> > want hacks in the code base, and am very thankful they are not
> > allowed.  If someone really wants an application to work, they can
> > spend time and effort on writing proper fixes for the Wine tree, as we
> > all do.
>
> Yes, I'm a software developer and I know from a uncountable amout of
> projects that perfect and absolute clean code is IMPOSSIBLE. Its always a
> calculation between the efforts and the expected results. Yes, You can write
> absolute (as far as this is generally possible) code but then wine will be
> arrive version 1.0 in 2020. Just think about the goal, users don't interst
> the coding quality of the sourcecode, they just want to run their windows
> apps on linux. I know a lot of people where have no idea about opensource.
> They just wan't to run their apps. And they wan't do it asap not after
> waiting 10 years. Look for all the alternate opensource project for
> properitary software, such as
> gimp,scribus,inkscape,openoffice,firefox,kdenlive,cinelerra,etc.
> Soon, the time will come where is no longer need for wine because the
> opensource apps are much better and more performant than actually the
> windows apps are. Don't You think wine (version 1.0) should be finished
> before this time?
>
> Roland

If they start allowing all sort of creepy hacks, the end result won't
be Wine getting done faster. If anything, it will become completely
unmanageable and require a rewrite. By then, it might be hopelessly
broken.

Since you are a developer, why don't you clean codeweaver's hacks and
resubmit the code? You are wasting time and effort arguing here that
could be better spent writing code.

Stephen

AW: Already Error while installing MS Office 2003

[Colin Wright]

(Reformatted to bottom-posting)

Roland Kaeser wrote:
> > ----- Ursprüngliche Mail ----
> > Von: Jim White 
> > An: Roland Kaeser 
> > CC: [e-mail]
> > Gesendet: Freitag, den 15. September 2006, 19:41:45 Uhr
> > Betreff: Re: Already Error while installing MS Office 2003
> >
> > Roland Kaeser wrote:
> > > Just tried to test install office 2003 on wine 0.9.21. But getting
> > > already errors. I read in C't (german it magazine) that office 2003
> > > works on codeweavers. Can somebody declare me this? Does codeweavers
> > > voluntary not provide the corrections to wine to sell their product?
> > > Looks very strange to me.
> > > ...
> >
> > Codeweavers version of Wine has changes that Alexandre deems
> > unacceptable for the "clean" WineHQ tree.
> >
> > The Codeweavers Wine source is here:
> >
> > http://www.codeweavers.com/products/source/
> >
> > Jim
>
> Hello
> > Codeweavers version of Wine has changes that Alexandre deems
> > unacceptable for the "clean" WineHQ tree.
>
> If this is that way, it would be real a horror. Why are code patches 
> which allows a huge major app (key application) to run on linux 
> "unacceptable" (From point of view of the MS users). Do we here make 
> trench warfares?  Or are there quality conceivabilities which are 
> completely unrealistic? Shouldn't we not see the major goal of wine? To 
> run windows apps on linux? Not to have a few lines code a bit better 
> quality etc. I think we don't have the choice to reject code. Be very 
> very thankful for each line which is checked in!! I think some 
> responsible persons are to deep in the code.  They are looking just into 
> the code but can't see the benefit of the code for the wine project 
> itself. Why don't just accept the code? There is enough time later to 
> make it more "beautiful" or correct it to a better quality. But for the 
> moment, some of the code directly allows important apps to work.
>
> Roland

<unlurk>
This is a very old, very shrivelled chestnut.

CodeWeavers' CrossOver Office is guaranteed to run a specific,
limited list of program, including specified versions
of Microsoft Office.  It may, or may not, run other program.

Having a limited list of supported program makes it feasible
to include program-specific code and incomplete implementations of
Windows API functions that could cause errors in other programs.

WineHQ's doesn't have the "advantage" of limited focus.  WineHQ
does not include program-specific code.  Its focus is a full
and efficient implementation of the Windows API.  Programs
become supported by WineHQ as new parts of the Windows API are
implemented and the implementations completed.  Program-specific
code would cause bloat and be difficult to maintain.  Accepting
inefficient code allow inefficiencies to build up and
impact greatly on performance.

That's not to say that WineHQ development isn't driven by
the desire to support particular programs.  It is, but the
difference to CrossOver is that the code that is accepted
into WineHQ is expected to work with all Windows program.
( There is a specific issue with the window management
that can cause a problem for some 3D games, but that would
involve another highly complex rewrite to fix so I think the
previous sentence is reasonable. )  When WineHQ breaks a
program that used to work it's usually a bug in new code
that the test suite couldn't identify, not because the code
to support one program is incompatible with another.

To get the CrossOver solutions into WineHQ the program-specific
code first has to be rewritten as an efficient, generic solution.
While that may delay support of some programs in the WineHQ
releases and source the long-term benefits for WineHQ are
speed, reduced size and more supported programs.

It's quite wrong to say that WineHQ can't afford to reject code.
The reason it can and should reject code can be summed up in
two words: open source.

The open source model allows WineHQ to have very high standards
because any user that needs support for specific programs can
download the source, patch it and compile it themselves.

In fact, that's how CrossOver works.  It's a version from WineHQ
patched for the supported programs.  When CodeWeavers rewrite their
program-specific patches into a generic solution that is committed
to WineHQ they will also be able to update their tree with the generic
solution.  Program-specific patches are a maintenance overhead and the
closer they are to the WineHQ tree the better.  By keeping their tree
closer to the WineHQ tree it will also be easier to use other patches
committed to WineHQ.  I'm sure that at certain times CrossOver is updated
to a set of patches against a newer WineHQ version for those reasons.

The CrossOffice source is publicly available at the URL Jim White gave.
Patches sent for submission to WineHQ are available on the
Wine patches list (gmane.comp.emulators.wine.patches) even if
not in the WineHQ repository.

Want the CrossOver program-specific code so you can run Office 2003
but don't want to or can't afford to pay for support?
Get the source from the URL Jim gave and compile it yourself.

Want to play World of Warcraft?  Download the WineHQ source,
get the World of Warcraft patch and compile it yourself.

Need support for another game that WineHQ can't yet handle?
Try some of the latest patches.

Want to run on Solaris?  Get the Solaris patches.

The WineHQ repository provides a evolving, high-quality
foundation on which to build.  Anything that weakens
that foundation would only damage Wine in the future.

I'm not a Wine developer.  I thought I'd give a little of my time
to save them some.

Colin

</unlurk>

AW: Already Error while installing MS Office 2003

[Detlef Riekenberg]

On Sa, 2006-09-16 at 06:34 +0000, Roland Kaeser wrote:
> Why don't just accept the code?

You want stable software, don't you?
> There is enough time later to make it more "beautiful" or correct it
> to a better quality.

Who will do it later?
Nobody!
> But for the moment, some of the code directly allows important apps to
> work.

And break other Applications.

AW: AW: Already Error while installing MS Office 2003

[Roland Kaeser]

> You want stable software, don't you?

Yes but not for the price of developing 10 years for a software.
> And break other Applications.

Not urgently

Hey guys can't anybody see the reason? The wine project (or the finish of itself) could bring linux the breakthrough. I know a lot of people who asks as first question: Is this or the other app working on linux? Then I will think about a migration.

Yes, faster development is paid by a less of stability. But is wine currently stable? By many tests with windows apps could I recognize that it is not ever!

We should make a weekly public list of currently working applications (out of the box). I strongly think this is the measurement of the development progress of wine. This is is also the only thing users are interested in! So if the developers has a huge effort to develop things in wine but the count of working apps is not increasing over the time so its a strong indicator that something goes wrong. Think about commercial software dev projects they have milestones and deadlines and they have to fulfil it. Why not making hard milestones and a hard deadline which the project itself can measure against it . Lets say the deadline of a version 1.0 is end of next year (2008-01-01). So if everybody has this deadline in brain, it meight make the whole thing a bit more efficient. Its easier to make hard priority decisions.

Roland
> ----- Ursprüngliche Mail ----
> Von: Detlef Riekenberg 
> An: Roland Kaeser 
> CC: Jim White ; [e-mail]
> Gesendet: Samstag, den 16. September 2006, 19:16:34 Uhr
> Betreff: Re: AW: Already Error while installing MS Office 2003
>
> On Sa, 2006-09-16 at 06:34 +0000, Roland Kaeser wrote:
> > Why don't just accept the code?
>
> You want stable software, don't you?
> > There is enough time later to make it more "beautiful" or correct it
> > to a better quality.
>
> Who will do it later?
> Nobody!
> > But for the moment, some of the code directly allows important apps to
> > work.
>
> And break other Applications.
>
> --
>
> By by ... Detlef

AW: Already Error while installing MS Office 2003

[Stephen Eilert]

I like the deadline idea, but I do think they've got this already,
just not in terms of working applications, but subsystems.

For the *weekly* application list, who is going to compile it? Wine is
not Microsoft, therefore they do not have access to something along
the lines of Microsoft's Compatibility Lab (and I think not even
Microsoft itself could release this weekly list).

Furthermore, applications have to be legally purchased to be tested,
as far as I know. I'm not a [wine]developer, but I think you have
absolutely no idea of the amount of effort you are talking about.

There is Wine Application Database. I've contributed one entry myself.
Not much, I know, but at least it is a start.

Stephen

On 9/16/06, Roland Kaeser  wrote:
> > You want stable software, don't you?
>
> Yes but not for the price of developing 10 years for a software.
> > And break other Applications.
>
> Not urgently
>
> Hey guys can't anybody see the reason? The wine project (or the finish of
> itself) could bring linux the breakthrough. I know a lot of people who asks
> as first question: Is this or the other app working on linux? Then I will
> think about a migration.
>
> Yes, faster development is paid by a less of stability. But is wine
> currently stable? By many tests with windows apps could I recognize that it
> is not ever!
>
> We should make a weekly public list of currently working applications (out
> of the box). I strongly think this is the measurement of the development
> progress of wine. This is is also the only thing users are interested in! So
> if the developers has a huge effort to develop things in wine but the count
> of working apps is not increasing over the time so its a strong indicator
> that something goes wrong. Think about commercial software dev projects they
> have milestones and deadlines and they have to fulfil it. Why not making
> hard milestones and a hard deadline which the project itself can measure
> against it . Lets say the deadline of a version 1.0 is end of next year
> (2008-01-01). So if everybody has this deadline in brain, it meight make the
> whole thing a bit more efficient. Its easier to make hard priority
> decisions.
>
> Roland
> > ----- Ursprüngliche Mail ----
> > Von: Detlef Riekenberg
> > An: Roland Kaeser 
> > CC: Jim White ; [e-mail]
> > Gesendet: Samstag, den 16. September 2006, 19:16:34 Uhr
> > Betreff: Re: AW: Already Error while installing MS Office 2003
> > On Sa, 2006-09-16 at 06:34 +0000, Roland Kaeser wrote:
> > > Why don't just accept the code?
> >
> > You want stable software, don't you?
> > > There is enough time later to make it more "beautiful" or correct it
> > > to a better quality.
> >
> > Who will do it later?
> > Nobody!
> > > But for the moment, some of the code directly allows important apps to
> > > work.
> >
> > And break other Applications.
> >
> > --
> >
> > By by ... Detlef

AW: AW: Already Error while installing MS Office 2003

[Roland Kaeser]

> For the *weekly* application list, who is going to compile it? Wine is
> not Microsoft, therefore they do not have access to something along
> the lines of Microsoft's Compatibility Lab (and I think not even
> Microsoft itself could release this weekly list).

Eventually we could talk to the application maintainers (as my self) to provide a weekly state (via mail ev.) of their maintaned app. Regarding to the application rating in the appdb. Just list all the apps with a gold state. It also whold give a good overview for which apps wine is currently ready and it whould also be a good monitor of regression issues.

Roland
> ----- Ursprüngliche Mail ----
> Von: Stephen Eilert 
> An: Roland Kaeser 
> CC: [e-mail]
> Gesendet: Samstag, den 16. September 2006, 20:11:24 Uhr
> Betreff: Re: AW: Already Error while installing MS Office 2003
> I like the deadline idea, but I do think they've got this already,
> just not in terms of working applications, but subsystems.
> For the *weekly* application list, who is going to compile it? Wine is
> not Microsoft, therefore they do not have access to something along
> the lines of Microsoft's Compatibility Lab (and I think not even
> Microsoft itself could release this weekly list).
> Furthermore, applications have to be legally purchased to be tested,
> as far as I know. I'm not a [wine]developer, but I think you have
> absolutely no idea of the amount of effort you are talking about.
>
> There is Wine Application Database. I've contributed one entry myself.
> Not much, I know, but at least it is a start.
>
> Stephen
>
> On 9/16/06, Roland Kaeser  wrote:
> > > You want stable software, don't you?
> >
> > Yes but not for the price of developing 10 years for a software.
> > > And break other Applications.
> >
> > Not urgently
> >
> > Hey guys can't anybody see the reason? The wine project (or the finish of
> > itself) could bring linux the breakthrough. I know a lot of people who asks
> > as first question: Is this or the other app working on linux? Then I will
> > think about a migration.
> >
> > Yes, faster development is paid by a less of stability. But is wine
> > currently stable? By many tests with windows apps could I recognize that it
> > is not ever!
> >
> > We should make a weekly public list of currently working applications (out
> > of the box). I strongly think this is the measurement of the development
> > progress of wine. This is is also the only thing users are interested in! So
> > if the developers has a huge effort to develop things in wine but the count
> > of working apps is not increasing over the time so its a strong indicator
> > that something goes wrong. Think about commercial software dev projects they
> > have milestones and deadlines and they have to fulfil it. Why not making
> > hard milestones and a hard deadline which the project itself can measure
> > against it . Lets say the deadline of a version 1.0 is end of next year
> > (2008-01-01). So if everybody has this deadline in brain, it meight make the
> > whole thing a bit more efficient. Its easier to make hard priority
> > decisions.
> >
> > Roland
> > > ----- Ursprüngliche Mail ----
> > > Von: Detlef Riekenberg
> > > An: Roland Kaeser 
> > > CC: Jim White ; [e-mail]
> > > Gesendet: Samstag, den 16. September 2006, 19:16:34 Uhr
> > > Betreff: Re: AW: Already Error while installing MS Office 2003
> > > On Sa, 2006-09-16 at 06:34 +0000, Roland Kaeser wrote:
> > > > Why don't just accept the code?
> > >
> > > You want stable software, don't you?
> > > > There is enough time later to make it more "beautiful" or correct it
> > > > to a better quality.
> > >
> > > Who will do it later?
> > > Nobody!
> > > > But for the moment, some of the code directly allows important apps to
> > > > work.
> > >
> > > And break other Applications.
> > >
> > > --
> > >
> > > By by ... Detlef

AW: AW: Already Error while installing MS Office 2003

[Chris Robinson]

On Saturday 16 September 2006 10:54, Roland Kaeser wrote:
> > And break other Applications.
>
> Not urgently

Depends on the application, no? Try to get the latest and greatest programs 
working, you run a strong risk of breaking old programs and games. People 
still do play/use old games/programs, so you'd immediately alienate them. Try 
to fix/hack them to work, you run the risk of breaking newer programs. In the 
end, you'll need to do a proper implementation to get most stuff working 
anyway. Why waste time with hacks?
> Hey guys can't anybody see the reason? The wine project (or the finish of
> itself) could bring linux the breakthrough.

Not with code hacked up the yin-yang. That'd be a one-way ticket to giving 
Linux/Wine the big "Unstable" badge.
> I know a lot of people who asks 
> as first question: Is this or the other app working on linux? Then I will
> think about a migration.

And with a hacked-up code base, it'd be one or the other, or neither. But most 
likely not both.
> Yes, faster development is paid by a less of stability. But is wine
> currently stable?

Wine is (almost) perfectly stable. It's just incomplete. Wine itself has 
rarely ever crashed on me. The only problems have arisen from 
its /unfinished/ WinAPI implementation. When it's complete, it'll ideally 
make Windows apps behave just as if they were on Windows. Using hacked code 
to make some programs work will almost certainly make sure other programs 
don't (with that list ever changing as more and more hacks are introduced). 
Is that stable?
> We should make a weekly public list of currently working applications (out
> of the box).

That is what AppDB is really for. But there are tons of Windows apps, and very 
few people that can commit keeping up with the latest changes. And it's not 
as simple as what works out of the box. It depends on the hardware people 
have, their driver versions, kernel versions, etc. Then you have to figure 
that the different packages for different package managers can introduce 
their own problems/tweaks.
> I strongly think this is the measurement of the development 
> progress of wine. This is is also the only thing users are interested in!

Just because that's what users are interested in doesn't mean that's the most 
important thing. A proper, manageable codebase to get 90% of the apps working 
later is far more important for Wine than a hacked up codebase that gets 
maybe 40% of the apps working now (and causing a megaton of problems to try 
to make the rest work later).

Do you want most apps to work in a while, or some apps to work now and most 
apps to work a long time from now (if ever)? And don't forget, everyone will 
have a different idea of which apps should work /now/. You complain about 
Wine taking so long to get most apps working. It'll be easilly 5 to 10 times 
longer to get most apps working if the codebase is mostly hacks.

AW: AW: Already Error while installing MS Office 2003

[Kopfgeldjaeger]

Hi,

what do you think about a wine branch that contains all available patches?
There should be a list with all those patches and as far as possible
information what a patch fixes/breaks and what would be required to get
it into the main wine.
And it would be nice if the action of patches can be seen by fixmes but
that would require a lot of work I think and is therefore optional.

And please don't understand me wrong, I am not volunteering for this job
as I'm currently busy. But if someone else volunteers for maintaining
these things, would they be officially accepted and get the required
space and bandwidth from winehq.org?

cu KGJ