On Mon, 08 Feb 2010, Szak�ts Viktor wrote:
Hi Viktor,
> If it works using current tools, it's nice, and we probably
> have to do only those steps you mention to make it easily
> available for users. And document it. F.e. in INSTALL (if
> the end result is elegant or simple), or a separate document
> if the size of the topic deserves it.
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.
Probably to make it easier for users we can add small option to hbmk2
which will attach to final code exported wrappers to hb_vmProcessSymbols()
and hb_vmExecute() or single function which can be used to extract
addresses of other functions so later it will be enough to extend
the list of pseudo exported symbols without touching hbmk2 code.
I can create such function.
> > 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())
>
> Pls remember that hbwin LoadLibrary/FreeLibrary functions
> are also used by other WAPI wrappers and pure (non-pcode)
> .dll support, so IMO we shouldn't remove or hide them, but
> simply document that pcode .dll must always be managed with
> HB_LIB*() functions.
Such documentation will not help users who do not know if some 3-rd
party libraries contains PRG code or not so it's useless and IMO makes
thing more complicated then necessary. The only one thing we should
made is redirecting above functions to HB_LIB*() ones which in windows
builds internally use the same WIN API functions and only have additional
code to protect HVM against corruption in MT mode, allow clean unloading
and execute INIT/EXIT PRG functions if any. The returned handles can be
used as any other GC pointer items used by HBWIN code. If necessary
we can add to HVM public function to extract library handle from
PHB_ITEM. Please also note that destructor for HB_LIBLOAD() GC pointer
items does not unload library automatically so it will work as current
functions even if user does not save it somewhere.
> 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.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
