Orbiter 2006-P1 and VC++ 2005

[jarmonik]

I have encountered a problem when building a DLL with MS Visual C++ 2005 for Orbiter 2006-P1. Looks like Orbiter can not load the Module in some computers. :compbash2: However, the problem doesn't appear on my computer with Orbiter 2006-P1.

Is there any special linker options those would cure the problem ?

There appears to be MS VC++ 2005 Redistributable package and MS VC++ 2005 (SP1) Redistributable package. Does it matter witch one is installed ?

Current Link Flags Are:
/OUT:".\Release/InterMFD.dll" /INCREMENTAL:NO /NOLOGO /DLL /MANIFEST /MANIFESTFILE:".\Release\InterMFD.dll.intermediate.manifest" /NODEFAULTLIB:"msvcirt.lib" /PDB:".\Release/InterMFD.pdb" /IMPLIB:".\Release/InterMFD.lib" /MACHINE:X86 /ERRORREPORTROMPT Orbiter.lib OrbiterSDK.lib Cowell2.lib AttitudeControl.lib user32.lib kernel32.lib gdi32.lib kernel32.lib


Current Compilation Flags Are:
/Od /Ob1 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "INTERMFD_EXPORTS" /D "_VC80_UPGRADE=0x0600" /D "_WINDLL" /D "_MBCS" /GF /FD /EHsc /MD /Gy /Fp".\Release/InterMFD.pch" /Fo".\Release/" /Fd".\Release/" /W3 /nologo /c /TP /errorReportrompt

 

[DaveS]

You need to install the VC++ 2005 Runtime files as the newer files that VC++ 2005 makes use of is not included by default in Windows XP or earlier Windows installations.

 

[jarmonik]

I can run the program fine in my computer but other users can't run it regardless what ever runtime libraries there are installed.

I am trying to solve the problem discussed in this thread http://orbiter-forum.com/showthread.php?t=2541

As far as I am a ware of Visual C++ 2005 build applications should run fine in Orbiter even if the Orbiter 2006 it-self is build with VC++ 6.0

I have MS Visual C++ 2005 SP1 Express.

 

[computerex]

Make sure you are statically linking. If you are using VC++ 2005 express edition, this won't work. But try this: Go to Project properties by right clicking on the project in the solution explorer, and clicking "Properties". Then collapse the C/C++ tree on the left, and click on "Code Generation". Make sure the "runtime library" is set to "Multi-threaded (M/T)". Then collapse the linker tree, and under "Input"->"Ignore Specific Library", enter: msvcirt.lib, msvcrt.lib

You can ask those users to check out your module with "Dependency Walker", it's a useful little utility that reveals dependencies.
http://www.dependencywalker.com/

 

[jarmonik]

Make sure you are statically linking. If you are using VC++ 2005 express edition, this won't work. But try this: Go to Project properties by right clicking on the project in the solution explorer, and clicking "Properties". Then collapse the C/C++ tree on the left, and click on "Code Generation". Make sure the "runtime library" is set to "Multi-threaded (M/T)". Then collapse the linker tree, and under "Input"->"Ignore Specific Library", enter: msvcirt.lib, msvcrt.lib

You can ask those users to check out your module with "Dependency Walker", it's a useful little utility that reveals dependencies.
http://www.dependencywalker.com/

It works, :woohoo: Thank you a lot.

 

[jarmonik]

It looks like that an application build with Visual C++ 2005 (SP1) do require a runtime library msvcr80.dll version 8.0.50727.762 in order to run. Is it possible to make the application to accept older versions of the same library like 8.0.50727.42 ?

If the prefered library 8.0.50727.762 is not present loading of the module will fail without any error messages. Based on the problems with recent release of IMFD I woud say that 8.0.50727.762 is not very common.

In order to avoid dependency problems it might be good idea to re-distribute the runtime libraries with Orbiter in a future. I suppose that should be possible.

EDIT: There is an option to choose between incremental and non-incremental linking does this have any effect in compatibility issues ?

 

[Director]

dll Hell

It looks like that an application build with Visual C++ 2005 (SP1) do require a runtime library msvcr80.dll version 8.0.50727.762 in order to run. Is it possible to make the application to accept older versions of the same library like 8.0.50727.42 ?

If the preferred library 8.0.50727.762 is not present loading of the module will fail without any error messages. Based on the problems with recent release of IMFD I would say that 8.0.50727.762 is not very common.

In order to avoid dependency problems it might be good idea to re-distribute the runtime libraries with Orbiter in a future. I suppose that should be possible.

EDIT: There is an option to choose between incremental and non-incremental linking does this have any effect in compatibility issues ?

I just ran across this problem myself, which I do not feel is adequately addressed in this thread, and with a little bit of research I discovered that it turns out this is a HUGE problem in the Microsoft VC+ community.

