Using FSUIPC.DLL directly

[_Jens_]

Hi,

I have A question about FSUIPC. If I want to write or read some variables to or from the FS2002 I can use FSUIPC. For communicating with the FS2002 I have to use the Functions FSUIPC_Open, FSUIPC_Close, FSUIPC_Read, FSUIPC_Write and FSUIPC_Process. All these Functions uses sendMessage. My question now is, if there is a possibility to communicate with the Functions of FSUIPC.dll directly. I give an example. If I want to get the verticalSpeed, I have call FSUIPC_READ with the OFFSET of verticalSpeed. Perhaps, there is a special Function in the FSUIPC.DLL like read_verticlaSpeed. If so, how can I get access to this function, so that I don't have to call FSUIPC_READ.

Thanks,

Jens

[Pete Dowson]

For communicating with the FS2002 I have to use the Functions FSUIPC_Open, FSUIPC_Close, FSUIPC_Read, FSUIPC_Write and FSUIPC_Process. All these Functions uses sendMessage.

No. Only FSUIPC_Process does the actrual Sendmessage. The Open function calls FSUIPC_Process as well, but that's only to verify the connection and obtain stuff like version numbers. The Read and Write functions are simple data format preparation to make it easier for programming. If you wanted to construct the data yourself you'd only use FSUIPC_Process.

My question now is, if there is a possibility to communicate with the Functions of FSUIPC.dll directly. I give an example. If I want to get the verticalSpeed, I have call FSUIPC_READ with the OFFSET of verticalSpeed. Perhaps, there is a special Function in the FSUIPC.DLL like read_verticlaSpeed. If so, how can I get access to this function, so that I don't have to call FSUIPC_READ.

I think you misunderstand the nature of separate processes. Think of each process in Windows as being a separate PC all to itself. Processes can communicate via messages or shared data files. No other way. FSUIPC uses both -- messages to ask it to do something, shared files (in memory, known as "memory mapped files") to exchange data. Other forms of inter-process communication such as the debugging aids to read and write a process memory and DDE use variations of the same basic method.

For you to call FSUIPC.DLL directly it would have to be loaded by your program and run in your process. In order to get information into or out of FS it would then have to use memory mapped data and messages to pass requests, just as the supplied library code does now. So the version of "FSUIPC.DLL" you would have in your program would effectively be just the code already provided for you but with macros or more layers to make the FSUIPC_Read and Process calls get single items of information. This would be very inefficient. It is best to build up the list of requests, whether read or write, and issue one Process call per cycle. If you time the cycles to approximate an FS frame rate, such as 20 times per second, then it works well.

Note that if such a library (DLL) were to be provided, despite its inefficiencies, it would be completely wrong to call it FSUIPC.DLL because it would be nothing like it. Almost none of the code in FSUIPC would be at all useful running in your process. It needs intimate connections to the data and procedures in Flight Sim, and those are only accessible in Flight Sim's process.

Additionally you should note that these "offsets" as such are mostly not offsets at all these days -- that's an illusion created by FSUIPC to maintain the interface as original designed for FS95 and FS98. You should think of the offsets as tokens for the variables rather than addresses or offsets from addresses. You could even equate names to each one to further this concept.

Finally, the techniques needed inside FSUIPC to get this information vary enormously. Yes, with some there may be a procedure for asking FS for the data, but that is rare and even when it is needed it is performed asynchronously with requests, synchronously with the FS update rate (frame rate). Many values are mapped into assorted data structures privately owned by individual C++ classes in the separate DLLs making up Flight Sim.

Regards,

Pete