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