If it can't open the file, then it isn't really included at this point. Are you sure the path is correct and that you have permission to go into that directory and access the file?

I will try that later but for now I am happy that I got rid of the first error, the new one is something I can deal with.

He did, but I'm guessing that the include went awry in some fashion.

I will try to do the whole process of including it again and try to figure out what went wrong.

I don't mean just #include <glfw.h>
I mean something like this: http://stackoverflow.com/questions/4702302/how-to-include-header-files-in-visual-studio-2008

Wow, I didn't realize that C++ had that much suckage to it. Then again, isn't that an MS developer tool?

C++ is a language. And by itself is pretty ok. Visual Studio C++ is an IDE (integrated development environment) produced by MS. But C++ code can written in almost anything, and can also be compiled with open source toolchains also (like mingw for windows or g++ on linux)

My point there is that the IDE should know to actually include things that you tell it to include and the compiler itself should know where to find the libraries.

So if I try to compile with VS2010, the program compiles, if I try to compile with gcc, the compilation fails?
The IDE shouldn't do anything without being told to do it, even if that means a failed compile. I have seen programs whose code included 50 more } than {, yet still compiled succesfully. Should the IDE refuse to compile due to wrong number of brackets?
I don't mind the IDE having an option to report said errors and suggest fixes, but unless the file is linked properly, the IDE shouldn't use it.

What are you talking about?

If I include something in the source, then it should be included. Putting an include line in the source should result in the library being included. The IDE itself shouldn't be holding back headers unless those headers are obscure and installed in weird places.

Then again, this is Windows we're talking about, and things regularly get installed to stupid places with little or no predictability. But, common libraries like this, shouldn't require anything more than an include in the source in order to get them to be included.

When I'm working on a Linux or *BSD system I rarely, if ever, have this problem because the compiler actually includes the things that I want to include.

Yeah, the problem on Windows is that there is no standard directory for includes and libraries, so each project must have the relevant directories added to its own search path variable (or the developer adds them to Visual's global search paths). On *nix there are default directories for them, so as long as you put them there, they'll be found.

Gcc is a compiler... and there are IDEs in the linux world also. Anyway the easiest way in command line is to have the directory with the include files in the INCLUDE environment variable. Libraries are added with -L. But normally on modern system installing a set of toolchain it results in the commond libraries/includes to be added by default. So your program will porbably work (except if you need some headers/libraries which are not installed)...

There are environment variables and compiler flags to tell gcc where to search for included header files, they are usually set to several default values which are normally sane (/usr/include, for example) and standardized. The fact you've never encountered the same problem as the OP on Linux is a matter of experiences on your part and not technical merits of either compiler.

While I don't necessarily argue that the Windows way of doing things can be a little annoying, I find that I prefer the Windows libraries segregated in their own directory, as most have build and testing tools of their own that I'd prefer to be organized in one location. I don't mind the Linux way of doing things either. TBH, I find having to make adjustments to the include paths trivial and is just a part of a sane build process.

Regardless, there is no way for either compiler to know where all the header files are going to be unless told and there are plenty of cases where I've had to tell gcc where to look for the proper include files. I would rather the compiler be explicit about include paths rather than try to find them on it's own, I often have to deal with several versions of one library on a system and if the compiler starts assuming things, then I run into problems.