Archived Forum Post

Index of archived forum posts

Question:

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);

...

implementation

uses chilkat_DLL_loader;

type

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

...

var

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

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

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

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

...

and in chilkat_DLL_loader something like:

function    Chilkat_CanUse:Boolean;

procedure   Chilkat_GetProcedureAddress(var P; ProcName: string);

implementation

uses windows, sysutils;

const

DLLPath = '...';

var ModuleName: String;

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

{$ifdef Win32}

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

{$else}

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

{$endif}

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

procedure   Chilkat_GetProcedureAddress(var P; ProcName: string);
var
    ModuleHandle: HMODULE;
begin
    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);
    end;
end;

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

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 (?)

Answer

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

Answer

Please see my post - http://www.chilkatforum.com/questions/11380/error-when-using-upx-with-chilkat-delphi

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

Answer

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..

Answer

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.

Rich

Answer

Here's a build where the .pas files use the dynamic loading scheme you suggested: http://chilkatdownload.com/prerelease/chilkat-9.5.0-delphi-dyn.zip

This is v9.5.0.62. I released v9.5.0.62 on the chilkatsoft.com 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..

Answer

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.

Answer

Thanks, this new build fixes it:

http://chilkatdownload.com/prerelease/chilkat-9.5.0-delphi-dyn.zip

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..

Answer

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