Free Pascal can't find entry point for dll - delphi

I am complete new to pascal.
I want to call my function in .dll file in free pascal and I get following error when I run the project:
The procedure entry point GetProcAddress could not be located in the dynamic link library HNLib.dll.
here is the code:
Program Test;
function GetProcAddress : Integer; cdecl; external 'HNLib.dll';
function GetProcAddress : Single; cdecl; external 'HNLib.dll';
procedure GetProcAddress( X : Single); cdecl; external 'HNLib.dll';
procedure GetProcAddress; cdecl; external 'HNLib.dll';
begin
GetProcAddress( 5.5 );
readln;
end.
.pas file and dll are in one directory.
Please Help ME!

GetProcAddress is not what you seem to think it is; it's purpose is to locate named procedures or functions in a DLL and return the address of that function so it can be called from your code. You have to first use LoadLibrary to load the dynamic link library (DLL) into memory, and then pass a handle to that DLL as the first parameter of GetProcAddress and the name of the function whose address you want as the second parameter. If the function can be found in the DLL, it's address is returned, and you can use that address to call the function.
(In addition, GetProcAddress is pretty Windows-specific, and the majority of functions in the WinAPI are stdcall and not cdecl. Unless you have documentation saying that the functions are using the cdecl calling convention, you should probably use stdcall.)
You would also need at least the Windows unit in your uses clause, since that's where GetProcAddress and LoadLibrary are declared.
See the WinAPI documentation on LoadLibrary and GetProcAddress for more information.
For a beginning programmer, you'll probably find it easier to use static linking of the functions instead of dynamic (which you get with GetProcAddress). An example of static linking would be (untested !!!- just a quick code example, since I don't have 'HNLib.DLL' to link against):
// Your Dll import unit
unit MyDllProcs;
interface
function GetIntCalcResult(const IntVal: Integer);
implementation
function GetIntCalcResult(const IntVal: Integer); stdcall; external 'HNLib.dll';
end.
// Your own app's code
program Test;
interface
uses MyDllProcs;
implementation
function DoSomethingWithDll(const ValueToCalc: Integer): Integer;
begin
Result := GetIntCalcResult(ValueToCalc);
end;
begin
WriteLn('DoSomethingWithDll returned ', DoSomethingWithDll(10));
ReadLn;
end.
Note that when statically linking DLL functions like this, your DLL must be available when your app starts, and the function must be contained in that DLL; if not, your application won't load.
Also, note that you can't typically have multiple functions with the same name in the DLL, as there's no information available to use to figure which one to load when the load is being done. Each should have a separate, distinct name or the loading will probably fail.

Related

Call and Reuse the DLL functions dynamically

I have created a DLL file with some functions and wish to reuse in a program multiple times in its different functions. But the Access-violation error comes after 2nd function of the program when calls the same DLL functions.
I'm currently using GetProcAddress. For example:
function xyz:boolean
var
dllHandle : cardinal;
EnBFStr : TEnBFStr;
StrToHex : TStrToHex;
Encodeddata , HexString : UnicodeString;
begin
dllHandle := LoadLibrary('Utilities.dll') ;
if dllHandle <> 0 then
begin
Encodeddata:='Sample';
#EnBFStr := GetProcAddress(dllHandle, 'EncodeBlowFishString') ;
#StrToHex := GetProcAddress(dllHandle, 'UniStrToUniHexStr') ;
if Assigned (EnBFStr) then
Encodeddata:=EnBFStr('Key','Text') ; //Sample would be replaced
if Assigned (StrToHex ) then
HexString :=StrToHex(Encodeddata) ; //call the function
FreeLibrary(dllHandle) ;
end;
There are other functions which is loading the library and calling these DLL functions multiple times. Also, within the same procedure/function, we are calling these DLL functions multiple times in (IF Else) conditions.
In earlier part of the program, I have tried to check for the DLL file is present. Also, I tried to directly load the functions as another alternative:
function EncodeBlowFishString (Const Key:UnicodeString; Const DecodedString:UnicodeString; ): UnicodeString; stdcall;
external 'Utilities.dll' name 'EncodeBlowFishString';
function UniStrToUniHexStr(Const aString:UnicodeString): UnicodeString; stdcall;
external 'Utilities.dll';
You are breaking the rules of memory allocation for DLLs. The return value is allocated by the callee but deallocated by the caller. Two solutions:
Use ShareMem as described in the comment at the top of a new library project.
Use standard interoperability techniques to ensure that allocation and deallocation always happens in the same module.
As an aside it is greatly wasteful to load and unload a DLL each time you want to use it. Load the DLL once only.
Furthermore I would like to point out that encryption operates on binary data and in my view you are storing up a world of pain by working instead with text.

