Leaderboard

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) HighMem.v0.85.7z EDIT: from beta version 0.9, HighMem supports shared memory, including mutex negotiation. HighMemv0.9.2.7z

Features: Create modern looking borderless and resizable GUIs with control buttons (Close,Maximize/Restore,Minimize, Fullscreen, Menu) True borderless, resizeable GUI with full support for aerosnap etc. Many color schemes/themes included. See MetroThemes.au3 for more details. 3 type of Windows 8/10 style buttons. Modern checkboxes, radios, toggles and progressbar. All buttons, checkboxes etc. have hover effects! Windows 10 style modern MsgBox. Windows 10/Android style menu that slides in from left. Windows 10 style right click menu Credits: @UEZ, for the function to create buttons with text using GDIPlus. @binhnx for his SSCtrlHover UDF Changelog: Download UDF with example:

Version 2.x.x and 3.x.x has been moved to branch 3.x About Autoit-Socket-IO Autoit-Socket-IO is a event driven TCP/IP wrapper heavily inspired from Socket.IO with focus on user friendliness and long term sustainability. I constantly want to make this UDF faster and better, so if you have any suggestions or questions (beginner and advanced) Do not hesitate to ask them, I will gladly help! Key features Simple API 99% data-type serialization thanks to Autoit-Serialize Can easily be extended with your own functionality thanks to Autoit-Events "Educational" examples Data encryption thanks to _<Crypt.au3> Limitations Speed. This UDF will sacrifice some speed for convenience Getting started Download the script from AutoIt or pull it from the official github repo git@github.com:tarreislam/Autoit-Socket-IO.git and checkout the tag 4.0.0-beta Check out the documentaion Take a look in the examples/ folder Changelog To see changes from 3.x.x and 2.x.x please checkout the 3.x branch Version 4.0.0-beta (This update break scripts.) Code base fully rewritten with Autoit-Events and decoupled to improve code quality and reduce bloat. The new UDF is very different from 3.x.x so please checkout the UPGRADE guide to fully understand all changes Added new documentation documentaion Success stories Since December 2017-now I have used version 1.5.0 in an production environment for 150+ clients with great success, the only downtime is planned windows updates and power outages. Newest version (2020-09-15!) Older versions (Not supported anymore) Autoit-Socket-IO-1.0.0.zip Autoit-Socket-IO-1.1.0.zip Autoit-Socket-IO-1.3.0.zip Autoit-Socket-IO-1.4.0.zip Autoit-Socket-IO-1.5.0.zip Autoit-Socket-IO-2.0.0.zip

I'm sure you could click it using the _IE functions.

It's working! Thanks! you are the best @Danp2

I would try something like this -- $oBtn = _IEGetObjByName($oForm,"ctl00$bodyPlaceholder$btnFecharProcessamento") While 1 If $oBtn.style.display <> 'none' Then ExitLoop Endif Sleep(500) WEnd _IEAction($oBtn, "focus") _IEAction($oBtn, "click")

joseLB, If your final goal is faster array manipulations you should also take a look at Accessing AutoIt Variables.

