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