COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
Matthew Bloch
matthew at bytemark.co.uk
Sat Nov 2 04:36:21 CST 2002
On Friday 01 November 2002 18:27, Lionel Ulmer wrote:
> Well, the problem seems to come from an incompatibility between g++ and the
> way Wine defines COM objects. From my experiences, the g++ vtable starts at
> offset 8 whereas Wine defines COM object vtables as starting at offset 0
> (ie vtable[0] == first method whereas for g++ vtable[2] == first method).
>
> Now as this is a purely WineLib problem, I will let people more competent
> than me solve the issue, it's just not DirectDraw related at all, but COM
> related... From what I could find out in 'obj_base.h', you should try
> rebuilding Wine with the 'ICOM_MSVTABLE_COMPAT' define set to 1 (and read
> the relevant warning in the associated comment of course :-) ).
Lionel, thanks for your efforts, I understand the problem now. I did a fresh
build of both wine and the game with this #define added in, but now I get a
similar error in DirectDrawCreate at ddraw/main.c:267; it tries to call
IDirectDraw7_QueryInterface but the backtrace clearly shows that it's calling
Main_DirectDraw_Release, which is off course two ahead of where it wants to
be in the table:
(gdb) bt
#0 Main_DirectDraw_Release (iface=0x403d7c70) at ddraw/main.c:121
#1 0x40fc07d7 in DDRAW_Create (lpGUID=0x0, lplpDD=0x40cc2d24, pUnkOuter=0x0,
iid=0x40fc816c, ex=0) at main.c:267
#2 0x40fc0895 in DirectDrawCreate (lpGUID=0x0, lplpDD=0x40cc2d24,
pUnkOuter=0x0) at main.c:289
#3 0x4085d836 in dummy () at Source/Main.cpp:320
#4 0x4085d891 in WinMain (hInst=0x40650000, hPrevInst=0x0,
lpCmdLine=0x403a0e55 "", nCmdShow=1) at Source/Main.cpp:339
#5 0x4065509c in __wine_exe_main ()
from /home/mattbee/Work/Nemesis/LSNClient.exe
#6 0x400ce100 in start_process () at ../../scheduler/process.c:564
#7 0x400d2ed6 in call_on_thread_stack (func=0x400cde56)
at ../../scheduler/sysdeps.c:112
So with the ICOM_MSVTABLE_COMPAT flag set I get the "off-by-two" calling error
from within Winelib when it's trying to invoke a COM function. When it's not
set I get the same bug occurring in my program when it tries to do the same.
I'll keep investigating but I'd be amazed if I was the only person who's tried
to build a DirectDraw application against Winelib-- surely someone else must
have solved this problem before? Or do most Wine users only use Wine for
loading PE executables?
cheers
--
Matthew Bloch Bytemark Computer Consulting Limited
http://www.bytemark.co.uk/
tel. +44 (0) 8707 455026
More information about the wine-devel
mailing list