Hello,

same goes for Tournament.com client (v1.66), http://appdb.winehq.org/objectManager.php?sClass=version&iId=9423

With winetricks mono112 (requires NET 2.0) the app still needs mscoree:CorBindToRuntimeEx() to be correctly implemented (actually returning "live" instance).
Nowadays there are more and more native apps that host/instantiate the CLR from unmanaged C++

Regards.

If this isn't too hard, let's address it for 1.0.

On 2008/03/14, Alexandre committed (69272d1f5204c106da8a480709bc392ec70b71ff) a patch from Alistair Leslie-Hughes which adds a stub for CorBindToRuntimeEx:

HRESULT WINAPI CorBindToRuntimeEx(LPWSTR szVersion, LPWSTR szBuildFlavor, DWORD nflags, REFCLSID rslsid,
                                  REFIID riid, LPVOID *ppv)
{
    FIXME("%s %s %d %s %s %p\n", debugstr_w(szVersion), debugstr_w(szBuildFlavor), nflags, debugstr_guid( rslsid ),
          debugstr_guid( riid ), ppv);

    *ppv = NULL;

    return E_NOTIMPL;
}


Is this enough to make the RufzXP and/or Tournament.com client applications start ?

RufzXP still crashes.

I downloaded the .net 1.1 version of RufzXP,
http://www.darc.de/referate/dx/software/rufzxp/rufzxp_fw1_1_setup_1_1_1.exe
and installed it after doing 'winetricks dotnet11' with a fresh winetricks.
Sadly, it aborts fairly quickly with the dialog
"Fatal Execution Engine Error (0x7925698a)"
There are numerous suspicious lines in the log, e.g.
fixme:shell:URL_ParseUrl failed to parse L"mscorlib"
fixme:shell:URL_ParseUrl failed to parse L"System.Drawing"
which look awfully like the ones in http://bugs.winehq.org/show_bug.cgi?id=11742
that were supposedly fixed.

This app runs just fine for me, after doing winetricks dotnet11 allfonts.
Did you try this on a fresh .wine?

I tried with a clean .wine, with today's winetricks dotnet11, 
both with and without allfonts.
In all cases, the app failed to start up.

I'm using
6b9bc1db7994f2664c1f1935df95f0b502277cb4 rufzxp_fw1_1_setup_1_1_1.exe
Is that the same for you?

Created attachment 11418 [details]
screenshot

Exactly the same:

sha1sum rufzxp_fw1_1_setup_1_1_1.exe
6b9bc1db7994f2664c1f1935df95f0b502277cb4  rufzxp_fw1_1_setup_1_1_1.exe

Starts just fine here; see screenshot

rm -rf ~/.wine 
winetricks dotnet11 allfonts
wine rufzxp_fw1_1_setup_1_1_1.exe

After the install, the app starts fine here. Weird it doesn't start for you

Aha.  +file showed 
trace:file:wine_nt_to_unix_file_name L"\\??\\Z:\\USR\\SHARE\\FONTS\\TRUETYPE\\ARPHIC\\UKAI.TTF" -> "/home/dank/.wine/dosdevices/z:/usr/share/fonts/truetype/arphic/ukai.ttf"

right before the crash.  That font is a known offender, see
http://www.codeweavers.com/compatibility/browse/name?app_id=2634;forum=1;msg=5561
I was able to work around it by doing
wget http://apt.debian.org.tw/pool/t/ttf-arphic-ukai/ttf-arphic-ukai_0.1.20060108.orig.tar.gz
tar -xzvf Desktop/ttf-arphic-ukai_0.1.20060108.orig.tar.gz ttf-arphic-ukai-0.1.20060108/ukai.ttf
mv ttf-arphic-ukai-0.1.20060108/ukai.ttf .wine/drive_c/windows/fonts/

Funny, I would have thought that bad font would have been fixed in Gutsy,
but I guess not.

Marking fixed!

uuhh, but is it really fixed?
Wouldn't it be better to resolve this one as a duplicate of that FastMD5 app-bug. It still doesn't run out of the box, you still need the 'winetricks dotnet11' work-around to get this running....

