Hi
I was creating them without any problems and from time to
time I made such tests together with HRB support.
As long as some of recent modification did not seriously
break sth then it should work without any problem.
The most important rule which users have to always remember:
it's illegal to link PCODE dll and any other DLLs with Harbour
static functions. If you make that then the same code is linked
twice so it may not work as expected, i.e. two independent HVM
stacks. This same is for any other projects and code so it's
rather basic knowledge about using shared libraries in Windows.
It also means that fully functional Harbour distribution should
have shared version of all libraries or at least provide easy
way
I don't know if I reach the point you are talking about, but in the xHarbour
scenario I mentioned before apparently it wasn't needed to resolve all the
references to any functions statically linked to the host executable,
because these references were intended to be resolved in runtime.
Inside hb_vmRegisterSymbols we inserted a hack to resolve the undefined
references both in the DLL and in the host aplication: if the symbol in the
DLL had an unresolved pointer (????DEAD address), we searched for its name
in the host symbol table and replaced the DEAD pointer for a resolved one,
and when the symbol was resolved in the DLL but not in the host symbol table
we fixed its address in the host symbol table, replacind the DEAD address
for the DLL resolved address. IOW, if the same symbol was in the DLL and in
the host and was undefined in one of them, we fixed it, otherwise, we let
go.
Does it make sense to you? Does this already apply to Harbour?
It seems to work like this using Blinker, and it offered yet the option to
replace or not to replace a doubly defined symbol when loading the DLL, but
we couldn't implement it unfortunatelly.
There are two possible methods to create PCODE dll.
1. when final application using PCODE dll is linked in shared mode with
harbour*.dll.
In such case it's enough to link the PCODE dll with exactly the same
harbour*.dll. That's all. No additional operations have to be done.
Please also note that harbour*.dll exports all Harbour functions marked
as HB_EXPORT so it's possible to use also C code inside PCODE dll which
uses full exported Harbour API.
That is not my case of use - we use harbour self contained executable +
pCode dll.
2. when final application using PCODE dll is linked with in static mode.
It's a little bit more complicated situation because in such case
it's illegal to link PCODE dll with harbour shared library
(harbour*.dll)
and as I notice above with static libraries too. It's possible to link
with above libraries but generated binaries will be wrong and can cause
any unpredictable results so user has to be careful to not create them
by mistake.
Compiled PRG code needs two functions from the static part of
application to wrok: hb_vmExecute() and hb_vmProcessSymbols().
These functions have to be exported by static part of application
and the PCODE dll has to be linked with import library having them.
We already have such import library and it's called hbmaindllp.
It is written in a way which allows to link it also with PCODE dlls
which are used by harbour applications linked in shared mode (I see
that you nicely updated harbour*.dll names but it needs some minor
cleanup yet to use these names, I'll commit it ASAP).
So this part is ready and user only need Harbour static libraries
which export above two functions. AFAIR by default they are not exported
so it's necessary to recompile harbour exporting them.
In xHarbour 0.9 it seems that hb_vmProcessSymbols and hb_vmExecute were
declared inside maindllp.c but just as wrappers to (VM_DLL_EXECUTE) macro.
Is this part of the same metodology you described?
We can resolve this problem enabling symbol exporting also in default
static builds or by introducing special wrappers in separate library
which is not part of harbour*.dll. In such case it will be enough to
link this new library with static part of application (using REQUEST
mechanism to force linking) and update hbmaindllp to use this wrapped
functions when original ones are not available (i.e. we can add _dll_
prefix for such wrapped function names.
PCODE DLLs can be linked with final application or can be loaded
dynamically. To load/unload dynamically any libraries always use
HB_LIBLOAD()/HB_LIBFREE(). Never use
WAPI_LOADLIBRARY()/WAPI_FREELIBRARY(),
LOADLIBRARY()/FREELIBRARY(), DLLLOAD()/DLLUNLOAD() because they do
not work correctly with HVM what can cause some very serious problems,
i.e. it's not possible to cleanly unload PCODE dlls, these functions
should be removed or wrapped to HB_LIBLOAD()/HB_LIBFREE())
To do anything in this regard, first I should see
how pcode .dlls are supposed to work, linked, etc.
See above. It should be whole description.
I also need to see if this is something Windows
specific or portable. The latter would certainly
make it more interesting to deal with.
In Windows shared libraries cannot be created with late binding
resolved at runtime and it causes that it's necessary to use
import libraries. On most of other systems (but not all) dynamic
runtime linker supports late binding so it's possible to create
shared libraries with insufficient dependencies which are resolved
at application startup or when function is called 1-st time.
In the meantime I'd suggest to consider to use
.hrb files instead. Unless there is the need to
include .c code in these pcode .dlls, they are
superior in all aspects, moreover they already work.
We still do not support HRL (libraries for HRB files what in
some cases can seriously reduce HRB functionality) anyhow HRB
is portable and always preferred format which has also many
features which are not available for DLLs.
This HRL support could eliminate the need to use DLLs in my case. Is it
planned to be done? How would it reduce HRB funcionality?
Thank you
Regards
Leandro
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
