How to pass a C string to a pascal function in a dll

Question

0.00/5 (No votes)

See more:

Hello guys.
I have a DLL containing this function:

function DCL_Initialize(bDeviceID: Byte; sIP: PAnsiChar): Byte; stdcall external 'DCL.dll';

now I want to call this function from C as this(somewhat simplified):

C++

#define DLL_EXPORT __declspec(dllexport) __stdcall
typedef char DLL_IMPORT DCLINITIALIZE(char bDeviceId, char *pStr);
pString = "Some string";
DCLINITIALIZE * pfnInitialize = (DCLINITIALIZE*)GetProcAddress(hModule, "DCL_Initialize");
if (pfnInitialize)
  pfnInitialize(1, pString);

The function doesn't return.
I think passing string to pascal routines from C may have special considerations.
My knowledge of pascal is very limited. and I don't know what is pAnsiChar;
Can anybody help me?

Edit:
I'm not sure the library is written in pascal. The only thing I know is its pascal prototype and that it works in a delphi application correctly.
pumpbin.exe /exports shows the names of funtions not capitalized

Edit2: string Software\Borland\Delphi\Locale found in DCL.dll several times, so it may be created by delphi

Edit3: The thread encounters a first chance exception and terminates. but the equivalent code in delphi works. the only thing to matter is passing char *sIP to
pascal function. is char * in C compatible to PAnsiChar in pascal?

Edit4: Visual studio 2013's debugger and delphi's debugger show different disassembly. Bellow is shown some part of both. The difference is marked by my comment.

C++

/11th assembly instruction in DCL_Initialize loaded by delphi 7
0029B8E7 55         push ebp
0029B8E8 688ABA2900 push $688ABA2900
0029B8ED 64FF30     push dword ptr fs:[eax]
0029B8F0 648920     mov fs:[eax], esp
//The following assembly instruction is two byte in delphi, 4 byte in C, and they are entirely different
0029B8F3 33DB       xor eax, eax    //different from C disassembler
0029B8F5 C605F0FF290000 mov byte ptr [$0029FFF0], $00
0029B8FC 33C0       xor eax, eax
0029B8FE 55     push ebp
0029B8FF 6863BA2C00 push $002CBA63
0029B904 64FF30     push dword ptr fs:[eax]
0029B907 648920     mov fs:[eax], esp
0029B90A 8A4508     mov al, [ebp+$08]
0029B90D E8FEFEFFFF call -$00000102
0029B912 85C0       test eax, eax
002CB914 740F       jz +$0f


//11th assembly instruction in DCL_Initialize loaded by C(Caller code compiled by visual studio 2010 or 2013)
004D52C7 55                   push        ebp
004D52C8 68 0E 55 4D 00       push        4D550Eh
004D52CD 64 FF 30             push        dword ptr fs:[eax]
004D52D0 64 89 20             mov         dword ptr fs:[eax],esp
//The following assembly instruction is two byte in delphi, 4 byte in C, and They are entirely different
004D52D3 C6 45 FF 00          mov         byte ptr [ebp-1],0   
004D52D7 C6 05 18 54 4E 00 00 mov         byte ptr ds:[4E5418h],0
004D52DE C6 05 20 54 4E 00 00 mov         byte ptr ds:[4E5420h],0
004D52E5 C6 05 19 54 4E 00 00 mov         byte ptr ds:[4E5419h],0
004D52EC 33 C0                xor         eax,eax
004D52EE 55                   push        ebp
004D52EF 68 E5 54 4D 00       push        4D54E5h
004D52F4 64 FF 30             push        dword ptr fs:[eax]  
004B52F7 64 89 20             mov         dword ptr fs:[eax],esp
004B52FA 8A 45 08             mov         al,byte ptr [ebp+8]
004B52FD E8 FA FD FF FF       call        039B50FC  
004B5302 85 C0                test        eax,eax
004B5304 74 11                je          039B5317

~~And noticable is use of fs segment register in delphi dll. Is delphi's PE model is flat?~~
Edit5: dumpbin /disasm produces an assembly listing exactly matching that of C disassembly, different from disassembly of Delphi.

Posted 2-Jul-15 1:13am

mr.abzadeh

Updated 5-Jul-15 1:37am

v10

Add a Solution

2 solutions

Solution 1

The pascal convention seems to be obsolete. Check here for more info:
https://msdn.microsoft.com/en-us/library/wda6h6df.aspx[^]

Good luck!

Posted 2-Jul-15 1:27am

E.F. Nijboer

Comments

mr.abzadeh 2-Jul-15 8:55am

I don't want to use pascal calling convention. I want to use a function in a dll whoes pascal prototype is known. source code not available

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Frankie-C · Accepted Answer · 2015-07-02T01:53:00

Solution 2

You have to simply provide a prototype for the function to call that is equivalent to PASCAL function.
In your case it should be:

C++

