[wined3d] Converting Wined3d to use WGL instead of GLX
jrliggett at cox.net
Sat Dec 17 02:53:02 CST 2005
On Sat, 2005-12-17 at 07:07 +0000, Aric Cyr wrote:
> Thanks for the suggestion, but I already have wine compiled with only "-g".
> Last time I checked gcc doesn't enable optimizations unless a -O option is
> specified explicitly (don't know if this has changed though).
> Anyways, I think I finally figured this all out. As I thought it turned out to
> be stack corruption, due to differing calling conventions. It just required
> fixing up my function pointers to be WINAPI (which I believe becomes stdcall)
> for all the wgl functions.
I think you're right IIRC. I think all win32 calls are stdcall (or
sometimes pascal, which is more or less the same thing I think, where
the function cleans up the stack and not the caller, as opposed to
cdecl, where the opposite happens) Calling conventions are a lot of fun,
aren't they? :)
> Now everything works fine, except this brings up another issue with
> wglGetProcAddress. The problem is that all gl extensions function pointers are
> declared WINAPI, and indeed this is what type of functoin wglGetProcAddress is
> expected to return. However for extensions that are not registered in
> opengl_ext.c wglGetProcAddress falls back to glXGetProcAddressARB which would
> return a non-WINAPI function pointer. After the first call to such a function
> we would have corrupted the stack. There doesn't seem to be a nice way to fix
> this that I can think of. wglGetProcAddress should never return a non-WINAPI
> function though, as that is just asking for trouble. Better to return NULL
> instead of falling back to glXGetProcAddressARB.
I agree here as well. The whole idea here is to avoid glx and use the
WGL layer to abstract it, right? It would be a really bad idea to trust
glXGetProcAddressARB because you can't really know for sure if the
calling convention is right, and that issue becomes a problem with any
shared library on any platform, precisely because of the problems you
were experiencing with the stack.
> As an aside to the wglGetProcAddress issue, all GL extenions called by wined3d
> are now passed through the thunks. It is only one extra function call so the
> impact should be minimal (too bad we can't inline these!), but I thought I
> should mention it anyways.
Good work! ;-)
> After cleaning up everything I've worked on I think I'll start submitting
> patches. First some pre-requisite patches for dlls/opengl32 and include/ and
> then the changes for dlls/wined3d. All together it is quite a large change, but
> I should be able to break it up into manageable pieces (hopefully!).
Great! I'd really like to see this kind of thing come to fruition. I
think it would be especially good to see wined3d run on windows for
More information about the wine-devel