VC 2008 vs VC2005

[SkippyBing]

I've been adapting a few of the examples to write data capture program for test flying and ship location.
I've used Visual Studio Express 2008, however when I sent them to some other people to try out they didn't work, I'm guessing because they don't have the run time libraries. I've spent the last hour or so trying to get the same routines to compile in Visual Studio 2005 as I understand the run time libraries are included with FSX anyway. Unfortunately I keep getting a long list of errors with simconnect.h, almost as if I hadn't set up the paths to the lib and inc directories except I have! Does anyone know why this is happening or have a link to a step by step guide to setting Visual Studio 2005 up for simconnect development?
I'm guessing the other option is to stick with VS '08 as it's working, but I don't want to rely on the end user having to download the run time libraries when I go beyond the beta testing stage.

 

[rhumbaflappy]

Actually, Visual Studio 2005 C++ also has runtime libraries... your testers just happen to have them already installed if the apps work in that environment.

The idea of downloading runtimes seems to take away from the idea of having machine language code. ( Might as well write it in .NET )

Borland C++ or Delphi can write actual self-reliant executables. I'm not sure if there is a modern Visual Studio solution.

Maybe somebody more familiar with C++ could tell you.

The VS2005 runtime installers are 1.6 MB, and the VS2008 are 1.7 MB... so including the runtime installer with the program ( which is encouraged by Microsoft ) isn't a huge load. And as a bonus, the enduser will be able to run all VS C++ 2008 programs in the future.

Dick

 

[n4gix]

If you simply include all the libraries and .h files the project requires, you can avoid the "run time" distribution problem entirely...

 

[SkippyBing]

Actually, Visual Studio 2005 C++ also has runtime libraries... your testers just happen to have them already installed if the apps work in that environment.

As I understand it FSX comes with the 2005 run time libraries so anyone who has FSX will have them which reduces the potential points of failure. The impression I get from various forums is that a lot of potential users review what an add-on is going to install and then veto anything they don't think is necessary, from a support point of view I'd like to make the install as idiot proof as necessary!
Bill, this might be a bit of a C++ 101 question, but how do I make sure I include all the libraries and .h files the project uses? If you know a good tutorial that'd be great, unfortunately last time I did any real programming was in DOS so it's quite a steep learning curve on the actual compiling!

 

[rhumbaflappy]

Here's something I'm finding

"Even native executables need the Microsoft runtime library dll if you dynamically link them to the runtime. This is the default in project properties, C++, Code Generation, Runtime Library = Multi-Threaded DLL.

You can avoid this by choosing Multi-threaded, which would statically link in the library code."

I checked to see if the VS2008 C++ express version has this option, and it does, though it defaults as Multi-Threaded DLL, and needs to be changed to simply Multi-Threaded.

Dependancy Walker should verify your app doesn't require the runtimes.

I made a small app, and indeed the MSVCR90.dll runtimes are NOT needed, when the simply Multi-Threaded is selected.

Thanks Bill. I have to take back all the nasty things I said about VS C++ apps.



And SkippyBing, this should solve your problem. A note however... the static linking will increase the size of your executable.

Dick

 

[SkippyBing]

Dick,

Thanks, I'll play around with that this evening.

 

[rhumbaflappy]

As I understand it, the VS C++ runtimes are about 10Mb installed. Most apps would only use a tiny fraction of these routines.

My small app just makes a window with a couple of menu items and the standard winow buttons. The Multi-threaded DLL version was 57,856 bytes. The simple Multi-threaded was increased to 91,136 bytes.

I think most application writers use the runtimes, and include the small runtime installer file with the packaging. But I do understand your point, as using a static include guarantees it will work without the enduser needing anything more.

Dick

 

[ziporama]

In your visual studio installation, you will find a redist folder with the distribution runtime of the VC libraries, which come in two flavors, one for the C Runtime (MSVCRT) and the Microsoft Foundation Classes (includes MFC+ATL).

End users can download the runtime from MSDN as well for free.

You may not distribute the debug versions (the names include a "D" in the file name). There is a .txt file in the redist folder that tells you what you can and cannot distribute, and that information is also online and in the help.