http://en.wikipedia.org/wiki/DLL_hell

What, if anything, is anybody doing about this problem wrt Orbiter and any new releases of Orbiter? This is a problem that doesn't seem to be going away, just seems to keep coming back, it wasn't adequately addressed in the old forum, and it doesn't seem to be adequately addressed here as well.

Just wondering. This has caused me more headaches than you can imagine.

 

[jarmonik]

It looks like I can not run the programs I have build anymore. Just a few days ago I started to receive error message "This application failed to start because MSVCR80D.dll was not found. Re-installing the application may fix the problem". I founded a way around this error by linking agains the "release" library not the "debug" library.
:compbash:
Just a moment ago the "release" build stopped working and started to report "This application failed to start because MSVCR80.dll was not found. Re-installing the application may fix the problem" and I am out of options. MSVC2005 is really a pain in the ass. Does MSVC2008 Express work any better ?

Of course, I could downgrade back to VC 6.0 but it is unsure that does the Orbiter support 6.0 in a future.


-----Posted Added-----


If I check the application with Dependency Walker everyting seems to be in place. No missing files or dependencies.

 

[mjessick]

This discusses some of the concepts, and shows which libraries are neeed. (It is probably not the best explanation for your precise problem.) This is for VC 2008. There is a link to 2005 information.

http://msdn.microsoft.com/en-us/library/ms235624.aspx

Options AFAIK:
1. You can put the needed DLL's into the "application" folder (Orbiters directory)
This is quick and dirty.

2. You can install the redistributable DLLs (for example, as part of the .NET framework). See the links for information on what you would do to "deploy" your application. Your users need to do something similar. If you use an installer, you can include this as part of the installation.


I was just fighting with a similar thing this morning. I had dumped the libraries into the Orbiter folder so I could just go on to what I was wanting to have fun with (which was NOT learning how to deploy Windows apps . Unfortunately, unless you properly include a "Manifest" in your DLL, to tell the system which libraries you should use, it won't load the MSVCRT etc. DLLs from the application folder. Manifests are now required to do this. As far as I could tell, the manifest was being embedded. My problem turned out to be a need to use the linker option to "ignore" the MSVCRT.lib release library (for my debug configuration). Not doing that was screwing up the manifest or the loading or something. There was a warning I hadn't noticed. So check all your warnings

 

[jarmonik]

1. You can put the needed DLL's into the "application" folder (Orbiters directory) This is quick and dirty.

This will result an error "This is unsupported way to load DLLs...."

Unfortunately, unless you properly include a "Manifest" in your DLL, to tell the system which libraries you should use, it won't load the MSVCRT etc

That is true but in my case the problem is that the application knows witch libraries it need to load but it just can't find them. VC++ Libraries are located in

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_5490cd9f

but the application don't understand to load them from there.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

-----Posted Added-----


I think I founded the problem. The manifest was not correctly embed into the output for some reason. After adding following line into additional options it started to work.

/outputresource:".\Debug\IPlan.dll;#2"

 

[eveningsky339]

Does Visual Studio 2008 have this problem as well? I personally prefer 2005, but if this problem is addressed in the newer version, I may use 2008 instead.

 

[martins]

What is the best way to address this problem in the next Orbiter version (which btw. will be compiled with VS2005)? Would it help if I pack the VS redistributable runtime libraries into the Orbiter folder, and ask every addon developer to use these libraries, instead of the installed system libraries?

The problem I can see with this approach is that it may become more difficult in the future to upgrade to a new compiler, because a new set of runtime libraries may require every single addon to be recompiled.

I guess the last resort would be to link everything static, which seems a bit wasteful, in particular if there are lots of active addons, each with their own private copy of the runtime code.

 

[Wraith]

I guess the last resort would be to link everything static, which seems a bit wasteful, in particular if there are lots of active addons, each with their own private copy of the runtime code.

Quite the contrary! There's a "thing" in Windows called WinSxS. Basically it maintains various versions of runtime libraries used by applications and makes sure the application gets the correct CRT DLL version it was linked against. The application specifies that with a manifest file. So see, Windows already undermines the notion of "shared library", by maintaining multiple versions of the CRT.

The only benefit of WinSxS is that theoretically Microsoft may issue bug fixes and security updates to every CRT version out there since VS2005 (and users of your program would automatically receive those updates). However, one shouldn't forget that such an update also may possibly break your program! Unlike Service Packs, regular updates received via Windows Update are not extensively tested for compatibility with existing software.

When you link the application against static CRT its size typically increases by 10-1000 KB (~300 on average), depending on how much of the CRT is actually used. I don't think that size is an issue to anyone. No, not today.

To sum up: If you link Orbiter core against static CRT, you'll get rid of those idiotic manifests and stupid dependencies at the expense of slightly increased exe size and inability to receive any updates to that specific CRT version.

Note: this decision won't affect any plugin developers at all. Since any plugin is a DLL, and since the DLL is an executable module (*), it must refer to its own CRT, either shared or static, but this is up to plugin developer to decide. And I totally recommend that plugin developers use static linking too.

------------
(*) -- Thus, the DLL may not refer to unresolved external symbols, including CRT. That's unlike a static library, which is not an executable.

 

[mjessick]

Does VS 2005 express compile resources? VS 2008 express is supposed to be able to recompile resources like cockpit bitmaps, but one of the older express versions (maybe 2003?) didn't do that. Hopefully VS 2005 projects for the example plugin dlls will be included with the SDK next release.

 

[tblaxland]

To sum up: If you link Orbiter core against static CRT, you'll get rid of those idiotic manifests and stupid dependencies at the expense of slightly increased exe size and inability to receive any updates to that specific CRT version.

Note: this decision won't affect any plugin developers at all. Since any plugin is a DLL, and since the DLL is an executable module (*), it must refer to its own CRT, either shared or static, but this is up to plugin developer to decide. And I totally recommend that plugin developers use static linking too.

I agree with your recommendations, however, VC++ 2005 Express will not allow you to statically link the CRT. I believe this is the same with VC++ 2008 Express.

Does VS 2005 express compile resources? VS 2008 express is supposed to be able to recompile resources like cockpit bitmaps, but one of the older express versions (maybe 2003?) didn't do that. Hopefully VS 2005 projects for the example plugin dlls will be included with the SDK next release.

VC++ 2005 will compile resources but it does not have a resource editor, which can be annoying. Resources can, of course, be edited outside of the IDE. This is the same for VC++ 2008 Express, IIRC.

 

[martins]

Does VS 2005 express compile resources? VS 2008 express is supposed to be able to recompile resources like cockpit bitmaps, but one of the older express versions (maybe 2003?) didn't do that. Hopefully VS 2005 projects for the example plugin dlls will be included with the SDK next release.

VS2005 projects for the sample codes will be provided. However I don't know about VS2005 express. I am using the full version. Are the project files for the full/express versions compatible?

 

[DaveS]

VS2005 projects for the sample codes will be provided. However I don't know about VS2005 express. I am using the full version. Are the project files for the full/express versions compatible?

Pretty much. I'm using VC++ 2008 Express and haven't noted any issues.

 

[computerex]

VC++ 2008 express edition allows static linking of the CRT, and it allows the conversion of older projects to the VC++ 2008 project file format. It allows you to compile resources and comes with the standard headers/libraries which saves you the hassle of installing the Platform SDK and manually editing the project's settings to add the Platform SDK's include/lib directories everytime you create a new project. It's an excellent environment for Orbiter add-on development, in fact the only thing it is missing is a resource editor. (VC++ 2005 express edition doesn't come with a resource editor either)

 

