If you're relying on this code to be performant, and you have the resources and skills, then you really want to look at vector intrinsics (or, linking a vector routine written with... I forget the name, but its a vector-aware C-like compiler, or perhaps an assembler, depending on which of those dependencies is more comfortable).
When linking, object files must come before their dependencies (because the linker resolves symbols from left to right on the command-line). Hence the correct order is your object files followed by libcurl followed by gnutls (probably) because your code needs symbols from libcurl which itself needs symbols from gnutls.
Basically, yes, I could ask the hard drive "does this file exist", but it's not going to prevent you from failing to open a file because they happened to disconnect the storage unit between your query and the open command.
Asking the filesystem if a file exists and then opening it afterwards is a logic error (time of check to time of use) although it's usually acceptable to treat your own files as a private resource. And, sure, you could disconnect the hard drive while the program is reading from the now open file, but then it wouldn't be a "file not found" error but rather an "device not found" error or similar on any half-assed system, that more accurately describes the underlying fault.
It's certainly important to handle all common cases of failures, and ideally take appropriate action in each case. On the other hand, I wouldn't worry too much about trying to handle everything; being truly robust (against every failure mode) typically involves copying large amounts of data because any destructive operation may need to be rolled back at any time in the eventuality of an error to preserve your program's state if you want to have any chance of recovering from the error. Furthermore this copying needs to be done speculatively regardless of whether an error actually occurred. Most software doesn't need or want to (or even can) pay that price; high-performance software like games certainly do not.
In any case, most everyday software crashes are due to programmer error (which will generally not result in an exception but instead in an inconsistent program state) and not environmental problems like an I/O error. And when it is, it's often pretty obvious to the user (hard drive failure, network down, ...) . So don't obsess over exception handling, you're better off spending your time testing your code exhaustively and making sure it works properly!
3D acceleration is the one thing that VM's actually don't do very well, so you'd do well do run your OpenGL experiments on actual hardware rather than a virtual machine. It will save you time and frustration in the long run.
C++ has lots of silly things in it. But there's not a whole lot of incentive to change that specific parsing peculiarity because it can be easily worked around by using extra pairs of parentheses to force the compiler into getting the parsing right, or using the new C++11 initialization features (which use curly brackets instead, sidestepping the issue). It looks odd but it's not that big of an issue in the real world; yes, people go WTF for the first time, but then read up on it and just move on.
By the way, declaring functions inside other functions is also uncommon in C. There's really not a whole lot of uses for it, except maybe for ultra-pedantic coders who insist on functions being declared only when used. There are uses for declaring (and defining) temporary, localized data types, like enums or structs, at function scope, which can come in handy sometimes, but functions... no, not really.
In your shader you should be able to access a per-instance unique index that you can use to select the appropriate transformation matrix to apply. For DX11 for instance (pun intended) it's SV_InstanceID. Dunno about DX9.
You're supposed to show that your engine stands out among the many alternatives by eating your own dog food and making one or more complete games using your engine and using them to highlight your engine's strengths and also weaknesses (or lack thereof). Just saying it's "simplified" or it "has a small learning curve" doesn't really cut it when someone is trying to pick an engine to work with, he'll see all those awesome games made in Unity or Unreal and that's what's going to drive his decision. Your engine may be awesome but unless you get people hooked on to it by marketing it you won't get many users.
What's this? I think it allocates a single char and puts the initial value 2 * 3 = 6 inside it, which is likely not what you want. Did you mean:
char* whdBuffer = new char[sizeof(USHORT)*3];
At this point you are probably corrupting the stack by asking ifstream to write 6 bytes into an array that contains only space for one byte, so fix that and try again.
Secondly, reinterpreting a char pointer as a USHORT (unsigned short) pointer is in general illegal and undefined behaviour because USHORT has stricter alignment requirements than char (doing the opposite is valid, though). If you need an array of USHORT, ask for an array of USHORT. It will work fine in this case because the "new" operator is guaranteed to return "sufficiently aligned" memory for all primitive types, but this may not hold in general (especially if you reinterpret a pointer into the middle of an array) and is a bad habit to get into, so just avoid reinterpreting pointers like that. Many C++ programmers are actually not aware of alignment constraints because the x86 processor in your desktop fixes up the unaligned accesses in hardware at (some) performance cost, however code that just freely reinterprets pointers like there's no tomorrow is liable to fail hard on less friendly processors like some ARM (mobile) processors
Well, realistically if you just drop it in a Github repository and forget about it you won't really get any visitors to it. You'll need to at least tell people that it exists, via e.g. social media or a GDNet journal entry or whatever. Beyond that, you don't have to maintain it if you don't want to, but if you are not interested in maintaining it, it's unlikely someone will just step up from the shadows to contribute and provide feedback, especially if it hasn't been "cleaned up" and if there's nobody else interested in said contributions.