Archived Forum Post

Index of archived forum posts


delphi (DLL version) static DLL names

Oct 21 '16 at 11:37

(possible to make feature request here ?)

linking to fixed DLLName like

function CkSFtp_Create: HCkSFtp; stdcall; ... implementation

function CkSFtp_Create; external DLLName;

is unhandy because of some reasons:

  1. the path must be in search path and you can't give a specific location f.e. in a config-file if needed for several applications in different paths.

  2. if the dll cannot be loaded the application will abort immediately without error message.

  3. if you need a certain functionality f.e. SFTP or MAIL just only in seldom concrete situations then only on first use of that will be nessary to load the DLL and link the DLL-Entries. But in the actual implementation the DLL is loaded on EVERY start which slows down the start of the application.

will there be any chance to switch this to dynamically loading ? f.e.

function    CkSFtp_Create: HCkSFtp;
procedure   CkSFtp_Dispose( handle: HCkSFtp);



uses chilkat_DLL_loader;


TFkt_CkSFtp_Create          =function   : HCkSFtp;      stdcall;
TFkt_CkSFtp_Dispose         =procedure( handle: HCkSFtp);       stdcall;



_lcl_init:Boolean = true;
_fkt_ptr_arr:   array [0..266] of Pointer;

function    _Map( k:Integer; n:String):Pointer;
    Result:=    _fkt_ptr_arr[k];
    if Result = nil then begin
        Chilkat_GetProcedureAddress( Result, n);
        _fkt_ptr_arr[k]:=   Result;

function        CkSFtp_Create: HCkSFtp;
    Result:=    TFkt_CkSFtp_Create(_map( 0, 'CkSFtp_Create'))
        ( );

procedure   CkSFtp_Dispose(
                                handle: HCkSFtp
    TFkt_CkSFtp_Dispose(_map( 1, 'CkSFtp_Dispose'))
        ( handle);


and in chilkat_DLL_loader something like:

function    Chilkat_CanUse:Boolean;

procedure   Chilkat_GetProcedureAddress(var P; ProcName: string);


uses windows, sysutils;


DLLPath = '...';

var ModuleName: String;

function        Chilkat_LoadModule:HModule;
    S:  String;
    S:=             DLLPath;

{$ifdef Win32}

    ModuleName:=    S + '\ChilkatDelphiXE.dll';


    ModuleName:=    S + '\ChilkatDelphiXE64.dll';


    Result:= GetModuleHandle(PChar(ModuleName));
    if Result = 0 then
        Result:= LoadLibrary(PChar(ModuleName));

procedure   Chilkat_GetProcedureAddress(var P; ProcName: string);
    ModuleHandle: HMODULE;
    if not Assigned(Pointer(P)) then begin
        ModuleHandle := Chilkat_LoadModule;
        if ModuleHandle = 0 then
            raise Exception.Create('Library not found: ' + ModuleName); // + ' ' + WLastError);
        Pointer(P) := GetProcAddress(ModuleHandle, PChar(ProcName));
        if not Assigned(Pointer(P)) then
            raise Exception.Create('Function not found: ' + ModuleName + '.' + ProcName);

function        Chilkat_CanUse:Boolean;
    Result:=    Chilkat_LoadModule <> 0;

I transformed each chilkat source in that way, but I think it would be better chilkat will provide the dynamically loading if other users will also need that kind of loading (?)


Thanks! I'll see what can be done... (I can't promise anything for now..)


Please see my post -

There is a valid reason you would want to add this enhancement.


Thanks! I'll try my best to get this in the v9.5.0.62 release. I'll likely post a pre-release here for you to test.. It should be this week..


I wrote a parser last night to reformat the code, I'll email the refactored units to support. If you're interested in it, you're free to use any or all parts of it.



Here's a build where the .pas files use the dynamic loading scheme you suggested:

This is v9.5.0.62. I released v9.5.0.62 on the site, and it still uses the old. I gave this a quick test and it looked OK. If you find any issues, please let me know.

Assuming all is OK, the next version released will contain the .pas files w/ this dynamic loading..


I did a diff of the code and found some issues: Atom.pas - several entries still have the stdcall directive on the methods in the interface section - ie. CkAtom_AddEntry.
Cache.pas - the CkCache_AddRoot has it also.
Cgi.pas - getAsyncBytesRead, AsyncPostSize, getSizeLimitKB, putSizeLimitKB and GetUploadSize used to be type LongWord, now they are Integer, not sure which is correct. CkGgi_AbortAsync and SleepMS have the stdcall directive

SocksProxy.pas existed in the old version but is missing from new one, intentional?

I stopped there as I see that there are a number of other units that still have the stdcall directive on some of the calls. I would guess that however you're creating these headers, once you fix whatever is causing this it'll resolve it in all the units.


Thanks, this new build fixes it:

Also, the Cgi class is deprecated and in any case, I don't think the Cgi class would be of any use in Delphi. It's not like a Delphi program would be running on a web server receiving incoming HTTP requests.

Also, the SocksProxy class was removed long ago. The Delphi .pas wrapper was still leftover, but couldn't have been used anyway..


Did a code review of this latest version, looks good to me.

It was a good exercise looking through all of those units, gave me some ideas on various other 3rd party software we use that we can replace with things implemented in ChilKat.

Thank you! Rich