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