Dynamicly handle not defined functions in a dll in dlephi

I have a dll which defines a simple functions to show a message:
library testdll;
uses SysUtils, Classes, Dialogs;
{$R *res}
procedure ShowDll;stdcall;
begin
ShowMessage('ShowDLL testdll.dll');
end;
exports ShowDLL;
begin
end.
And my main file call this dll dynamicly using this procedure:
i defined a new type:
type
testdll = procedure;stdcall;
Then on my button click event:
procedure TForm1.Button1Click(Sender:TObject);
var
dllHandle: THandle; //Don't use Cardinal; it's limited to 32-bits
test : testdll;
begin
dllHandle := LoadLibrary('testdll.dll');
if dllHandle <> 0 then
begin
#test := GetProcAddress(dllHandle,'ShowDLL');
if Assigned(test) then
ShowDLL
else
ShowMessage('Func not found');
end
else
ShowMessage('dll not found');
end;
This works. But I don't know if it's possible to handle not defined functions with my dll. My purpose here is to call a function without knowing if it will be defined in my dll. So i would like the dll to tell me if the functions exists or not.
For example here i only have a ShowDLL procedure. If i call another method which does not exists it will show 'Func not found' from my main application. But i would my dll to tell me this. Is this possible? If yes, how could i achieve this pls?
EDIT: I can't modify the main function this is only a test. In my final version there will be only the dll. So exporting all functions into my main application is not possible here. That's why i want to know id the dll alone can handle it rather than doing this in my main application which i can't do.
I don't have acces to the main application to modify any code in it. I only know what are functions that will be used in this application that i will later export in my dll using exports statement. So what i try to achieve is to catch a not defined function with the dll if it's possible.
Your code already demonstrates how to detect the presence of an export. Namely to call GetProcAddress and compare the result with nil.
You can reduce the amount of boiler plate code by using delay loading. This essentially lets the compiler generate the code the performs the checks. This relies on the delayed keyword.
procedure testdll; stdcall;
external 'testdll.dll` delayed;
When you call this function, if it cannot be found, an exception is raised. Indeed this behaviour can be customised, as described in the documentation: http://docwiki.embarcadero.com/RADStudio/en/Libraries_and_Packages#Delayed_Loading
Update
In a comment to this answer you state that the executable cannot be changed. In which case, the message that you wish to avoid will be shown if the function is missing. You ask if the missing export can be handled by the DLL but that is not possible. When you call GetProcAddress, no code inside the DLL is executed. All the processing is done external to the DLL by reading its PE metadata.
The obvious conclusion is that the DLL must export the function. If the true DLL does not, put another DLL in its place. Use an interposer DLL that exports the function. Implement the function by delegating to the true DLL, if the true DLL exports the function. Otherwise do something else, whatever you please.

Point to a DLL using a dynamic path

My problem is not exporting a function, but importing it. I know for sure that both the function and DLL both work because I have used a hard-coded path to point to the DLL.
This is what is currently working:
function RoamingAppDataPath: String; external 'C:\Users\Peter\AppData\Roaming\ss\Application\ss.dll';
However I need to point to the DLL with a dynamic value so what I tried to do is
Declare a global variable (DLLPath: String)
Assign DLLPath the value - RoamingAppDataPath+'\ss\Application\ss.dll'
Note: RoamingAppDataPath is a function that outputs the path to the roaming app data folder.
The code I am trying to run is:
function RoamingAppDataPath: String; external DLLPath;
When I compile the code, Delphi is telling me that it is expecting a constant expression:
E2026 Constant expression expected
What is the work around for this?
You have to bind at runtime and that means you need to use LoadLibrary and GetProcAddress:
var
lib: HMODULE;
RoamingAppDataPath: function: string;
lib := LoadLibrary(dllfilename);
if lib=0 then
RaiseLastOSError;
Pointer(RoamingAppDataPath) := GetProcAddress(lib, 'RoamingAppDataPath');
And then you can call it:
radp := RoamingAppDataPath;
Some comments:
I don't know why you write this function when it exists in standard system libraries.
Using string across DLL boundaries is liable to fail. You need to be using ShareMem and make sure that all code is built with the same Delphi version. Better to allocate the buffer in the calling code.
Even if you would be able to use a Variable, you would nowhere be able to set a value to DLLPATH, since already initalization would not be used if a static DLL can not be used.
You will have to use dynamic loadingif you want to define the path for the DLL.
procedure Test;external 'Notexists.DLL';
var
Form2: TForm2;
implementation
{$R *.dfm}
procedure TForm2.Button1Click(Sender: TObject);
begin
test;
end;
initialization
Showmessage('Hallo'); // will never be seen if test is used.

