Pretty Good Solitaire shootout: Wine vs. Crossover

Fri Feb 18 14:49:04 CST 2005

Mike Hearn wrote:
> On Fri, 18 Feb 2005 17:33:35 +0100, Holly Bostick wrote:
>>B) The game itself runs 99.9% perfectly under Crossover (only the
>>Help/Rules are not available) but *does not run at all* under Wine
>>(well, the splash screen shows, but then the app crashes to desktop when
>>trying to open the games selection menu window).
> 
> This is almost certainly a case of you having DCOM installed in Crossover
> but not Wine. CXSetup will install it automatically in quite a few
> instances. 
> 
> I just checked and there are no magic patches in our OLE Automation code
> that might make this work.

OK, I believe you-- Crossover does not say that it installed DCOM (it
does not appear in the installed apps menu, nor do I see a dlloverride
listed in the config for this app, though it might be in the Registry
somewhere; I didn't check).

Not wanting to deal with Winetools or Sidenet at the moment, I 
downloaded both DCOM95 and DCOM98 from Microsoft. I could not
install DCOM95 (because my winver was set to Win98 and I didn't feel
like changing it; I'll confirm that DCOM95 can be installed that way, 
and also solves the problem, later). I do have a Windows98 license, so I 
was able to install DCOM98 after finding the correct methodology from 
the Sidenet site (as you all probably know, the implementation in Wine 
is considered to be newer than the real DCOM98, so without doing a 
WINEDLLOVERRIDES="ole32=n" wine dcom98.exe, DCOM98 won't install).

Having got it installed, I still needed to know what DLLs to override so
that it would be used. A Google search led me to a German site that
indicated "things related to OLE" (and the dll override I had done to 
install DCOM in the first place was also a clue), so I tried making 
ole32 native (didn't work), then added oleaut32, which did. I then 
commented out ole32, and it still worked. Oleaut32 seems to be the key.

So now it seems to be working (haven't tested extensively, but I expect
no problems). Are these procedures (manual installation of DCOM, and
list of dlls contained in DCOM, so that one knows which dlls to
override) documented somewhere on the Wine site? I couldn't find any 
such information in a quick search. I understand that installing native 
DCOM has issues that would need to be explained (like the Win98 license 
issue; I don't really know the status of DCOM95 in terms of 
redistribution), but it seems clear that this must sometimes be done 
nonetheless. If Wine can't do as Crossover does and automatically grab 
some DCOM when it's needed, then somebody should explain how a user gets 
it (I remember a discussion about DCOM needing to be taken off SF, and 
somebody hosting it somewhere else, but I don't even know where to get 
it now, except from Microsoft, which apparently won't be an option much 
longer-- thank heavens I'm a backup packrat), how they install it 
manually, and what to do afterwards in terms of DLL overrides. Shouldn't 
they? Or is this too "gray-area" to be mentioned on the official site?

>  
>>What is the proper information to add to the appdb if the app runs under
>>Crossover but not Wine? Or should I not add the app at all at this time?
> 
> Probably best to add it but mention it needs native DCOM, after you
> confirmed that I'm not talking rubbish.

Since you were not talking rubbish, and since I now know how to get PGS
running, I can add it to the appdb (plus a bunch of versions, since I 
figure they should all work about the same as each other, now that the 
DCOM issue is taken care of). I think I've earned a Neverwinter Nights 
break, but I'll get on it tomorrow and consider it a chance to test out 
Jonathan's appdb patches ;-) .

> 
>>CX creates a full Programs menu folder, containing the application, the
>>website link, and the uninstaller; Wine does not seem to create a
>>Programs menu at all (but this could be a SuSE menu issue). 
> 
> No, it's just that the Crossover menu code is proprietary and Wines
> equivalent doesn't work on modern desktops.

Eeuuww, that sucks (not the Crossover end, the fact Wine's equivalent
doesn't work on modern desktops). Having desktop icons, or at least a
menu entry, is kind of crucial in the "ease-of-use" stakes for those of
us who don't ever want to see a command line (and even some of us who
don't mind the command line). Perhaps not the highest-priority task, but 
not chopped liver, either.

> 
>>A slight problem is that when I attempted to enter my registration code,
>>which I keep saved in a text file, using the internal right-click
>>"Paste" operation crashed the program to desktop; but using Shift+Insert
>>to paste the text worked fine.
> 
> Sounds like a bug we should fix! Can you post a backtrace please?

Backtrace, backtrace.... just a minute.. <frantic searching as to how to
do that>... here you go:

[holly at SuSE: ~/games/wine/goodsol_latest] 08:02  $ wine goodsol.exe
fixme:ole:CoRegisterMessageFilter stub
wine: Unhandled exception (thread 0009), starting debugger...
WineDbg starting on pid 0x8
Unhandled exception: page fault on read access to 0x102475cf in 32-bit 
code (0x660930bc).
In 32 bit mode.
err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file 
DLL\MSVBVM60.dbg ("Y:\\games\\wine\\goodsol_latest")
Register dump:
  CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
  EIP:660930bc ESP:406cdcbc EBP:406cdcc4 EFLAGS:00210206(   - 00      - 
RIP1)
  EAX:102474ff EBX:00000302 ECX:6610eec0 EDX:00000300
  ESI:102474ff EDI:00000000
Stack dump:
0x406cdcbc:  00000000 6606125a 406cdce0 660930e9
0x406cdccc:  102474ff 66092bfb 00000302 00000000
0x406cdcdc:  417f2d90 406cdcfc 660930e9 6606125a
0x406cdcec:  66092bfb 00000302 417f01a4 417f01a4
0x406cdcfc:  406cdd2c 66092d04 417f2d90 66092bfb
0x406cdd0c:  00000302 00000000 6607a813 4180ec94
Backtrace:
=>1 0x660930bc in msvbvm60 (+0x930bc) (0x406cdcc4)
   2 0x660930e9 in msvbvm60 (+0x930e9) (0x406cdce0)
   3 0x660930e9 in msvbvm60 (+0x930e9) (0x406cdcfc)
   4 0x66092d04 in msvbvm60 (+0x92d04) (0x406cdd2c)
   5 0x66036dd7 in msvbvm60 (+0x36dd7) (0x406cdd98)
   6 0x660bb013 in msvbvm60 (+0xbb013) (0x406cde00)
   7 0x660213a8 in msvbvm60 (+0x213a8) (0x406cde28)
   8 0x66020361 in msvbvm60 (+0x20361) (0x406cde84)
   9 0x407408f7 WINPROC_wrapper in user32 (0x406cdea8)
   10 0x40741c1b WINPROC_CallWndProc in user32 (0x406cdeec)
   11 0x407472c5 CallWindowProcA in user32 (0x406cdf30)
   12 0x4072a6f2 DispatchMessageA in user32 (0x406cdf5c)
   13 0x66014979 __vbaInStr in msvbvm60 (0x406cdf9c)
   14 0x660148b2 __vbaInStr in msvbvm60 (0x406cdfe0)
   15 0x66014790 __vbaInStr in msvbvm60 (0x6601a360)
   16 0x66010e00 BASIC_CLASS_AddRef in msvbvm60 (0x660d3526)
   17 0x0c2474ff (0x0424448b)
   18 0x00000000 (0x00000000)
0x660930bc: movl	0xd0(%esi),%edi
Wine-dbg>bt
Backtrace:
=>1 0x660930bc in msvbvm60 (+0x930bc) (0x406cdcc4)
   2 0x660930e9 in msvbvm60 (+0x930e9) (0x406cdce0)
   3 0x660930e9 in msvbvm60 (+0x930e9) (0x406cdcfc)
   4 0x66092d04 in msvbvm60 (+0x92d04) (0x406cdd2c)
   5 0x66036dd7 in msvbvm60 (+0x36dd7) (0x406cdd98)
   6 0x660bb013 in msvbvm60 (+0xbb013) (0x406cde00)
   7 0x660213a8 in msvbvm60 (+0x213a8) (0x406cde28)
   8 0x66020361 in msvbvm60 (+0x20361) (0x406cde84)
   9 0x407408f7 WINPROC_wrapper in user32 (0x406cdea8)
   10 0x40741c1b WINPROC_CallWndProc in user32 (0x406cdeec)
   11 0x407472c5 CallWindowProcA in user32 (0x406cdf30)
   12 0x4072a6f2 DispatchMessageA in user32 (0x406cdf5c)
   13 0x66014979 __vbaInStr in msvbvm60 (0x406cdf9c)
   14 0x660148b2 __vbaInStr in msvbvm60 (0x406cdfe0)
   15 0x66014790 __vbaInStr in msvbvm60 (0x6601a360)
   16 0x66010e00 BASIC_CLASS_AddRef in msvbvm60 (0x660d3526)
   17 0x0c2474ff (0x0424448b)
   18 0x00000000 (0x00000000)
Wine-dbg>quit
WineDbg terminated on pid 0x8
[holly at SuSE: ~/games/wine/goodsol_latest] 08:36  $

>  
>>The application does not run. The splash screen is displayed, for what
>>is the "normal" amount of time (~ 5 seconds), but when the splash screen
>>disappears, the game selection menu does not appear in its place (you're
>>returned to the console prompt). So the app fails cleanly, but the
>>output is horrific (because its over 6000 lines long).
> 
> Ah yes, the hex dump of doom. I've debugged this one before but didn't get
> very far.

Oh, thanks.. at least now I know what that is (the "hex dump" part-- the 
"of doom" part I could guess on my own :-) )

>  
>>fixme:ole:SPCF_CreateInstance
>>(0x40a50d00,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x403f1ec0),
>>creating stdpic with PICTYPE_NONE.
>>fixme:ole:OLEPictureImpl_Load Could only read 67468 of 138330 bytes in
>>no-header case?
>>fixme:ole:OLEPictureImpl_Load Unknown magic 746c, 67468 read bytes: 6c
> 
> Basically what is happening here is that the format VB (sometimes) stores
> images in hasn't been fully reverse engineered. There are a few gaps in
> our knowledge.

Between this and the results of the backtrace, this seems to "confirm" 
my (completely ignorant) suspicion that this app uses VB very heavily 
and in a way that is more than even Windows expects sometimes (under 
Windows, I remember having to copy the VB runtimes from either a 
previous or later version of Windows in order to get this app running, 
but since I eventually just copied all 3 runtime dlls by default to 
whatever system32 I was using, I forgot about it). Even though I know 
nothing about this in any functionally helpful way, it doesn't surprise 
me that VB seems to be the "bad guy".

> thanks -mike

Thank you.

Holly