7 posts in this topic
Please answer me these questions three, ere the other side you see:
Are you running a 64-bit machine with a 64-bit Windows operating system? Can your AutoIt scripts cope with having directive #AutoIt3Wrapper_UseX64=Y, and thus @AutoItX64=True? Are you sick and tired of seeing this error message?
If you (like me) answered "YES" to all three questions, then the _HighMem library may ease your pain (the name commemorates a useful utility from the days when CPUs were still steam-powered). Forget about pathetic boot switches /3GB and /userva; in a full-fledged 64-bit environment, _HighMem can pre-allocate all available physical/virtual RAM you've got (or any smaller size you need), and manage individual allocations therein with four simple functions:
_HighMem_StartUp( $nSize, $sUnit="GB" ) ; parse size of total region to pre-allocate, e.g. (10,"GB") _HighMem_Allocate( $nSize, $sUnit="B" ) ; returns $pOffset (new allocation's base address) _HighMem_Release( $pOffset ) ; existing allocations are identified by their offset (base address) _HighMem_CleanUp() ; close handles, release all pre-allocated memory Of course, existing AutoIt limitations remain in force (e.g., DllstructCreate() is still limited to 2 GB per call), but the maximum of 2-4 GB of virtual memory per Windows process can (under the right circumstances, in the proper environment) be circumvented. However, this is the first beta release, so glitches are likely, and performance may vary. In fact, it may not work at all for you (if you're running 32-bit, for example). And since this involves your own hardware, it's unlikely I would be able to reproduce your issues in my own work environment. Nevertheless, if you find obvious bugs or mistakes in the code, please do post. And if it works for you, that's also good to hear. My own motivation for developing it was to supercharge my matrix computing environment (Eigen4AutoIt), so it can handle matrices of any size that fit in machine RAM.
The attached zip contains the library itself (HighMem.au3) and two test examples. HighMem_Test1 performs a dry run stress test of the allocation management system; it does not actually do any memory I/O. By contrast, HighMem_Test2 pre-allocates a 6 GB space, stores 3 x 2GB structs there, performs some basic I/O, and releases the allocations one by one. Obviously, for this to work you'll need at least that much free RAM to begin with (check with Task Manager -> Performance -> Memory if you're unsure). My own test environment has 16 GB of physical RAM, and runs W10Pro/64.
EDIT: minor edits added to improve user experience (many more status messages if $_HighMem_Verbose=True)
EDIT: from beta version 0.9, HighMem supports shared memory, including mutex negotiation.
I developing simple script for one program to do the automatic clicks.
Now I developed on xp and win 7, but on win 10 gives me error.
But the point for me to make it clear and not having basic mistake
with choosing x64 and x86 system.
So if I choose x64 system, does it going to work on x86?
when compiling do I need to check or uncheck x64 compatibilities?
Right now I'm installing new autoit v3 full install and it ask me what version to do like:
- use native x64 tools by default
- Use x86 tools by default (recommanded for compatibility)
I assume I should use x86, because this is for 32bit machines?
I know those are the basic questions of building the application for windows or any OS,
but I didn't do any of this and if someone can give me information, just to do point,
use always that or this, it would be great!
Looking for working code to get full path of process - both 32 & 64 bit.
I tryed this bellow, but it works only for 32-bit processes, even if compiled for x64...
Thanx for suggestions!
Func _ProcessGetPath($vProcess) ;get the program path done by MrCreatoR Local $iPID = ProcessExists($vProcess) If NOT $iPID Then Return SetError(1, 0, -1) Local $aProc = DllCall('kernel32.dll', 'hwnd', 'OpenProcess', 'int', BitOR(0x0400, 0x0010), 'int', 0, 'int', $iPID) If NOT IsArray($aProc) OR NOT $aProc Then Return SetError(2, 0, -1) Local $vStruct = DllStructCreate('int') Local $hPsapi_Dll = DllOpen('Psapi.dll') If $hPsapi_Dll = -1 Then $hPsapi_Dll = DllOpen(@SystemDir & '\Psapi.dll') If $hPsapi_Dll = -1 Then $hPsapi_Dll = DllOpen(@WindowsDir & '\Psapi.dll') If $hPsapi_Dll = -1 Then Return SetError(3, 0, '') DllCall($hPsapi_Dll, 'int', 'EnumProcessModules', _ 'hwnd', $aProc, _ 'ptr', DllStructGetPtr($vStruct), _ 'int', DllStructGetSize($vStruct), _ 'int_ptr', 0) Local $aRet = DllCall($hPsapi_Dll, 'int', 'GetModuleFileNameEx', _ 'hwnd', $aProc, _ 'int', DllStructGetData($vStruct, 1), _ 'str', '', _ 'int', 2048) DllClose($hPsapi_Dll) If NOT IsArray($aRet) OR StringLen($aRet) = 0 Then Return SetError(4, 0, '') Return $aRet EndFunc
I wondered why negative integers I wrote into registry (e.g. negative x-coordinates of a gui if using two monitors and the right one is the main one) wouldn't return right when reading. Now I know: it is saved as an unsigned integer (without algebraic sign). So here is a snippet that is changing unsigned to signed integer:
Global Const $g_sRegKey = "HKEY_CURRENT_USER\Software\" & @ScriptName ; path to registry RegWrite($g_sRegKey, "Value", "REG_DWORD", -2147483647) ; write some negative integer into registry; -2147483647 highest possible negative integer , 2147483648 highest possible positive integer if talking of 32bit Local $sValue = RegRead($g_sRegKey, "Value") ; read out registry ConsoleWrite("Value: " & $sValue & @CRLF) ; show real value in console Local $sResult = _SignedInteger($sValue) ; change to signed value ConsoleWrite("Result: " & $sResult & @CRLF) ; and show it in console Func _SignedInteger($iUnsignedInteger) Local $iSignedInteger If $iUnsignedInteger > (2^31) Then ; then it means a negative integer $iSignedInteger = $iUnsignedInteger - (2^32) Else $iSignedInteger = $iUnsignedInteger EndIf Return $iSignedInteger EndFunc It took me some time to find out the problem and so I hope I can help somebody with this.