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

[raysan5]

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.

[Dav1dde]

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).

[raysan5]

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.

[Dav1dde]

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.

[raysan5]

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...

[Dav1dde]

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!

[fordcars]

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?

[Dav1dde]

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!

[Dav1dde]

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

[Zingam]

@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 ';'

[Dav1dde]

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

[Zingam]

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

[Zingam]

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!

[Dav1dde]

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.