fsuipc sdk 64bit

[edox677]

Hi

 

I am using the fsuipc c code and the libs for years. We had to upgrade our software to 64bit system with the use of VS2015. Since this fsuipc doesn't work.

Is a 64bit usage of the sdk even possible? What items have to be changed

 

 

kind regards
Maik

[Pete Dowson]

On 5/23/2017 at 8:53 PM, edox677 said:

I am using the fsuipc c code and the libs for years. We had to upgrade our software to 64bit system with the use of VS2015. Since this fsuipc doesn't work.

FSUIPC won't know whether what's calling it is 32- or 64-bit. The IPC part of the name means "inter process communication", and 32- and 64- bit processes can talk using its protocol just the same as 32- and 32- etc.

On 5/23/2017 at 8:53 PM, edox677 said:

Is a 64bit usage of the sdk even possible? What items have to be

If you are using that old LIB (going on 19 years since it started!), then the small source is provided in the SDK. You'd need to recompile it as a 64-bit version, adjusting things in it to match. The structures which get sent should be identical though, as FSUIPC won't be able to handle 64-bit pointers etc.

I have a 64-bit version of FSUIPC now running, and all 32-bit client applications work fine with it. I think it should be reciprocal?

Have you checked out Paul Henty's .Net DLL interface? I think he did a 64-bit compatible version.

Pete

 

[CAG2]

On 5/26/2017 at 1:15 AM, Pete Dowson said:

FSUIPC won't know whether what's calling it is 32- or 64-bit. The IPC part of the name means "inter process communication", and 32- and 64- bit processes can talk using its protocol just the same as 32- and 32- etc.

If you are using that old LIB (going on 19 years since it started!), then the small source is provided in the SDK. You'd need to recompile it as a 64-bit version, adjusting things in it to match. The structures which get sent should be identical though, as FSUIPC won't be able to handle 64-bit pointers etc.

I have a 64-bit version of FSUIPC now running, and all 32-bit client applications work fine with it. I think it should be reciprocal?

Have you checked out Paul Henty's .Net DLL interface? I think he did a 64-bit compatible version.

Pete

 

Can you please link the 64bit .net interface? My application relies on the .NET client. Or will it continue to work with 64bit FSUIPC with the 32bit client?

Mark

[Thomas Richter]

Hi,

it is in the sub-forum above, FSUIPC Client DLL for .NET

Thomas

[Pete Dowson]

6 hours ago, CAG2 said:

Can you please link the 64bit .net interface? My application relies on the .NET client. Or will it continue to work with 64bit FSUIPC with the 32bit client?

Either.

Pete

 

[Paul Henty]

Mark,

You'll need version 3 which I haven't officially released yet. I've attached the latest (release candidate) version here. There are copies in various threads in the sub-forum but it would be difficult to find them.

Note that version 3 will only work with the .NET4 framework or higher.

Also there is one breaking change from version 2.5:

* BREAKING CHANGE: You cannot write to an offset than has never been read. (Not applicable to Write-Only offsets).

It's a duel 32/64 binary so it will work as either depending on your how your client application is set.

Paul

 

FSUIPCClient3.0_RC2.zip

[edox677]

On 25.5.2017 at 7:15 PM, Pete Dowson said:

FSUIPC won't know whether what's calling it is 32- or 64-bit. The IPC part of the name means "inter process communication", and 32- and 64- bit processes can talk using its protocol just the same as 32- and 32- etc.

If you are using that old LIB (going on 19 years since it started!), then the small source is provided in the SDK. You'd need to recompile it as a 64-bit version, adjusting things in it to match. The structures which get sent should be identical though, as FSUIPC won't be able to handle 64-bit pointers etc.

I have a 64-bit version of FSUIPC now running, and all 32-bit client applications work fine with it. I think it should be reciprocal?

Have you checked out Paul Henty's .Net DLL interface? I think he did a 64-bit compatible version.

Pete

 

Hey Pete Thanks for that information.
I have managed to to create my own lib based on VS2014 with a 64bit compiler.
I have attached a screenshot where I get stuck.
The exception occurs in the FSUIPC_Process method. Maybe you can comment this since I don't have any glue how to debug this.

Just a remark, I changed the file-maping object creation to

 

 

// create the file-mapping object
	m_hMap = CreateFileMapping(
					(HANDLE)0xFFFFFFFFFFFFFFFF, // use system paging file
					NULL,               // security
					PAGE_READWRITE,     // protection
					0, MAX_SIZE+256,       // size
					szName);            // name 

 