Work around with Delphi DLL

I have two applications in Delphi for which I don't have any code source:
I use an interface from application A to call an DLL file from application B. Example, I usually pass a service number, 200011, from interface A to call DLL file B for a value return. But, recently the application A have changed the variable. I have to add P00200011 to call DLL file B.
I have tried to create an DLL C#, but the DLL in B is created with the fastcall convention and I cannot change this DLL file.
What are others ways I can do it? I'm out of ideas.
You need to write a wrapper DLL. You build your DLL with the functions you want to intercept, and in your code you simply load and call the original DLL. Then you place your wrapper in the same directory of your application. All calls from the application will go to your wrapper DLL and from there to the original DLL.
Here is a simple example
supose you have this library (B.DLL)
library B;
function B_FUNCTION(value:integer): integer; export;
begin
result:=value+1;
end;
exports B_FUNCTION;
end.
And this program that uses it
program A;
{$apptype console}
function B_FUNCTION(value:integer): integer; external 'b.dll';
var i:integer;
begin
i:=B_FUNCTION(2010);
writeln(i);
end.
Compile both programs and run them. The result printed is 2011.
Now, code your wrapper DLL
library w;
uses windows;
function B_FUNCTION(value:integer): integer; export;
var
adll: Thandle;
afunc: function(v:integer):integer;
begin
adll:=LoadLibrary('TRUE_B.DLL');
afunc:= GetProcAddress(adll,'B_FUNCTION');
result:=afunc(value+1);
FreeLibrary(adll);
end;
exports B_FUNCTION;
end.
Build it, you'll have A.EXE, B.DLL and W.DLL. Replace them
REN B.DLL TRUE_B.DLL
REN W.DLL B.DLL
Execute A, now it will spit 2012.
It's not entirely obvious to me which parts are yours and what calls what, but you should be able to create your own intermediate DLL in Delphi with an interface that uses fastcall and which forwards the call to the real DLL using another calling convention.

Delphi DLL / Form communication

I have embedded a form in a DLL and can call the DLL and show the form and return various functions from the DLL back to the main app, however I cannot figure out how to get the DLL to trigger events in the main applications form.
For example in the main app I have a dataset and I want to have a button on the form in the DLL to goto a certain record in the dataset but cannot see how this is done.
Can anybody could point me to an example or give me some pointers on how to to this?
If a DLL needs to invoke behavior in the host application, then the host should provide a callback function to the DLL that the DLL stores and calls when appropriate.
Your DLL exports a function that tells it to display the form, right? Add a couple of parameters to that function for the EXE to provide a pointer to a callback function. The callback function should accept at least one parameter, which should be of type Pointer. The caller (the EXE) will use that parameter as a context parameter, some way for it to be reminded why the DLL is calling the EXE's function. Your DLL will store the function pointer and the context pointer, and when it's time for the DLL to tell the EXE something, it will call that function and pass the context value back. The DLL won't do anything with the context value; it's just something to store and pass back to the EXE verbatim.
The DLL's interface will look like this:
type
TDllCallback = function(Context: Pointer): DWord; stdcall;
function DisplayForm(Parent: HWnd; Callback: TDllCallback; Context: Pointer): DWord; stdcall; external Dll;
The EXE will define a callback function like this:
function CallbackFunction(Context: Pointer): DWord; stdcall;
begin
TMainForm(Context).DoSomething;
Result := 0;
end;
It will call the DLL function like this:
procedure TMainForm.DoDllTaskClick(Sender: TObject);
begin
DisplayForm(Handle, CallbackFunction, Pointer(Self));
end;
Notice how the signature of CallbackFunction matches the TDllcallback type defined earlier. Tey both use the stdcall calling convention, and they're both standalone functions, not methods. Avoid methods since method pointers are particular to Delphi, and you shouldn't require your DLL to be used only by Delphi hosts, if possible.
Because DLL's code being executed in the same address space of main application there are a plenty ways of doing communications.
Define a callback function in the main app and give its address to the DLL.
Define a message handler in the main app and send a message from DLL in response to some event.
etc.

Resources