Avoid #include "windows.h", just relevant parts (like GLFW3)

Question

Avoid #include "windows.h", just relevant parts (like GLFW3)

raysan5 opened this issue 9 years ago · comments

I want to use glad in my project (raylib) but some symbols defined by windows.h conflict with my symbols. If I comment #include "windows.h" on glad.h everything compiles fine but programs crash on init.

Would it be possible to include only the required windows.h parts into glad.h?

GLFW3 works this way.

David Herberth · Answer 1 · Thu Jan 21 2016 17:10:40 GMT+0800 (China Standard Time)

Should be possible. The main reason I can think of right now is only APIENTRY, but a bigger issue is khrplatform.h which also includes windows.h, but this time I can't influence it. Which means I need to make glad smarter about including khrplatform.

I'll be looking into it!

So if you just want a quick fix until I have a proper solution, remove the khrplatform.h and windows.h includes and define #define APIENTRY __stdcall on windows (location where windows.h was previously included).

Ray · Answer 2 · Thu Jan 21 2016 19:54:21 GMT+0800 (China Standard Time)

Hi @Dav1dde, thanks for the answer.

I tried the proposed solution and after dealing with some #defines, I get the following library compilation warnings (MinGW / gcc 4.7.2 / Windows 10 Home N 32bit):

glad.c: In function 'open_gl':
glad.c:53:5: warning: implicit declaration of function 'LoadLibraryA' [-Wimplicit-function-declaration]
glad.c:55:9: warning: implicit declaration of function 'GetProcAddress' [-Wimplicit-function-declaration]
glad.c: In function 'close_gl':
glad.c:65:9: warning: implicit declaration of function 'FreeLibrary' [-Wimplicit-function-declaration]

And, consequently, the following linkage warnings on programs:

