beatle

I'm currently working on a replacement managed SimConnect library that will hopefully work under the Compact Framework when I'm done (that's the plan anyway :-> ) allowing for the creation of WinMo SimConnect addons (or possibly even WinCE based FS hardware?) - I just got the library working under Silverlight last night for the first time - WooHoo. Tim

Hey Pete (and all), No fixes to suggest right off the top of my head, but is it possible that the folks who are having problems with I/O errors might have something odd installed in their networking stack (ie some sort of debugging/monitoring driver, weird network card with older driver, etc). If only some folks are having it, and its related to the networking section of the code, seems likely something in the networking driver stack. In a networking system where clients connect to servers, if the server gets an error trying to talk to a client, there really isn't anyway for it to recover and rebuild the connection, since the clients are the ones that make the connections :-> The fact that FS doesn't crash and removes any menues that the add-on that got the error had created seems to me like its handling the error correctly. I would think this is the behavior you would want if a client suddenly stopped responding (because it was remote and the network went down or the external app faulted, etc). Tim http://beatlesblog.spaces.live.com

DLLMain is called by the OS DLL loader when the DLL is loaded, not by FSim. You might want to try adding some dummy code inside the module_init function and place a breakpoint in there and see if the debugger gets there, that will give you a better idea if FS is really loading your DLL correctly inside its process space. Haven't used C++ with the latest VStudio IDE, but the Use Managed Extensions OFF sounds right (Pete, the new IDE handles both managed and "normal" C++ in the same IDE now, so I imagine that option just chooses between them) - also the /D WIN32 and /D _WINDLL command line options seem to imply a standard Win32 PE DLL, so I think you are good there. Tim

You can't load a C# based DLL inside of Flight Sim, it has no knowledge of things Managed/CLR. That's why the FSUIPC example of a loadable module is only in C, because it has to be a standard PE format DLL, not a managed one, in order to load inside FS. The reason someone was able to do the same with Delphi is because it still generates standard PE format DLLs - you can basically use any langauge that generates standard PE format DLLs, heck back in FS95 & FS98 several of the standard FS modules were still written in assembler :-> Tim

Try placing an extern "C" in front of the ImportTable and Linkage definitions; ie: extern "C" DLLEXPORT MODULE_IMPORT ImportTable = { and extern "C" DLLEXPORT MODULE_LINKAGE Linkage = { As Pete says, C++ tends to mangle the exported names of stuff compared to straight C. If that doesn't work, you could move the C++ code to a seperate .CPP file and leave the straight C code required to interface to FS in a .C file. Also, I noticed you mentioned C# at the top of your post, make sure you are using Native C++ and not Managed C++, FS won't load a Managed C++ module. Tim

Cause if you use the DialogBox API call, you are creating a Modal dialog box, which basically sits in its own Message Processing Loop (also called a Message Pump) until the dialog is closed, thus depriving Flight Sim of any chance to process messages itself. You need to create a Modeless dialog box, but off the top of my head, I can't remember what the standard Win32 API calls are for that (check MSDN for Modeless Dialog Box), I haven't used the standard API calls to do dialog boxes in quite sometime (for my personal programming projects I use .NET 2.0 and, Unfortunately FlightSim uses MFC dialogs - over my strenuous objections about 10 years ago :-> - so for Work related stuff I'm still using MFC) Tim

Hey Pete, <<< Writing a module to work as part of FS is no easy task, and in VB it is even more difficult -- in fact until recently I would have said it was impossible, but I think someone has achieved it. >>> Butwhy would anyone want to :D (Apologies from a long-time VB bigot to any VB fans out there, just seen way too many "Ugly" apps written in VB :D ) If someone has managed it, they must have used at least some C code also, I don't think there would be anyway to duplicate the Import / Export tables the module system uses from VB (could be wrong though, haven't used VB much myself actually). Of course, writing modules is real easy when you have all the header files available (ducking and running really fast :D ), of course, having been the one that designed/implemented most of the FS95/FS98 module system helps also :D . Tim

Hey Pete, Long time no type. I'm bbaaaccckkk :-> (as in back on as a full time developer on the Flight Sim team again). How goes things over in sunny england these days? I'm telecommuting from my house in Fredericksburg, VA (so I get to avoid sunny weather in the pacific northwest most of the time :->). Type at ya later, Tim Gregson