[wined3d] Converting Wined3d to use WGL instead of GLX

[James Liggett]

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
testing purposes. 
> 
> Regards,
>   Aric
> 
> 
>