[mjessick]

I found it time consuming to convert (essentially) VC6 projects because mine were organized badly for modern use. I had used a structure designed years ago with multiple libraries for major sub systems (that structure was useful back 10 years ago when full builds took an hour ) but not so much anymore with much faster computers. Now it just causes more work for no real gain.

When I receive all Martin et. al.'s hard work on the demo projects I will likely just scrap all that and just toss all the source into different VC 2008 "filters" to organize it, add the extra include directories and be done with it. (Or I can modify all the #includes adding a subdirectory to get rid of that extra work too.) Editing a bunch of superfluous static library linking folders for debug and release builds is a useless pain.

Starting from examples already working (for all the compiler and linker options) will no doubt make it much easier for beginners than finding and following the wiki pages helping set up the compiler.

It is obviously more efficient for the whole community to have this done once centrally and consistently. I appreciate all the work involved converting a large and aged (8 year or more?) project through 10 (or even 7) years of compiler upgrades. It will be very helpful and and a time saver to many for the future!

 

[jarmonik]

What is the best way to address this problem in the next Orbiter version (which btw. will be compiled with VS2005)? Would it help if I pack the VS redistributable runtime libraries into the Orbiter folder, and ask every addon developer to use these libraries, instead of the installed system libraries?

VS2005 doesn't allow to link into a runtime libraries this way. At least I have not succeed. It seems that it must be done through the manifests.

Unfortunately using VS2005 is not as simple as using VC 6.0 it's not enough that someone knows how to write a code. Now it's also important to know many other things from the build environment like how to plug the manifests in the DLL and what libraries need to be ignored in order to build using correct libraries.

It would be good idea to have a web page that would describe how to avoid and fix most common pitfalls when using VS2005. I suppose there are allready this kind of pages so maybe we just need to find a link.

Also including a project templates within the SDK woud be good idea.