Dumb questions on how the FSUIPC interface actually works

[scruffyduck]

OK apologies before I start on this one - if I have missed the obvious place that it is documented in then just point me If it is in the c++ documentation for fsuipc then I don't have it here in Florida and I can look at it when I get back to the UK as I only brought the Visual Basic with me. I have looked in the programmers guide which is great for identifying the offsets etc but the urls shown for further info seem to be dead.

I am trying to get my feeble mind around how the interface works. I understand C++ a little, Visual Basic a lot, but I use another flavor of Basic (REALBasic). I have converted the Visual Basic program into my version and have a working interface so that I can read and write data to and from FS using FSUIPC. I am not at all sure how it works though. I understand the concept of creating a filemapping object pointing at memory (I think) and that I can make read and write requests which I then process using the process routine (which uses windows messaging?). However somewhere in the middle of all this the miracle happens and that I have not gotten to the bottom of yet. I can see that the read request sets up a header and space after it to hold the returned data. A write request sets up a write header and the data to be sent. The process routine then executes the read and write and the read data ends up in the memory after the read request.

At the moment the class I have for FSUIPC exposes all it's methods and properties as public. What I am trying to do is firstly understand at a more pseudocode level how things happen.

Any pointers (no pun intended :wink: ) much appreciated

[Pete Dowson]

I have looked in the programmers guide which is great for identifying the offsets etc but the urls shown for further info seem to be dead.

Are there URLs for further info? I don't recall those. Let me know so I can either delete them or update them.

I am trying to get my feeble mind around how the interface works.However somewhere in the middle of all this the miracle happens and that I have not gotten to the bottom of yet.

In order to transfer data between two processes, there are a limited number of choices. Don't forget that separate processes run in separate virtual machines, with their own virtual memories. They cannot see each other directly.

The choices include the obvious one -- writing a file to disk for the other to read -- and also "pipes", which is a sort of serial link managed by Windows, and DDE (Direct Data Exchange) which was favourite in Windows 3.1 days but I think is rather inefficient (though with the right stuff installed does have the advantage of working over Networks, nowadays, I believe).

The method used by FSUIPC is actually one also used by debugging API facilities to read and write process memory. It is memory-mapped files.

All that happens is that the client program creates a memory-mapped file, with a unique name generated from its process ID and a few other things that FSUIPC can check. Since it cannot actually TELL FSUIPC this name (it cannot place the string in shared memory until the memory is shared --- classic chicken and egg dilemma), it registers the string with Windows as an Atom name. Atoms are guaranteed unique in the system. Windows provides an ID number for the Atom, which the Client can pass over to FSUIPC in a Message.

This allows FSUIPC to obtain the memory-mapped filename, by asking Windows for the string corresponding to the atom number. Thus, it can "open" the memory mapped file, and read and process the data, placing the results back into the same area for the client to read when the Message call returns.

There. Simple, eh? :wink:

Most folks don't need to know all this, BTW. Just use the stuff provided. :)

Regards

Pete

[scruffyduck]

Thanks Pete

At the top of the pdf file - programmers guide to FSUIPC there are a couple of urls - I don't have my notebook with me so can't tell you which ones they are exactly - one points to a fasm related site which does not seem to have anything related to FS6IPC or FSUIPC and the other is to a danish site?? - the link given is dead - pete lillendal or somesuch?

Thanks for the explanation - that is more or less as I understood it - to get it working in my language environment I needed to change the declares around - particularly the parameter types so I spent some happy hours with the Win32 API :roll: :roll: I finally figured things out today - I wanted to hide all the offset and byte size data in a class so I am now reading it from a private look-up table. The other thing I was trying to get my head araound was the sequence of read and write messages. Finally figured that for reads it is readRequest --> processRequests ---> get and convert the return data. whilst writing is writeRequest ----> convert The Data ---> process request - leastway that is how I have it and OI can black box the interface class now and forget about how it works :D :D

I have another question though - and this is down to my ignorance in handling hex and binary data types. I am reading the data fine from FS but getting brain damage trying to convert it into a useful number. It is probably a combination of my ignorance of the numbers and how to manipulate themplus my lack of experience in manipulating memory directly.

For example I am trying read magnetic variation - it is in two bytes base on your excellent documentation - I think the number is a signed 16 bit integer :? I have a mag variation of 3degW which is being reported in the FSUIPC log as 4A FF (from memory) but so far I cannot get the actual value out of it even though I am dividing by 65536 and multiplying by 360. Ah well if you could confirm my assumption that it is a 16bit signed integer then I have some other ideas.

[Pete Dowson]

