Re^2: Win32::API and 'short' arguments

Thanks for so detailed an answer ! A few followup questions:

How do you dump a DLL in such way ? I want to examine mine and see if there's name mangling.
My DLL has no DEF file with it (it has a LIB file for linking from C++) and its .h file just places WINAPI as I demonstrated, so I guess I can't know which compiler options were enabled. Though I'm pretty sure it was compiled with a MS compiler.
So is there a chance to successfully call functions from the DLL if it was compiled with _cdecl ?
I get a segfault when I declare the arguments / return value as SHORT, but don't get it when I declare them INT. How can this be affected by what you described ?
Finally: will all the same problems surface using an XS wrapper for the DLL ?

Thanks in advance.

Comment on Re^2: Win32::API and 'short' arguments

Replies are listed 'Best First'.
Re^3: Win32::API and 'short' arguments by BrowserUk (Patriarch) on May 10, 2006 at 07:53 UTC
`dumpbin.exe /exports the.dll` If you have a tool available to disassemble the dll, you can work out which calling convention was used. For the example above, the when built using `_stdcall`, the disassembly looks like: `Disassembly of Function test (0x00331000) SYM:test 0x331000: PUSH EBP 0x331001: MOV EBP,ESP 0x331003: MOVSX EAX,DWORD PTR [EBP+0x8] ; ARG:0x8 0x331007: MOVSX ECX,DWORD PTR [EBP+0xC] ; ARG:0xC 0x33100B: ADD EAX,ECX 0x33100D: MOVSX ECX,DWORD PTR [EBP+0x10] ; ARG:0x10 0x331011: ADD EAX,ECX 0x331013: MOVSX ECX,DWORD PTR [EBP+0x14] ; ARG:0x14 0x331017: ADD EAX,ECX 0x331019: POP EBP 0x33101A: RET 0x10` [download] When built with `_cdecl` it looks like `Disassembly of Function test (0x00331000) SYM:test 0x331000: PUSH EBP 0x331001: MOV EBP,ESP 0x331003: MOVSX EAX,DWORD PTR [EBP+0x8] ; ARG:0x8 0x331007: MOVSX ECX,DWORD PTR [EBP+0xC] ; ARG:0xC 0x33100B: ADD EAX,ECX 0x33100D: MOVSX ECX,DWORD PTR [EBP+0x10] ; ARG:0x10 0x331011: ADD EAX,ECX 0x331013: MOVSX ECX,DWORD PTR [EBP+0x14] ; ARG:0x14 0x331017: ADD EAX,ECX 0x331019: POP EBP 0x33101A: RET` [download] The significant part of that is the last (RET) line. In the former, the called code (the function itself) is responsible for cleaning up the stack, hence `RET 0x10`. In the latter case, the calling code is responsible for cleaning up the stack, hence the bare return. Not with Win32::API that I am aware of. It might be possible to build a modified version to do it, but it would be messy. Using XS would be simpler and better. I don't really understand this. Are you using W::API::Prototype::ApiLink() or Win32::API->new() and 'ssss'? If the latter, according to the docs, the 's' template does not mean 'short', but 'struct'. As mentioned above, shorts are placed on the stack as ints; the difference is in how they are addressed (16-bit indirect operands instead of 32-bit indirect etc.). I think you would have to use 'IIII' for the latter method. I'm far from expert with XS. You would still need to determine which calling convention was used, but it should be possible to prototype the external call in the XS code to cater for either successfully, though you may need to do a little manual intervention if the dll was built with `_cdecl`. If you are not getting traps when using 'IIII' (or ApiLink and 'SHORT'), then odds are that it was built using `_stdcall` and Win32::API may be all you need. Though if you are prepared to get stuck in with writing an XS wrapper, it would be considerably more efficient. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Win32::API and 'short' arguments
by BrowserUk (Patriarch) on May 10, 2006 at 07:53 UTC

dumpbin.exe /exports the.dll

If you have a tool available to disassemble the dll, you can work out which calling convention was used. For the example above, the when built using _stdcall, the disassembly looks like:

Disassembly of Function test  (0x00331000)
  SYM:test
  0x331000: PUSH     EBP                                  
  0x331001: MOV      EBP,ESP                              
  0x331003: MOVSX    EAX,DWORD PTR [EBP+0x8]              ; ARG:0x8
  0x331007: MOVSX    ECX,DWORD PTR [EBP+0xC]              ; ARG:0xC
  0x33100B: ADD      EAX,ECX                              
  0x33100D: MOVSX    ECX,DWORD PTR [EBP+0x10]             ; ARG:0x10
  0x331011: ADD      EAX,ECX                              
  0x331013: MOVSX    ECX,DWORD PTR [EBP+0x14]             ; ARG:0x14
  0x331017: ADD      EAX,ECX                              
  0x331019: POP      EBP                                  
  0x33101A: RET      0x10
[download]

When built with _cdecl it looks like

Disassembly of Function test  (0x00331000)
  SYM:test
  0x331000: PUSH     EBP                                  
  0x331001: MOV      EBP,ESP                              
  0x331003: MOVSX    EAX,DWORD PTR [EBP+0x8]              ; ARG:0x8
  0x331007: MOVSX    ECX,DWORD PTR [EBP+0xC]              ; ARG:0xC
  0x33100B: ADD      EAX,ECX                              
  0x33100D: MOVSX    ECX,DWORD PTR [EBP+0x10]             ; ARG:0x10
  0x331011: ADD      EAX,ECX                              
  0x331013: MOVSX    ECX,DWORD PTR [EBP+0x14]             ; ARG:0x14
  0x331017: ADD      EAX,ECX                              
  0x331019: POP      EBP                                  
  0x33101A: RET
[download]

The significant part of that is the last (RET) line. In the former, the called code (the function itself) is responsible for cleaning up the stack, hence RET 0x10.

In the latter case, the calling code is responsible for cleaning up the stack, hence the bare return.

Not with Win32::API that I am aware of.
It might be possible to build a modified version to do it, but it would be messy. Using XS would be simpler and better.
I don't really understand this. Are you using W::API::Prototype::ApiLink() or Win32::API->new() and 'ssss'?
If the latter, according to the docs, the 's' template does not mean 'short', but 'struct'.
As mentioned above, shorts are placed on the stack as ints; the difference is in how they are addressed (16-bit indirect operands instead of 32-bit indirect etc.). I think you would have to use 'IIII' for the latter method.
I'm far from expert with XS.
You would still need to determine which calling convention was used, but it should be possible to prototype the external call in the XS code to cater for either successfully, though you may need to do a little manual intervention if the dll was built with _cdecl.

If you are not getting traps when using 'IIII' (or ApiLink and 'SHORT'), then odds are that it was built using _stdcall and Win32::API may be all you need. Though if you are prepared to get stuck in with writing an XS wrapper, it would be considerably more efficient.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]
[d/l]
[select]