As the subject says, all of the WGL functions that should be declared in wingdi.h are currently only found in dlls/opengl32/wgl.h. I ran across this recently while working on getting wined3d to use wgl instead of glx directly. Currently I work around it by including wgl.h and adding makefile include options to point to dlls/opengl32. It would be much cleaner and correct if I could forgo this and just include wingdi.h. Anyone have problems with me submitting a patch which would move the relevant (i.e. not all) parts of dlls/opengl32/wgl.h into include/wingdi.h?
From MSDN (for wglCreateContext):
=== Requirements
Windows NT/2000: Requires Windows NT 3.5 or later. Windows 95/98: Requires Windows 95 or later. Available as a redistributable for Windows 95. Header: Declared in wingdi.h. Import Library: Use opengl32.lib. ===
Regards, Aric
Anyone have problems with me submitting a patch which would move the relevant (i.e. not all) parts of dlls/opengl32/wgl.h into include/wingdi.h?
Not from me. It simply that when I did the OpenGL work, 'winelib' was not really a priority and so I did not think about putting the 'wgl.h' headers somewhere usable for something else than the GL library itself.
Anyway, about your D3D over WGL project, I am still wondering how you are going to link 'wined3d' against OpenGL32.DLL. Direct linking or 'GetProcAddress' linking ? If it's the former, will you PE-link against OpenGL32.DLL or ELF-link against libGL.so ?
Just wondering because if it's the former, you also need a complete set of 'GL' headers in Wine to have the stdcall version of all GL calls (and pay the price of thunking on each GL call).
Lionel
Lionel Ulmer <lionel.ulmer <at> free.fr> writes:
Anyone have problems with me submitting a patch which would move the relevant (i.e. not all) parts of dlls/opengl32/wgl.h into include/wingdi.h?
Not from me. It simply that when I did the OpenGL work, 'winelib' was not really a priority and so I did not think about putting the 'wgl.h' headers somewhere usable for something else than the GL library itself.
Okay, I'm submit a patch for wgl headers then. I should be able to just move the relevant declarations from dlls/opengl32/wgl.h to include/wingdi.h without any problems I think. Please let me know if there are any gotchas I should watch out for.
Anyway, about your D3D over WGL project, I am still wondering how you are going to link 'wined3d' against OpenGL32.DLL. Direct linking or 'GetProcAddress' linking ? If it's the former, will you PE-link against OpenGL32.DLL or ELF-link against libGL.so ?
Just wondering because if it's the former, you also need a complete set of 'GL' headers in Wine to have the stdcall version of all GL calls (and pay the price of thunking on each GL call).
Well I am only working on removing glX calls from wined3d and replacing them with wgl calls so I'd rather not impact the GL code if possible. At first I didn't quite understand your question, so let me see if I got this right. Currently wined3d directly links to libGL.so (via EXTRALIBS in the Makefile). So if I wanted to use opengl32.dll (for wgl), and I added it to IMPORTS it would override the libGL.so calls?
Currently that is what I am doing, but if that is causing all GL calls to go through opengl32.dll then that is not good... Since there are not too many wgl calls, it would probably be best to GetProcAddress them. In fact, I am doing this for a few wgl extensions anyways, so I might as well just do it for all of wgl. I'm not that familiar with the wine linking issues, so please let me know if I am off here.
Cheers, Aric
On Tue, Nov 29, 2005 at 05:39:13AM +0000, Aric Cyr wrote:
Well I am only working on removing glX calls from wined3d and replacing them with wgl calls so I'd rather not impact the GL code if possible. At first I didn't quite understand your question, so let me see if I got this right. Currently wined3d directly links to libGL.so (via EXTRALIBS in the Makefile). So if I wanted to use opengl32.dll (for wgl), and I added it to IMPORTS it would override the libGL.so calls?
Well, this is the big question. I think we should ask Alexandre what happens in the Wine build system if a symbol is exported both by a Win32 DLL (here OpenGL32.DLL) and a Linux ELF DLL (here libGL.so) and a Wine DLL requires to be linked to both.
In my opinion I would have both GLX and WGL code co-exist... I really fear that to make some game happy in WGL, we would 'cheat' and report some stuff which is not exactly aligned with what the GPU really supports. Which means that WineD3D will not be able to trust what WGL reports as it may be tweaked.
Finally, if we get some 'GLX-only' extensions (maybe threading related - one can always hope :-) ), how could one support that using WGL ? Add our own fake extensions to WGL and 'thunk them' ?
Lionel
Lionel Ulmer lionel.ulmer@free.fr writes:
Well, this is the big question. I think we should ask Alexandre what happens in the Wine build system if a symbol is exported both by a Win32 DLL (here OpenGL32.DLL) and a Linux ELF DLL (here libGL.so) and a Wine DLL requires to be linked to both.
The Win32 DLL will take precedence, so everything would get linked to opengl32, which is probably not what you want.
On 12/6/05, Alexandre Julliard julliard@winehq.org wrote:
Lionel Ulmer lionel.ulmer@free.fr writes:
Well, this is the big question. I think we should ask Alexandre what happens in the Wine build system if a symbol is exported both by a Win32 DLL (here OpenGL32.DLL) and a Linux ELF DLL (here libGL.so) and a Wine DLL requires to be linked to both.
The Win32 DLL will take precedence, so everything would get linked to opengl32, which is probably not what you want.
Okay, so GetProcAddress() for all wgl functions seems to be the way to go, correct? I'll implement it that way so that opengl32.dll doesn't get pulled into wined3d via IMPORTS. It is not a big change anyways, since there are already glX function pointers for some functions. I'll just change them all to their wgl equivalents and add the standard functions as well.
-- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)
-
Alexandre Julliard -
Aric Cyr -
Lionel Ulmer