Hi Przemek,
>> 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.
Okay we can do it. I'll also need a name proposal for
such hbmk2 option. Or maybe a new main switch instead of
-hbdyn (like -hbdynvm ?) which also turns on this extra
feature automatically, but a good name would be nice
even for this case.
>>> 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.
I see. In case HB_LIB*() is a superset of other hbwin
specific loaders, I agree to drop those. (convert them
to stubs). For sure DLLLOAD() is an Xbase++ compatibility
function so we should keep it as such, and this way we
could even move it to core.
>> 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
Though even this can only be done if said .dll doesn't depend
on other 3rd party .dlls. So in case the .c code implements
some wrappers (which is typical), the underlying API needs to be
linked to the pcode .dll statically. If I see it correctly.
> 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.
Agreed. I'm not yet live .hrb user, so can't oversee the
benefits of .hrl, but sounds good nevertheless :)
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