one points to a fasm related site which does not seem to have anything related to FS6IPC or FSUIPC

Ahthat would have carried Adam Szofran's original stuff.

and the other is to a danish site?? - the link given is dead - pete lillendal or somesuch?

Pelle Liljendal is the author of FSInterrogate, the very useful utility I include in the SDK. He was working on a new one with new facilities, including arrays and string support, but I think real work got the better of him for time.

His website used to work fine -- he hosted loads of interesting FS programs. Shame it has gone. I certainly haven't heard from him for a while, though my emailed updates don't seem to get returned.

I'll remove both links. thanks.

Finally figured that for reads it is readRequest --> processRequests ---> get and convert the return data. whilst writing is writeRequest ----> convert The Data ---> process request

Not sure where you get the "conversion" bit. there's no conversion in the stuff I wrote. You get what there is.

And really the sequence is "a whole mix of all the reads and writes you want to do in one cycle provided they fit in the buffer space" then a single process, then go do your own thing before coming back for another cycle.

If you think in terms of one process call for every single read and every single write you will have extremely inefficient programs.

For example I am trying read magnetic variation - it is in two bytes base on your excellent documentation - I think the number is a signed 16 bit integer :?

Yes. Though I don't know what you mean by "two bytes base". It's a 16-bit integer.

I have a mag variation of 3degW which is being reported in the FSUIPC log as 4A FF (from memory)

Why not use FSInterrogate, which not only shows all this stuff in all sorts of ways, but even shows the conversions as well? That's what it is provided for!

but so far I cannot get the actual value out of it even though I am dividing by 65536 and multiplying by 360.

If you divide a 16 bit integer by 65536 you'll get zero, so multiplying it by 360 is no good. Try it the other way around.

4A FF is not hexadecimal "4AFF" because you are reading a byte display. Intel processors, unlike Motorola, use lo-hi representation, so the number id FF4A. You'd see all this with ease if you use the tools provided.

FF4A hex = -182 decimal

(-182 x 360) / 65536 = -1 as near as dammit. So I think your memory made an error somewhere if it was -3 (3W). 3W would be

(65536 x -3) / 360 = -546 decimal = FDDE hex (or DE FD in two successive bytes).

Please, please, PLEASE use FSInterrogate. You will find it an invaluable learning tool.

Regards,

Pete

[scruffyduck]

Hi Pete

Thanks for your reply - dunno what I meant by two bytes base either :?

by conversion I was referring to the calculations I need to do to get the offset data into a useable form. I had realised that it is not efficient to process every single request one at a time and I am batching them up.

Thanks for the info on the hex number - I did manage to figure that one out after a while - I can change the 'endianess' of my meory blocks and when I did that it all worked.

Thanks also for the pointer to FSInterrogate - it is to my huge embarrasment that I did not realise what it would do for me :oops: :oops: . I'm leaving back for the UK in a few hours and when I get home I will investigate it in detail - hopefully that will stop me asking dumb questions :) :)

[scruffyduck]

Hi pete

Just to let you know that i have now delved into FSInterrogate and it does indeed answer all my questions - thanks again!

[Pete Dowson]

Just to let you know that i have now delved into FSInterrogate and it does indeed answer all my questions - thanks again!

Good. Have fun!

Pete

[rafael54]

Hello folks, I would like to know if there is a way to get this RealBasic module, class or what ever it is :)

[Pete Dowson]

Hello folks, I would like to know if there is a way to get this RealBasic module, class or what ever it is :)

What "RealBasic" module? Sorry, never heard of it.

Pete

[scruffyduck]

Hi Pete

Rafael has emailed me - at the beginning of last year I was working using RealBasic and FSUIPC but stopped when I found that programs written using it could not supply the information you needed to generate a key.

[Pete Dowson]

Rafael has emailed me - at the beginning of last year I was working using RealBasic and FSUIPC but stopped when I found that programs written using it could not supply the information you needed to generate a key.

No Version Information? Tut tut!

In that case the answer is to purchase a User key for FSUIPC. Then all the application validity checks are bypassed.

Regards,

Pete

[scruffyduck]

That's correct Pete which is why I changed tools to dotNET :D Since my utilities are freeware you have been kind enough to supply keys and my users do not need a registered version. Mind you I always encourage people to register :wink:

[rafael54]

Rafael has emailed me - at the beginning of last year I was working using RealBasic and FSUIPC but stopped when I found that programs written using it could not supply the information you needed to generate a key.

No Version Information? Tut tut!

In that case the answer is to purchase a User key for FSUIPC. Then all the application validity checks are bypassed.

Regards,

Pete

OK I will proceed in that way thans and sorry for the delay in my response :D