Winelib article in this month's C/C++ User's Journal
http://www.cuj.com/current/feature.html?topic=current An immodest plug for my introductory Winelib article that the CUJ editor Joe Casad was soliciting through thist list back in December. It's now in the print journal and on their web site at the (temporary, by the looks of things) link above. Thanks to the people who offered criticism before publication; hopefully in the three months since I wrote it the information isn't too out of date! cheers, -- Matthew Bloch Bytemark Hosting tel. +44 (0) 8707 455026 http://www.bytemark-hosting.co.uk/ Dedicated Linux hosts from 15ukp ($26) per month
Reviewing an article on Winelib
I'd like to solicit a bit of feedback on an article I wrote for the C/C++ User's Journal entitled "Dropping Windows with Winelib" and is an introduction to making Win32 code run with Winelib under Linux. I'm conscious of a duty to present the work of others, and what I consider to be an important free software project, in an helpful light. Because it's intended for publication I can't post it publically but would appreciate anyone who knows WINE better than I do to cast a critical eye over it; if you email me privately I'll send it to you. thanks, -- Matthew Bloch Bytemark Computer Consulting http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
Re: Plea to fix winelib COM vtable bug
On Saturday 02 November 2002 16:15, Ove Kaaven wrote: > Your particular problem is probably that the > ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE isn't in the vtables found in > ddraw/user.c and ddraw/hal.c, but I'd still just use > ICOM_USE_COM_INTERFACE_ATTRIBUTE to avoid this kind of problem, unless you > really want to fix all the places someone forgot this stuff... I tried the attribute setting but gcc 2.95.4 doesn't support it, at least it warned me it was ignoring an unknown attribute. Maybe I should be using gcc-3.2 by now but I don't want to cause any more problems, and couldn't face another full recompile, nearly an hour for both WINE and the game on my laptop. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
PATCH: DirectDraw vtable fixes
Found it; a few of the DirectDraw ICOM_VTABLE declarations did not have the
ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE macro prefixing their elements. This
meant that, well, all sorts of havoc broke loose when wrong functions were
called :) I hope this is an uncontentious patch attached.
--
Matthew Bloch Bytemark Computer Consulting Limited
http://www.bytemark.co.uk/
tel. +44 (0) 8707 455026
Index: ddraw/hal.c
===
RCS file: /home/wine/wine/dlls/ddraw/ddraw/hal.c,v
retrieving revision 1.7
diff -u -3 -p -r1.7 hal.c
--- ddraw/hal.c 6 Aug 2002 23:49:46 - 1.7
+++ ddraw/hal.c 2 Nov 2002 16:04:11 -
@@ -549,6 +549,7 @@ HAL_DirectDraw_GetFourCCCodes(LPDIRECTDR
static ICOM_VTABLE(IDirectDraw7) HAL_DirectDraw_VTable =
{
+ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE
Main_DirectDraw_QueryInterface,
Main_DirectDraw_AddRef,
Main_DirectDraw_Release,
Index: ddraw/user.c
===
RCS file: /home/wine/wine/dlls/ddraw/ddraw/user.c,v
retrieving revision 1.11
diff -u -3 -p -r1.11 user.c
--- ddraw/user.c 19 Oct 2002 17:16:00 - 1.11
+++ ddraw/user.c 2 Nov 2002 16:04:11 -
@@ -558,6 +558,7 @@ User_DirectDraw_SetDisplayMode(LPDIRECTD
static ICOM_VTABLE(IDirectDraw7) User_DirectDraw_VTable =
{
+ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE
Main_DirectDraw_QueryInterface,
Main_DirectDraw_AddRef,
Main_DirectDraw_Release,
Index: dsurface/dib.c
===
RCS file: /home/wine/wine/dlls/ddraw/dsurface/dib.c,v
retrieving revision 1.17
diff -u -3 -p -r1.17 dib.c
--- dsurface/dib.c 18 Oct 2002 23:48:59 - 1.17
+++ dsurface/dib.c 2 Nov 2002 16:04:12 -
@@ -1112,6 +1112,7 @@ DIB_DirectDrawSurface_SetSurfaceDesc(LPD
static ICOM_VTABLE(IDirectDrawSurface7) DIB_IDirectDrawSurface7_VTable =
{
+ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE
Main_DirectDrawSurface_QueryInterface,
Main_DirectDrawSurface_AddRef,
Main_DirectDrawSurface_Release,
Index: dsurface/fakezbuffer.c
===
RCS file: /home/wine/wine/dlls/ddraw/dsurface/fakezbuffer.c,v
retrieving revision 1.4
diff -u -3 -p -r1.4 fakezbuffer.c
--- dsurface/fakezbuffer.c 3 Jul 2002 01:20:07 - 1.4
+++ dsurface/fakezbuffer.c 2 Nov 2002 16:04:12 -
@@ -156,6 +156,7 @@ FakeZBuffer_DirectDrawSurface_SetSurface
static ICOM_VTABLE(IDirectDrawSurface7) FakeZBuffer_IDirectDrawSurface7_VTable=
{
+ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE
Main_DirectDrawSurface_QueryInterface,
Main_DirectDrawSurface_AddRef,
Main_DirectDrawSurface_Release,
Index: dsurface/gamma.c
===
RCS file: /home/wine/wine/dlls/ddraw/dsurface/gamma.c,v
retrieving revision 1.3
diff -u -3 -p -r1.3 gamma.c
--- dsurface/gamma.c 31 May 2002 23:25:46 - 1.3
+++ dsurface/gamma.c 2 Nov 2002 16:04:12 -
@@ -72,6 +72,7 @@ DirectDrawGammaControl_SetGammaRamp(LPDI
ICOM_VTABLE(IDirectDrawGammaControl) DDRAW_IDDGC_VTable =
{
+ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE
DirectDrawGammaControl_QueryInterface,
DirectDrawGammaControl_AddRef,
DirectDrawGammaControl_Release,
Index: dsurface/hal.c
===
RCS file: /home/wine/wine/dlls/ddraw/dsurface/hal.c,v
retrieving revision 1.6
diff -u -3 -p -r1.6 hal.c
--- dsurface/hal.c 31 May 2002 23:25:46 - 1.6
+++ dsurface/hal.c 2 Nov 2002 16:04:12 -
@@ -362,6 +362,7 @@ HWND HAL_DirectDrawSurface_get_display_w
static ICOM_VTABLE(IDirectDrawSurface7) HAL_IDirectDrawSurface7_VTable =
{
+ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE
Main_DirectDrawSurface_QueryInterface,
Main_DirectDrawSurface_AddRef,
Main_DirectDrawSurface_Release,
Index: dsurface/thunks.c
===
RCS file: /home/wine/wine/dlls/ddraw/dsurface/thunks.c,v
retrieving revision 1.6
diff -u -3 -p -r1.6 thunks.c
--- dsurface/thunks.c 3 Jul 2002 21:06:58 - 1.6
+++ dsurface/thunks.c 2 Nov 2002 16:04:12 -
@@ -387,6 +387,7 @@ IDirectDrawSurface3Impl_SetSurfaceDesc(L
ICOM_VTABLE(IDirectDrawSurface3) DDRAW_IDDS3_Thunk_VTable =
{
+ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE
IDirectDrawSurface3Impl_QueryInterface,
IDirectDrawSurface3Impl_AddRef,
IDirectDrawSurface3Impl_Release,
Index: dsurface/user.c
===
RCS file: /home/wine/wine/dlls/ddraw/dsurface/user.c,v
retrieving revision 1.14
diff -u -3 -p -r1.14 user.c
--- dsurface/user.c 18 Oct 2002 23:48:59 - 1.14
+++ dsurface/user.c 2 Nov 2002 16:04:12 -
@@ -627,6 +627,7 @@ static void User_copy_from_screen(IDirec
static ICOM_VTABLE(IDirectDrawSurface7) User_IDirectDrawSurface7_VTable
Re: Plea to fix winelib COM vtable bug
I think I'm closer now...
trace:ddraw:User_DirectDraw_Construct (0x403a7c70,0)
Program received signal SIGINT, Interrupt.
[Switching to Thread 16384 (LWP 2877)]
0x40f510e4 in DDRAW_Create (lpGUID=0x0, lplpDD=0x40c92d38, pUnkOuter=0x0,
iid=0x40f585d0, ex=0) at main.c:264
264 while(1);
(gdb) print pDD
$1 = (struct IDirectDraw7 *) 0x403a7c70
(gdb) print *pDD
$2 = {lpVtbl = 0x40f5a960}
(gdb) print *pDD->lpVtbl
$3 = {dummyRTTI1 = 1089756760, dummyRTTI2 = 1089756316,
QueryInterface = 0x40f45cf0 ,
AddRef = 0x40f45f8c ,
Release = 0x40f45fd4 ,
So the create function is apparently unaware of the dummy values and is
filling them in regardless... more later...
--
Matthew Bloch Bytemark Computer Consulting Limited
http://www.bytemark.co.uk/
tel. +44 (0) 8707 455026
Plea to fix winelib COM vtable bug
This is a summary of my recent probs with Winelib in the hope that someone who
knows the COM stuff can fix them quickly, because hacking through the jungle
of include files and definitions is hard work
In short, I've built the latest wine cvs with the ICOM_MSVTABLE_COMPAT flag
set in include/wine/obj_base.h, so each vtable has two dummy words at the
start for g++'s benefit.
I then added these statements to the start of my WinMain to cause a segfault:
IDirectDraw* dd;
DirectDrawCreate(0, &dd, NULL;)
and for good measure, wrapped the call to IDirectDraw7_QueryInterface in
DDRAW_Create (which is where the segfault occurs) in ddraw/main.c with these
two warnings:
WARN("about to call IDirectDraw7_QueryInterface vtbl size = %d\n",
sizeof(DDCF_Vtbl));
hr = IDirectDraw7_QueryInterface(pDD, iid, lplpDD);
WARN("called IDirectDraw7_QueryInterface\n");
and when running the program, the trace clearly shows that the Release entry
point is being called instead, and crashing, though the vtable is the
expected size (5 entry points, plus 2 dummy dwords):
warn:ddraw:DDRAW_Create about to call IDirectDraw7_QueryInterface vtbl
size = 28
warn:ddraw:DDRAW_Create offset is 12271064
trace:ddraw:Main_DirectDraw_Release (0x403a7c70)->() decrementing from 1.
warn:ddraw:Main_DirectDraw_Release doing final release
Looking at the pre-processor output from compiling ddraw/main.c, I can see
that IDirectDraw7Vtbl type has the two extra words grafted onto the front, as
it should:
struct IDirectDraw7Vtbl {
long dummyRTTI1;
long dummyRTTI2;
HRESULT (__attribute__((__stdcall__)) *QueryInterface)(IDirectDraw7* me,
const IID* const a, LPVOID* b);
ULONG (__attribute__((__stdcall__)) *AddRef)(IDirectDraw7* me);
ULONG (__attribute__((__stdcall__)) *Release)(IDirectDraw7* me);
...
The problem seems to be that the call is offset not just by two table entries,
but four. Somewhere in that jungle of macros, the "vtable base adjustment"
of +2 is being applied twice, I'm sure of it. But I'm buggered if I can find
out where this is happening; I'm still looking but it's slow progress and I
believe it's a winelib bug.
Any suggestions on how to fix it would be welcome. cheers,
--
Matthew Bloch Bytemark Computer Consulting Limited
http://www.bytemark.co.uk/
tel. +44 (0) 8707 455026
Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
On Saturday 02 November 2002 11:06, Andreas Mohr wrote: > On Sat, Nov 02, 2002 at 10:36:21AM +0000, Matthew Bloch wrote: > > 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? > > I'd say that *BY FAR* most people use Wine to run programs. > What would you use Winelib for anyway ? > IMHO it has somewhat limited use, given that you don't really gain a lot > from "porting" programs via Winelib (neither performance, nor code size, > nor ...). Yes, I'd discovered this since I started, because I assumed there would be some speed advantage. My motivation to start the port through WINE was being able to use gdb and other familiar UNIX tools to debug a Windows program, and to be able to extract the Windows code piece by piece until I was left without any Win32 dependencies. Of course if anyone can tell me how to debug a PE executable running under WINE with gdb I'd be interested, but I assumed it would be even more of an uphill struggle than getting a ELF/winelib version working. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
On Saturday 02 November 2002 10:36, Matthew Bloch wrote: [snip] > 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; Sorry, to clarify this should be line 265 as I added some log statements. Line 267 in the unmolested source actually *is* a Release call, but it's definitely an IDirectDraw7_QueryInterface call that this bug happens with. -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
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=0x4065, 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
Re: SIGSEGV in IDirectDrawImpl_EnumDisplayModes (test program)
,%esi
7e0: 83 c4 f4add$0xfff4,%esp
7e3: 68 50 00 00 00 push $0x50
7e8: e8 fc ff ff ff call 7e9
7ed: c9 leave
7ee: c3 ret
7ef: 90 nop
-
and the ddraw trace looks like this:
-
trace:ddraw:initialize enabling DirectDraw HAL
trace:ddraw:DDRAW_Create ((null),0x40c92d38,(nil))
trace:ddraw:DDRAW_FindDriver ((null))
trace:ddraw:HAL_DirectDraw_Create
trace:ddraw:HAL_DirectDraw_Construct (0x403a7390)
trace:ddraw:User_DirectDraw_Construct (0x403a7390,0)
trace:ddraw:Main_DirectDraw_QueryInterface
(0x403a7390)->({6c14db80-a733-11ce-a521-0020af0be560},0x40c92d38)
trace:ddraw:Main_DirectDraw_AddRef (0x403a7390)->() incrementing from 1.
trace:ddraw:Main_DirectDraw_Release (0x403a7390)->() decrementing from 2.
trace:ddraw:User_DirectDraw_EnumDisplayModes
(0x403a7390)->(0x40c92d3c,0x40c92d34,0x40c92cf8,0x40f481c0)
trace:ddraw:User_DirectDraw_EnumDisplayModes - mode: 512x384
trace:ddraw:User_DirectDraw_EnumDisplayModes - 8 bpp, R= G=
B=
---------
Any comments would be appreciated.
--
Matthew Bloch
Re: SIGSEGV in IDirectDrawImpl_EnumDisplayModes
On Friday 01 November 2002 12:19, Lionel Ulmer wrote: > > Yes, to my eye it looks like a linking problem but I'm not sure how to > > tell. Maybe if I whittle it down to a single .c file which I can post to > > the list it'll make it easier to diagnose. > > Well, the easier would be that, yes. Basically, just create the DDraw > interface (as done in createDirectDrawObject) and call 'CreateSurface' on > it. That should be enough to reproduce the problem (now that I think of it, > I could do it myself, but well, I have no experience about creating Winelib > apps :-) ). Have managed to break my wine build after a cvs update (seem to immediately branch to zero running my program!), so still working on this. > Another thing helpful would be a disassembly of the 'setUpWindowedSurfaces' > method (this would show what code is generated for the > 'mp_directDraw->CreateSurface' call and thus understand why it choose the > wrong method). Okay, if it'll help you although my knowledge of x86 calling conventions and post-286 instructions etc. (last x86 I wrote was in a BIOS five years ago) is pretty hopeless :-) 2fac : 2fac: 55 push %ebp 2fad: 89 e5 mov%esp,%ebp 2faf: 81 ec 8c 00 00 00 sub$0x8c,%esp 2fb5: 57 push %edi 2fb6: 56 push %esi 2fb7: 53 push %ebx 2fb8: 8b 7d 08mov0x8(%ebp),%edi 2fbb: 83 c4 fcadd$0xfffc,%esp 2fbe: 6a 6c push $0x6c 2fc0: 6a 00 push $0x0 2fc2: 8d 5d 94lea0xff94(%ebp),%ebx 2fc5: 53 push %ebx 2fc6: e8 fc ff ff ff call 2fc7 2fcb: c7 45 94 6c 00 00 00movl $0x6c,0xff94(%ebp) 2fd2: c7 45 98 01 00 00 00movl $0x1,0xff98(%ebp) 2fd9: c7 45 fc 00 02 00 00movl $0x200,0xfffc(%ebp) 2fe0: 8b 57 08mov0x8(%edi),%edx 2fe3: 8b 0a mov(%edx),%ecx 2fe5: 6a 00 push $0x0 2fe7: 8d 47 10lea0x10(%edi),%eax 2fea: 50 push %eax 2feb: 53 push %ebx 2fec: 52 push %edx 2fed: 8b 41 20mov0x20(%ecx),%eax 2ff0: ff d0 call *%eax 2ff2: 89 c6 mov%eax,%esi 2ff4: 83 c4 10add$0x10,%esp 2ff7: 8d 45 80lea0xff80(%ebp),%eax 2ffa: 83 c4 fcadd$0xfffc,%esp 2ffd: 50 push %eax 2ffe: 68 00 02 00 00 push $0x200 3003: 8d 5d 84lea0xff84(%ebp),%ebx 3006: 53 push %ebx 3007: e8 fc ff ff ff call 3008 300c: 83 c4 fcadd$0xfffc,%esp 300f: 53 push %ebx 3010: 56 push %esi 3011: 57 push %edi 3012: e8 fc ff ff ff call 3013 3017: 83 c4 20add$0x20,%esp 301a: eb 09 jmp3025 301c: 8d 74 26 00 lea0x0(%esi,1),%esi 3020: e8 fc ff ff ff call 3021 3025: 83 c4 f4add$0xfff4,%esp 3028: 57 push %edi 3029: e8 fc ff ff ff call 302a 302e: 83 c4 f4add$0xfff4,%esp 3031: 57 push %edi 3032: e8 fc ff ff ff call 3033 3037: 83 c4 20add$0x20,%esp 303a: 83 c4 f4add$0xfff4,%esp 303d: 57 push %edi 303e: e8 fc ff ff ff call 303f 3043: eb 02 jmp3047 3045: eb d9 jmp3020 3047: 8d a5 68 ff ff ff lea0xff68(%ebp),%esp 304d: 5b pop%ebx 304e: 5e pop%esi 304f: 5f pop%edi 3050: c9 leave 3051: c3 ret 3052: 89 f6 mov%esi,%esi -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
Re: SIGSEGV in IDirectDrawImpl_EnumDisplayModes
On Thursday 31 October 2002 18:41, Lionel Ulmer wrote: > > Sorry, that was the method I posted, I happened to paste the wrong > > function name; this is the entire function with line 852 marked: > > Care to give me the actual data type of 'mp_directDraw' ? It seems that as > you supposed, it does not use the correct function pointer when you use > 'mp_directDraw->CreateSurface' and call instead 'EnumDisplayModes' thus, of > course, leading to a crash as the callback function is not filled in > properly. Declared in the header as: IDirectDraw* mp_directDraw; I'm working from the position of not knowing much about DirectDraw, so this is all new territory. > The only thing I find strange is that you call CreateSurface with the 3rd > argument being NULL and we should see that in the trace for > 'EnumDisplayModes'... Yes, to my eye it looks like a linking problem but I'm not sure how to tell. Maybe if I whittle it down to a single .c file which I can post to the list it'll make it easier to diagnose. -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
Re: SIGSEGV in IDirectDrawImpl_EnumDisplayModes
On Thursday 31 October 2002 14:32, Lionel Ulmer wrote:
> > Apologies for needing some more hand-holding: from Alexander's advice I
> > now have the game linking and beginning to execute. It now gets stuck
> > while executing this piece of C++:
>
> Hmm, according to the backtrace, it is rather crashing when executing
> 'User_DirectDraw_EnumDisplayModes' (ie something like
> mp_directDraw->EnumDisplayModes(...)) in the
> tDirectDrawScreen::setUpWindowedSurfaces method.
Sorry, that was the method I posted, I happened to paste the wrong function
name; this is the entire function with line 852 marked:
--
void tDirectDrawScreen::setUpWindowedSurfaces()
{
DDSURFACEDESC ddsd;
memset(&ddsd,0,sizeof(DDSURFACEDESC));
ddsd.dwSize = sizeof(DDSURFACEDESC);
//Set up the caps for the primary
ddsd.dwFlags = DDSD_CAPS;
ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE;
//Finally create the primary surface (line 852)
HRESULT hr = mp_directDraw->CreateSurface(&ddsd,&mp_primarySurface,NULL);
handleErrors(hr,"Failed to create windowed primary surface.");
//Calculate and preserve current screen size
setScreenSize();
//Calculate and store current screen position
setScreenPosition();
//Create a "backbuffer" surface exactly the same size as primary
createBackBuffer();
}
--
the ddraw trace looks like this:
--
trace:ddraw:initialize enabling DirectDraw HAL
trace:ddraw:DDRAW_Create ((null),0x808c718,(nil))
trace:ddraw:DDRAW_FindDriver ((null))
trace:ddraw:HAL_DirectDraw_Create
trace:ddraw:HAL_DirectDraw_Construct (0x403a9be0)
trace:ddraw:User_DirectDraw_Construct (0x403a9be0,0)
trace:ddraw:Main_DirectDraw_QueryInterface
(0x403a9be0)->({6c14db80-a733-11ce-a521-0020af0be560},0x808c718)
trace:ddraw:Main_DirectDraw_AddRef (0x403a9be0)->() incrementing from 1.
trace:ddraw:Main_DirectDraw_Release (0x403a9be0)->() decrementing from 2.
fixme:ddraw:Main_DirectDraw_WaitForVerticalBlank
(0x403a9be0)->(flags=0x00010021,handle=0x8)
trace:ddraw:User_DirectDraw_EnumDisplayModes
(0x403a9be0)->(0x40c92c4c,0x808c720,0x40c92be8,0x40f55dfc)
trace:ddraw:User_DirectDraw_EnumDisplayModes - mode: 512x384
trace:ddraw:User_DirectDraw_EnumDisplayModes - 8 bpp, R= G=
B=
(bang!)
--
and the backtrace from the exception looks like this:
--
#0 0x40c92c4c in ?? ()
#1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403a9be0,
dwFlags=1086925740, pDDSD=0x808c720, context=0x40c92be8, callback=0x40f55dfc
) at ddraw/user.c:373
#2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8,
dwFlags=1086925900, pDDSD=0x808c720, context=0x40c92a94, cb=0x40c92a94) at
ddraw/thunks.c:348
#3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c710) at
Source/tDirectDrawScreen.cpp:852
#4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c710,
fullScreen=false, screenWidth=640, screenHeight=480) at
Source/tDirectDrawScreen.cpp:88
#5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c710,
fullScreen=false, screenWidth=640, screenHeight=480) at
Source/tDirectDrawScreen.cpp:55
#6 0x4082d76f in InitApp (hInst=0x4062, nCmdShow=1) at
Source/Main.cpp:289
#7 0x4082d8fc in WinMain (hInst=0x4062, hPrevInst=0x0,
lpCmdLine=0x403710dd "", nCmdShow=1) at Source/Main.cpp:322
#8 0x4062509c in __wine_exe_main () from
/home/mattbee/Work/Nemesis/LSNClient.exe
#9 0x400b3799 in start_process () at ../../scheduler/process.c:564
#10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at
../../scheduler/sysdeps.c:112
--
> From what I see, I wonder if the enum procedure you give to DDraw has the
> right protoype (ie is it a STDCALL or a CDECL function) ?
I'm not supplying any procedure to DDraw; could it be that some linking
problem has caused EnumDisplayModes to be called instead of CreateSurface?
That's what the backtrace implies. I've tried a rebuild of the relevant
source files just in case but the same thing happens.
If it helps, this is the function that creates the mp_directDraw variable,
called before setUpWindowedSurfaces:
--
void tDirectDrawScreen::createDirectDrawObject()
{
HRESULT hr = DirectDrawCreate(0,&mp_directDraw,NULL);
handleErrors(hr,"Failed to create Direct Draw Object.");
}
---
SIGSEGV in IDirectDrawImpl_EnumDisplayModes
Apologies for needing some more hand-holding: from Alexander's advice I now
have the game linking and beginning to execute. It now gets stuck while
executing this piece of C++:
---
void tDirectDrawScreen::destroy()
{
DDSURFACEDESC ddsd;
memset(&ddsd,0,sizeof(DDSURFACEDESC));
ddsd.dwSize = sizeof(DDSURFACEDESC);
ddsd.dwFlags= DDSD_CAPS;
ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE;
HRESULT hr = mp_directDraw->CreateSurface(&ddsd, &mp_primarySurface, NULL);
// crashes here
...
}
---
This being the segfault that occurs:
---
#0 0x40c92c4c in ?? ()
#1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403acc00,
dwFlags=1086925740, pDDSD=0x808c678, context=0x40c92be8, callback=0x40f55dfc
) at ddraw/user.c:373
#2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8,
dwFlags=1086925900, pDDSD=0x808c678, context=0x40c92a94, cb=0x40c92a94) at
ddraw/thunks.c:348
#3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c668) at
Source/tDirectDrawScreen.cpp:852
#4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c668,
fullScreen=false, screenWidth=640, screenHeight=480) at
Source/tDirectDrawScreen.cpp:88
#5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c668,
fullScreen=false, screenWidth=640, screenHeight=480) at
Source/tDirectDrawScreen.cpp:55
#6 0x4082d76f in InitApp (hInst=0x4062, nCmdShow=1) at
Source/Main.cpp:289
#7 0x4082d8fc in WinMain (hInst=0x4062, hPrevInst=0x0,
lpCmdLine=0x403708ad "", nCmdShow=1) at Source/Main.cpp:322
#8 0x4062509c in __wine_exe_main () from
/home/mattbee/Work/Nemesis/LSNClient.exe
#9 0x400b3799 in start_process () at ../../scheduler/process.c:564
#10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at
../../scheduler/sysdeps.c:112
---
Any ideas why this might be happening?
--
Matthew Bloch Bytemark Computer Consulting Limited
http://www.bytemark.co.uk/
tel. +44 (0) 8707 455026
Re: Debugging advice
On Thursday 31 October 2002 01:14, you wrote: > Matthew Bloch <[EMAIL PROTECTED]> writes: > > $WINE/tools/winebuild/winebuild \ > > -fPIC -DSTRICT -D_REENTRANT \ > > -exe LSNClient.exe -mgui Builds/native-debug-linux/Source/*.o \ > > -L$WINE/dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -lddraw -ldsound \ > > -lwinmm -ldisplay -ldispdib >Source/LSNClient.exe.c > > display and dispdib are 16-bit dlls, you shouldn't import them. Still does the same thing whether I include then on the winebuild cmd line or not. Could you explain what the error message "loaded .so but dll ... not found" means? What does display.dll do? > > What efficiency gains will I make > > compiling a native "shared library exe" with gcc as opposed to just > > compiling with Visual C and running it under the normal WINE binary > > loader? > > There are basically no efficiency gains, there is no overhead in > running a PE exe compared to a native one. Okay, but presumably it's easier (as in not impossible!) for me to debug a program with GDB if I'm using a elf binary as opposed to a PE binary, which is mostly my object here. thanks, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
Debugging advice
Hi there; I feel like I'm "nearly there" with porting this game to run with winelib, a version checked out from winehq CVS about a week ago. Because I wanted my build system to be cross-platform, and WINE only as a stop-gap, I'm using the Jam build system and so can't directly take advantage of winemaker. Plus I would rather learn and document how the build process works manually, since I can't find this information anywhere else. Anyhow I now have the 400-odd source files compiling happily against my wine header files once I'd excised the need for Direct3D. I have a directory full of object files with external references to Win32 functions and a WinMain function. So to do the final linking step I've used (based on watching the example winemine build process): $WINE/tools/winebuild/winebuild \ -fPIC -DSTRICT -D_REENTRANT \ -exe LSNClient.exe -mgui Builds/native-debug-linux/Source/*.o \ -L$WINE/dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -lddraw -ldsound \ -lwinmm -ldisplay -ldispdib >Source/LSNClient.exe.c and then compiled & linked LSNClient.exe.c to the rest of the object files with the -shared flag, which leaves me with a shared library. Sideline: am I correct in thinking that winebuild's job is to scan the supplied object files for Win32 dependencies and construct the necessary glue code to load the needed .dll.so files? What's the reason that the linking process can't correspond more closely to "normal" linking, i.e. where I could just supply -lddraw -lwine to my program to produce a final binary? I then run ../wine/wine LSNClient.exe to try to run the game, and get this error: err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found - 16-bit dll or version conflict. err:module:PE_fixup_imports Module (file) display.dll (which is needed by Y:\Work\Nemesis\LSNClient.exe) not found Any idea what might be going wrong, or how I could diagnose it? More generally, the natively compiled .exe runs okay (if grindingly slowly, and with a couple of display glitches) under the binary loader, but I assumed that if I could produce a native version I'd be avoiding a lot of overhead and make my debugging job easier since I could use familiar GNU tools to debug my portability code as I wrote it. What efficiency gains will I make compiling a native "shared library exe" with gcc as opposed to just compiling with Visual C and running it under the normal WINE binary loader? I'm interested in how the latter works efficiently, so any advice in this direction would be appreciated-- I've thought on more than one occasion that maybe I should skip the WINE stop-gap and port it to SDL all at once, but the idea of being able to gradually wean the game off Win32 is appealing. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
Re: Wine securityflaw.
On Sunday 27 October 2002 11:37, Peter Andersson wrote: > What is it with you people? > I was just trying to make a point about the security risks about using wine > at present. And you start flameing me? I don't see any flames, just strong criticism of your idea for which you may not have thought all the issues through. WINE is not a sandbox as Alexandre pointed out, because writing a sandbox for any system is hard work: as proof look at the complexity of Valgrind, a program which emulates an x86-Linux system on top of another x86-Linux system for diagnostic purposes. Think how much harder it is to write the same kind of code for an OS when you've not got the same OS under your feet; it would be a slow-performing monster of a program. Given that WINE is not a sandbox, simplistically it's a translator of system calls & binary formats, the risks of running a WINE-based program are exactly the same risks you run with any unknown binary code, so any checks on sanity of syscalls are better done in the kernel or general-purpose executable wrapper than in WINE specifically. I started a conceptually similar emulator project to WINE a while ago for another OS (riscose.sf.net): a program to run RISC OS binaries on Unix. The issues are the same: just because malicious code comes from an unfamiliar OS doesn't make its destructive capabilities any different from native code, so if you're looking to tighten security of WINE programs, look to the same methods you'd use to tighten security of *any* unknown program: run it as a different user, run it in a Usermode Linux instance (user-mode-linux.sf.net), use kernel patches to restrict its use of system calls. But WINE shouldn't be bothered with any of this. If you're interested in playing with this kind of work, I know someone has written a Python-based framework (called Subversion or Subterfuge or something like that, sorry, can't find a link...) which lets you run any Linux process with bits of Python code intercepting and changing or barring system calls on the fly. That could be used to prototype a much more general Linux security framework, and one that could be used for more projects than just WINE. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
Re: License query
On Sunday 27 October 2002 01:56, you wrote: > Matthew Bloch <[EMAIL PROTECTED]> writes: > > I'm porting a closed-source game to Linux, and as a stop-gap I'd like to > > get a version out using WINE until I can rewrite the > > Direct(Sound|Draw|3D) backends with SDL. After reading this post: > > > > http://lists.debian.org/debian-devel/2002/debian-devel-200205/msg02823.ht > >ml > > > > and then downloading the source from the winehq.com cvs, I'm confused as > > to my options. The LICENSE file implies that the ddraw DLL is > > transgaming's IP but the files themselves have LGPL declarations at the > > top. > > Everything in the winehq.com tree is under LGPL, and there is nothing > in the LICENSE file about ddraw, it looks like you are confusing it > with the one from the Transgaming tree. So if you want only LGPL code, > make sure you only check things out from winehq.com. You're right, I still had the winex sources hanging around which was what confused me. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
License query
I'm porting a closed-source game to Linux, and as a stop-gap I'd like to get a version out using WINE until I can rewrite the Direct(Sound|Draw|3D) backends with SDL. After reading this post: http://lists.debian.org/debian-devel/2002/debian-devel-200205/msg02823.html and then downloading the source from the winehq.com cvs, I'm confused as to my options. The LICENSE file implies that the ddraw DLL is transgaming's IP but the files themselves have LGPL declarations at the top. In short, am I within my rights to release a statically linked binary which uses the core WINE source code, providing I comply with the other terms of the LGPL? I notice some files have Transgaming's name on them, but appear to be LGPL. I think I'm within my rights, but not sure: the post above gives me most of the information that explains this state of affairs, but not everything. Any further pointers on WINE licensing history would be appreciated. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
