Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
INDY Cross Platform
#1
I apologise if this is a trivial question. I have looked in the documentation (the PDF is copyrighted 2006 so I am unsure of the currency), done the usual web searches, stack overflow etc, but nothing definitive. There are numerous parts of the documentation that say:

Quote:Additional code changes may be required to maintain cross platform compatibility, as discussed in previous sections.

I'm note even sure what that means.

Regardless, I have a third party component that uses Indy. I have asked the vendor whether it is cross platform. His advice is that 'his' code is cross platform, but he uses INDY and INDY is not cross platform. INDY uses 

Quote:The component is not compatible with Firemonkey as it uses DLL files form Indy and the DLLs aren't cross-platform.

To which I replied:

Quote:According to StackOverflow, INDY works with FMX (and in my case macOS) and has for some time. Since there is nothing visual the VCL doesn't get invoked (this is from 2011).

Quote:Indy ships with the IDE (and has since D6) so there is nothing extra to buy if you already have XE2 installed. Also, Indy is open-source, so you can upgrade an Indy installation using source code from Indy's public access SVN server or mirror.
Regarding FireMonkey, Indy does work in FireMonkey. Indy uses whatever the native socket API is on a given platform (WinSock on Windows, Posix on Mac, libc on Kylix, etc).
The only known gotcha with Indy under FireMonkey at the moment is the TIdAntiFreeze component is not available at design-time. The IDE cannot resolve it correctly due to the non-standard way it is packaged (to be adressed in Indy 11). You can instantiate it programmably in code at run-time, though.

To which he replied:

Quote:Indy works with Firemonkey, although the 2 DLL files included (ssleay32.dll, libeay32.dll) aren't cross-platform.

So I have been having a discussion with a vendor who is simply a user of INDY and I don't think he quite has all of the knowledge. Further, whilst his code might work with FireMonkey, it will only do so in Win32 mode, he uses Registry and other windows dependent units AFAICT.

Regardless, and so my (apologetically trivial) question: Is INDY (latest version) Cross Platform, ie. can I use it in my application that is to be deployed on macOS? and if so, is there anything 'special' I would need to do?

For the record, his USES clause contains these references to INDY components:

  IdHTTP,
  IdLogFile,
  IdComponent,
  IdSocks,
  IdSSLOpenSSL;
Reply
#2
(10-28-2018, 11:38 PM)Cirrus22 Wrote: Regardless, I have a third party component that uses Indy. I have asked the vendor whether it is cross platform. His advice is that 'his' code is cross platform, but he uses INDY and INDY is not cross platform.

Then he doesn't know what he is talking about, because Indy is most definitely cross-platform.

(10-28-2018, 11:38 PM)Cirrus22 Wrote:     The component is not compatible with Firemonkey as it uses DLL files form Indy and the DLLs aren't cross-platform. 

Indy supports FireMonkey, and every platform that FireMonkey supports (Windows, OSX, iOS, Android, Linux). And it supports FreePascal, so it supports a lot more platforms than Delphi does.

He might be referring to the fact that some portions of Indy do make use of external libraries on various platforms (DLLs on Windows, SOs on Linux/Android, DyLibs on Apple, etc) for things like OpenSSL, ZLib, etc. But those are optional pieces. The majority of Indy is platform-agnostic, except for the underlying socket APIs used.

(10-28-2018, 11:38 PM)Cirrus22 Wrote: To which I replied:

According to StackOverflow, INDY works with FMX (and in my case macOS) and has for some time. Since there is nothing visual the VCL doesn't get invoked (this is from 2011).

Yup.

(10-28-2018, 11:38 PM)Cirrus22 Wrote: To which he replied:

         Indy works with Firemonkey, although the 2 DLL files included (ssleay32.dll, libeay32.dll) aren't cross-platform. 

DLLs are specific to Windows, but the concept of dynamic libraries is not. OpenSSL is available on many platforms, and Indy can use OpenSSL on all of the supported FireMonkey platforms (though there are some issues on Android 6+).

But more importantly, OpenSSL is merely Indy's default library of choice for SSL/TLS support, but OpenSSL is not a requirement. Any SSL/TLS library can be used with Indy as long as you have a TIdSSLIOHandlerSocketBase-derived wrapper component for it. For example, Eldos Blackbox provides such a component for its own SSL/TLS library. And Indy's team is researching to provide a new component for SChannel on Windows as an alternative for OpenSSL (and maybe other SSL/TLS libraries on other platforms in the future as OpenSSL platform support is starting to wain, such as BoringSSL, LibreSSL, etc). So, if you are willing to put in a little extra work when needed, you are NOT tied to OpenSSL specifically.

(10-28-2018, 11:38 PM)Cirrus22 Wrote: Is INDY (latest version) Cross Platform

Yes.

