Delay loading DLLs anyone?

[voodooattack]

Can FB support delay-load modules?

I've actually tried to find any topic about this in the gnu linker "ld"'s manual.. no trace of such thing.. :(

even when i try to link using the Visual Studio linker to add delay loading, i've gone through the pain of linking to gnu (libgcc/mingw32) stuff, yet, after solving it out.. i hit the dead line..

the linker complains about these symbols:

Code: Select all

___FB_CTOR_BEGIN__
___FB_CTOR_END__
___FB_DTOR_BEGIN__
___FB_DTOR_END__

which i found in the linker script file "i386pe.x"

Code: Select all

    ___FB_CTOR_BEGIN__ = . ; __FB_CTOR_BEGIN__ = . ;
    *(.fb_ctors);
    ___FB_CTOR_END__ = . ; __FB_CTOR_END__ = . ;
    ___FB_DTOR_BEGIN__ = . ; __FB_DTOR_BEGIN__ = . ;
    *(.fb_dtors);
    ___FB_DTOR_END__ = . ; __FB_DTOR_END__ = . ;

since i can't read that, i was asking.. is there any way to get over it..?

and if there's any, could the support for delay load modules be added as a freebasic built-in feature (i'd be really glad to help)..

delay loading modules can be really important for systems like windows, where APIs actually dissapear on some versions... :(

i know ld supports "lazy binding" modules on linux, so i think portability wouldn't be of much trouble.. am i correct?? or is there something i'm missing?



thanks :)

[cha0s]

are you talking about specifying WHEN the dll is loaded? if so you could try the dylib* commands i.e. dylibload, dylibsymbol... theres some more too that i cant remember

[voodooattack]

are you talking about specifying WHEN the dll is loaded? if so you could try the dylib* commands i.e. dylibload, dylibsymbol... theres some more too that i cant remember

well that's kinda correct, but in a different way..
the loading/unloadaing is managed by linker generated code...

this means that a delay loaded module, will get loaded only the 1st time a function from that dll is called.. :)

what actually happens is that, the linker creates a section in the executable called .IAT that contains a table of every delay load import, while each function addresses a tiny stub that's generated for every function..

what actually happens when you call a delay load import?, the loader queries the address from the .IAT, and calls it, the tiny stub determines what dll/function name is required, and pass the info to a per-dll stub that loads the dll, finds the function and patches the .IAT so any further calls to the functions go directly, then calls your function passing the parameters of the 1st call :)

in case the loader is unable to find the function/dll an expection is triggered that can be easily trapped by setting an expection handler...

see, this allows you to port newer apps to older systems without major code changes..

[cha0s]

ah... no idea, sorry. :S

[v1ctor]

No idea either, if LD supports that in Linux, i guess there's some way to do the same in Windows - while applications like Firefox don't appear to use that in Windows (dunno if its built with Mingw).

The ___FB_CTOR_'s were removed in 0.16, but without the C++ constructors list been called, module-level and static constructors defined in FB won't work.

[voodooattack]

No idea either, if LD supports that in Linux, i guess there's some way to do the same in Windows - while applications like Firefox don't appear to use that in Windows (dunno if its built with Mingw).

The ___FB_CTOR_'s were removed in 0.16, but without the C++ constructors list been called, module-level and static constructors defined in FB won't work.

thanks i'll try to dig it up ;D