DllCall return type Topic is solved

[pneumatic]

DllCall("LoadLibrary", "Str", "Psapi.dll")

Why does the above work, given the LoadLibrary function returns a HMODULE, and we haven't specified a return type, as per:

ReturnType: If the function returns a 32-bit signed integer (Int), BOOL, or nothing at all, ReturnType may be omitted. Otherwise, specify one of the argument types from the types table below.

Windows docs doesn't say much about the format of HMODULE, so I'm not sure what to specify as the return type.

Another example in ahk docs specifies "Ptr" as the return type, but I've seen others use "UPtr".

DllCall("LoadLibrary", "Str", "MyFunctions.dll", "Ptr")

I'm running 64-bit Unicode - which return type should I use?

Thanks

[Helgef]

You should use "ptr" (prefix u or not doesn't matter). The docs should too. The example will probably always seem to work since the returned handle is only used to free the library and you probably won't notice if that fails due to a truncated handle.

Cheers.

[pneumatic]

(prefix u or not doesn't matter).

Are you sure because

Prepend the letter U to any of the integer types above to interpret it as an unsigned integer. Strictly speaking, this is necessary only for return values and asterisk variables because it does not matter whether an argument passed by value is unsigned or signed (except for Int64).

The example will probably always seem to work since the returned handle is only used to free the library and you probably won't notice if that fails due to a truncated handle.

MsgBox says the handle is the same integer regardless of whether I use Ptr or UPtr as the return type. Or is MsgBox just not capable of showing the difference between signed/unsigned binary data?

[Helgef]

It doesn't matter for this use case, that was my point. How you interpret the sign of the number doesn't change the relevant bit representation of the numbers the functions return (LoadLibrary) or get passed (FreeLibrary). Whether you use ptr or uptr on 32 bit could impact the appearance of the number if you want to convert it to a string, and could also impact the result if you do any arithmetic operation with it. But we don't do that with such handles normally.

Example,

Code: Select all

; compare ahk 64 to 32
varsetcapacity(x, a_ptrsize)
numput(-1, x, "ptr")	; ptr or uptr will not matter here on either 64 or 32
msgbox % numget(x, "uptr")
msgbox % numget(x, "ptr")

Cheers.

[pneumatic]

I think I understand what you're saying, insofar as the underlying binary data being the same for practical purposes, regardless of signness.

But I was concerned that perhaps when ahk's source code for DllCall interacts with WinAPI, that ahk might be telling WinAPI "please return me a value of type Ptr" , in which case maybe WinAPI would say to ahk "no sorry ahk, you specified the wrong return type, I'm not going to return you anything".

But it seems that is not the case, as WinAPI still returns the hModule even when no return type is specified.

I see that jNizM uses UPtr for LoadLibrary, and I wonder what his reasoning for that was, since Ptr seems like the more "default" choice, even if it doesn't matter.

[Helgef]

Seems like you got it . It think that HMODULE ultimately is a void*, so omitting the U is strictly speaking more correct, but it doesn't matter.

Cheers.