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

Reply via email to