Before I can make changes to Kamehaha, I need to first get a working development environment for it. I was hopefully that since the google code project had a directory called "build" with a microsoft visual studio solution file (.sln) in it that it would work with visual studio. The file is from an older version than MSVS C++ 2010 which I used to convert and open it. Upon trying to compile the program however, I received a serious of errors due to the missing header file "XnCppWrapper.h". A quick google showed me this was a header from the OpenNI library. This is puzzling because the windows version of Kamehaha was supposed to be using the Microsoft SDK according to the
project page. However it looks like there is an OpenNI port as well, not just for linux but even for windows. It also looks like the build2010 folder in the source files has another microsoft visual studio solution which is perhaps the Kinect SDK one. Since I will be modifying the kamehameha program to use the web service for kinect data, it doesn't really matter which library the solution is using for now since I will eventually eliminate that dependency. But, to try and just get the solution to compile, I went ahead and installed the OpenNI sdk. This however didn't fix the issue and upon searching the installation directory for the missing header file I saw that it had not been installed. My google of the wrapper had turned up this
github which is what initially told me it was part of OpenNI.
At this point, I looked back to the google code project for kinect kamehameha to see if I missed anything. I did realize that I had checked out just the trunk from the svn repository and reliazed there were 3 separate branches with what I thought might be different code. They were: dev-1.0a, openni2-beta, and port-linux. Logically dev-1.0a seemd the only possibility for the Microsoft Kinect SDK but alas it too required the XnCppWrapper.h header file. Also upon commenting out the include a host of errors appeared as clearly the code was using the OpenNI library. So the mystery remains, where is the Microsoft Kinect SDK version of the code that the author so clearly states he is using? There was a second solution (.sln) file in the "build2010" folder and even though it didn't have any source files, which meant it was probably using the same files as "build" which were pulled from the "src" folder which are using OpenNI, I decided to try it. It actually compiled fine but when it came time to run the executable, windows threw an error saying the application failed to start due to the application config being incorrect. Googling this problem was useless as a whole host of different things can cause it.
Finally I decided to try compiling the source files with MinGW. This however yields an error about the missing header file "crtdbg.h" which is apparently a visual studio file necessary for debugging memory leaks. This include is in nearly every source file so it would not be trivial to just comment it completely out and see if it works.
So, with not many options left, I went back to the github which had the missing header file needed by openNI and downloaded the entire repository. I then linked the visual studio project to the downloaded library and it resolved that particular missing header error. However, I was still getting an error due to miss-matching path and output file names between the linker and some other configuration file in visual studio. I renamed the linkers output file name to match the other value (not sure where it was coming from as VS just said "targetname:") and now have one error left, LINK: cannot open file 'OpenNI.lib'.
I did some googling and found
this post. At the bottom, someone mentions checking the path variable. I didn't have that exact path variable set but nothing in the error message told me to what the actual name should be so instead I looked at the linker's dependencies and found the "OpenNI.lib" dependency. It was relative so I went to the OpenNI install directory from my installation earlier and found OpenNI2.lib. Due to a newer version of OpenNI, it looks like it was not picking up the library. I then changed the dependency to OpenNI2.lib and added its directory to the "Additional Library Directories" setting under Linker > General in VS. Unfortunately it looks like OpenNI2 had lots of changes as there were multiple compiler errors to unresolved symbols which I'm guessing were removed or changed in OpenNI2.
So, I proceeded to install the latest version of OpenNI (1). I remembered he had a branch called OpenNI2-beta but since it was "beta" decided not to try my luck and have to start all over trying to get the VS solution to compile. So, with openNI (v1.5.7.8) installed alongside openNI2, I switched the solution back to using the old lib. At this point I also realized the github project I had downloaded was also v1.5.7.8 of openNI and that could have been part of the reason the previous compile didn't work.
At any rate, finally, the compile successfully completed... only to fail when VS tried to run the executable and producing the same error as running the executable produced from the solution in the "build2010" folder.
Then I began googling the error message again. I found
this post which doesn't seem to relate much to my issue however it mentioned dependency's and a dependency walking program. A quick google and I found
this program which when used on the executable I was producing, discovered the program could not find 3 DLLs:
OPENNI.DLL
GPSVC.DLL
IESHIMS.DLL
I've been trying to resolve the openNI issue first but haven't turned up much. I lost the link but an article I read on the issue mentioned that your should be including the appropriate ".lib" file in the visual studio project and that the .lib file is responsible for linking the executable to the dll. Unfortunately I already am including the correct .lib file so it sounds like perhaps its an openNI issue... Also, I was able to find the openni.dll under the openNI installation directory in the "bin" folder. I tried adding that folder to my path but it made no difference on the executable and dependency walker still showed it couldn't find it.
Then I found a way to get dependency walker to give me the path that the program was using to look for the DLLs and found that the path for all 3 of the missing DLLs was simply the debug folder i.e. the output folder for the executable.
I did some research and found
this article which leads me to believe it is a 32 vs. 64 bit issue. I installed the openNI 32-bit library so perhaps that was part of it. I tried manually finding and copying the missing dlls into the debug folder but then dependency walker said there were "conflicting CPU types".
Unfortunately, installing the 64-bit version of openNI didn't work either as I got similar unresolved external symbol errors I received when I tried openNI2.
To be thorough, I went back to the solution from the build2010 file and ran dependency walker on the executable it produced. This time the openni.dll was not missing but the other two previously mentioned were. It is also worth noting that the gpsvc.dll and ieshims.dlls are related to group policy and internet explorer respectively. Two dlls that have little to do with this project, so I think. Also dependency walker includes an extra icon next to each of these entires that openni.dll didn't have when it was missing from the other solution. It looks like they might be delay load dependencies. The second question on their website's
faq here seems to indicate that those types of missing dependencies are harmless so long as the calling dll handles it properly. In all likely hood I'm guessing those two missing dlls have nothing to do with the executable's issue to run.
So, back to the drawing board. This time, I noticed that at the end of the error message from running the executable, windows says "check the Application error log for more information". Well, as it turns out, the application log does have some useful information. In particular, it was logging the following:
Activation context generation failed for "C:\Users\DARA\Desktop\kamehameha\dev-1.0a\build2010\MSSDK_Debug\kinect-kamehameha.exe". Dependent Assembly Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="XXXXXXX",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.I started googling for sxstrace.exe thinking it would give me more details and found
this article. A key thing to note here is that in the application log, the source of the error was "SideBySide". Also, that article I linked to led me to understand that
Microsoft.VC90.DebugCRT was causing the problem. Googling that led me to
this post and ultimately, the
final answer. And boy, is it anti-climatic. The first reply states this:
It looks like you have a dependency on a debug library (Microsoft.VC90.DebugCRT)
Debug libraries are not provided in any redistributable pack (because they are not redistributable).
This probably means you are trying to run a debug build on a machine that does not have Visual Studio installed. The solution to the problem is to build and distribute a release build, not a debug build.
I had noticed that the project was set to Debug but I thought nothing of it. I had no idea that a "debug" version could cause such issues. Simply changing the drop down in visual studio (there is no name or way to describe said dropdown other than it is in the top toolbar...) to _Release fixed everything. The program compiled and ran flawlessly. Here I will also note that they are two versions of each _debug _release pair respectively, MSSDK_ and OpenNI_. The "build" folder only had debug and release and since I was required to do all of the crazy include stuff for OpenNI, I guess that was the only library it supported. The build2010 folder however worked find without it and I now see that is because it lets you choose between which library to use.
So this long journey through dependencies and libraries ended up being a single value fix. From debug to release. Quite frustrating. Looking back there is not much I could've done to get to the solution quicker either. Perhaps noticing that the application logs had more information on the problem would've saved me the time of trying to fix the "build" folders dependencies.