Me and my colleagues love your products so far and are very interested in using it for our products and not only as experimental to see the capabilities. By saying that we always come across the same situation. We have 32-Bit Legacy Clients (not only one but 12 with different codebase) which cant be upgraded to 64 Bit. We want to introduce Java, but newer Versions are build in 64 bit. We have DLL´s i need to convert to plugins but they require to be in 64 bit sooner or later because we need to communicate with 64-Bit MAPI-Clients. We are currently discussing ideas how we can get the communication workable (generic if possible) but came not to any final conclusion. So i ask if maybe Hydra might be able to do the communication.
It would be super awesome if our 32-Bit Host could communicate with a 64-Bit Plugin. Does Hydra already have those possibilities? I would see it as a “must have” since it would make it more and more usable for users to switch from old codebase towards modern languanges like C# or Java.
I would love to hear some input before me and my colleagues start to discuss it further and may “build” a solution for a general issue.
our Host application is written in Delphi 10.2+ with roundabout 4-5 Million lines Code each product. Only one product is still written in Delphi 7. Our plugins should be written either in Delphi 10.2+ or in java. We also have a mail client application communicating through a dll to windows mapi system. There came our first 64-Bit issue (not hydra based) that customer use Outlook 64-Bit or Thunderbird 64-Bit. In order to simplify this task i want to release a 64-Bit DLL. But then i need to communicate from Host to Plugin which leads in same issue, 32-Bit Host 64 Bit plugin. The other idea is using java in near future and replace step by step legacy code in delphi. Here we are limited to Java 1.8 32-Bit or OpenJDK 13 (which exist only in 64-Bit). If Hydra could wrap communication between 32 and 64 Bit Host\Plugins it would be a key decision for us using hydra in future official (including more licences since i use a single developer license for my personal experiements). And since its a very basical issue between Bitness-based application also a key feature for other customers.
Can you tell me if the concern is visual or non-visual? non-visual is a problem that’s probably doable to solve (but I’ll let anton continue on that one), but mixing visual controls is a bit trickier.
In general this is a fundamental platform limitation: 32-bit windows apps cannot load 64-bit libraries and vice versa.
For example this means that 32-bit Delphi host cannot load 64-bit JVM dll that is required to communicate with Java code.
Also Delphi plugins use either direct library loading or in-process COM where mixed bitness as also not allowed due to platform restrictions.
However there IS a possible solution (even 2 actually).
The 1st one is to use out-of-process COM:
A 64-bit host app is created that loads 64-bit plugins and exposes its functionality via COM. Then this COM server is registered in a special way (see below).
32-bit client then calls methods of that COM server to do its work.
This approach also allows to load 64-bit library from 32-bit code. It is almost the same approach as above. The difference is that it would use different communication protocols to perform method calls. https://cc.embarcadero.com/Author/802978
Please note that this approach will enable only non-visual plugins. One of the steps of visual plugin implementation implies that a window handle is passed from host to the plugin. This handle is used to embed plugin message loop into the host’s one. Passing 64-bit handle to 32-bit code and using it there can lead to errors or even crash the Windows GUI subsystem.
Could be both… non visual atm since we do draw ui in delphi 10.2 and want call java plugins. but it also could happen that we get requirements to display ui from plugins
The Solution of building a com server is not new for us. We use a MAPI-Framework written in delphi forcing us to install a COM-Server to communicate from 32-bit dll to 64-bit MAPI-Client. The complexity approachs when you have multiple systems with different requirements but the same shared components. In our case we have customers who use different versions of the component which require to install different com-servers which led into issues by the component manufacturer, he says he cannot mix multiple com instances.
The Question for me were more straight forwarded to hydra. It would be decent if i could tell hydra “load a 32-bit plugin” or “load a 64-bit” plugin and the hydra subsystem would handle the bridging.
Of course, trying to mix up the solutions described above “would” be possible.
Thanks a lot so far for this living discussion and the given input.
In the COM-based approach (first one) you do not need to use these 3rd party components via COM, so the shouldn’t be any conflicts regarding this.
The idea is that you create a 64-bit host app that calls these components (either directly or via Hydra plugins, not via COM). Then this host app exposes its own COM interface that is later utilized by the 32-bit client app
I will log this for further discussion. Please assume no ETA on this feature as we need to discuss and think this over first.
Could these be standalone windows/dialogs (which should be doable, and doesnt fall under Hydra’s UI support, as the guy would be handled entirely by the plugin), or would they have to be embedded ion a 32-bit-based host window (probably impossible)?
32 Bit Client need to either call a 32-bit or 64-bit dll (based on mapi requirements). NO GUI required from Plugin
32-Bit Client need to communicate with a java rest client in 32-bit or 64-bit. No GUI required from Plugin
32-Bit Application runs a 64-Bit Plugin with Gui not embedded in Host.
This alone would be already our key to use hydra as very important framework.
Ofc if we could run a java ui onto a delphi frame would be nice to have but the above described cases are very important for us.
Atm i run a single developer license, i test the possibilities because I want to use hydra for our upcoming tasks. I need to fullfill the requirements in order to get the budget to buy more licenses or a site license. Those requirements would be very important
Yes definitly. In my oppinion i think most users require to step away from delphi or use\call libraries\api written in .net, java or delphi. Small companies like mine dont have the resources of developing enterprise level ui components so we are forced to stay on our prevous purchased ui. We also get a lot of libraries we need to offer support or write API for a communication. GUI is a very less priority on those tasks.
A lot of legacy code from past( not only in my current job but also in previous) were designed and written on the typical vcl designer architecture. One very big .pas file combined with a dfm. Modern patterns splitting GUI, Business Logic and Database access.
I plan on splitting our legacy code into 3 parts :1) UI written in Delphi using Hydra to 2) communicate with a java written non ui rest client which 3) communicate with a rest server with database access.
There are only very less reasons using java as UI. I think most users using .NET\C# might not have the requirement of a cross bitness… Java users are more or less forced to use 64-Bit on JVM since OpenJDK is only available for 64 Bit.
still thinking about this topic also another thing came to my mind.
In december we once also discussed Hydra Java Plugin Interface in Delphi. Being in urge of designing an architecture for future modules i found https://adoptopenjdk.net/. They seem to be able to build 32-Bit OpenJDK version but they arent supported by latest Eclipse. I hoped we could use this and then load JVM with 32 bit in order to import written interfaces to delphi. I guess those 2 topics are going hand in hand with a further discussion. Seems like 64-Bit is the only way using java in near future.
