Hi Przemek, >> Sorry but I know nothing about pcode .dlls, hence >> there is no support for it in hbmk2 (yet?). I can't >> recall anyone doing any tests with this (besides me >> a while back, but without any results) > > 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. [...] > 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. > 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.
Okay and thank you very much. I'm afraid this topic falls beyond the threshold of my brain capacity and interest :( 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. > 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. >> 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. Hmm... same applies as above, I'm trying to assemble the pieces of puzzle, but until I haven't seen or used these in practice, it's very difficult to digest it. I hope it better helps Leandro, though. >> 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. Amen. 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. ] Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
