Custom Query (3927 matches)

There is a possible situation with freeing loaded modules that are not initially loaded (load-time dynamic linking). Modules loaded only by call to LoadLibrary function -DllCall(), are unloaded unintentionally (user perspective) in some situations. Script demonstrates this behavior:

Global $hWINHTTP = DllOpen("winhttp.dll") ; for example
ConsoleWrite("Internal handle of the module: ")
ConsoleWrite($hWINHTTP & @CRLF)


ConsoleWrite("Real handle of the module: ")
ConsoleWrite(_GetModuleHandle("winhttp.dll") & @CRLF)


; Calling the 'wrong' function will unload the module. Why?
DllCall($hWINHTTP, "none", "Blahblah") ; There is no "Blahblah" function exported from winhttp.dll

; But there is no change with internal handle. That's ok for now.
ConsoleWrite("Internal handle of the module: ")
ConsoleWrite($hWINHTTP & @CRLF)

; Get real handle again. This time it will fail because AutoIt called FreeLibrary internally already.
ConsoleWrite("Real handle of the module: ")
ConsoleWrite(_GetModuleHandle("winhttp.dll") & @CRLF) ; will cause error because the module is unloaded

; Check internal handle again:
ConsoleWrite("Internal handle of the module: ")
ConsoleWrite($hWINHTTP & @CRLF)


; DllOpen again to check internal count of handles. This should be 1 because the module is unloaded by AutoIt internally, but it's 2 in this case.
$hWINHTTP = DllOpen("winhttp.dll")
ConsoleWrite("Internal handle after reopening the module: ")
ConsoleWrite($hWINHTTP & @CRLF) ; it's increased by one, like there were no unloading happening



Func _GetModuleHandle($sModule)

	Local $aCall = DllCall("kernel32.dll", "ptr", "GetModuleHandleW", "wstr", $sModule)

	If @error Or Not $aCall[0] Then
		Return SetError(1, 0, -1) ; just to show error
	EndIf

	Return $aCall[0]

EndFunc   ;==>_GetModuleHandle

This is bad because effectively it disables us from declaring dll handles on global scope (as constant even more):

; Load module and get handle
Global Const $hWINHTTP = DllOpen("winhttp.dll")

; Unload it unintentionally
DllCall($hWINHTTP, "none", "Blahblah") ; comment this line out for script to work properly

; Call some function from that dll
Global $aCall = DllCall($hWINHTTP, "int", "WinHttpCheckPlatform") ; http://msdn.microsoft.com/en-us/library/aa384089(VS.85).aspx

ConsoleWrite("! WinHttpCheckPlatform @error = " & @error & @CRLF) ; will be 3
ConsoleWrite("WinHttpCheckPlatform return value = " & $aCall[0] & @CRLF)

It's clearly intentional, therefore it's not a bug, but still it would be nice if someone could share some light on the matter. Is declaring dll handles on global scope ok, or is it more proper to open handle prior actual call (and close it afterwards), or maybe to call by string and DllOpen() it once at top of the script if necessary, or whatever?

Thanks in advance.

Documentation says that the size of 'ptr' with DllStructCreate() is 4 bytes and unlike with, for example, 'int_ptr' there is no mention of differences when x64 AutoIt is used. I would assume it's the same thing with other alike types.

$tStructure = DllStructCreate("ptr")
$iSize = DllStructGetSize($tStructure)

ConsoleWrite("Size of ptr = " & $iSize & " bytes" & @CRLF)
MsgBox(64, "ptr", "Size = " & $iSize)

Link to the post with the results of that test ​http://www.autoitscript.com/forum/index.php?showtopic=105150&view=findpost&p=749787.

With new 3.3.2.0 version there are issue(s) with data types with DllCall() function. If I ask for dword AutoIt returns int. For example:

$sFile = "NonExistingFile"

$aCall = DllCall("kernel32.dll", "dword", "CreateFileW", _
		"wstr", $sFile, _
		"dword", 0x80000000, _ ; GENERIC_READ
		"dword", 0, _ ; prevent sharing
		"ptr", 0, _
		"dword", 3, _ ; OPEN_EXISTING
		"dword", 0, _
		"ptr", 0)

$hFile = $aCall[0]

ConsoleWrite("! " & $hFile & @CRLF)
MsgBox(0, '$hFile is', $hFile & @CRLF)

Same thing is for any parameter. If I do "dword*", 0 , i get int value returned. I could write an example with GdipBitmapGetPixel from gdiplus.dll if you need it to verify this additionally. For non-transparent white it will return -1 instead of asked (and proper) 4294967295 (0xFFFFFFFF).