Pretty Good Solitaire shootout: Wine vs. Crossover

[Holly Bostick]

Hi,

This application is not in the database, so I started testing prior to
adding it and (most likely) maintaining it.

Pretty Good Solitaire (PGS) is a Solitaire game compilation; the benefit
over native applications is the huge number of Solitaire variants
available (the current version has 610 Solitaire games; previous
versions have at least 500). Pysol and Aisle Riot don't even come close,
especially if you have a favorite variant that is only found in this
compilation.

The demo of the current version (10.2.0) is available at

http://www.goodsol.com/downloads/gdsoltb.html

Previous versions (7.2.0, 8.11, 9.2.0) are available at

http://www.goodsol.com/downloadpre.html

I also have version 9.1.0, which is an old "previous version" no longer
available on the main site.

Wine: 20050217

Crossover: 4.1 Demo

Distribution: SuSE 9.2

Video: ATI binary drivers 8.10.19 under X.org 6.8

Cutting to the chase, the interesting thing here is that:

A) the setup runs better under Wine than Crossover (but runs fully in
both cases)

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

I find this fascinating, so I did more tests; fuller information to
follow, but I'll ask my question now in the event you don't want to read
the rest of what will likely be a very long post:

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?
I'd feel pretty stupid suggesting that one buy CX to run a Solitaire 
game (even a great compilation such as this), but on the other hand, the 
app runs flawlessly under CX, which seems worthy of mention if a user 
does want to run it (since it does not run at all under Wine). Any 
suggestions would be appreciated.

But here's my test results, in case it will help you figure out what the
missing link is:

-----------------------------------------------------------

Installers:

The game (any version) ultimately installs fine under both Wine and
Crossover.

However, there are differences during install.

Wine does not produce any errors when running the installer (unless that
tiny, unreadable, and non-resizeable 2nd dialog box is meant to display
them), and all text (license and 'readme') is visible in the installer
dialogs.

Crossover produces duplicate error boxes when the first install screen
is extracting/loading (you hit OK on the first, then the duplicate
appears, then you hit OK and the install proceeds with no further error
dialogs), and no license or 'readme' text is visible in the installer
dialogs provided for this purpose.

The error is as follows:

Access violation at address  {version-dependent, specific addresses follow}

Read of address 00000000

In version 720 the address is 417930BA

In version 8.11 the address is 4173C0BA

In version 9.20 the address is also 4173C0BA

In version 10.2 the address is 41B880BA

Neither Wine nor CX can extract the program icon. However, at some point
previous, CX was able to get the icon from at least one version of PGS,
as I have a saved icon from PGS 500 (which is version 8.11) that I
stored some time ago when I tested this install on an acquaintance's
machine while housesitting. Unfortunately, I don't remember what version
of CX this person had (dammit). I certainly don't get an icon extracted
(even from 8.11) now, with 4.1 Demo, and iirc, no attempted install of 
later versions of PGS successfully extracted the application icon on the
acquaintance's machine (which is likely why I saved the one icon I did
get when I cleaned up prior to losing access to the machine).

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). CX creates
the desktop icon (using the default CX icon, since the program icon 
could not be extracted); Wine does not (but this could be because the CX 
icon is already there and cannot be overwritten).

But in both cases, the application is installed.

CX: Using one of the CX icons runs the game (any version) perfectly
using CX; the splash screen is displayed, and for the first run, the
"add player" dialog is displayed and works, for an unregistered first
run, the registration dialog is correctly shown and links on that screen
correctly open Firefox and display the URL.

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.

