5 posts in this topic
This topic is now closed to further replies.
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.
This got closed and im trying to figure out why isint this one closed too:
I didint want to "hack" or "automate" a game all i wanted to do is learn memory reading and i needed help so i ask again
hey, can anybody enlighten on lesser known Windows hacks or uses ?
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 am having a bit of trouble and was wondering if anyone may have a workaround for my issue. I made a script that would automatically install a piece of software each night on a Windows 7 Box. Now I have been instructed to do the same with a Windows 10 box since the application is now being tested on Windows 10.
The way I did the win7 installation was that I made a script and then made an executable that I call with a batch file along with the Installer. So the process is
AutoitMainFile calls batch file, batch file opens Installer, and the automatedinstaller.exe The automatedinstlaller waits 10-20 seconds to make sure the Installer has been fully loaded.
When I try to do the same both get loaded but the automatedinstallation.exe does not send commands to the installer. The code does work and nothing from the program we are wanting to install has changed as our Windows 7 runs every night no problem.
Do I need to make a new automatedinstall script for windows 10?
Any advice is appreciated