Porting DLL wrapper from Delphi to Lazarus - app crashes

[Tomas Silva]

Hello all,

I'm working on porting an application from Delphi to Lazarus, and that involves porting a few custom components I wrote as well.

One of those components is giving me a major headache. It's a component that wraps around a set of C-implemented functions from a vendor DLL which allow for communications between systems (probably not familiar to most, it's called HDX from Avaya). The details shouldn't be important: it's a set of functions which I've declared as

Code: Pascal  [Select][+][-]

1. cdecl; external "dll_name.dll";

and they get structured together by the component, so when I invoke the component's method "Inicializa" a sequence of functions is called to connect to a server and set up a listening channel which then receives connections.

Well, that all works flawlessly when compiled on Delphi. Lazarus compiles it fine as well, but when I run a Lazarus program using the component I get an External: ? error (not on the first DLL function, but on the second!).

I can't control this exception even through a try..except block. I tried using the component from the pallette, creating it dynamically - no difference.

I'm using Lazarus 1.8 with FPC 3.0.4.

I tried using different $PACKRECORDS, $PACKENUM and $OPTIMIZATION settings, to no avail.

Could anyone help me?

Thanks!

[PeterX]

{$MODE DELPHI} or {$mode objfpc}{$H+}  ?

[Tomas Silva]

Hi PeterX,

{$MODE DELPHI} or {$mode objfpc}{$H+}  ?

Tried both already. No change in results.

[PeterX]

If You not only wrap C function calls  but have a more complex object,
Create, Init, AfterConstruction, ... BeforeDestruction, Destroy ..

Probably You access properties that are not ready, in Lazarus' LCL ?
LCL internally is different from VCL .. 

[Tomas Silva]

That doesn't look to be the case. The component is pretty simple, and all properties I access can be evaluated at debug time. The exception occurs point-blank at the moment I try to execute the second function.

[Thaddy]

Code: Pascal  [Select][+][-]

1. cdecl; external "dll_name.dll";

Really? Even Delphi doesn't know that syntax, (double quotes!!!)

Code: Pascal  [Select][+][-]

1. cdecl external 'dll_name.dll';

is more likely, as is stdcall instead of cdecl.
The double quotes should give you a syntax error and on Windows stdcall is more likely than cdecl, although it can happen.
And what's missing is the dll entry name...

Code: Pascal  [Select][+][-]

1.  external 'dll_name.dll' name 'whatever_you_are_looking_for_function';

Note in both Delphi as  FreePascal 'name' is case sensitive. It can also be an index number, although that is rare.

Your example code doesn't work in both Delphi AND FreePascal.

[Tomas Silva]

Hi Thaddy, of course if I had used double quotes on my code I wouldn't have even been able to compile my program. You must think I'm just guessing my code. I'm not. I reproduced it kind of loosely, I admit it, and used double quotes on my post instead of single; it's not like that on my code. So you're right.

About cdecl or stdcall, I tried both - in fact I started out with the latter. Both with the same results.

Although you seem to have taken the time to mock me a little, thanks for the tip about repeating the function's name after the declaration. Indeed I never had to use that on Delphi, maybe that's what's missing on my Lazarus version. I'll try that and report back.

Cheers!

[marcov]

Does your code strictly adheres to the principle that whatever module (exe,dll) allocates memory also frees it ?

[Tomas Silva]

No good. The app still crashes. On the Details that Windows provides, the Fault Module Name is "ntdll.dll" which is NOT the DLL where the functions exist; obviously the exception occurs at some inner part of the execution.

[Tomas Silva]

Hello, marcov!

Does your code strictly adheres to the principle that whatever module (exe,dll) allocates memory also frees it ?

Yes, pretty much. All allocating routines defined in the DLL have corresponding freeing routines, and my code is structured with that principle in mind.

[Thaddy]

Indeed I never had to use that on Delphi, maybe that's what's missing on my Lazarus version. I'll try that and report back.
Cheers!

Then you were using a Delphi version completely unknown to me.... Delphi demands the syntax as I wrote, it is FPC that has more relaxed rules..

[Tomas Silva]

Thaddy, believe me, I've been using only this for years:
(modified for clarity)

Code: Pascal  [Select][+][-]

1. function function_name(parameter: integer): integer; stdcall; external 'DLLName.dll';

Mostly on Delphi XE5, but before that I used the same syntax I don't even know how many times. So yes - your version of Delphi seems to be quite different indeed.

Anyway the change didn't make any noticeable difference on the result...

[Tomas Silva]

On my initial post I only posted from the "cdecl" onwards as I thought this was obvious and too tiny a detail to linger over, sorry if I misjudged.

[Thaddy]

On my initial post I only posted from the "cdecl" onwards as I thought this was obvious and too tiny a detail to linger over, sorry if I misjudged.

How does the linker know what routine to call? This is never gong to work with both the Delphi internal linker or the FPC internal linker.
You should have name <string> or index <ordinal>

Post me some - working- Delphi code....

Maybe you confuse some statically linked code with the use of a dll? As long as the name is correct that could work, but not with a dll.
Note I worked for Borland, I know these things...(most of the time)

[Tomas Silva]

Hey Thaddy, as I stated before, I use this:

Code: Pascal  [Select][+][-]

1.  function function_name(parameter: integer): integer; stdcall; external 'DLLName.dll';

The routine to call is function_name, as long as it matches the definition on the DLL.

Sorry - I thought that was common knowledge.