Other than the fact that the Help is not available (nothing happens if
you click the "Help" or "Rules" buttons in the main menu or an
individual game, which kinda sucks if you want to try a new game but
don't know the rules), this application has only a couple of very minor
problems, and can be said to be Gold. All text is visible, all options
are readable, useable and work properly; I even followed the link from
the Options screen and successfully downloaded and installed additional
card sets.

The only minor issues other than those already mentioned are things I 
noticed when using earlier PGS versions in the past, but may no longer 
be relevant with version 10.2.0 (not yet tested):

1) game saving on exit did not quite work properly if you exit
immediately after winning a game (on the reward screen, choose exit
immediately, or choose New Game, don't do anything, and exit
immediately); when you reopen PGS and select the same game variant as
you had just been playing, you don't get a 'clean' new game, but instead
the game autoplays to some (indeterminate) point in a previous game you
had played. If, however, you win a game, select 'New Game', make one
move, then exit, when you reopen and select the same game type, the same
game # will open, and your one move will be played automatically
(because it was properly saved on exit). *This issue no longer appears 
in version 10.2.0.*

2) Opening Thunderbird (seems to be specific to T-bird, but did not test 
extensively because I did not realize this seems PGS version-specific) 
caused a horrendous amount of flickering (non-critical, as it did not 
hurt the program's function in any way, it was just insanely annoying), 
but this seems to have been related to PGS versions 9.10 and below; I am 
not seeing this with 10.2 at all, so it's something I'd have to test as 
a version issue for the appdb.

3) Sometimes (possibly when the system was under relatively heavy load 
in some way), drawing of the game screen was imperfect; some "later" 
cards on the table (meaning cards visible but not playable at the moment 
due to game rules) were only partially drawn (not critical, since the 
cards were not playable). The cards were visible (meaning that the space 
for the partially or not drawn card was clearly "used" by an object not 
completely visible), and the card itself was present and could be played 
when it became playable according to the game rules. Playing the card 
would also cause it to be drawn properly, but the space where it had 
been was not necessarily redrawn (so that the card under it, which 
should have become completely visible when the partially-drawn card was 
moved, had a "bite" taken out of it). This was a non-critical error 
which could be resolved by using the "Restart" button to redraw the 
table. Since I don't know what caused this in the first place, I can't 
test whether it still happens. For all I know, it could be something 
fixed in the ATI drivers.

The point being that Codeweavers could put this on their list of 
supported apps, insofar as it runs more than well enough to be 
considered perfect.

Wine, though, is a different story.

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

Here's the start and end of it:

[holly@SuSE: ~/games/wine/goodsol] 08:27  $ wine goodsol.exe
fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 4.0, please 
report !!
fixme:ole:CoRegisterMessageFilter stub
fixme:ole:OleLoadPictureEx 
(0x413825fc,103393,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406cf82c), 
partially implemented.
fixme:ole:OLEPictureImpl_Construct Unsupported type 3
fixme:ole:OLEPictureImpl_get_hPal (0x403a1998)->(0x406cf770): stub
fixme:ole:OleLoadPictureEx 
(0x41383efc,4158,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406cf82c), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403d9138), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403d91b0), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403d8908), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403d8980), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403d89f8), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403d8a70), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403d8ae8), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da2a8), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da320), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da398), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da410), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da488), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da500), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da578), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da5f0), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da668), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da6e0), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da758), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da7d0), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da848), 
partially implemented.
fixme:ole:OleLoadPictureEx 
(0x41383efc,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=32,y=32,f=0,0x403da8c0), 
partially implemented.
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 74 00 00 00 00 00 00 6c 74
00 00 00 00 00 00 ff 03 3e 00
00 00 04 08 00 6c 62 6c 53 74
61 74 73 00 01 04 09 00 00 80
05 e0 10 78 00 9f 06 cf 03 12
15 00 1f 00 25 01 00 00 00 90
01 44 42 01 00 0d 4d 53 20 53
61 6e 73 20 53 65 72 69 66 ff
03 43 00 00 00 05 08 00 6c 62
6c 54 79 70 65 73 00 01 03 02
00 00 80 04 09 00 00 80 05 d0
02 d0 02 c7 0b ef 01 12 13 00
1f 00 25 01 00 00 00 90 01 44
42 01 00 0d 4d 53 20 53 61 6e
73 20 53 65 72 69 66 ff 03 46
00 00 00 06 0b 00 6c 62 6c 47
61 6d 65 4e 61 6d 65 00 01 03
<snip of over 6000 lines of this>
6d 6e 75 54 72 61 79 45 78 69
74 00 13 03 05 00 45 26 78 69
74 00 ff 03 03 04
fixme:ole:OLEPictureImpl_Destroy Unsupported type 0 - unable to delete
fixme:ole:CoRegisterMessageFilter stub
[holly@SuSE: ~/games/wine/goodsol] 08:28  $