That example I posted yesterday was a bit poor, as the second process does not use my dedicated PID-bases HighMem functions to map another process's shared memory and individual allocations. When I have some spare time I'll post a proper example. Secondly, I failed yesterday to emphasise the difference between using shared mem for exchanging data between processes (IPC), and for creating a joint workspace where multiple processes can act simultanuously or (with mutex handling) consecutively (as I do in E4A). If you need to send large arrays back and forth all the time (including string conversion and dllstruct I/O), then esp. those string conversions will be slow. Instead, I would suggest you use the joint workspace approach, with one process creating a database-like struct, and other processes performing repeated data I/O there. As for speed, as long as your contiguous allocations fit in physical RAM (as opposed to virtual RAM, which is far bigger, but may swap to your pagefile), access times should be about three orders of magnitude faster than using regular file I/O (when the latter is/were not swapped into/out of RAM). Of course, if your data are numeric only, then you should really look into using Eigen4AutoIt (E4A, link in my sig), which already integrates HighMem in x64, and has extensive (numeric) data manipulation functionality (copy,swap,sort,reverse,cell-wise arithmetic, conditional replace, etc). If you're using arrays that contain variable-length strings, however, then you should probably adopt the struct approach, pre-allocating fixed-width fields within the struct (structs allow indexed access of their individual members, which can be different vartypes). That's basically your requested "AT" feature, if I understand your description correctly (haven't used Pascal since secondary school). Check DllstructCreate in the help file for more info. Finally, re. mutexes (mutices?), I think I mentioned elsewhere that these are just system-wide flags that multiple processes can query, set, and reset. They do not block access in any way. You don't need them if you're just reading, but I would suggest you do use them if mutliple processes can write to the same location and use the information therein for other actions.

Hi Jose. My first impulse was to just refer you to my Eigen4AutoIt environment (v4.1), which contains a working example (test #20 in the EIgenTest subdirectory) of a matrix (struct) being created by one process, an subsequently written two in alternating fashion by a second process and the first (both filling it with their PID). That example illustrates mutex usage as well, as you'll see each process failing to obtain the mutex until the other one releases it (after which a successful write occurs). My second impulse was to refer you to the _WinAPI_CreateFileMapping example in the AutoIt Help, which shows how to share a joint memory allocation between two processes without mutex. But of course, that one doesn't involve the HighMem environment, which takes care of all the nitty gritty of keeping your memory allocations organised. So my third impulse, followed here, is to share two tiny test scripts from my earliest testing phase of _HighMem. Both use a struct as a string buffer for one process to store user-defined text in and the other process to read it back, just like in the CreateFileMapping example (but using the HighMem environment). Obviously, you can stick anything you like into a struct, including an array (e.g., convert to string and store in struct at one end, and do the reverse at the other end). If you need more extensive examples of how to use structs as generic tmporary containers for any type of variable, I would suggest you study my Pool IPC environment (link in my sig below). Start this script first (the HighMem equivalent of the AutoIt Help file example referred to above), but don't fill the inputbox yet... #AutoIt3Wrapper_UseX64=Y #NoTrayIcon #include <MsgBoxConstants.au3> #include <WinAPI.au3> #include <WinAPIFiles.au3> #include "D:\Autoit\HighMem\HighMem.au3" $_HighMem_verbose=True Opt('WinWaitDelay', 0) Global Const $g_sTitle = 'TestHighMem' Global $sText Global $mapobjectname=$_HighMem_NamePrefix & '123' ; fake PID _HighMem_StartUp(1) _HighMem_MapExternalMemory(123, False) ; fake PID Local $sText,$tData = DllStructCreate('wchar[1024]', $_HighMem_ExternalBaseOffset[1]) While WinWait($g_sTitle, '', 1) Sleep(200) $sText = DllStructGetData($tData, 1) DllStructSetData($tData, 1, '') If $sText Then MsgBox(BitOR($MB_ICONINFORMATION, $MB_SYSTEMMODAL), $g_sTitle & " (receiver)", " " & @CRLF & $sText) WEnd _HighMem_CleanUp() Then start the second one below, then type something and press Ok. #AutoIt3Wrapper_UseX64=Y #NoTrayIcon #include <MsgBoxConstants.au3> #include <WinAPI.au3> #include <WinAPIFiles.au3> #include "D:\Autoit\HighMem\HighMem.au3" $_HighMem_verbose=True Opt('WinWaitDelay', 0) Global Const $g_sTitle = 'TestHighMem' Global $sText Global $mapobjectname=$_HighMem_NamePrefix & '123' _HighMem_StartUp(1,"GB",$mapobjectname) Local $sText,$tData = DllStructCreate('wchar[1024]', $_HighMem_BaseOffset) While WinWaitClose($g_sTitle) $sText = StringStripWS(InputBox($g_sTitle & " (sender)", 'Type some text', '', '', -1, 171), 3) If Not $sText Then ExitLoop DllStructSetData($tData, 1, $sText) If Not WinWait($g_sTitle, '', 1) Then ExitLoop WEnd _HighMem_CleanUp() IMPORTANT: this simple example works for a single allocation only, because it maps the struct directly to the shared memory base pointer (the start of the total pre-allocated region). But obviously, only the first allocation has an offset of zero. Any allocation made thereafter by script 1 will have a relative offset larger than zero. So you have to start parsing those offsets to your second (and third, fourth, etc) script(s) using some form of IPC (for example, using my Pool environment ). And the second script then calls _HighMem_AllocateExternal ( $PID, $offset, $size, $unit="B"), after first calling _HighMem_MapExternalMemory( $PID ). Maybe I can provide a nexample of that some other time. I'm not sure by what you mean by "efficient" in this context. Using a shared resource and just communicating a pointer once is certainly less data traffic than moving a 1000x1000 cell array back and forth every time, if that's what you mean. And yes, these allocations can be any size that fits into your virtual memory. Does that clarify things for you?

I cannot think of much that can't have dangerous code nowadays, tbh. When I did my latest round of C|EH, we were hiding malicious code in the white space of a text documents, embedding code into jpg files, single-pixel exploits on web pages, etc. In short, if you aren't 100% sure on the source and authenticity of the file, never say never.

idk if there is anything in the wild that exfiltrates via this method nor am i seeing any use after free ops. However, there a metric shit ton of ways to BSOD and affect availability, and they do store functions, so i would certainly give them a non-zero chance.