Since you do not seem to have any experience in the area you might as well start with the ancient but still relevant Beej's Guide to Network Programming. I would strongly advise forgetting about game related usage for now and do something simple (like a very simple file server or chat program).
That cannot work. GLEW requires an active OpenGL context before you can initialize it. I'm not sure when GLUT guarantees you an active OpenGL context (check the documentation), but certainly not before the first GLUT call.
Edit: You should really get into the habit of checking return values. Checking the result of glewInit() would have put you onto the right track much sooner.
A) For the 15th time, I can't give you much specific information at this moment because I'm not at home and so I don't HAVE it available, except from memory, and trust me, that's very unreliable.
I'm well aware of that fact. You mentioned it several times. Still, you post pages of text without content instead of doing the reasonable thing: saying "I will post the information asked for after the next time I got home, pasting the actual errors and as much information I can gather into a file on [my USB stick equivalent] and will then paste more detailed information when I then regain Internet access on [some time]. That said, considering what you already are having problems with, doing anything in this area without some kind of Internet access will be an uphill struggle. Extremely uphill. You wouldn't even need much Internet, even a phone with a very limited datarate will do. Mostly just enough to Google a bit and having a way to post in forums like this while you work.
B) There IS a fair amount of information in the e-mail correspondence. I stated the exact windows I opened and what I clicked and what I typed where.
I read it, some bits several times and I see absolutely no hints to give more specific advice.
Despite your claims you don't ever provide any specific information. Important bits of information are:
1) what have you done?
2) what happens (including the exact verbatim error messages you are getting)?
Considering we are most likely dealing with the typical problems of someone inexperienced trying to link a library even extremely basic information regarding (2) would most likely be enough to help you (for example "C1083: Cannot open include file: 'blabla.h'").
The basic procedure for linking a library is always the same:
a) make sure the compiler can find the include files (failure to do so correctly will for example result in a C1083)
c) link the required import libraries (missing libraries will result for example in LNK2001s; messing up during (b) will result for example in LNK1181)
Really, as far as libraries go you have the simple case to deal with. You don't have to compile any library yourself to ensure the runtime and compile time options match. You just have to get something linked that dropped into your lap. You might have to observe specific documented restrictions in extreme cases (some compile time options that need to be set in a specific way, runtime libraries that have to be used or even exact compiler version numbers), but most libraries like that don't require anything like that.
The core issue is, that after four extremely verbose posts of yourself, you still have not provided any information to help narrow down your problems into one of the categories above. As a result, helping you is nearly impossible. Very general, unspecific problems will result in very general, unspecific answers.
There is a lot of self-pity and complaining but the signal-to-noise-ratio is frighteningly low.
From what I can tell from the flow of conversation setting up the basic search paths for your IDE of choice is indeed the problem you seem to be having. It's not their job to teach you that - that is like buying a book from a store and then complaining to them that you are unable to read. When they say
We are sorry you are still having issues, but the use of our lower-level type SDK requires comfort in using the visual studio environment and the c++ language.
I can only agree with them. The should not even have to give you any special instructions. When a developer installs a library, they will usually immediately look for the headers, import libraries and DLLs and work with them as they work with any other library.
I see no chance for you to complete your project if you cannot even master to link to a library without exact screenshots and instructions guiding your way. If you have specific problems (not the 'it does not work' we get so far) then we are probably happy to help, although I would say practically all of your problems can be solved quicker by simply googling.
As for the Razer Hydra, it seems that their API is also for C++ (although I heard something about a wrapper for C#. Does anyone know about this or its progress? BTW this is supposedly the same API that will be used by STEM.) I seemed to be able to sloppily get their DLLs and garbage imported into a simple C++ test project, in which I then just called a function to check if the Hydra is connected, and wouldn't you know it - it doesn't compile! I got a error that the DLL is invalid or some nonsense. I tried it with the 32 and 64 bit DLLs and neither work, though they each say a slightly different position in the file which is invalid. I got these files directly from Sixense (they created them) and I didn't have any error downloading them or installing anything. The drivers and everything else work, and so should this. I don't see how there could be a problem with the files, because they're the same ones that any developers would use. It seems like something else must be going wrong but I can't imagine what. Has anyone been able to get this to work, and if so, how?
You seem to be doing something wrong. DLLs don't feature during compilation at all (nevertheless you claim there are compile errors). You might be describing linker problems, but DLLs in almost all cases don't feature during linking as well (the import libraries do. You are not giving the linker the DLLs instead of the import libraries, do you?). The point where actual problems with DLLs usually happen is during runtime. Unfortunately you are not describing what you tried nor the error message (What exactly did you do? What exactly is the error message? Do not try to paraphrase errors, copy'n'paste them).
By the way, for some reason, people often mistake me for a beginner
Yes, unfortunately I can see how that would happen. You do not describe what you did and what your exact errors are in any sufficient detail to allow helping you (I picked one of your paragraphs to write something about but I could have done something very similar with all of them). As another example your problems with the Falcon sound like you just need more accurate descriptions on where to set the include directory/library search paths in modern MSVCs. That's the usual thing you need to do with libraries. Very occasional you need something more (like disabling exceptions for some reason). If that is truly the problem you are having (and if it is not, once again: What does the description say? What did you try? What happened?) then I would strongly suggest you spend some more time with C++ in simpler scenarios. Write some programs, work on linking with a library of your own creation. Because right now it seems you are stuck on extremely simple things and you only have two choices: 1) wait for someone to write the C# wrappers you need. 2) get more experience with C and/or C++ and write them yourself. Since you seem to committed to this, even if it takes 20 years, starting on (2) might not be a bad idea. Worst case, you learned some new stuff by the time (1) happens.
That suggests linking works fine now and you are just stuck with runtime errors. Have you verified that glewInit is called at the correct time and succeeds? Have you verified that the functionality you want to use is actually provided by your driver?
Also, you should learn enough about debugging an application to find the line where this error happens.
One major source of possible problems here is the target platform. Trying to link x86 libraries into x64 targets (or vice versa) will be silently ignored by many linkers (including MSVC's), leading to errors identical to not linking with the library at all. Are you certain you have downloaded the correct build for your target?
What exactly do you mean by "nonsense-chars"? It's expected for ä, ü or ö to be encoded as two bytes in UTF8.
If you know your file is encoded in UTF8, you should open it as an std::fstream, not an std::wfstream. Load your text as an std::string (that's the nice thing about UTF8 - everything fits into normal chars). If you need it as something else (like UTF16 or UTF32) use an UTF conversion library of your choice.
Warning: there are a lot of caveats regarding what to capture in the lambda and how to do it regarding the lifetime of the objects involved. Unless you know what you are doing exactly I would strongly recommend you post some use case examples and how you intend to use this.
That is impossible. As the documentation says: any non-empty std::function objects will always compare non-equal. Even if they were created using the same source-function. Even if they are copies of each other.
The typical way to solve this is returning some kind of Connection-object which uniquely identifies that particular connection. See for example how boost::signals2 works.
I would strongly advise compiling a static library with the exact compiler and the exact build settings you intend to use it with. You might be able to work without that provided you have a pure C library, but I don't have significant experience in that area.
As soon as C++ enters the picture it's just not worth it. Even for the same version of the same compiler setting a different flag can break ABI-compatibility (for example the safe iterator define on earlier MSVCs would do that). That can lead to extremely annoying, very subtle, hell to find problems. On the other hand the Windows version of gcc had one or two (unintentional) ABI breaks some time between 4.8.0 to 4.8.2. Check the changelogs for details.
Also note that is not a problem limited to static libraries. Unless you can make several restrictions regarding choice of runtime and other build settings an interface between dynamic libraries is also extremely limited (regarding allowed types and memory ownership).
On Windows you can usually get around compiling your own libraries if you stick to MSVC and you do not divert from the standard 'Debug' and 'Release' configurations. I would still suggest you get into the habit of compiling your own libraries though. You will need it sooner or later anyway and it's better to get skill points in compile-foreign-code without a really nasty deadline at your back.