mfrias Posted November 29, 2020 Report Posted November 29, 2020 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
John Dowson Posted November 29, 2020 Report Posted November 29, 2020 Its in the SDK folder, UIPC64_SDK_c_version2.zip.
mfrias Posted November 30, 2020 Author Report Posted November 30, 2020 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?
John Dowson Posted November 30, 2020 Report Posted November 30, 2020 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
mfrias Posted November 30, 2020 Author Report Posted November 30, 2020 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?
John Dowson Posted November 30, 2020 Report Posted November 30, 2020 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.
John Dowson Posted November 30, 2020 Report Posted November 30, 2020 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?
John Dowson Posted November 30, 2020 Report Posted November 30, 2020 Ok, I can now confirm that 64-bit compiled programs work ok with the 32-bit WideClient.
mfrias Posted November 30, 2020 Author Report Posted November 30, 2020 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
John Dowson Posted November 30, 2020 Report Posted November 30, 2020 Then maybe its just the character set? For the FSUIPC SDK, you need to compile with a multi-byte character set, not unicode. John
John Dowson Posted November 30, 2020 Report Posted November 30, 2020 Then I'm sorry, I don't know what the issue is or could be.
mfrias Posted November 30, 2020 Author Report Posted November 30, 2020 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?
Pete Dowson Posted November 30, 2020 Report Posted November 30, 2020 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
John Dowson Posted November 30, 2020 Report Posted November 30, 2020 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.
mfrias Posted November 30, 2020 Author Report Posted November 30, 2020 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.
John Dowson Posted November 30, 2020 Report Posted November 30, 2020 When installed, its integrated into FSUIPC7. Run FSUIPC7, and look in the Add-ons->WebSocket Server menu, There's an Online Help menu entry that takes you to http://fsuipcwebsockets.paulhenty.com/
mfrias Posted November 30, 2020 Author Report Posted November 30, 2020 I just found that URL in the forum thanks. Let's have a go at it
mfrias Posted November 30, 2020 Author Report Posted November 30, 2020 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.
mfrias Posted November 30, 2020 Author Report Posted November 30, 2020 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; }
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now