>
> > 3) I'd use some other name, like HB_EXPORTFORCED, because
> > the meaning of 'p' is very ambiguous (it was "*p*code dynamic lib
> > probably, but this isn't precise).
>
> If you export at least one symbol then you automatically disable
> automatic conversion in MinGW builds. This conversion is enabled
> only if application does not export any other symbols. It means
> that in MinGW builds you will have to introduce to compilation
> phases just like in other builds.
Doesn't sound very good, one more reason to avoid it.
> > 4) It's still unclear what is the importance of maindllp.c, as it's not
> > used anywhere inside Harbour.
>
> It has to be linked with DLL library created bu user. It allows to
> use such DLL with static (of course if symbol used in maindllp.c are
> exported) and dynamic (using harbour.dll) Harbour applications.
Thanks, I think I got it now. (except for the content of that file)
> IMHO it is widely used. Just check in the archive how many people asked
> about it when __EXPORT__ macro name was changed to HB_DYNLIB. I guess
> that so far most of users updated their build scripts and JF is one
> of the last one. In xharbour.news you can also find that people quite
> often ask how to make own .DLLs or how to use own .DLLs without
> xharbour.dll but with static binaries (AFAIR some of them asked about
> it on this list too).
Usage of harbour.dll per se was also changed by __EXPORT__, and
I assume this created most of the confusion. Difficult to know, even
.dlls were quickly changing and are very much immature areas (on Windows)
maybe even till today, so I'm not sure how many highly advanced users
are out there actually using this. I wouldn't think it's a very
high number.
Certainly not high enough to design whole Harbour around it, or
introduce bad side effects for 99% of users. BTW, so far no one could
tell any good reason to use it, which doesn't mean there aren't any, but
these
are probably less obvious than most other things. I'd certainly be
interested
to hear about them, after spending so much time making them available.
> > [ A possible one is to have stubs for these exported functions, ...
> > should be disabled in such mode. ]
>
> Yes, it's interesting solution. maindllp.c should be updated to look
> also for alternative names of above functions. This new library should
> not be a part of harbour.dll.
Of course. In fact it's already being filtered out at .dll creation
phase in hb-mkdyn.bat.
> In such case it will be enough if user will add to his code linked
> in static part of application a REQUEST, f.e.:
> REQUEST HB_EXPORT
> to force linking the library module. Or we can simply use .obj file.
> In such case it will be enough to link it. We can also add an option
> to hbmk2 to link such .obj file.
> Such separated code linked with static part of applications resolves
> also other problem. It's not necessary to know the exact name of
> harbour.dll in dynamically linked applications. In fact we need only
> one symbol to be exported. It can be function which will return addresses
> of any other functions necessary for loaded module, f.e.:
>
> HB_EXPORT FARPROC hb_getProcAddres( int iFunc )
> {
> switch iFunc:
> case 1;
> return ( FARPROC ) &hb_vmExecute;
> case 2;
> return ( FARPROC ) &hb_vmProcessDllSymbols;
> [...]
> default:
> return NULL;
> }
>
Okay, so let's pick that for a direction. I will need help because
this is really an area very very, very off track of everything I'm
expert in or even interested in.
I'd avoid including object files in the distribution to keep things
consistent, so I'd say let's stick with a lib.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
