On Tuesday, 9 January 2018 at 18:32:24 UTC, Benjamin Thaut wrote:
Am 09.01.2018 um 16:03 schrieb Andre Pany:
[...]
First let me say that what you are describing is a very
uncommon and ill-advised use case. As such there is not going
to be any nice to use workflow to acieve what you are trying to
do. Still this doesn't mean that it won't be possible.
Why ill-advised? What you're describing is a cyclic dependency
between your main executable and your dll written in delphi. If
you google for "cyclic dependency dll" you will usually get the
advice to break your cylic dependency by splitting your code
into more dlls. My personal experience shows the same. Cyclic
dependencies in dlls are usually not worth the additional
effort and hassle. Also you want to export things from your
executable, which is also very uncommon. What you should be
doing is having 2 dlls and one executable. You have one common
library written in D that is build into a dll. Then you have
your delphi library which uses the common.dll. Finally you have
your main executable written in D which uses both the
common.dll and your delphi.dll. This should make it possibly to
break the cycle and get you an easy setup.
If you absolutley must do it the way you describe it, its still
possible. You will have to compile all modules that export
something from your executable with the "-c -shared"
parameters. E.g.
dmd -m64 -c -shared moduleThatExports1.d moduleThatExports2.d
-ofexports.obj
Now you link the resulting exports.obj file into your
executable by calling dmd again
dmd -m64 restOfModules.d exports.obj delphi.lib -ofmain.exe
Finally you have to get the handle to your main executable by
calling
HMODULE handle;
GetModuleHandleExA(0, null, &handle);
in your delphi dll and then fetching the function pointer for
each and every function you want to call from delphi via:
GetProcAddress(handle, "mangeledFunctionSymbol")
Now finally you can call these functions pointers from delphi
and they will call into the D code within your executable.
Instead of all that hassle you could instead just have a
function in your delphi dll:
void recieveFunctionPointer(const(char)* name, void* ptr);
which you call for every function that you want to make
available from D to delphi. Your delphi code then stores away
these pointers depending on the name. That way you don't need
to export anything from your executable and can build it
normally. Instead of having a function call per function you
could obviosuly also use a struct that is defined the same way
in D and delphi and contains all relevant functions pointers.
Thanks for your deep analysis. There are several reasons I want
to have the exe as Delphi application:
1) I faced some minor (Delphi) IDE/Libraries bugs with having the
Delphi gui within a dll.
2) The Delphi IDE provides you the possibility to e.g. easily
change the exe icon/attach additional resources to the exe, ...
3) Delphi lets you also create android/iPhone applications. I
assume there will be no other way than place the D coding within
a shared object for this scenario.
I completely agree with you, it is mad. My gut feeling is, you
have the greatest benefit from the IDE and convenience if the
executable is written in Delphi.
I try to support both ways in my library, so the developer can
decide.
Kind regards
Andre
