Hmmm... something must have changed...
Since both your exe and the sample are not working, start with the sample.
The first thing to check is to make sure the OpenFlight DLLs (mgapilib.dll and others) will be found when you run the sample exe. This "mechanism" must be set up by you (how your exe finds DLLs). There are many ways to set up for this in Windows. You can set PATH env var, you can put your exe in the same folder as the DLLs etc depending on how you want your environment set up. In the 4.2 samples, the Environment property is set (in the Debugging Properties of the Visual Studio project) to point to the installed location of the OpenFlight API DLLs.
First check this to make sure the DLLs will be found when you run the sample exe. I suspect once you fix this, your exe will start behaving better also.
Let us know what you find.
Nothing has changed with the setup. Maybe the DLL has been corrupted?
Here are the relevant system env vars (which have not changed):
PRESAGIS_OPENFLIGHT_API=C:\TrustedApps\Presagis\OpenFlight_API_4_2
PRESAGIS_OPENFLIGHT_API_4_2=C:\TrustedApps\Presagis\OpenFlight_API_4_2
When I go there, I see all of the files/dirs are still in there, including the lib, include and bin directories. All the files I would expect to be in there, including the DLLs and LIBs are still in there.
The color2 project properties (which I have not touched) show everything I would expect:
Additional Include Directories: $(PRESAGIS_OPENFLIGHT_API)\include
Additional Dependencies: mgdd.lib mgapilib.lib
Additional Library Directories: $(PRESAGIS_OPENFLIGHT_API)\lib
Just uninstalled, and reinstalled the API. Still had the same problem running color2, without making any changes whatsoever. Something weird is going on...
The PRESAGIS env vars you listed are only important for "building" your exe/plugin. There is nothing set by the API installer to tell Windows "how to find DLLs" when your app runs. This is a Windows thing (PATH env var and the other items I listed before). See the OpenFlight API FAQ in the Reference "When I run my stand-alone application, the wrong version of the API runs. Why?" or Google Search "how does Windows find DLLs when application runs". I found this link that might help you understand this.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx.
From what you see, I don't think the OpenFlight API env is broken, I think something in your Windows env is broken. Check the API FAQ and this Windows link and then try to verify that when you run the exe the DLLs are being looked for in the right place.
Thank you for your response. I do understand what you are saying, and I do believe that ultimately there is something going on with my Windows env. However, I have not been able to find anything wrong there. I've double-checked all my System env vars, and also hard coded paths to the OF API lib and include dirs into my path var. I've made sure there are no competing paths to the DLL in my env. I only have one copy installed.
I looked at the FAQ article, and despite what is says in there, for some reason the exe is looking at the current directory, and stopping there. I'm thinking that could be something set up when I compile and build the exe. When I open color2.exe in depends it shows that MGAPILIB.DLL (no path) could not be found. All of the other DLLs it loaded show full paths. Furthermore, if I copy mgapilib.dll into the same dir as the exe, it gets past the error (but fails a bit further as it looks for the other DLLs).
Depends seems to indicate that color2.exe is looking in the directory from which the application loaded, and stopping there.
I looked at the FAQ article, and despite what is says in there, for some reason the exe is looking at the current directory, and stopping there. Iââ¬â¢m thinking that could be something set up when I compile and build the exe.
The sample apps do not do this. I am not even sure you can do this per exe. This is a standard thing that Windows does when you run any exe. There is a prescribed "search order" used by Windows to find DLLs. The sample apps do not "override" this mechanism and you'd never really want to (even if you could which I don't think is possible).
When I open color2.exe in depends it shows that MGAPILIB.DLL (no path) could not be found. All of the other DLLs it loaded show full paths.
It makes sense that only "found" DLLs would show paths in depends. And the paths shown are the places where the DLL was found (given the search order). This is helpful to confirm to you which DLLs WOULD BE LOADED when you run. For example, if the DLL was in the same folder as the exe, depends would show that folder. If the DLL was in the PATH env folder, depends would show that folder. The location of the DLL is dynamic based on the "first" one found using the search order described in that link. Again, depends shows NO path only when the DLL could not be found using that search order. Put another way, the depends program uses the same "searching algorithm" to locate DLLs as Windows does when the exe is run. This confirms that the location of the DLL is NOT contained in the exe, it is "deduced" using the search path I mentioned above at runtime by Windows when the exe runs and the path shown in depends is dynamic.
Depends seems to indicate that color2.exe is looking in the directory from which the application loaded, and stopping there.
I am not sure you can conclude that.
Here is one sure way to make your exe run. Put the exe in the same folder as mgapilib.dll (and all the other dependent DLLs). As you've discovered you can't simply move mgapilib.dll to the folder where the exe is because mgapilib.dll has many other dependencies. Flip it around, move the exe to the bin folder where all the API DLLs are installed. Then run your exe. If that works then you can continue working backwards to isolate why Windows is not finding the DLLs.
Great info, thank you!
I did as you suggested, and went the other way. It seems like it finds mgapilib.dll okay, but then I get this error when running color2.exe in ...OpenFlight_API_4_2\bin\debug:
The application was unable to start correctly (0xc0150002). Click OK to close the application.
The interesting thing is, if I build a "release" version of color2, and copy it to bin\release, it seems to work! I wonder if it has something to do with the debug env, or the version of Visual Studio the API was compiled in vs. Visual Studio 2008 (which I use).
None of this makes any sense though. How could this be working for days, and then all of sudden not? :-(
Ok, now we're getting somewhere...
The interesting thing is, if I build a ââ¬Åreleaseââ¬Â version of color2, and copy it to bin\release, it seems to work! I wonder if it has something to do with the debug env, or the version of Visual Studio the API was compiled in vs. Visual Studio 2008 (which I use).
Actually version 4.2 of the OpenFlight API was compiled in VS 2005 (VC8) - yes the 5 and 8 are confusing.
The Debug problem you have is well understood. The OpenFlight API DLLs require a very specific version of the MSVCRT libraries. These are sometimes called "MSVCRT Restributables" which is a fancy name for the MSVCRT DLLs that apps / DLLs require. The OpenFlight API installer includes the "Release" versions of the VS2005 redistributables. This is why when you link the Release OpenFlight API DLLs, you have no problem. We are not allowed to redistribute the Debug versions of these.
You have to get these with MS Visual Studio. The version you need is listed in the OpenFlight API Reference. That section is repeated here for you:
Both of the VC8 versions of the OpenFlight API DLLs are dependent on VC80 CRT version 8.0.50727.4053. The OpenFlight API installer automatically installs the proper Microsoft Visual Studio 2005 (release) redistributable package if your computer does not already have it. The debug version of the CRT should be installed on your computer when you apply the proper patches/service packs to Visual Studio 2005.
So you have two choices:
1) Build your debug versions with API release DLLs (you can still debug your code but not OpenFlight API - which you really can't do meaningfully without the source code)
2) Go get the proper service pack for VS2005 (you can install this and then continue building VS2008, no problem)
None of this makes any sense though. How could this be working for days, and then all of sudden not? :-(
You are correct, I am sorry that I can't help there. Perhaps Windows Update did something to your computer?
Thanks so much! I just backed up the debug DLLs, and copied the release DLLs into the debug folder. Now it's working. Thanks so much for your help.
I continue to be perplexed by the fact that this was all working before, but I'm out of time messing with set up. Gotta code!
... Gotta code!
Don't we all!
Craig
My exe has been running great for a couple of days. I'm compiling fine and there have been no changes to my paths (e.g. the location of the OpenFlight API has not changed). All of a sudden it crashes immediately. If I comment out everything except the mgInit and mgExit calls, it crashes. If I comment those calls out the exe runs fine again.
I'm thinking through all of my debugging there may be some left over OF API processes running, or maybe some bad memory juju going on. So I shut everything down, and rebooted my machine. My exe still crashes! Are there any processes I should check for in Windows Task Manager, or any other methods for cleaning up left over OpenFlight stuff?
Edit: Also, I wrapped the mgInit/mgExit calls in an IF block. When I run the exe I don't even enter the IF block to make the mg calls. So, it's actually just the simple presence of the calls, no execution required, that makes the exe crash.
Edit 2: Also, I just tried to run the color2 sample exe in the bld sample solution, and even though I used to be able to run this example with no problem, now I get this: