On Tue, 18 May 2010, Szak�ts Viktor wrote: Hi,
> Before going further can you help define in > normal words what is the description / distinction > between -hbdyn and -hbdynvm modes? -hbdyn creates DLL which is not linked with HVM. -hbdynvm creates DLL which is linked with HVM and other Harbour core libraries. > When do we use which mode? When we need or not HVM to be linked with final dynamic library so it depends on the code I'm linking. I can use -hbdyn to create DLL which does not have any references to Harbour core code. I can use -hbdyn and -lhbmaindllp to create DLL containing compiled .PRG modules (PCODE DLL) which can be dynamically loaded by static or dynamic Harbour application. I can use -hbdyn and -static to create self contain DLL which uses it's own private copy of HVM and Harbour RTL library which can be linked statically or loaded dynamically with/from any other applications, this application can use it's own HVM copy which will not interact with the one included in DLL in any way. I can use -hbdynvm and -shared to create PCODE DLL which can be linked statically or loaded dynamically by shared linked Harbour application and HVM code and structures are shared in such case. There are also many other situations when user may need -hbdyn or -hbdynvm. > [ we now have .prg .dlls, "normal" .dlls, "VM" > .dlls, but I'm starting to get confused, which > means it's difficult to organize the internals. > F.e. now I can introduce a new sub-switch inside > -hbdyn mode for 'vm', or I could cleanup the modes > into a flat list. ] See above. Please also remember that dynamic shared libraries using HVM are initialized just like normal EXE files and when they contain their own HVM switches like -gt* should be enabled just for executable binaries. If they share HVM then you can also enable them and they will be ignored so you do not have to implement any special case for such situation. > Enabling specific features based on the mode is > less of a problem. > > Bonus: Do you have any hint how to use .def files > with watcom compiler? Spent 1 hour on it to no avail, > maybe it's too obvious or it was too late. See my second message. WLINK seems to not accept .DEF files directly and uses a little bit different syntax. Only LINK can accept them and probably internally translates them to WLINK format. We can add translation from .DEF files to this format or we can simply include .DEF files directly using "@" command in WLINK .lnk file and user will have to use OpenWatcom compatible format for them. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour