..

[69255]

Edited March 23, 2012 by 69255

[jchd]

Maybe this would work:

Local $res = DllCall("IMG.dll", "struct", "IMGGetThisFile", "int", 1)
; here I take Longword to mean unsigned 32-bit integer
Local $Tdirentry = DllStructCreate("dword;dword;char[24]", $res[0])
ConsoleWrite("Tdirentry.startblock = " & DllStructGetData($Tdirentry, 1) & @LF)
ConsoleWrite("Tdirentry.sizeblocks = " & DllStructGetData($Tdirentry, 2) & @LF)
ConsoleWrite("Tdirentry.Name       = " & DllStructGetData($Tdirentry, 3) & @LF)

[jchd]

Yes, I now always assume one is using the latest AutoIt release.

Do you know where it crashes: during the call or when accessing the return value?

Try adding some ConsoleWrite("we get here" & @LF) right after the DllCall. That will tell us.

Leave "struct" as return value.

Edited January 5, 2012 by jchd

[jchd]

You are compiling for 32-bit for this 32-bit DLL, aren't you?

I'm looking at Delphi calling convention and found that "external" is an obsolete keyword for Delphi v1, which used the "pascal" calling convention (not supported by AutoIt AFAICT). If that's where the problem lives, then I guess your only hope would be to write a [bunch of] thunk function(s) to alleviate those calling convention discrepancy.

You can still try "struct:cdecl" as return type, since you're only having one argument (argument order differs, but is irrelevant for 1 arg).

Crossing fingers!

[jchd]

Can you post the interface part of the other successfully called functions?

Edit: please join some DllCall for those which work.

Edited January 5, 2012 by jchd

[jchd]

Looks like the fact that the offending function returns a 24-byte large structure (which doesn't fit in the eax register used to return int in some other of your examples) is causing havoc. I guess that if it returned a pointer instead there wouldn't be any problem.

I'm seeking help among devs about this. It may require some delay before someone has time to look in gory details, so be a little patient.

OTOH, it's still possible to write a (say) C thunk function to wrap the call, but this is a last resort. It can even be made by "inline" asm (close to) but this is even more last resort!

Really too late for me (04:38 AM): seeking some sleep now.

Ah, I forgot to welcome you to this forum!

[Valik]

jchd is correct. The Delphi code is returning a structure. The code is poorly written. For anything larger than a 64-bit value a pointer should be returned or a parameter passed into the function. AutoIt does not support this situation because it shouldn't exist. Only an amateur would return a structure from a function. You'll have to use a wrapper function written in C++ or something to re-package the data. AutoIt's not going to handle this.

Note that I do not believe the struct type can be used for a return value. It doesn't make sense, you tell it "struct" but what size? It could be 1 byte or it could be 400 bytes.

[jchd]

Yeah, that's what I was wondering. I was surprised to discover (tonight) this new return type and asked myself by which magic it could work. Maybe by marking the stack somehow but this would be fairly risky even if DEAD:BEEF isn't a highly common integer/pointer/whatever "user" value...

(I didn't dig further to fetch information about how Delphi is actually going to return that stuff, that is: which code does it generate in such situation.)

[ProgAndy]

Here is some text about structure return values I found on Wikipedia (for cdecl, stdcall should be the same I think)

http://en.wikipedia.org/wiki/X86_calling_conventions

There are some variations in the interpretation of cdecl, particularly in how to return values. As a result, x86 programs compiled for different operating system platforms and/or by different compilers can be incompatible, even if they both use the "cdecl" convention and do not call out to the underlying environment. Some compilers return simple data structures with the length of 2 registers or less in EAX:EDX, and larger structures and class objects requiring special treatment by the exception handler (e.g., a defined constructor, destructor, or assignment) are returned in memory. To pass "in memory", the caller allocates memory and passes a pointer to it as a hidden first parameter; the callee populates the memory and returns the pointer, popping the hidden pointer when returning.

I think you should be able to do this with the DLLCall-function.

[jchd]

That could work if the OP is lucky and crossing fingers hard. stdcall reverts arguments order BTW.

Anyway, as Mat said in another thread, the safest bet will be to single-step the offending function(s) and watch where things land then from there devise a clean way to invoke it/them.

[trancexx]

ProgAndy is right of course. this should work (jchd's modified):

Local $Tdirentry = DllStructCreate("dword;dword;char[25]")
DllCall("IMG.dll", "ptr", "IMGGetThisFile", "struct*", $Tdirentry, "int", 1)
ConsoleWrite("Tdirentry.startblock = " & DllStructGetData($Tdirentry, 1) & @LF)
ConsoleWrite("Tdirentry.sizeblocks = " & DllStructGetData($Tdirentry, 2) & @LF)
ConsoleWrite("Tdirentry.Name       = " & DllStructGetData($Tdirentry, 3) & @LF)