[Bug 30438] Lexware Buchhalter 2012 fails to start

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Apr 18 17:59:00 CDT 2012


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

Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |dotnet
             Status|UNCONFIRMED                 |NEW
         Depends on|                            |25340, 30447, 29355
     Ever Confirmed|0                           |1

--- Comment #5 from Anastasius Focht <focht at gmx.net> 2012-04-18 17:59:00 CDT ---
Hello,

thanks for the media, confirming.

The COM class in question lives in "LFOApplication20.dll".

I traced the whole msi based installation, dumped the MSI with Orca, watched
for self-registration/registry data writes - no avail - the CLSID is not
written to registry.

The solution: "LFOApplication20.dll" is a registration-less COM server, using
PE manifest:

--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files/Lexware/buchhalter/2012

$ find . -iname "*.dll" | xargs -i strings {} | grep
"808380AA-A7F5-4DCF-A0F0-EF014F6ACE7A" 
...
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0"><assemblyIdentity name="LFOApplication20" type="win32"
version="16.0.0.0"></assemblyIdentity><file name="LFOApplication20.dll"
hashalg="SHA1"><comClass clsid="{808380AA-A7F5-4DCF-A0F0-EF014F6ACE7A}"
tlbid="{ADD6EE71-E283-4D0E-8D17-8656A4FE5163}"
description="LFOApplicationManager Class" threadingModel="Apartment"
progid="Lexware.LFOApplicationManager"><progid>Lexware.LFOApplicationManager.1</progid></comClass><typelib
tlbid="{ADD6EE71-E283-4D0E-8D17-8656A4FE5163}" version="1.0" helpdir=""
flags="HASDISKIMAGE"></typelib></file><comInterfaceExternalProxyStub
name="ILFOApplicationManager" iid="{0760996F-AD1B-43D3-BFAD-2E30341C928B}"
tlbid="{ADD6EE71-E283-4D0E-8D17-8656A4FE5163}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub><comInterfaceExternalProxyStub
name="ILFOApplicationManager2" iid="{C6347F57-28A7-4BD5-BF20-A97F0AC21F81}"
tlbid="{ADD6EE71-E283-4D0E-8D17-8656A4FE5163}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub><comInterfaceExternalProxyStub
name="ILFOApplicationManager3" iid="{F3D0A10D-7B38-45FB-B943-504AB0F18F9E}"
tlbid="{ADD6EE71-E283-4D0E-8D17-8656A4FE5163}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub><comInterfaceExternalProxyStub
name="ILFOApplicationManager4" iid="{1B83E4FB-98A1-4045-8F5B-233F5EE035E4}"
tlbid="{ADD6EE71-E283-4D0E-8D17-8656A4FE5163}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub></assembly>
--- snip ---

This is bug 25340

=========

Many of the dlls in application folder are either pure .NET assemblies or
mixed-mode ones.
There is also VC++ 2010 runtime with managed/mixed mode parts.

The .NET metadata pointed by CLR/CLI header always starts with "BSJB"
signature.

Metadata Header Storage Signature:

--- snip ---
0x424a5342 Signature (hex for "BSJB" (only backwards due to endianness))
0x0001 Major Version
0x0001 Minor Version
0x00000000 Extra Data Offset
0x0000000c Version String Length
'v2.0.50727' Version String
--- snip ---

Using some shell wizardry we scan through all local assemblies to find the .NET
Framework versions required:

--- snip ---
$ find . -type f \( -iname "*.dll" -or -iname "*.exe" \) | xargs -i file {} |
grep assembly | cut -f1 -d: | xargs -IX sh -c "echo X && (hexdump -C X | grep
BSJB -B0 -C2)"
...
./Haufe.Common.UI.ProgressBar.dll
00000c70  50 41 44 50 b4 00 00 00  42 53 4a 42 01 00 01 00  |PADP....BSJB....|
00000c80  00 00 00 00 0c 00 00 00  76 34 2e 30 2e 33 30 33  |........v4.0.303|
00000c90  31 39 00 00 00 00 05 00  6c 00 00 00 84 09 00 00  |19......l.......|
./AxInterop.RenesisXLib.dll
00000460  42 53 4a 42 01 00 01 00  00 00 00 00 0c 00 00 00  |BSJB............|
00000470  76 32 2e 30 2e 35 30 37  32 37 00 00 00 00 05 00  |v2.0.50727......|
00000480  6c 00 00 00 88 03 00 00  23 7e 00 00 f4 03 00 00  |l.......#~......|
--- snip ---

We need .NET Framework 2.0 and 4.0 installed in WINEPREFIX.

Basic recipe (correct order of recipes is necessary, if ie7 comes there will be
some crashing/hanging process on self-registration, preventing clean wineserver
shutdown)

$ bash winetricks -q ie7 (bug 30447)
$ bash winetricks -q msxml3 (bug 29355)
$ bash winetricks -q dotnet20 dotnet40

<app installer>

=========

For the registry-free COM server there is a workaround (because
DllRegisterServer is exported and typelib data is present):

--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files/Lexware/buchhalter/2012

$ find . -type f -iname "*.dll" | xargs grep -l DllRegisterServer | xargs -i
regsvr32 {}
--- snip ---

Not pretty but well...

There is also a small problem while registering one dll:

--- snip ---
fixme:actctx:parse_depend_manifests Could not find dependent assembly
L"Microsoft.VC80.MFC" (8.0.50727.762)
err:module:import_dll Library MFC80.DLL (which is needed by L"C:\\Program
Files\\Lexware\\buchhalter\\2012\\KRCheck.dll") not found
--- snip ---

VC++ 2005 runtime is not shipped by installer, this is probably an oversight by
vendor/packager.
Not sure if this dll is really needed, you might skip it or 'winetricks -q
vcrun2005' before registration.

=========

After installation there will be a font/gdiplus problem on startup:

--- snip ---
System.ArgumentException: Value of '-11' is not valid for 'emSize'. 'emSize'
should be greater than 0 and less than or equal to System.Single.MaxValue.
Parameter name: emSize
   at System.Drawing.Font.Initialize(FontFamily family, Single emSize,
FontStyle style, GraphicsUnit unit, Byte gdiCharSet, Boolean gdiVerticalFont)
   at System.Drawing.Font..ctor(IntPtr nativeFont, Byte gdiCharSet, Boolean
gdiVerticalFont)
   at System.Drawing.Font.FromLogFont(Object lf, IntPtr hdc)
   at System.Drawing.Font.FromHfont(IntPtr hfont)
   at Lexware.Common.UI.Navigation.NavigationPanel.UseUISettings()
--- snip ---

'winetricks -q gdiplus' works around.

The next bug is nasty, resulting in endless paint/redrawing loop of whole app
window, eating wineserver/X CPU.
Use 'virtual desktop' mode, 1024x768 min. resolution to work around otherwise
it's hard to kill :)

$ wine explorer /desktop=foo,1024x768 ./Pcbh32.exe

The app is initially minimized, click on the icon (not the "x" part though) and
"maximize" to show main gui.

Note: after exiting of app, wineserver will be still running (partly bug
30439):

--- snip ---
C:\Program Files\Common Files\Lexware\LxWebAccess\LxWebAccess.exe -Embedding
--- snip ---

You might need to kill that process (or -k).

Regards

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



More information about the wine-bugs mailing list