[Pete Dowson]

The read structure includes a pointer which tells the Process where to store the data it receives. That will be 64-bit unless you change it to a DWORD and avoid using it as a pointer, but some sort of offset to your program instead. 

It is the FSUIPC end which doesn't know about all this -- it doesn't use the pointer at all in any case. Howeverm if it is 8 bytes instead of 4, none of the following parts will be right, so the read will fail, probably just returning an error.

Whilst you can convert the existing SDK source to suit 64-bit, it is messy. I will provide a 64-bit version of the stuff in the SDK, but I am away until 20th June now, so it will be later that week.

Pete

 

[edox677]

17 hours ago, Pete Dowson said:

The read structure includes a pointer which tells the Process where to store the data it receives. That will be 64-bit unless you change it to a DWORD and avoid using it as a pointer, but some sort of offset to your program instead. 

It is the FSUIPC end which doesn't know about all this -- it doesn't use the pointer at all in any case. Howeverm if it is 8 bytes instead of 4, none of the following parts will be right, so the read will fail, probably just returning an error.

Whilst you can convert the existing SDK source to suit 64-bit, it is messy. I will provide a 64-bit version of the stuff in the SDK, but I am away until 20th June now, so it will be later that week.

Pete

 

Alright,

 

looking forward to get it
Thanks for your help!

[edox677]

Hey Pete, how are you. Any news concerning the 64-bit Version.

Maik

[Pete Dowson]

52 minutes ago, edox677 said:

Pete, how are you.

Overworked for sure. Just about finished catching up after my (short) break, and investigating and fixing some bugs or P3Dv4 problem solutions. Will just get 5.102a, or maybe 5.103 out, then next on my list is the 64-bt user library, and sorting out MakeRunways to deal with the new airport data formats -- that might be a big job.

54 minutes ago, edox677 said:

news concerning the 64-bit Version.

Maybe tonight or if not, tomorrow morning.

Pete

 

[edox677]

1 hour ago, Pete Dowson said:

Overworked for sure. Just about finished catching up after my (short) break, and investigating and fixing some bugs or P3Dv4 problem solutions. Will just get 5.102a, or maybe 5.103 out, then next on my list is the 64-bt user library, and sorting out MakeRunways to deal with the new airport data formats -- that might be a big job.

Maybe tonight or if not, tomorrow morning.

Pete

 

Thanks!

Really appriciate your effort!

[Pete Dowson]

The 64-bit solution for external 64-bit programs interfacing to FSUIPC5 is now available in Download Links subforum, and in the main SDK package also downloadable through the Schiratti "Dowson" page. It includes a working "Hello" demo program.

Pete

 

 

[edox677]

On 21.6.2017 at 5:28 PM, Pete Dowson said:

The 64-bit solution for external 64-bit programs interfacing to FSUIPC5 is now available in Download Links subforum, and in the main SDK package also downloadable through the Schiratti "Dowson" page. It includes a working "Hello" demo program.

Pete

 

 

I just implemented your code and only get a few lines of code further.