Warning: resolving _GetProcAddress by linking to _GetProcAddress@8
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving _FreeLibrary by linking to _FreeLibrary@4
c:/raylib/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../libraylib.a(glad.o):glad.c:(.text+0xd374): undefined reference to `LoadLibraryA'

After some investigation on those functions I got:

LoadLibrary() belongs to kernel32.dll, declared in winbase.h, included by windows.h.
GetProcAddress() belongs to kernel32.dll, declared in winbase.h, included by windows.h.
FreeLibrary() belongs to kernel32.dll, declared in winbase.h, included by windows.h.

I tried including just winbase.h but it has lots of undefined values... as expected...

Hope this information could be useful.

David Herberth · Answer 3 · Thu Jan 21 2016 22:58:35 GMT+0800 (China Standard Time)

Thanks, that should only a problem if you use a glad version with loader. In your case you seem to use glfw anyways, so a loader is not necessary (just pass (GLADloadproc)GglfwGetProcAddress to gladLoadGLLoader). Including windows.h in glad.c instead of glad.h should also work just fine.

I will still be looking into removing windows.h completely.

Ray · Answer 4 · Fri Jan 22 2016 08:56:48 GMT+0800 (China Standard Time)

Many thanks! It works! :D

Program works great and executable is nearly 150KB smaller than GLEW alternative but I noticed a very weird issue when using GLAD.

I use gDEBugger 5.8.1 profiler to test my library programs and when running a program using GLAD, textures are not detected at all, neither glBindTexture() calls or glDrawElements() calls... it's very weird because those calls are correctly detected when using GLEW... and in fact, program displays textures correctly in both cases!

I know gDEBugger is a quite old tool, maybe it's a bug on the program...

David Herberth · Answer 5 · Fri Jan 22 2016 09:00:51 GMT+0800 (China Standard Time)

Awesome! I have no idea about the gDEBugger thing, but you could try apitrace, they are using glad in the testsuite, so I assume it works with glad!

Carl Hewett · Answer 6 · Wed Apr 20 2016 12:19:19 GMT+0800 (China Standard Time)

I know this is old, but maybe glad.c could define NOMINMAX before including windows.h to avoid problems related to the min and max macros defined by that file?

David Herberth · Answer 7 · Wed Apr 20 2016 15:50:24 GMT+0800 (China Standard Time)

I haven't forgotten about the issue, unfortunately I simply don't have time to work on it. It should be possible to completely get rid of Windows.h.

I will look into your suggestion when I get around to fix this, Thanks!

David Herberth · Answer 8 · Sat May 21 2016 18:49:28 GMT+0800 (China Standard Time)

I finally had time to look into it, I decided to still include windows.h in the header file, all you need to do in order to stop glad from including it, is to define APIENTRY before including glad.

I added this to the README.

Commit: 865dd12

Hristo Hristov · Answer 9 · Fri Aug 31 2018 04:45:15 GMT+0800 (China Standard Time)

@Dav1dde

If Windows.h is included before glad.h:

c:\program files (x86)\windows kits\10\include\10.0.17134.0\um\oaidl.h(487): warning C5103: pasting '/' and '/' does not result in a valid preprocessing token C:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\shared\wtypes.h(745): note: in expansion of macro '_VARIANT_BOOL' c:\program files (x86)\windows kits\10\include\10.0.17134.0\um\oaidl.h(487): error C2059: syntax error: '/' c:\program files (x86)\windows kits\10\include\10.0.17134.0\um\oaidl.h(487): error C2238: unexpected token(s) preceding ';' c:\program files (x86)\windows kits\10\include\10.0.17134.0\um\oaidl.h(502): warning C5103: pasting '/' and '/' does not result in a valid preprocessing token C:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\shared\wtypes.h(745): note: in expansion of macro '_VARIANT_BOOL' c:\program files (x86)\windows kits\10\include\10.0.17134.0\um\oaidl.h(502): error C2059: syntax error: '/' c:\program files (x86)\windows kits\10\include\10.0.17134.0\um\oaidl.h(502): error C2238: unexpected token(s) preceding ';' C:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\um\propidlbase.h(319): warning C5103: pasting '/' and '/' does not result in a valid preprocessing token C:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\shared\wtypes.h(745): note: in expansion of macro '_VARIANT_BOOL' C:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\um\propidlbase.h(319): error C2059: syntax error: '/' C:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\um\propidlbase.h(319): error C2238: unexpected token(s) preceding ';'

David Herberth · Answer 10 · Fri Aug 31 2018 17:24:04 GMT+0800 (China Standard Time)

This error doesn't seem to come from glad, but from oaidl.h. What happens if you temporarily remove the include?

Hristo Hristov · Answer 11 · Sat Sep 01 2018 12:38:59 GMT+0800 (China Standard Time)

Sorry! It seems the issue was caused by this compiler switch "/experimental:preprocessor" in VS2017.

Hristo Hristov · Answer 12 · Sat Sep 01 2018 13:37:18 GMT+0800 (China Standard Time)

Anyway wouldn't it be better if glad doesn't use defines that are defined in Windows.h to avoid issues, e.g. use APIENTRY_GLAD instead of defining APIENTRY.
Also instead of disabling the inclusion of Windows.h by defining APIENTRY wouldn't it be better to do it via unrelated define like GLAD_NO_WINDOWS_H.
I glanced over glad2 and it looks that it was addressed there:

#ifdef APIENTRY
#define GLAD_API_PTR APIENTRY
#elif GLAD_PLATFORM_WIN32
#define GLAD_API_PTR __stdcall
#else
#define GLAD_API_PTR
#endif

Also the webservice page could use some link, documentation to make it easier to understand for newcomers. Like for example what does " Generate a loader" do (I know now).

And also thank you very much for this library!

David Herberth · Answer 13 · Sat Sep 01 2018 17:36:32 GMT+0800 (China Standard Time)

Initially I did it this way to be as close as possible to the original gl.h and the XML specification (which uses APIENTRY) in hindsight this was not the best choice but the problem is changing it now may break a few setups, which I want to avoid (a simple library as glad should be add-in and forget). There are a few more bad decisions in the current glad version, all of which I don't want to "fix", simply because it will break peoples code.

Hence the glad2 "rework", where I try to get rid of all these issues and bad decisions I made early on.

Regarding documentation, yeah that's another thing where I want to get better at, it's currently in a very bad state and relies on tutorials linking to glad and explaining as well as experienced users that don't need the documentation. Also something I want to improve with glad2, unfortunately I don't have a lot of time to do this, but I'll get there.