Sign in to follow this  
Guest petemaxkoller

Simconnect dont work unser Vista64?

Recommended Posts

Hi Please see my other post about simconnect does not initialize under Vista64.As I have a dualboot system also with Win-XP-Home, so I tried it out on this system and simconnect is initializing without problem when starting FS X.So it must be a Vista64 problem!!Anyone had made the same experience?Thanks Peter

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

While I do not support Vista 64 for the addon I'm selling and this is listed clearly on the website and in the description at the shop... a Vista 64 user bought it and found out... it works. And I do use SimConnect.But overall, I've seen several SC issues for some of my customers and recently I ran in to one myself. This one seemed to be related to an uninstall not working properly after which the following install did not fully re-install simconnect.For me it helped to delete all the SimConnect.dll files in the %windir%winsxs folder and then run all the SimConnect.msi files, that is: the RTM version, the SP1 version and the SP2 version.Daniel

Share this post


Link to post
Share on other sites

If you are using managed code, you need to change the build configuration to build X86 native instead of the default "Any CPU", as the "Any CPU" version will expect there to be a 64-bit version of the SimConnect.dll file (the unmanaged one that the managed lib is a wrapper around). I believe there are instructions about how to do this on www.fsinsider.com .If you're app is a native (ie not-managed) app, again, make sure you have Visual Studio setup to build a 32-bit native app instead of a 64-bit native app.For managed apps, eventually we hope to have a fully managed SimConnect client that doesn't just wrap the existing non-managed DLLs APIs (in fact, the current managed wrapper was an "extra" that wasn't originally planned for the FSX SDK, but one of our new devs did it while "learning" the software and we decided to include it). I think I may have "signed up" to do this at some point in the near future :-> , as part of on-going ESP related work, but its not currently scheduled or anything, so don't be looking for it tomorrow (I mean I'm good, but not that good :-> ). That should allow managed clients to then build using the "Any CPU" option and hopefully also allow using it on Compact Framework devices (ie PDAs and Smart Phones).

Share this post


Link to post
Share on other sites

TimThank you for your explanation, but I must say (sorry) that I did not understand what I have to do to get it work (simconnect to be loaded during the loading of FSX on my Vista64 PC to connect later on to remote client application on a Win-XP client).Do I have to reinstall SDK 1a in a special way on my Vista64 PC?Thanks for helping and sorry.Peter / LSZH / Switzerland

Share this post


Link to post
Share on other sites

Sorry, I misread your original problem. I thought it was a SimConnect based addon you were having problems launching, not FSX itself.About the only thing I can think of off the top of my head would be firewall/AV type issues maybe.I can say it should work just fine, I have one of my dev machines running Vista64, and its been running a SimConnect based session with my laptop (Vista32) and another desktop (Vista32 Enterprise) most of the day today with no problems.

Share this post


Link to post
Share on other sites

Couple of notes from my experience:I have no problems on Vista 64 from the development or client end. I am running as an administrator so you may have to relax some security settings from the default.Vista 64 is very tight on security, the tightest yet from MS. It enforces features differently from Vista 32 or even Windows 2003 server for that matter. My first act was to relax security quite a bit (a risk I'm incurring) just so I could run my usual software without being prompted every dang minute about a security risk.Drivers will not load unless they are signed (there was a boot switch in the RC removed in RTM, now this can only happen from the F8 menu at bootup, a total pain), and code signing DLLs is virtually mandatory for FSX module files (.dlls). This can be done easily with the Windows SDK tools using a self-signed cert. The port used by SimConnect must be unblocked from the windows firewall dialog. Other than that, check the the usual configuration file issues with simconnect proper, especially if you want to run clients locally and remotely concurrently. It may help to run Simconnect in console mode with verbose debug output turned on (see simconnect.ini in the SDK docs), as it will tell you what Simconnect is/is not doing.A note on managed code since I just spent two weeks wrestling with this and documentation is, shall we say, all over the place and not very clear.You will be running the 64 bit version of the .NET layer on Vista 64 - it runs 32 bit just fine. However, you also get a new choice in that you can target either 32 (x86) or IA64 (WOW64). The delivered SimConnect.DLL is a 32 bit DLL, as is the .LIB file, so you will need to compile everything for 32 bit. In practical terms, you must set your project build to 32 bit for native DLLs (FSX modules in c++ for example), and for the .NET builds, set the code to X86 only (the default is "Any CPU". The other choice is "WOW64". The "Any CPU" setting will target whatever O/S platform you're on, so WOW64 if your O/S is 64 bit, and X86 on Vista 32 or XP 32. There is no way to set this at the solution level, so you must individually set the target build for each project in the configuration manager. Again, set to "x86" for .NET projects, and "win32" for native (c++) projects.Another loading problem are the runtime libraries. I recommend you use static libraries for native code to avoid issues on Vista clients. It makes your native code a bit bloated, but your customers won't have to deal with missing or mismatched CRT or MFC libraries.Curiously, you will not get a compile time error if you mix and match .NET modules unless you have a direct DLLImport statement somewhere. You will get a runtime loader "unknown initialization error" if any dependency/reference in the load tree is platform mismatched. That includes native dll dependencies (such as the simconnect.dll or the managed equivalent, since it uses the native 32 bit simconnect.dll internally.In VS2008, you can also set which version of the framework to what you need. Note that even if you target for .NET 3.5, the actual version of the CLR loaded is 2.x, the subsequent functionality in 3.0 and 3.5 are in DLLs loaded by 2.x.Hope this helps,Etienne

Share this post


Link to post
Share on other sites

I'm also seeing Simconnect issues with Vista 64. This is on a new system with fresh installs of FSX, SP1, and SP2. My GoFlight units are also not working correctly, or I should say the GFConfig software. GF recommended I reinstall Simconnect.It that would help, how does one go about re-installing Simconnect for FSX/SP1/SP2? I'm told its on one of the DVDs.Richard

Share this post


Link to post
Share on other sites

You should install the SDK from the DVD of the Deluxe version, then update it to SDK SP2 from the fsinsider.com site or if you have acceleration to the SDK that's on the Acceleration DVD (the sdk.msi, not the one in SP1a)When this is done, you will have something like:C:Program FilesMicrosoft GamesMicrosoft Flight Simulator X SDKSDKCore Utilities KitSimConnect SDKThere you will find a 'lib' folder, which contains a SimConnect.msi file, executing this will install SimConnect SP2.There will also be a 'LegacyInterfaces' folder, containing a FSX-RTM and FSX-SP1 folder, each containing a SimConnect.msi, which will install the specific simconnect versions when executed.Installing like this should also add the SimConnect installs to the Add/Remove programs interface or it's Vista familiar.Daniel

Share this post


Link to post
Share on other sites

A fellow user in the FSX forum recommended I disable ddl.xml and exe.dll. I already had exe.dll (GoFlight) disabled. Once I launched with dll.xml disabled, my troubles disappeared. There were three items in the dll.xml file, three pertaining to the SDK and FSUIPC. I uninstalled and reinstalled FSUIPC. The problem for me appears to be fixed, but I have a lot of FSUIPC reconfiguring to do. Thanks for the reply. If the issue returns, I'll try what your have written.Regards,Richard

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this