Now, I can't imagine what insanely proprietary (VB?) code a bloody 
Solitaire app could use that is completely supported by CX, and 
completely unsupported by Wine, but maybe one of you can.

If there is any further debugging that would be of use, please specify 
what channels you want, and I'll (figure out how to) do it.

I think I'll leave this off the appdb for the time being, but any 
suggestions that would help me include it would be welcome (since I 
guess I must be willing to maintain it, having done so much work already 
;-) ).

Thanks for your time,
Holly

[Mike Hearn]

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

[Holly Bostick]

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

[Mike Hearn]

On Fri, 2005-02-18 at 21:49 +0100, Holly Bostick wrote:
> Not wanting to deal with Winetools or Sidenet at the moment, I 
> Having got it installed, I still needed to know what DLLs to override so
> that it would be used.

You normally use ole32,oleaut32,rpcrt4=n to use native DCOM. This is not
documented on WineHQ but is documented on the WineKB I run:

http://navi.cx/svn/misc/trunk/winekb/NativeDCOM.xml
> commented out ole32, and it still worked. Oleaut32 seems to be the key.

It is. Oleaut32 contains the Visual Basic support code, amongst other
things.
> they? Or is this too "gray-area" to be mentioned on the official site?

It's not a gray area, we just don't have a place to put random tidbits
of information like that. Hence the constant discussions about a wiki
and the KB site I did.
> Eeuuww, that sucks (not the Crossover end, the fact Wine's equivalent
> doesn't work on modern desktops). Having desktop icons,

WineHQ will do desktop icons, I have several here.
> 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.

The main problem is that it's a total head trip. Menus on Linux are a
mess and always have been. Things are looking up, but it'll probably be
about a year before it makes sense to do menu integration in upstream
Wine.
> Unhandled exception: page fault on read access to 0x102475cf in 32-bit 
> code (0x660930bc).

What a strange address. Hmmm.
> =>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)

It crashes 8 frames deep into the Visual Basic virtual machine,
unfortunately we can't debug this one just with a backtrace.
> > 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 :-) )

You're looking at the contents of the resource in hexademical form (as
raw binary is not very compact). It's a silly behaviour but this bug is
triggered so rarely nobody took out that debugging code.
> > 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

It does yes. But we can't help that.

Our VB support isn't so hot as most apps written in it have native
equivalents so few people are interested in improving it (it's also
quite hard as you need a good understand of variants and COM).

thanks -mike

[Fabian Cenedese]

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

This looks like the error I already tried to fix last year (without knowing what
I did :)

http://www.winehq.org/hypermail/wine-devel/2004/01/0911.html
http://www.winehq.org/hypermail/wine-devel/2004/01/0968.html
http://www.winehq.org/hypermail/wine-devel/2004/02/0036.html
http://www.winehq.org/hypermail/wine-devel/2004/02/0053.html

Maybe that's worth trying again in your case.

bye  Fabi

[Tom]

Holly Bostick wrote:
> 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?

Hello Holly,

*I* would add the game to both databases there is a CX apps/game db here :
http://www.codeweavers.com/compatibility/

And I take it you already know where the Wine db is ;)

<plug>
While your there vote for DirectX   :-)
</plug>

Tom