Hi Przemek
I agree though I do not now if I'm right person to describe it
in INSTALL. For shared binaries using harbour*.dll there is
no problem at all and it's enough to link PCODE dll with harbour*.dll.
The problem is only with binaries which have HVM linked with static
part of application. In the previous message I forgot to write that
also functions called in PRG code compiled to PCODE DLL creates
dependencies so programmer should declare them using DYNAMIC clause.
He can generate header file with all functions which are visible
for core part of his application using this code:
#if 0 // uncomment it for tests */
proc main()
genFuncList()
return
#endif
proc genFuncList()
local aFunc, hFile
aFunc := getFuncList()
asort( aFunc )
hFile := fcreate("dynamic.ch")
aeval( aFunc, {|x| fwrite( hFile, "DYNAMIC " + x +
hb_osNewLine() ) } )
fclose( hFile )
return
func getFuncList()
local aFunc, nCount := __dynsCount(), nDst:=0, n
aFunc := array( nCount )
for n := 1 to nCount
if __dynsIsFun( n )
aFunc[ ++nDst ] := __dynsGetName( n )
endif
next
asize( aFunc, nDst )
return aFunc
and then simply #include it in .prg files compiled and linked into
PCODE dlls.
Maybe I misunderstood your tip, but the big problem we have here is that the
names of the functions that will be called from the DLL are not known by the
"host" application before run time. We load the DLL, then we call a known
function (via macro evaluation) to get some info about the content of the
DLL and based on this info we fill the macros that result in the dll
functions names. So it's fundamental in this case that the unresolved
references from dll to the app and vice-versa can be resolved in run time,
the same way as blinker dlls load to clipper apps, with no need to declare
the dynamic symbols in the static part prg's.
Now the only thing I'm still interested in, is what
are the advantage of pcode-.dlls over .hrb files?
[ I can only cite inclusion of .c functions. ]
Yes, mixed PRG and C code is probably the only one real feature.
Probably it's mostly important for 3-rd party extensions which can
be distributed as single DLL. For .prg code only HRB files seem to
be much better solution though support for HRL files with optional
conversion of all internal bindings to static when HRL is loaded
will make it even more flexible for big projects.
If we could have collections of hrb modules libbed inside one single file
that could be loaded and unloaded dinamically there would be no need of
using plataform dependant dlls for harbour code. Tha would be just perfect.
Thanks Przemek
Best regards
Leandro
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
