>>>>> #include "hbapi.h"
>>>>> HB_EXPORT_ATTR PHB_FUNC dll_hb_vmProcAddress( const char * szFuncName )
>>>>> {
>>>>> return hb_vmProcAddress( szFuncName );
>>>>> }
>> I see. Can't it be added unconditionally for all Windows .exes?
>> Is there any downside?
>
> It enables symbol exporting. It will increase final binaries due to
> additional runtime code and DLL symbol table. In MinGW it's about 35Kb.
> I know that it's not very much for current desktop computers but I do
> not like to link unnecessary code. I do not know what if it cause some
> noticeable startup speed overhead but I think it's minor.
>
> Alternatively we may not touch HBMK2 at all and users can add to their
> main .prg code:
>
> #pragma begindump
> #include "hbapi.h"
> HB_EXPORT_ATTR PHB_FUNC dll_hb_vmProcAddress( const char * szFuncName )
> {
> return hb_vmProcAddress( szFuncName );
> }
> #pragma enddump
>
> I've already implemented the modification I was talking about and used
> above code to test them,
I did some tests with mingw32-tdm and majority of the (here 32KB)
overhead is relocation table. Some compilers add it all the time (bcc),
for some it's good to turn it on to support address randomization
(though it's not 100% clear from docs if this is required or not).
It won't affect memory footprint, only disk size.
Truly though, it's too large of an effect to make on all .exes
for such a niche feature like pcode .dll.
As for the switch name I think it should be -hbexedyn.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
