It appears that although support for binary apps using OpenGL exists in wine, you cannot compile a Windows OpenGL app using winelib, because none of the wgl prototypes exist in wingdi.h
These prototypes exist in wgl.h, but that is not installed using "make install", nor is that where apps would expect them.
-- Tom Schutter (mailto:tom@platte.com) Platte River Associates, Inc. (http://www.platte.com)
On Wed, Jul 14, 2004 at 09:53:17AM -0600, Tom Schutter wrote:
It appears that although support for binary apps using OpenGL exists in wine, you cannot compile a Windows OpenGL app using winelib, because none of the wgl prototypes exist in wingdi.h
Yes, this is a known problem in Winelib right now (and we never got any bug report about it, so I never actually fixed it).
These prototypes exist in wgl.h, but that is not installed using "make install", nor is that where apps would expect them.
Yeah, "wgl.h" should be installed as other includes (ie move it from dlls/opengl32/wgl.h to include/wgl.h). But we will have another problem later on as using the Linux GL headers is problematic (as the Linux headers define the prototypes as 'cdecl' and Wine's implementation is 'stdcall').
Lionel
Lionel Ulmer wrote:
On Wed, Jul 14, 2004 at 09:53:17AM -0600, Tom Schutter wrote:
It appears that although support for binary apps using OpenGL exists in wine, you cannot compile a Windows OpenGL app using winelib, because none of the wgl prototypes exist in wingdi.h
Yes, this is a known problem in Winelib right now (and we never got any bug report about it, so I never actually fixed it).
Uhhh. So should I file a bug report?
These prototypes exist in wgl.h, but that is not installed using "make install", nor is that where apps would expect them.
Yeah, "wgl.h" should be installed as other includes (ie move it from dlls/opengl32/wgl.h to include/wgl.h). But we will have another problem later on as using the Linux GL headers is problematic (as the Linux headers define the prototypes as 'cdecl' and Wine's implementation is 'stdcall').
I don't see where the conflict is. I thought that wgl was Windows only. What Linux headers will define prototypes that appear in wgl.h?
Uhhh. So should I file a bug report?
Well, it would be a nice way to prevent it falling out of my TODO list (which is rather huge :-) ).
I don't see where the conflict is. I thought that wgl was Windows only. What Linux headers will define prototypes that appear in wgl.h?
The problem is not with the wgl.h header, but with the other OpenGL headers (GL/gl.h, GL/glext.h) which are almost the same between Windows and Linux. except for the calling convention. And as you use Wine's OpenGL library, you need to include a GL/gl.h file that defines this prototype with a 'stdcall' convention (which you will not have when including Linux' GL include which declares it as a 'cdecl' prototype). So Wine needs also to provide not only wgl.h but also GL/gl.h and GL/glext.h.
Basically, it's a mess :-)
Lionel
Hi,
On Wed, Jul 14, 2004 at 08:45:04PM +0200, Lionel Ulmer wrote:
Uhhh. So should I file a bug report?
Well, it would be a nice way to prevent it falling out of my TODO list (which is rather huge :-) ).
I don't see where the conflict is. I thought that wgl was Windows only. What Linux headers will define prototypes that appear in wgl.h?
The problem is not with the wgl.h header, but with the other OpenGL headers (GL/gl.h, GL/glext.h) which are almost the same between Windows and Linux. except for the calling convention. And as you use Wine's OpenGL library, you need to include a GL/gl.h file that defines this prototype with a 'stdcall' convention (which you will not have when including Linux' GL include which declares it as a 'cdecl' prototype). So Wine needs also to provide not only wgl.h but also GL/gl.h and GL/glext.h.
Basically, it's a mess :-)
...which could perhaps be solved by making the calling convention a define in the Linux headers, no?
/* our headers usually need cdecl, but external software sometimes has different requirements, so allow overriding */ #ifndef WGL_CALLCONV #define WGL_CALLCONV cdecl #endif
And Wine then simply does: #define WGL_CALLCONV stdcall #include "opengl_header.h"
Or am I completely and utterly mistaken here?
Andreas Mohr
On Thu, Jul 15, 2004 at 09:29:34AM +0200, Andreas Mohr wrote:
...which could perhaps be solved by making the calling convention a define in the Linux headers, no?
/* our headers usually need cdecl, but external software sometimes has different requirements, so allow overriding */ #ifndef WGL_CALLCONV #define WGL_CALLCONV cdecl #endif
And Wine then simply does: #define WGL_CALLCONV stdcall #include "opengl_header.h"
Or am I completely and utterly mistaken here?
No, but the problem is that do not have any control on the GL headers (you have some shipped by Mesa, some by NVIDIA, some by SGI, you may even have one shipped by Sun or Apple if you compile a Winelib application there).
Note that what you propose is actually already doable on the headers I have on my box (no idea where they come from, must be a mix between Mesa, NVIDIA and SGI :-) ) as all API functions are prefixed by a 'GLAPI' define which is defined as '__stdcall' if '_WIN32' is defined (we are lucky that Wine does not define _WIN32 in any of its header files :-) ).
Lionel
-
Andreas Mohr -
Lionel Ulmer -
Tom Schutter