On Mon, 08 Feb 2010, Szak�ts Viktor wrote: Hi,
> 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. 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 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. 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. 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. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
