Recently Browsing 0 members
No registered users viewing this page.
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'm using the following:
newly installed Beta 126.96.36.199
SQlite version 3380000 aka 3.38.0
I put sqlite3.dll and sqlite3_x64.dll in C:\Windows\System32 since many scripts depend on them.
I extended the output of _SQLite_Startup()
ConsoleWrite("@AutoItX64 " & @AutoItX64 & @CRLF) ConsoleWrite("$sDll_Filename " & $sDll_Filename & @CRLF) ConsoleWrite("_SQLite_LibVersion=" & _SQLite_LibVersion() & @CRLF)
Also using the script from https://www.autoitscript.com/autoit3/docs/libfunctions/_SQLite_Startup.htm for testing.
>Running:(188.8.131.52):C:\Program Files (x86)\AutoIt3\autoit3.exe "R:\Download\aasdf.au3" @AutoItX64 0 $sDll_Filename sqlite3.dll _SQLite_LibVersion=0 >Running:(184.108.40.206):C:\Program Files (x86)\AutoIt3\autoit3_x64.exe "R:\Download\aasdf.au3" @AutoItX64 1 $sDll_Filename sqlite3_x64.dll _SQLite_LibVersion=3.38.0 >Running:(220.127.116.11):C:\Program Files (x86)\AutoIt3\Beta\autoit3.exe "R:\Download\aasdf.au3" @AutoItX64 0 $sDll_Filename sqlite3.dll _SQLite_LibVersion=0 >Running:(18.104.22.168):C:\Program Files (x86)\AutoIt3\Beta\autoit3_x64.exe "R:\Download\aasdf.au3" @AutoItX64 1 $sDll_Filename sqlite3_x64.dll _SQLite_LibVersion=3.38.0
Why doesn't it work in 32bit, despite me having the 32bit sqlite.dll? Autoit urges running scripts in 32bit mode and Scite starts scripts just in 32bit mode without the flag?
With #AutoIt3Wrapper_UseX64=Y it just works, both normal Autoit and beta!
maybe someone can help me.
If automated a script that should xcopy from various paths (all within C:\*\...) to a external Disk (HDD). (Backup data of users who get new pcs win10)
I tried it several times with windows 10 home/pro any clients and never got any failure. (after the testing was done)
But when i tried to run it shortly ago on a windows 7 pro x64 client, the script started (as i saw in taskmanagr.exe) but i didn't performed any of the actions when i came down to the xcopy part.
(in the systemtray, it showd the scipt to start, but it was marked as "paused" and i couldn't stop this. No plan why)
i inserted/attached the script down here.
Does anyone know why? any ideas?backup-scrp.au3
PS: the tray debug line just added by today (i re-try it tomorrow when i've set up another win7 client to test with)
PPS: i know my coding-style isn't very optimized
This piece of code creates and reads OK a key at "HKEY_LOCAL_MACHINE" and can be changed for a key at "HKEY_CURRENT_USER"
$sta= RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor", "wav", "REG_SZ", "5555") MsgBox(4096,"wrote", $sta &@cr& @error) $zz= RegRead ("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor", "wav") MsgBox(4096,"readed","="&$zz &@cr& @error) Exit With HKEY_CURRENT_USER, in RegEdit we can see the created key, and we can create the key by hand/RegEdit and everything Works OK.
At HKEY_LOCAL_MACHINE we can´t see the created key above thru RegEdit, but it Works (even not seeing, I can read). But if I create "by hand"/RegEdit the key, it can´t read it with $zz= RegRead ("HKEY_LOCAL_MACHINE.... above.
I´m the PC´s WIN.7 administrator. Even so I ran RegEdit as administrator and also the compiled AU3 and also plain. No changes.
edit: even if Try "HKEY_LOCAL_MACHINE\SOFTWARE\AAA", "wav", the same holds true.
$sta= RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\AAA", "wav", "REG_SZ", "4444") MsgBox(4096,"wrote", $sta &@cr& @error) $zz= RegRead ("HKEY_LOCAL_MACHINE\SOFTWARE\AAA", "wav") MsgBox(4096,"readed","="&$zz &@cr& @error) Exit Seems that it creates this key at another place.... I can read the above value ("4444"), even after a boot, even the key not showing in regedit. And if I create it by hand key AAA/wav with a distinct value (666), t, it continues Reading the old value = 444.
Heres a function for searching for a bitmap within another bitmap. The heart of it is written assembly (source included) and working pretty quick I feel. I have included an example which is pretty basic and should be easily enough for anyone to get the concept.
You will be given a small blue window that will take a screencapture of that size:
It will then take a full screenshot and highlight all locations that it found
Please let me know if you have any issues or questions. Thanks!
Rewrote for fasmg. Added full source with everything needed to modify
GAMERS - Asking for help with ANY kind of game automation is against the forum rules. DON'T DO IT.