#pragma comment(lib, "DCL.lib")
#ifdef __cplusplus
extern "C" {
#endif
char __declspec(dllimport) WINAPI DCL_Initialize(char bDeviceID, char *sIP);
#ifdef __cplusplus
    }
#endif

The function name is normally all capitals in PASCAL. Delphi don't capitalize functions.
The pragma instructs the linker to include the library DCL.lib in the link stream, you have to pass to the linker the folder the dll is (normally the /I switch). If you don't have a typelibrary (DCL.lib) available for the dll you can use an utility to build a typelib from a DLL, i.e. Tlbexp.exe[^] from MS, or polib from PellesC[^].
Or loading dinamically the function as in your sample.
The pAnsiChar, aka PChar, type is equivalent to the null terminated C string.
If the function don't return you have to check with debugger to understand what happens. One problem could be due to Pascal compiler, while C is generally compliant PASCAL isn't. Maybe the calling convention is different.
I have also noticed that you removed the underscore between DCL and INITIALIZE in function name. Make a dump of DLL and check if both functions, DCL_INITIALIZE and DCLINITIALIZE, exists, in that case you are calling a different function.

Posted 2-Jul-15 1:53am

Frankie-C

Updated 2-Jul-15 6:25am

v7

Comments

mr.abzadeh 2-Jul-15 8:51am

That didn't work. The error is:
error LNK2019: unresolved external symbol "__declspec(dllimport) char __stdcall DCL_Initialize(char,char *)"
The function name in uppercase also didn't work. dumpbin.exe /exports shows the function name not capitalized. I'm not sure the DCL.DLL is written in pascal, The only thing I know is it's pascal prototype
function DCL_Initialize(bDeviceID: Byte; sIP: PAnsiChar): Byte; stdcall external 'DCL.dll';
is used in a delphi application and it works correctly.
I think using #pragma comment will not work here because the DCL.dll doesn't export function __imp_DCL_Initialize

Frankie-C 2-Jul-15 12:17pm

The name of the function then is 'DCL_Initialize' because you got it with podump.
The __imp_DCL_Initialize should exist because it is automatically created from the linker when builds the jump table.
The #pragma comment tells to the linker to include the import library DCL.lib, not to change symbol. You can remove it and add DCL.lib to the linker input files list.

mr.abzadeh 2-Jul-15 13:04pm

The DCL.lib is compiled and linked with borland delphi, and no __imp_... functions exist in it. There isn't any decorative problem, because I Get the address of function. dumpbin.exe with option /exports shows exactly the same name, no decoratation exists in DCL.dll. It is interesting that the function name is case sensitive. I think The only problem is compatibility of char * and PAnsiChar. Sorrily, I don't have a delphi or pascal compiler to test this problem on depth. Thanks a lot

Frankie-C 3-Jul-15 5:31am

Sure the library name is undecorated. I refer to the decoration problem on C compiler side (and this could be correct using the 'extern C'). But I forget that even C will look for the decorated symbol DCL_Initialize@8 that doesn't exist in your library. What I don't understand is if you created an import library from the DLL or not. If you don't you'll never find aliased symbols.
Anyway using the GetProcedureAddress should solve the problem.
The not return problem can be related to parameters, as far as I know in C and Delphi they are pushed onto the stack in the same order (reversed respect as they are declared), but just to check you can try to reverse them in the function declaration.

Frankie-C 2-Jul-15 12:22pm

Are you using C or C++? If you're using C++ the problem could be the decorations.
Try to include the declaration between 'extern C' See updated answer.

mr.abzadeh 2-Jul-15 9:03am

The pascal prototype shows stdcall. The function name is DCL_Initialize and It exists because GetProcessAddress finds it. The removal of underscore is by mistake.
I debug the assembly instructions until I reach the instruction 'call eax' ehich does not return. so this can not be because of calling convention.

Frankie-C 2-Jul-15 12:20pm

The instruction 'call eax' is inside the function DCL_Initialize?

mr.abzadeh 3-Jul-15 4:34am

Yes, since pfnInitialize is a pointer fo function, The compiler calls it in this way:
move eax, dword ptr pfnInitialize
call eax

Frankie-C 3-Jul-15 5:20am

So this is before entering the DLL code.
What you should do to check for wrong calling convention is to find the return instruction and check if the function returns to a wrong address. If so there could be wrong calling convention or stack corruption. For the __stdcall convention you must encounter something as:
. mov esp,ebp
. pop ebp
. ret 8 //__stdcall cleans stack on return
Now you have 2 cases:
1. Your software never reaches the return -> wrong parameters, missing Delphi runtime or the like
2. After ret instruction you don't return to the calling point: wrong calling convention, stack corruption or wrong parammeters.
The program simply hung-up or you get an exception?

mr.abzadeh 3-Jul-15 13:40pm