Now I got stuck at this line (IPCUser64 line 223 with dwError = 0 :

 

if (dwError != FS6IPC_MESSAGE_SUCCESS)
	{	*pdwResult = FSUIPC_ERR_DATA; // FSUIPC didn't like something in the data!
		return FALSE;
	}

 

[Pete Dowson]

You have an error then, in the data you are providing. The same source is used in the library which is supplied and linked to the UIPCHello demo.

Check your code. Check the data accumulated in the mapped memory before calling SendMessageTimeout.

Why are you using the original source and not the compiled LIB file? Maybe you have something ncorrectly set for your compilation.

Anyway, you need to do your own debugging I'm afraid. I can't do it from here.

Pete

 

[edox677]

15 hours ago, Pete Dowson said:

You have an error then, in the data you are providing. The same source is used in the library which is supplied and linked to the UIPCHello demo.

Check your code. Check the data accumulated in the mapped memory before calling SendMessageTimeout.

Why are you using the original source and not the compiled LIB file? Maybe you have something ncorrectly set for your compilation.

Anyway, you need to do your own debugging I'm afraid. I can't do it from here.

Pete

 

Hi.

Since we all working on the same project I used to implement source and header files in such a manner that every user has to compile its own lib file.

Anyway I just tried to check the UIPCHello64.exe with this response : IPC request contains bad data

 

So is there really a bug on my side?

If I start the UIPCHello.exe I get the "link established" message.

 

Cheers
Maik

 

[Pete Dowson]

30 minutes ago, edox677 said:

Anyway I just tried to check the UIPCHello64.exe with this response : IPC request contains bad data

Strange. It works fine here. Which version of FSUIPC are you using? It should be 5.103 now, but the 64-bit client features were added in version 5.102, at the same time as the 64-bit SDK release.

Always check you are up to date with FSUIPC!

30 minutes ago, edox677 said:

So is there really a bug on my side?

Assuming you are now using the supported version of FSUIPC5, yes. Check the data format built up for the request being sent by the SendMessgeTimeout. i.e. the data in the buffer allocated as the shared memory-mapped file.  It's the same as for 32-bit except the Read header has a different ID and the pointer to where the Read function will deposit the data is, of course, 64-bit instead of 32.

Pete

 

[edox677]

22 minutes ago, Pete Dowson said:

Assuming you are now using the supported version of FSUIPC5, yes.

 

no it's 3.999 since I only use FS9!!!!

[Pete Dowson]

Blimey! You shoud have said up front!

 

Remember I said "The 64-bit solution for external 64-bit programs interfacing to FSUIPC5 is now available"? It is even quoted in an earlier message in this thread! Note the FSUIPC5.

Sorry, there will never be 64-bit interface into FSUIPC3. I am no longer in any position to make changes to that 14 year old version! I am amazed anyone is still developing anything for it. It seems to make no sense at all when the latest versions are so good.

I may not even develop a 64-bit interface for FSUIPC4, though I could do one there relatively easily if someone asks. Really my 64-bit development was only intended for 64-bit simulators.

For FS9 you'll need to adapt the source of the LIB Read and Process functions to avoid using the 32-bit pointer as a pointer -- maybe some 32-bit index into your own data repository, or a 64-bit pointer converted into a 32-bit offset from the base of your code.

The pointer itself is never used as such in FSUIPC, so you can adapt it to do whatever you want.

Pete

 

[edox677]

hey Pete.

Ich compiled everything in 64 bit but did not get it running. I checked pointes and variables, length  .... you name. I did not find any solution.
So back to basic I created a 32bit software which is now sending fsuipc data via local tcp port as tcp server to my software.

So another question:

what is the maximum frequency the data can be polled from the fsuipc interface. I constant update rate of 5 Hz for example is very desirable for me.

 

Kind regards

[Pete Dowson]

On 11/3/2017 at 9:24 AM, edox677 said:

Ich compiled everything in 64 bit but did not get it running. I checked pointes and variables, length  .... you name. I did not find any solution.

Sorry, I've no ideas how this relates to anything. The last i saw from you was this:

On 6/27/2017 at 9:54 AM, edox677 said:

no it's 3.999 since I only use FS9!!!!

So what are you talking about now?

On 11/3/2017 at 9:24 AM, edox677 said:

what is the maximum frequency the data can be polled from the fsuipc interface. I constant update rate of 5 Hz for example is very desirable for me.

That depends entirely on how fast your FS is running, and how much degradation you are will ing to make it suffer.  But 5 Hz is only one poll every 50 mSecs, which is normal for an FS frame rate of 20 fps. Relatively slow.

But there's no way of guaranteeing a "constant" ratre. It is bound to vary a bit according to what FS is doing. just read the elapsed time offset too (it is in milliseconds) so just can adjust for any unevenness.

Pete

 

[edox677]

sorry Pete for my last unprecise post.
I am dependend from fs9 so I am stuck to fsuipc 3.999. That is why I did this workaround by creating a tcpserver with fsuipc lib which is able to read fs9 data and stream it to my application by tcp.
I don't need a constant update rate but I don't get more than 2 to 4 Hz update rate.
The fsuipc read functions are blocking my whole program.
That's why I was wondering if I can speed this up a little.

 

Kind regards
Maik

[Pete Dowson]

On 11/13/2017 at 7:49 PM, edox677 said:

I don't need a constant update rate but I don't get more than 2 to 4 Hz update rate.

You definitely have something wrong in your program, then, or you are asking FSUIPC to do something which takes a long time and hence pausing FS9, like loading a new flight or aircraft every 250-500 mSecs. But you'd certainly notice that!

Pete