Maybe it would be better to gather all apps that run with the 'winetricks dotnet11" work around under that bug

I'm not quite sure it's a duplicate of bug 11742,
but you're right, it's not at all fixed yet;
thanks for the correction.

This is unlikely to be fixed for 1.0. Is the source of the current show
stopper known?

No, and .net is not going to be fixed for 1.0, so deferring.

Hello,

revisiting.
Yes, that app still unearths deficencies in .NET Framework 1.1 installation.
The app crashes for me at startup.
Wine: GIT (1.1.7+)
App: 6b9bc1db7994f2664c1f1935df95f0b502277cb4 rufzxp_fw1_1_setup_1_1_1.exe

If it really worked for you earlier then this might be a regression in msi.

From a quick glance it seems that Wine's msi doesn't publish/install some assemblies into GAC.

One prime example is: "Microsoft.VisualBasic.dll" assembly.
The app expects this assembly in GAC (otherwise it won't run).

It gets installed to: "C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\GAC\\Microsoft.VisualBasic.dll" - which is correct as _temporary_ location before final phase.
Windows installer always employs 2-step transactional process for CLR assemblies.
At the end this assembly should get published/installed to: "C:\\WINDOWS\\assembly\\GAC\\Microsoft.VisualBasic\\7.0.5000.0__b03f5f7f11d50a3a\\Microsoft.VisualBasic.dll"

--- snip msi install log ---
..
001f:trace:msi:msi_check_file_install_states file L"Microsoft_VisualBasic_dll_3_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" is named L"Microsoft.VisualBasic.dll"
001f:trace:msi:msi_check_file_install_states file L"Microsoft_VisualBasic_dll_3_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" resolves to L"C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\GAC\\Microsoft.VisualBasic.dll" 
..
001f:trace:msi:MSI_ProcessMessage ((nil) 0 200 L"File: Microsoft.VisualBasic.dll,  Directory: C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\GAC\\,  Size: 299008") 
..
001f:trace:msi:cabinet_copy_file extracting L"C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\GAC\\Microsoft.VisualBasic.dll"
..
001f:trace:msi:execute_script Executing Action (L"MsiPublishAssemblies")
001f:trace:msi:ACTION_PerformAction Performing action (L"MsiPublishAssemblies")
001f:trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `ActionText` WHERE `Action` = 'MsiPublishAssemblies'" 0x33f010 
..
001f:trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `MsiAssemblyName` WHERE `Component_`='VB7_Runtime_GAC_____X86.3643236F_FC70_11D3_A536_0090278A1BB8'" 0x33ef70
..
001f:trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `Media` WHERE `LastSequence` >= 5153 AND `DiskId` >= 0 ORDER BY `DiskId`" 0x33ed30 
..
001f:trace:msi:MSI_GetPropertyW returning L"C:\\windows\\temp\\IXP000.TMP\\" for property L"SourceDir"
001f:trace:msi:msi_cabextract Extracting L"C:\\windows\\temp\\IXP000.TMP\\netfx1.cab"
..
001f:trace:msi:cabinet_copy_file extracting L"C:\\windows\\temp\\System.Configuration.Install.dll"
001f:trace:msi:cabinet_notify (3)
001f:trace:msi:install_assembly installing assembly: L"C:\\windows\\temp\\System.Configuration.Install.dll"
001f:fixme:msi:install_assembly Manifest unhandled
001f:fixme:msi:install_assembly Assembly should be privately installed 
.. 
--- snip msi install log ---

install_assembly() is never called for Microsoft.VisualBasic.dll (VB7_Runtime_GAC_____X86.3643236F_FC70_11D3_A536_0090278A1BB8).

Either regression or there are still missing bits in msi/ACTION_MsiPublishAssemblies.

---

So what should we do with this bug?
The bug title doesn't reflect the current problem.
Either change the title to something more matching or close this one and open a new one copying the information there.

---

As side note: While investigating this, I encountered that race condition other people occasionally reported but no one including me took it for real...
Google for: StopDarwinService() - Call to ControlService() failed! winehq

Only happens with winetricks dotnet11 (or some other installer which tries to interact with msi server service) when WINEPREFIX is being newly created.
Looks like there is a SCM race between msi service shutdown - initiated when wineboot exits - and the app executed immediately thereafter which tries to query/control the service.

I added a note to appdb entry, though this might also apply to other stuff.

As quickfix, you might want to put a small sleep (3-5 secs) before spawning the installer in winetricks to make sure msi service shutdown is finished after wineboot exited.

Regards

Hello,

revisiting ... 
The affected assemblies are already extracted/copied from temporarily written cab files into "C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\GAC\\" before the MsiPublishAssemblies stage.
This looks like a temporary GAC location until it comes to MsiPublishAssemblies.

In MsiPublishAssemblies most of the assemblies are temp extracted from primary cab "netfx1.cab" and directly installed into system GAC.
Unfortunately the assemblies from previous install step which are also members of MsiAssembly table have their assembly->file->IsCompressed set and hence the install_assembly() stage is skipped.

I resolved the source of these assemblies to their original target location "C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\GAC\\" and made them valid install_assembly() targets.
For these assemblies the original target must be removed after this step.
It seems useless to keep them in "C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\GAC\\" - they will never be visible as GAC assemblies from this (temp) location.

With ACTION_MsiPublishAssemblies properly fixed, all assemblies get correctly installed into system wide GAC (added additional trace msg to track the state)

--- snip ---
...
0024:trace:msi:msi_check_file_install_states file L"Microsoft_VisualBasic_dll_3_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" is named L"Microsoft.VisualBasic.dll"
0024:trace:msi:msi_check_file_install_states file L"Microsoft_VisualBasic_dll_3_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" resolves to L"C:\\windows\\Microsoft.NET\\Framework\\URTInstallPath\\GAC\\Microsoft.VisualBasic.dll"
0024:trace:msi:resolve_folder Working to resolve L"URTInstallPath.3643236F_FC70_11D3_A536_0090278A1BB8"
0024:trace:msi:resolve_folder    already resolved to L"C:\\windows\\Microsoft.NET\\Framework\\URTInstallPath\\" 
...
0024:trace:msi:ACTION_MsiPublishAssemblies L"Microsoft_VisualBasic_dll_3_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" assembly->installed: 0
0024:trace:msi:ACTION_MsiPublishAssemblies L"Microsoft_VisualBasic_dll_3_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" assembly->file->IsCompressed: 1
0024:trace:msi:resolve_file_source Working to resolve source of file L"Microsoft_VisualBasic_dll_3_____X86.3643236F_FC70_11D3_A536_0090278A1BB8"
0024:trace:msi:resolve_folder Working to resolve L"GAC.3643236F_FC70_11D3_A536_0090278A1BB8"
0024:trace:msi:resolve_folder    already resolved to L"C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\GAC\\"
0024:trace:msi:install_assembly installing assembly: L"C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\GAC\\Microsoft.VisualBasic.dll"
0024:fixme:msi:install_assembly Manifest unhandled
...
--- snip ---

The app which uses the VB.NET assembly then starts and runs successfully - with native gdiplus and riched20 overrides to work around other insufficiencies.

Regards

Adding keyword 'patch' (even though we don't have one) because
the analysis is so clear...

(In reply to comment #16)
> Adding keyword 'patch' (even though we don't have one) because
> the analysis is so clear...
> 

Perhaps we need an 'Anastasius' keyword ;-).

Status?
I got similar Problems with an installer:

fixme:jscript:to_object unsupported vt 0
fixme:jscript:JSGlobal_ActiveXObject 
fixme:msi:AutomationObject_Invoke Method 2, L"Property" wflags 1 not implemented, clsid {000c109e-0000-0000-c000-000000000046}
fixme:jscript:JSGlobal_ActiveXObject 
fixme:msi:AutomationObject_Invoke Method 14, L"FeatureRequestState" wflags 1 not implemented, clsid {000c109e-0000-0000-c000-000000000046}
fixme:msi:msi_unimplemented_action_stub MsiUnpublishAssemblies -> 166 ignored L"MsiAssembly" table values
fixme:msi:msi_unimplemented_action_stub UnregisterTypeLibraries -> 43 ignored L"TypeLib" table values
fixme:msi:msi_unimplemented_action_stub UnregisterProgIdInfo -> 61 ignored L"ProgId" table values
fixme:msi:msi_unimplemented_action_stub RemoveShortcuts -> 38 ignored L"Shortcut" table values
fixme:msi:msi_unimplemented_action_stub RemoveFolders -> 599 ignored L"CreateFolder" table values
fixme:msi:install_assembly Manifest unhandled
fixme:msi:install_assembly Assembly should be privately installed

No File is installed in any directory, eccept C:\\windows\\Microsoft.NET\\Framework\\v2*\\GAC\\

Hello,

--- quote ---
Status?
I got similar Problems with an installer
--- quote ---

Just check corresponding appdb entries for current status, I tend to keep everything up-to-date.
The reason is either there are no resources for fixing or the bug's importance is considered low (questionable).
But you are not alone ... there are a couple of msi bugs open for some time now I consider major (including regressions) - you have to live with it.

You could try to fix it by yourself - all bugs contain enough analysis/hints to produce a workable patch along with conformance test.

Regards

> So what should we do with this bug?
> The bug title doesn't reflect the current problem.
> Either change the title to something more matching 

Done, also changing to component to msi

updated download link

Assigning to Hans.

Created attachment 28368 [details]
msi: Fix installation of assemblies from multiple compressed sources.

The problem is that we don't advance to the right cabinet, so only
assemblies in the first cabinet will be installed.

Hello,

--- quote ---
The problem is that we don't advance to the right cabinet, so only
assemblies in the first cabinet will be installed.
--- quote ---

Sure, with that patch it looks a lot better ;-)
The missing assemblies (Microsoft.VisualBasic.dll and companions) are now installed though I can't test with that RufzXP app anymore as the download link seems to require some kind of registration now.

Regards

Patch committed as d17ebc4032e8828bcdfce9927be84d0809606996.

Hello,

--- quote ---
Patch committed as d17ebc4032e8828bcdfce9927be84d0809606996.
--- quote ---

The .NET 1.1 Framework based version of the app isn't available anymore (links are dead while .NET 2.0 ones are alive).
I'm sure this bug is fixed hence it should be closed.

Regards

Closing.

(In reply to comment #26)
> Hello,
> 
> --- quote ---
> Patch committed as d17ebc4032e8828bcdfce9927be84d0809606996.
> --- quote ---
> 
> The .NET 1.1 Framework based version of the app isn't available anymore (links
> are dead while .NET 2.0 ones are alive).
> I'm sure this bug is fixed hence it should be closed.
> 
> Regards

I still have the rufzxp_fw1_1_setup_1_1_1.exe lying around on my disk here. I can confirm the app starts fine in current git after installing .net 1.1.

Closing bugs fixed in 1.2-rc3.

Hello folks,

adding stable download link via Internet Archive for documentation.

From:

https://web.archive.org/web/20210309153413/http://www.rufzxp.net/download.htm

https://web.archive.org/web/20170301180632/http://rufzxp.net/software/rufzxp_fw1_1_setup_1_1_1.exe

https://www.virustotal.com/gui/file/5d7f6c1f23caa3bff96f37ad859e64115f8419a82619bcd3b45ab80f2327dcce

$ sha1sum rufzxp_fw1_1_setup_1_1_1.exe 
6b9bc1db7994f2664c1f1935df95f0b502277cb4  rufzxp_fw1_1_setup_1_1_1.exe

$ du -sh rufzxp_fw1_1_setup_1_1_1.exe 
2.5M	rufzxp_fw1_1_setup_1_1_1.exe

Regards