Pretty Good Solitaire shootout: Wine vs. Crossover

Mike Hearn mh at codeweavers.com
Fri Feb 18 12:21:26 CST 2005


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

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

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

IIRC (I looked at this last summer) 0x746c means "Visual Basic resource"
and is a trivial wrapper, the reason the code pukes out is that it seems
to be wrapped twice or something. But I'm not sure why or what this means.

thanks -mike




More information about the wine-devel mailing list