For some reason, there are painful issues with compiling a stand-alone executable from C code to make an OK API-based control program. When I started a new project, added the OK API .h and .cc files and made my executable, and then took it over to the PC where it was going to be run, it complained about the lack of a "MSVCP100D.DLL" file. That's when I noticed that I'd made a debug build accidentally and went back and compiled a "Release" build. After that it complained about a missing "MSVCP100.DLL" file. This problem does not occur when building the flashloader.exe.
I began comparing the compile options between my project and the flashloader project. There is a preprocessor options entry that's full of flags corresponding to ifdef's in the OK code for the flashloader project, so I added the same flags to my own project, but it didn't mitigate the DLL issue.
I found out that the DLL is the C++ standard library, as shown here:
http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
Obviously, there's something in the way that the flashloader executable is linked that includes the library in the executable, but my freshly-started project is linking in such a way that it requires dynamic access to the DLL. Downloading DLLs from sites returned by Google is a pretty bad idea, so I went about figuring out how to find it on my system or get it from M$.
The following site hints that this DLL should have been installed on my system at a particular location (C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages). However, it wasn't. I think that this was because I am using VS Express, not the full version.
http://cboard.cprogramming.com/windows-programming/128217-msvcp100-dll.html
Navigating a series of links from the above and other hits from Google (here is some entertaining flail: http://code.google.com/p/nulldc/issues/detail?id=109), I learned that what DLLs can be "redistributed" by developers is a big hairy deal, and there's a confusing list of what can and can't, but no direct link to how to get any of them. Here is the M$ list:
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
That would seem to hint that distribution of this DLL is frowned on, but in spite of that, M$ will give you a download that installs this DLL and several others on any target system. It's called vcredist_x86.exe, and can be had from here:
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84
So, once I had vcredist_x86.exe, I put it on the system in the lab and was able to run my executables (rather than find what I was doing wrong with the linker).
Edit: The answer might be in a post that I missed in the cboard thread above. One of the lower posts says:
"Also you can statically link the runtime libraries by changing your project settings:
Configuration Properties -> C/C++ -> Code Generation -> Runtime Library
If you want to statically link the runtime, don't choose one of the DLL options."
