Weird. I vaguely remember MS explaining their lack of a 64bit version with something like "it's pointless, there is no reason these tools would ever require more than 4GB". So at least at some point they went with "why bloat up the executables and double our maintenance efforts when there is zero benefit?"

Are we already at the point where this has become the new "nobody needs more than 640k" statement? ,-)

I could see the executable getting larger, but I'd also propose that they get rid of the 32-bit version. The maintenance would stay the same, and they're writing native stuff. Holding onto the 32-bit world, which doesn't exist in desktop-class hardware hasn't existed for quite some time. We're even seeing 64-bit architecture on mobile devices more and more, and any 32-bit mobile CPU would require a separate compiler for 32-bit code anyway (which, that compiler could be a 64-bit executable too, lol).

I could see the executable getting larger, but I'd also propose that they get rid of the 32-bit version. The maintenance would stay the same, and they're writing native stuff. Holding onto the 32-bit world, which doesn't exist in desktop-class hardware hasn't existed for quite some time. We're even seeing 64-bit architecture on mobile devices more and more, and any 32-bit mobile CPU would require a separate compiler for 32-bit code anyway (which, that compiler could be a 64-bit executable too, lol).

There are still 32bit Windows systems out there. Making VS 64bit only would exclude those, while keeping it 32bit doesn't seem to have any major drawbacks at the moment.

I just wish they'd at least make the native platform's architecture default at first, but it's just a gripe. It's caused me to go out and learn something, so I'm pretty happy there

Aside from that, I think I've come across the answer to my problem. I think GLEW's dll might be wrong. For example, when I added the FBXSDK, I could compile the project using the FBXSDK API calls, but the application would crash telling me that libfbxsdk.dll was missing. The DLL for my architecture and platform was in the same folder that my current config/platform was pointed to for Additional "Library Directories" under my project's Properties->Linker->General tab. Of course, the static .lib file was included as an additional dependency for the project to build, but then DLLs are linked at run-time... So, what would be the best practice for building my projects with DLL dependencies? Right now, I have four build configs:

32-bit Debug and Release

64-bit Debug and Release

I'm going to switch to 64-bit Debug once I get around to building GLEW and GLFW for that. Right now, I'm putting all required DLLs into my project's directory so it'll build. However, when running the project directly from Windows Explorer, I'd have to have a copy of all those DLLs for the correct platform/config in the corresponding folder. This would require some manual copying and pasting, which is fine for the moment, but is there a more automated way of doing this? I'd like to release my project as an open-source one once I figure out which 3rd-libraries I need, and which ones I have permission to distribute.