Pretty Good Solitaire shootout: Wine vs. Crossover

[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