I shouldn't say 'Yes' above. the function is __stdcall. It's return instruction is ret 8. but the problem is that It hangs, debug window shows a first chance exception, and thread terminates. but 20% of cpu is taken by my app(how is cpu taken, once thread terminated?), and never returns.
The equivalent code in Delphi works. It returns and never hangs.
the delphi code is as this:
{declaration}
function DCL_Initialize(bDeviceID: Byte; sIP: PAnsiChar): Byte; stdcall external 'DCL.dll';
{usage}
procedure TForm1.Button1Click(Sender: TObject);
begin
{Edit1 and Edit2 are TEdit controls}
DCL_Initialize(StrToInt(Edit1.Text), PAnsiChar(Edit2.Text));
end;

mr.abzadeh 3-Jul-15 15:23pm

Never reaches the return point. wrong parameters is not a candidate because a test delphi app calling with exactly the same parameters succeds.
Now I have 2 cases:
1: Missing delphi runtime. if so, calling a function from a delphi dll from c will be feaseless
2: Internal structure of pAnsiChar maybe not compatible to char *.

Frankie-C 4-Jul-15 9:33am

The CPU used by your app may be used by another thread created inside the call that runs for a while before to die, or could be the OS housekeeping on memory in case of memory access exception. The debugger should tell you when the app under test is creating another thread.
What you mean for 'first chance exception'?
No doubt on the PAnsiChar, it is the C null terminated string, so it is correct. But looking to Delphi code I'm not sure that you're passing an ANSI string, maybe the problem is that it wants a widechar string, you could check. In this case the typedef should be:
typedef char DLL_IMPORT DCLINITIALIZE(char bDeviceId, wchar_t *pStr);
About the runtime don't know what to tell, eventually you can have a look at libraries loaded in Delphi...
This DLL is publicy available?

mr.abzadeh 4-Jul-15 15:41pm

First chance exception. And the thread is terminated. That's what debug window's saying, not me. I'm passing ansi char, delphi passes ansi char, and the routine expects ansi char, I debuged the routine to a point in C and delphi. Both were stdcall. parametes passed right to left, stack cleaned by called routine. Strange is that disassembly window in Delphi and visual studio are different. Please see my Edit on main post

Frankie-C 4-Jul-15 17:12pm

Ok the debugger got an exception and passed it back to sw for handling, but it should say also what kind of exception is.

The sequence:
xor eax,eax
push ebp
push xxxxxxxxh //some exception handling address
push dword ptr fs:[eax]
mov dword ptr fs:[eax],esp

is used to set the structured exception handling (SEH), and the register fs points to the current TIB (at fs:[0] there is a pointer to an EXCEPTION_REGISTRATION structure). For more info see http://reverseengineering.stackexchange.com/questions/2895/delphi-pascal-try-except-finally-block.
But from your report it seems that you are looking to two completely different functions... :-( Are there multiple functions with similiar names in your DLL?

mr.abzadeh 4-Jul-15 17:26pm

No, only one function. dumpbin.exe /exports only one function with this name. but they are different when called from C and delphi. why? It's not a bug of disassembly because eip changes appropriately.
The information you provided about exception handling I understand that the DLL functions uses it's own try/catch. This is the reason that the exception is not cached by host functions try/catch. I will try to bypass DLL function's try/catch to see if I can catch the exception

mr.abzadeh 4-Jul-15 17:36pm

I tried to bypass DLL function's exception handling by skipping
mov dword ptr fs:[eax],esp
No success. It seems that the DLL function uses try/catch in many inner functions

Frankie-C 4-Jul-15 17:53pm

The assembler code you reported has a lot of errors, I don't know if the disassembler has problems or you made some transcription errors (if you manually wrote it).
But I can't see any reason for different dissassembly (the opcodes are absolutely different). And the C disassembly make much more sense than the Delphi one...
Try to create a disassembly of the whole dll using dumpbin with switch /DISASM. Redirect the output to a file.

mr.abzadeh 4-Jul-15 19:02pm

I copy and pasted C disassembly, and I type the delphi disassembly because delphi 7 disassembler didn't allow copy. I didn't modify anything. I searched for the binary code in the image itself. It matches the C disassembly and differs from the delphi disassembly. I have com to a point that the DLL modifies
it's code when loading from delphi, may occur on dllMain, possibly to protect itself. I will try dumbin /disasm also.
Thanks for helping me.

mr.abzadeh 5-Jul-15 6:42am

dumpbin /disasm produces an assembly listing exactly matching that of C disassembly, different from disassembly of Delphi.

Frankie-C 5-Jul-15 7:08am

Really strange, anyway looking again the disassemblies you have write in the question there a re 16 bytes missing in the Delphi one, the C procedure seems 16 bytes longer, and this make no sense. You may want to check again the delphi disassembly.
If the Delphi code is scrambled you should see a call somewhere in delphi source, or in DllMain, else there is a little stupid error you are doing in dynamically linking the procedure.

mr.abzadeh 2-Jul-15 10:03am

DCLINITIALIZE is a typedef, not function name

Frankie-C 2-Jul-15 12:18pm

My wrong. I've not seen.