For VC2005, you need the 80 release, for VC2008, you need 90. FSX was compiled against VC2005 and comes with the 80 release when you install it.

These days, the redistribution libraries install in the side by side folder, and multiple versions co-exist. The dependency manifest in your exe or dll will include the reference to the proper library. The idea is for there to be only one copy of the specific runtime library on the computer to avoid "dll he11", noting that you may have multiple versions of a redist depending which service pack of the C++ compiler used. The manifest will refer to the correct version. You can of course statically link the library to your code, but the shared method is preferred.

If you run the tool depedencywalker (google it), it will load your dll or exe and tell you which runtime libraries you need, and check for their dependencies as well. In some cases, your program won't load because it has a dependency that is other than the runtime library so it's a good tool to use before you package your code for distribution.

Hope this helps,

Etienne

 

[rhumbaflappy]

Hi all.

That's very good information.

In the VS C++ Express 2008, you would find the VS runtimes here here:

C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT

And these files are only about 1.3 MB... I appear to have been mislead about the size of the runtimes... perhaps their SxS system installation is 10 MB.

These files would have to be within the same folder as your app, as I understand it, if they are not already in the SxS folder by the official runtime installer.

So there we have 3 different ways to deal with the runtimes.

1) Package the runtime installer downloaded from Microsoft. This will setup the SxS folder and runtimes and set your endusr's system to run all VS 2008 C++ apps in the future ( might be 10MB for their system ).

2) Include the actual runtime DLLs you used to create the app. These will need to be in the app's folder and should superceed any runtimes in the SxS folder. This is what Etienne wrote about. This adds a little more than 1 MB, and 3? files.

3) Make a static compilation of the app as Bill suggested. Then there is only one file to worry about ( the app itself ), and your endusers can be blissfully unaware of not having the VS 2008 runtimes missing on their system.

I'm biased towards 3. I don't like the use of SxS or the registry or unneeded CFG or INI files or runtimes...

Oddly, I've been programming in C#, and that uses a lot of extras I don't like. But I don't have to use installers, registry, etc. If the endusers' system is properly updated for Windows, then they'd have the right setup automatically.

Dick

 

[Geoff_D]

I refer you to the UPDATE section on MS FS FsInsider website.

Support Alert: Updated Visual Studio Redistributable

2/23/2007



Some add-on content built for Flight Simulator X includes executable code built with Microsoft's premier development platform, Visual Studio. If you're using such an add-on, there is an issue with an update to Visual Studio that may prevent the add-on from loading properly.

Visual Studio 2005 Service Pack 1 has been released, and includes updated "redistributable" components. These are files required at runtime by applications built using Visual Studio, and are not backwards compatible in most circumstances. In other words, content created for Flight Simulator X using Visual Studio 2005 SP1 will require the updated redistributable components or it will fail to load. It is the responsibility of the add-on developers to include all components required for their for their content. This issue will not be affected by the forthcoming release of Service Pack 1 for Flight Simulator X. If and when the redistributable components are made available for download separately, we will make them available here.

So, typically, to run most addons that were even developed with VS2005, the latest C++ VS2005 distributable need to be installed on a users machine, in addition to the older ones, included with FSX.

Anyone, using any addons for FSX, would be strongly advised to install both the lastest VS2005, and VS2008 C++ Distributables, from the most reliable source -- ie The Microsoft update website.

-----------------------------
Then we have the whole .net version issue with C# addons, and associated issues with Simconnect, and simconnect versions

One day, maybe, someone will write and distribute a Diagnostic Tool, that users can run, to report excatly waht is installed, what needs to be installed, and what is installed and does not work correctly.
Just because the correct versions of .net and simconnect are installed, does not necessarily mean that a C# program will run correctly. There are cases where .net is either corrupted, or was installed after simconnect, and simconnet therefore did not install correctly for .net.

Funn stuff, and what developer's nightmares are made of ...

Geoff_D

 

[BASys]

Hi Folks

We need a definitive way of guaranteeing users can download all the latest vcredist versions,
rather than just a specific recent vcredist version.