(10-28-2018, 11:38 PM)Cirrus22 Wrote: can I use it in my application that is to be deployed on macOS?

Yes.

(10-28-2018, 11:38 PM)Cirrus22 Wrote: and if so, is there anything 'special' I would need to do?

No.

(10-28-2018, 11:38 PM)Cirrus22 Wrote: For the record, his USES clause contains these references to INDY components:

  IdHTTP,
  IdLogFile,
  IdComponent,
  IdSocks,
  IdSSLOpenSSL;

None of those units are platform-specific. Though, the IdSSLOpenSSL unit does depend on the IdSSLOpenSSLHeaders unit, which it turn supports OpenSSL libraries (in DLL, SO, or DYLIB form) on all of FireMonkey's supported platforms. In the case of iOS, you do need to use the IdSSLOpenSSLHeaders_static unit and static-link .A files, as Indy loads OpenSSL statically on iOS devices (due to an old Apple restriction on loading libraries dynamically), but it loads OpenSSL dynamically on all other platforms (including the iOS simulator).

Reply
#3
Remy,

Thank you for your detailed response. I will indeed pursue the SSL issue (I sort of have to). I need to provide access to the Dropbox API through a DLL (in windows) and a DYLIB in macOS. It appears than anything with the FMX Forms unit in it blows up the application with the DYLIB with "Could not Register TFMXApplicationDelegate". I was suing the TMS FMX Cloud Pack (and VCL Cloud Pack). The people at TMS know absolutely nothing about unit their component(s) in a DLL and when I queried them about using it in a DYLIB actually told me they doubted that you could use FMS application / DYLIB (actually, I though that was the whole point of FMX, maybe I should just look at some other language):

Unfortunately the TMS FMX Cloud Pack does not include support to be used in DYLIB.
The product has indeed not been tested in this scenario.
We are currently not aware if there is even support to use any FMX application in this scenario, as like you mentioned using FMX.Forms is already causing issues.
Unfortunately even only researching if it would be possible to use TMS FMX Cloud Pack in a DYLIB could take a significant amount of development time let alone implementing the required changes which could likely be technically challenging.
Please also note that we haven't noticed any demand from other customers for the TMS FMX Cloud Pack in this scenario. 

Anyway, I'm not getting any support there which is disappointing since the reason I purchased the FMX Cloud Pack was because of the cross platform ability. So it's cross platform (I think) provided you ONLY use it in an application.

Sorry, I digress. I appreciate (once again) your lengthy response, answering ALL of my questions in detail where required.

regards,
kevin
Reply
#4
Kevin,

FWIW I've been using IdSSLIOHandlerSocketOpenSSL in an FMX project for several years, without needing to do anything other than drop it on the form. I originally did this with XE5 but it works equally well now using Tokyo.

Remy,  

For the Windows (VCL) version using XE5, I originally seemed to need to include ssleay32.dll and libeay32.dll with the app but it now does not seem to be necessary with Tokyo.  Am I correct?  And is that because IdSSLOpenSSL is now automatically added to the form when IdSSLIOHandlerSocketOpenSSL is added?

Thanks,

Scott
Reply
#5
(10-29-2018, 11:08 PM)Cirrus22 Wrote: It appears than anything with the FMX Forms unit in it blows up the application with the DYLIB with "Could not Register TFMXApplicationDelegate".

That is something that needs to be taken up with Embarcadero. The only issue I see in Quality Portal that is related to TFMXApplicationDelegate is RSP-18580: Firemonkey applications don't terminate normally on macOS.

(10-29-2018, 11:08 PM)Cirrus22 Wrote: when I queried them about using it in a DYLIB actually told me they doubted that you could use FMS application / DYLIB (actually, I though that was the whole point of FMX, maybe I should just look at some other language)

FMX can consume, and create, dylibs for OSX. Just because the TMS folks didn't test it doesn't mean it can't be done at all.

(10-31-2018, 06:34 PM)shochberg Wrote: For the Windows (VCL) version using XE5, I originally seemed to need to include ssleay32.dll and libeay32.dll with the app but it now does not seem to be necessary with Tokyo.  Am I correct?

No. The DLLs are still required. If you are not deploying them, Indy is likely loading them from elsewhere on your system's DLL search path.

(10-31-2018, 06:34 PM)shochberg Wrote: And is that because IdSSLOpenSSL is now automatically added to the form when IdSSLIOHandlerSocketOpenSSL is added?

No, that is not why. And besides, the IdSSLOpenSSL unit is the one that actually implements TIdSSLIOHandlerSocketOpenSSL, it should have always been getting added automatically regardless. Maybe you are thinking of the IdSSLOpenSSLHeaders unit instead? Doesn't matter, the DLLs are still required nonetheless.

Reply
#6
Thanks Remy. I think the entire Embarcadero ecosystem would collapse without you participating in various forums.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)