Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hello,

 

I have had to migrate my Acars to use 64 bits. This means I need to compile it linking to a 64 bit FSUIPC_User.lib

Where can I find this?

I tried recompiling using the IPCuser.c + .h files and in fact it seemed to work in terms of compilation an all. But when I invoke "fsuipc open", I get mumbo jumbo (something like: ÃÂo

Thanks,

Miguel

Posted

Yes, I had already seen it but I think the problem here is more obvious:

 

My FS2004 is [still] running on a Windows XP (32bit). I have my Acars running on a Windows 10 (x64) laptop accessing via WideFS. Would this be compatible?

Posted
32 minutes ago, mfrias said:

My FS2004 is [still] running on a Windows XP (32bit). I have my Acars running on a Windows 10 (x64) laptop accessing via WideFS. Would this be compatible?

WideClient is 32-bit (all versions). Its seems unclear if this would work with a 64-bit client. You can re-compile against the 64bit SDK and try it.

But 32-bit clients work fine with all versions of FSUIPC and WideFS, so you can just stick to 32-bits unless you have other reasons to move to 64-bit.

Sorry I can't give more information. I'll do some testing on this at some point as I'd also like to be clear on this (i.e. 32-bit/64-bit client with 32/64 bit WideFS or FSUIPC) but I have a lot to do at the moment (and for the forseable future!) so haven't really got time to check this any further at the moment. If you do rebuild you client as a 64-bit one, please let me know if it works ok with WideFS/WideClient.

John

 

Posted

I did recompile it with the 64bit lib. The reason for moving to 64 bits is that my Acars uses other libs. One of them has to do with TLS/SSL/HTTPS and must be compiled 64 bits, which forces everything else to upgrade as well.

If anyone else has used the 64 bit version, if they use WideClient did it work?

I was also wondering if there is another way to access MSFS variable via FSUIPC but not using the lib. I see there is a new web sockets program, would this allow to access the data another way?

Posted
1 minute ago, mfrias said:

If anyone else has used the 64 bit version, if they use WideClient did it work?

Pete's found a 64-bit TrafficLook client and is testing now....I or he wil let you know shortly...

2 minutes ago, mfrias said:

I was also wondering if there is another way to access MSFS variable via FSUIPC but not using the lib. I see there is a new web sockets program, would this allow to access the data another way?

Yes, you can use that. Its built on top of the .net dll client, which (I believe) is built on top of the 32-bit SDK, so it will be using the same under the covers.

Posted
11 minutes ago, John Dowson said:

Pete's found a 64-bit TrafficLook client and is testing now....I or he wil let you know shortly...

Problems compiling this, sorry.

16 minutes ago, mfrias said:

I did recompile it with the 64bit lib.

So, does your software work with WideClient when recompiled with the 64-bit lib?

 

Posted
13 minutes ago, John Dowson said:

So, does your software work with WideClient when recompiled with the 64-bit lib?

 

No. Let me give a more detailed outlook on the whole solution. I am one of the few Tcl/Tk programmers on earth 🙂 I developed the Acars entirely in Tcl. But for FSUIPC I used the FSUIPC_User.lib and compiled my own DLL (Tclfsuipc.dll) to link the Tcl framework to FSUIPC. Basically, I create a new command called "fsuipc" within Tcl so that it interfaces with the FSUIPC lib and therefore with MSFS.

This was programmed back in 2010 (!). And I've never had to touch it since.

 

However, I wanted to migrate my VA's website to HTTPS. This requires adding the TLS layer on top of HTTP. But due to the security mechanisms and all many of the security protocols are not allowed any more. Therefore, I had to upgrade to using the latest version of the TLS lib which is 64 bit. This means that I had to start using Tcl 64 bit. And hence, all libs used must be 64 bits now.

This means I had to recompile Tclfsuipc.dll as a 64 bit DLL. In Visual Studio 2019 I changed the include/libs parameters and selected everything to become 64 bits. Initially the linker was complaining about FSUIPC_User.lib, because it was still the 32 bit version and therefore there were no 64 bit symbols available. I then used the FSUIPC_User.lib in "UIPC64_SDK_C_version2" and it compiled ok and produced the DLL.

Then, I integrated everything into my Acares EXE but then I initiate the FSUIPC connection I get three or fours garbled characters and no connection.

My setup:

 

Win XP, FS2004, WideServer

Win 10, WideClient 7 where my Acars now runs

Posted

Ok, in terms of websocket I am trying to start this line of thought. Having issues connecting at the moment but... what are the commands within the WS? Is there a manual for this?

Posted

I would advise compiling a Debug version and doing some interactive debugging. There must be something wrong in your code or your adaptation somewhere. Perhaps you should also explain this 

"But when I invoke "fsuipc open", I get mumbo jumbo (something like: ÃÂo"

when FSUIPC_open merely returns an error or success code in Result. Where do you see "mumbo jumbo"?

Pete

 

 

Posted
7 minutes ago, mfrias said:

what are the commands within the WS? Is there a manual for this?

If you have installed the web-socket server, there should be a menu entry that takes you to the on-line manual.

Posted

I'm using a small program (FSUIPC WebSockets Server) that comes with the FSUIPC7 zip to start the web sockets server on port 2048. It has version 0.2.0.5.

 

When I open it I only see Web Services, Flight Sim, Options and About tab on the left. 

Posted

I was using the program itself not the FSUIPC7 application which is why I didn't find any help.

However, my websocket client test works with:

wss://echo.websocket.org

but doesn't work with:

ws://localhost:2048/fsuipc

 

Although I used the help page test and it does in fact connect. Weird... got to do with localhost probably.

Posted

So basically it is now working... Honestly I don't know why this happens. Here is the code I use regarding FSUIPC Open:

 

int TCLFSUIPC_OPEN(Tcl_Interp *interp) {
    DWORD dwResult;
    char err[1024];

    dwResult = 3; // this was added right now and it seems that setting an initial value here makes it work.
    if (FSUIPC_Open(SIM_ANY, &dwResult)) {
        return TCL_OK;
    }
    
    sprintf_s(err, "FSUIPC: Failed to open link: %s", pszErrors[dwResult]);
    Tcl_SetResult(interp, err, TCL_STATIC);
    FSUIPC_Close(); // Closing when it wasn't open is okay, so this is safe here
    return TCL_ERROR;
}

 

 

 

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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.