AIUI -
Microsoft Update does not automatically pull down the latest VC Redists.

e.g.
There's an ongoing FSX CTD issue with the Tabbed Dialog activeX control
affecting users having the VS2005 MFC80.dll versions less than 3079 installed.

Affects VC Redist versions 870 through 3078.

See FSDev - Wiki - Missions - Go To Briefing - CTD (FSX/A)


HTH
ATB
Paul

 

[rhumbaflappy]

Hi all.

If you compile statically as Bill suggested ( option #3 above ) then you can guarantee success of your executable for the enduser, without worrying about runtimes.

Dick

 

[ziporama]

I'm a bit concerned about memory use for FSX in-process dlls on 32 bit boxes. The reason I'm worried is that many fans already get in OOM territory without my stuff loaded, and I want to do as much as possible to reduce the footprint. Granted, it won't matter as much on a 64 bit system, yet still does given that FSX (or FS9) are still stuck in the 2Gb maximum addressable space as 32 bit apps.

MS does recommend the use of side by side shared libraries, it's not much, but it helps, and it usually works (except for simconnect I suppose ).

My current solution for the DLL nightmare is to simply parse the side by side folder and look for the right entries - it's easier to do in a setup program I suppose than at runtime inside the sim

For simconnect, I find that if I use default manifests and let the O/S decide for me, I can easily get in trouble. One also assumes that the redist installer does its job correctly, and it's not hard to have that auto-run with an installer - nothing will be installed unless a new version needs to be setup.

This said, FSX doesn't do much checking of its own it seems as it's more than happy to crash with that invalid MFC80.DLL in missions, so we shouldn't feel so bad

Then again, no-one told me that I wasn't supposed to remove VC2005 which apparently is at the root of many evils in both the MFC 8.0 and .NET 2.0 realm. It took me a week to recover, and obviously there are still traces of that disaster on my box that rears its ugly head frequently.

Etienne

 

[BASys]

Hi FOlks

This said, FSX doesn't do much checking of its own it seems
as it's more than happy to crash with that invalid MFC80.DLL in missions,
so we shouldn't feel so bad

Etienne -
Just to clarify,
it's not the missions that crash,
it's the IE browser displaying the Briefing pages.

HTH
ATB
Paul

 

[ziporama]

Thanks for that detail

 

[rhumbaflappy]

It's the most recent update to the runtimes that cause the crash. They exist in this folder:

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.1833_x-ww_2fd6f5db

727.1833 is the evil version number.

It's an update of VS C++ runtimes that is loaded by the VS2008 SP1 update! So even if you get rid of VS2005, you'll still have the problem that some VS2005 programs will not run right. Yes... the runtimes for VS2008 SP1 update VS2005 as well.

To get back my missions, I did a bad thing:


++++++++++++++++++++++++++++++++++++++++++
I went to:

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.1833_x-ww_2fd6f5db

and replaced all 4 files with the older versions from:

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_3bf8fa05

...now everything works fine.

I know we're not supposed to do this, but there is no alternative if we want
both missions and VC++ express 2008.

I saved the original files into:

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.1833_x-ww_2fd6f5db\Originals

Mission briefings are now uneventful, but who knows what I messed up now.
++++++++++++++++++++++++++++++++++++++++++

The manifests and policies are also updated by this, so to remove the files from that folder is not an option. So the problem is using using VS2005, but VS2008 caused the problem.

There still hasn't been an redistributable update for SP1 that fixes this.

+++++++++++++++++++++++++++++++++++++++++

Being curious, I used Paul's suggestion and used "For computers that do not have Visual Studio 2005 installed " as he stated in the WIKI. The other URL for VS 2005 developers gives you a number to call... not a good option.

I reset my WinSxS files back to the originals and tested... FSX crashed on mission briefing.

Under the downloads tab, using the EN english x86 version, I downloaded and then installed.

I checked the WinSxS folder, and the new folders are present. FSX no longer crashes.

With this I can verify Paul's information is right, and I would suggest using this hotfix, rather than messing with the WinSxS files.


Dick

 

[BASys]

HiFolks

It's the most recent update to the runtimes that cause the crash.

Hi Dick
v.1833 was distributed with VS2008 Express.
Issue exists with any version from v.870 onwards to v.3078.

AIUI - only from reading elsewhere.
Issue was -
- Prior to v.870 used non-standard indexing of tabs.
- v.870 rationalised indexing of tabs, but without backwards compatibility.

v.3079 and onwards supports both -
- the original tab indexing
- the corrected tab indexing
i.e. its a dual compatibility version.

With this I can verify Paul's information is right,
and I would suggest using this hotfix, rather than messing with the WinSxS files.

As you konw, I've been there.
Its painful.

EDIT

The other URL for VS 2005 developers gives you a number to call... not a good option.

I think I've seen a direct link to update somewhere.
I'll include it in the wiki, once I relocate it.


HTH
ATB
Paul

 

[jimkeir]

Hi,

I'm a little puzzled at the efforts people are going to

I've removed VS2005 and upgraded to 2008 without any issues whatsoever. I also use both runtime and linktime linking against the standard C libraries, MFC and SimConnect without any issues - obviously using SxS in the way that Bill intended and not trying to parse the structure myself. Chances are you'll have trouble on Win7 if you do that, the behind-the-scenes structure is different there IIRC.

I have to say I don't believe in static linking most of the time. Say you'd statically linked against a version of the standard libraries which had a bug - you'd need to rebuild and redistribute your app to get any fix. You also end up with reduced memory space as someone pointed out, and more diskspace taken up. I've used it from time to time on personal tools I want to run from USB stick on any PC without having to install anything, but not other than that.

I don't get any mis-linked stuff at all, at least as far as I've heard. That's what SxS is for, and although I hate losing the 17Gb of diskspace that it currently takes up, the mechanism does seem to work. What exact problems are people having?

Cheers,
Jim

 

[rhumbaflappy]

Hi Jim.

The problem with Mission Briefing broken in FSX is caused by the WinSxS, as the VS2008 SP1 install adds a buggy MFC80 dll.

Removing VS2005 makes no difference, the VS2008 SP1 download loads the bug to the VS2005 runtimes. So using an app that requires the VS2008 SP1 runtimes breaks parts of VS2005 apps, including FSX.

Paul points out the fix, but Microsoft is a bit lazy in publicizing the fix for this.. Paul does their job for them in the Wiki article he mentions above.

Skippybing has written an app in VS2008 and some of his endusers cannot get it to work... they are missing the MFC90 runtimes. If they download the VS2008 SP1 runtimes, they will break their Mission Briefing, and the sim will crash, as can some other VS2005 apps.

Some endusers are also loath to add the runtimes to their systems... they just want the app to run right now, without a lot of messing about.

This forces Skippybing to include the proper VS2008 runtimes in the same folder as the app as part of an installed package, or he can build a static app, as Bill suggested, which is the most idiot-proof way to help the enduser. And yes, the app designer would have to issue a new app if the runtimes used are buggy... but that is actually what most responsible app designers would do.

Waiting for MS to deliver a Windows update that includes the fix to the WinSxS doesn't work. The VS2008 SP1 bug has been around since August 2008, and they haven't fixed it yet. I downloaded the VS2008 SP1 runtimes yesterday, and they still have the poisoned VS2005 runtimes.

And even if they make a Windows Update fix ( the right way to solve this mess ), that assumes the endusers keep their operating system updated... which I doubt happens in the real world. Why new VS2005 and 2008 updates are not included with the monthly windows security fixes is beyond me.

So as counter-intuitive as this is, guaranteeing the right runtimes is now a problem... one introduced by Microsoft. WinSxS fails because of the lack of effort by Microsoft to get the bugs removed that they introduced. WinSxS would only work if MS followed through by scanning endusers systems and updating the installed WinSxS as part of the Windows Update process. Apparently they aren't doing this, or doing this right.

Back to Skippybing's problem, I would say the best couse of action is as Bill suggested, and make it a static app. If the runtimes are bugfrre when statically included, they will be that way forever.

If Windows7 doesn't allow the app to work, then a new version could be made for that OS. But I would think there would be backward compatibility for VS2008 apps.

Dick