Leaderboard

If you set the Label background colour with GUICtrlSetBkColor() and happen to forget the colour you set it as, then why not try GUICtrlGetBkColor() Function: #include-once #include <WinAPIGdi.au3> ; #FUNCTION# ==================================================================================================================== ; Name ..........: GUICtrlGetBkColor ; Description ...: Retrieves the RGB value of the control background. ; Syntax ........: GUICtrlGetBkColor($hWnd) ; Parameters ....: $hWnd - Control ID/Handle to the control ; Return values .: Success - RGB value ; Failure - 0 ; Author ........: guinness ; Example .......: Yes ; =============================================================================================================================== Func GUICtrlGetBkColor($hWnd) If Not IsHWnd($hWnd) Then $hWnd = GUICtrlGetHandle($hWnd) EndIf Local $hDC = _WinAPI_GetDC($hWnd) Local $iColor = _WinAPI_GetPixel($hDC, 0, 0) _WinAPI_ReleaseDC($hWnd, $hDC) Return $iColor EndFunc ;==>GUICtrlGetBkColorExample use of Function: #include <MsgBoxConstants.au3> #include 'GUICtrlGetBkColor.au3' Example() Func Example() Local $hGUI = GUICreate('GUICtrlGetBkColor() Example', 500, 350) Local $iLabel = GUICtrlCreateLabel('', 10, 10, 480, 330) GUISetState(@SW_SHOW, $hGUI) Local $aColor = [0x0000FF, 0x8FFF9F, 0xEC4841, 0xB0E35D, 0x440BFD] ; Random colour array. Local $iColor = 0 For $i = 0 To UBound($aColor) - 1 GUICtrlSetBkColor($iLabel, $aColor[$i]) Sleep(20) $iColor = GUICtrlGetBkColor($iLabel) ; Pass the controldid to the function. MsgBox($MB_SYSTEMMODAL, '', 'Background Color: ' & _ConvertToHexFormat($aColor[$i]) & @CRLF & _ 'GUICtrlGetBkColor() Hex Format: ' & _ConvertToHexFormat($iColor) & @CRLF & _ 'GUICtrlGetBkColor() Returned: ' & $iColor, 0, $hGUI) Next GUIDelete($hGUI) EndFunc ;==>Example Func _ConvertToHexFormat($iColor) Return Hex($iColor, 6) EndFunc ;==>_ConvertToHexFormatAdditional thanks to Yashied for pointing out the obvious in this >forum message about _WinAPI_GetPixel() and the hint about returning a RGB number

LAST VERSION - 1.0 22-Mar-12 I think many of you would like to combine any data of your project, for example skin images, into a single file (package), and as necessary extract them from it. Moreover, it would be better to avoid creating temporary files on the disk. Yes, of course, you can use a resources of the executable file or native FileInstall() function, but in the first case you can not add data after compilation the script, the second case leads inevitably to write data to disk that is not good. Alternatively, you can use, for example, .zip archives, but here again you are limited to using only the files. For this reason, I decided to invent their own file format (.pkr) for storing any data (it can be a files or a memory data directly), and devoid of all the above shortcomings. Below is the detailed structure of the .pkr file (package). As you can see from the screenshot, the package consists of a header and one or more data packets following one another. The package header has a length of 256 bytes and represents PKHEADER structure that contains a basic information about .pkr file, including a short text comment. Here is a description of the PKHEADER structure. -------------------------------------------------------------------------------------------------- | PKHEADER | |--------------------------------------------------------------------------------------------------| | Offset | Length | Purpose | |--------|--------|--------------------------------------------------------------------------------| | 0 | 4 | The file signature (0x504B5221) | |--------|--------|--------------------------------------------------------------------------------| | 4 | 4 | The package version, 1.0 | |--------|--------|--------------------------------------------------------------------------------| | 8 | 8 | The file size, in bytes | |--------|--------|--------------------------------------------------------------------------------| | 16 | 4 | The number of packets in the package | |--------|--------|--------------------------------------------------------------------------------| | 20 | 4 | Reserved | |--------|--------|--------------------------------------------------------------------------------| | 24 | 8 | The absolute offset, in bytes, of the first packet in package | |--------|--------|--------------------------------------------------------------------------------| | 32 | 224 | The package comment, max 224 bytes (112 characters) | --------------------------------------------------------------------------------------------------The first four bytes of the .pkr file always contain the same sequence of bytes (signature) - 0x504B5221 ("PKR!" in ASCII characters). This allows to uniquely identify the package. Then follows a DWORD value representing the package version, currently 1.0 (0x00000100). Next is the size of the package file (INT64), in bytes. Although the size of the .pkr file is not limited, the length of one packet may not exceed a little more than 4 gigabytes (see below). Note that the value of this member should be equal to the actual file size, otherwise it is assumed that the package is damaged. The next member (DWORD) of the structure contains the number of packets in the package. It should not be zero, since it is not allowed to create empty packages. The next four bytes are reserved for future use. The sixth member (INT64) of the PKHEADER structure is the most important and contains an offset of the first packet in the package from the beginning of a file, in bytes. This means that the first packet does not necessarily follow immediately after the header. The latest in the package header is a comment. The length of the comment is limited to 224 bytes (112 wide characters, including the null-terminating character). After the packet header may be located a Packet Relocation Table (PRT) of variable size that contains information for fast packets searching, but is not currently used and has a zero length. Following the PKHEADER and PRT begins a packets. Each packet consists of its own header and three data sections: Description, Info, and Data. Why three? Because so much easier to classify the data within the package. You will understand this when you try to use the library for their projects. A description of the packet (PKPACKET structure) shown in the following table. -------------------------------------------------------------------------------------------------- | PKPACKET | |--------------------------------------------------------------------------------------------------| | Offset | Length | Purpose | |--------|--------|--------------------------------------------------------------------------------| | 0 | 4 | The size, in bytes, of the packet header structure (40 bytes) | |--------|--------|--------------------------------------------------------------------------------| | 4 | 4 | The size, in bytes, of the description block, max 8192 bytes (4096 characters) | |--------|--------|--------------------------------------------------------------------------------| | 8 | 4 | The size, in bytes, of the information block, max 64 KB | |--------|--------|--------------------------------------------------------------------------------| | 12 | 4 | The size, in bytes, of the data block, max 4 GB | |--------|--------|--------------------------------------------------------------------------------| | 16 | 8 | The 64-bit unique identifier of the packet | |--------|--------|--------------------------------------------------------------------------------| | 24 | 4 | The checksum (CRC32) of the compressed data, or zero if no compression | |--------|--------|--------------------------------------------------------------------------------| | 28 | 4 | The uncompressed data size, in bytes, or zero if no compression | |--------|--------|--------------------------------------------------------------------------------| | 32 | 8 | Reserved | |--------------------------------------------------------------------------------------------------| | Description | |--------------------------------------------------------------------------------------------------| | Information | |--------------------------------------------------------------------------------------------------| | Data | --------------------------------------------------------------------------------------------------The first member (DWORD) of the PKPACKET structure always contains the length, in bytes, of the packet header and currently is 40 bytes, but can be changed in the future. The second, third, and fourth members (DWORD) of the structure contains the lengths of the corresponding data sections, in bytes. If any section is missing, the value of its length is zero. A full packet length, in bytes, can be calculated by summing the four values is listed above. The fifth member (INT64) of the structure represents a unique packet identifier (ID). It is a 64-bit positive number that uniquely identifies a packet within the package. The sixth and seventh members (DWORD) of the PKPACKET structure is used only if a data of the Data sections are compressed, otherwise have a zero values. In the case of compression, the sixth member of the structure contains the exact data size of the Data section, in bytes, after uncompression. The last member (INT64) of the packet header is reserved for future use. Immediately after the packet header begins a three data sections that are described in more detail below. The Description section is the first in the packet and designed to store any text information. It may be, for example, the name of the file, in the case of adding a file into the packet, or just a short description of the data that is in the packet. The maximum length of the this section is 8 kilobytes (8,192 bytes) or 4096 wide characters (including the null-terminating character). The Info section immediately follows after the Description section. Here you can store any auxiliary binary data, for example, the attributes of the file, the date and time that a file was created, last accessed, and last modified., or something else. Alternatively, you can store in this section are small files such as cursors, icons, etc. The length of this section is limited to 64 kilobytes (65,535 bytes). The Data section is the third in the packet, and used to store main packet data. The maximum length of this section may be up to 4 gigabytes (4,294,967,295 bytes). Moreover, the data of this section can be compressed by using the native LZ algorithm (not the most optimal but fast enough). These three data sections represents a one packet, and must follow continuously each other that as shown above. Furthermore, any or all of these sections can be missing in the packet. Then after the first packet immediately begins another packet, if any, etc. As you can see, the .pkr files have a simple structure consisting of the sequential blocks of data. Especially for ease of use of packages, I wrote the UDF library which you can download below. A detailed description of each function you can find inside the library. Also, the archive includes all the examples and supporting files. As an additional example, you can download the Package.pkr file containing the same files as the .zip archive, but only created by using this library. I hope this UDF library will be useful for your projects. Also, if anyone have any questions or comments, please post it in this thread. I will be glad to any feedback and constructive suggestions. Almost forgot, this library requires >WinAPIEx UDF library version 3.7 or later. Available functions Package UDF Library v1.0 Package.zip Examples Extracting file (Simple) Adding binary data (Simple) Extracting binary data (Simple) Addition Extraction GUI (Advanced)

A fullscreen console with custom commands! Introduction: Hi everyone! This funny project started as a question in the help section: https://www.autoitscript.com/forum/topic/174404-edit-detect-key-before-updating-content/ I'd like to share this script with everyone that is interested. Why would I want it? You like the old style fullscreen console (like in the old day's), You can add custom commands, You can customize the font a lot more compared to cmd.exe, You can share ideas or add tweaks to the script. Still to do: Write a simple custom programming language to implement this tool. Writing a little help file / pdf to describe my little programming language. Add little sound effects like a beep if there is a syntax error (optional). Clean up and modify Console.Au3 content. Add an option to have to type a login password (optional). Make an optional installer that also gives scripts for this tool a custom icon and open with command. ...Call Neo? Thanks to: xxaviarxx: debugging, some ideas. jguinch: debugging, adding a bunch of tweaks and ideas. kylomas: debugging, new ideas. Edits and updates: Added usage of tab key in edit control Edit has focus now on startup I'm currently rewriting a simple custom programming language to implement this tool. UDF download: Console.au3 Regards TheAutomator

GetModuleFunc.h 1. Introduction This writing describes in detail method for retrieving the address of exported function for loaded module without using any available API on either 32bit, 64bit or ARM based Windows systems. Structures definitions are taken from Microsoft SDK 7.1, unless otherwise specified. Loaded module is searched by name, not path. The code is written in form of function that has two parameters, WCHAR pointer to the module name and CHAR pointer to the function name, written in C++ and compiled using Microsoft Visual Studio Express 2013 for Windows Desktop. Basic knowledge of C++ is assumed. Attached GetModuleFunc.h has the full code for the function. 2. NT_TIB Structure defined inside winnt.h. It's the staring point for the algorithm. It includes self-referencing field - Self pointer, offset of which is used on non-ARM systems to read Thread Environment Block data. typedef struct _NT_TIB { struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; PVOID StackBase; PVOID StackLimit; PVOID SubSystemTib; #if defined(_MSC_EXTENSIONS) union { PVOID FiberData; DWORD Version; }; #else PVOID FiberData; #endif PVOID ArbitraryUserPointer; struct _NT_TIB *Self; } NT_TIB; typedef NT_TIB *PNT_TIB; 2.1. TEBThread Environment Block is chunk of memory filled with various information about the thread. TEB is defined inside winternl.h as: typedef struct _TEB { PVOID Reserved1[12]; PPEB ProcessEnvironmentBlock; PVOID Reserved2[399]; BYTE Reserved3[1952]; PVOID TlsSlots[64]; BYTE Reserved4[8]; PVOID Reserved5[26]; PVOID ReservedForOle; // Windows 2000 only PVOID Reserved6[4]; PVOID TlsExpansionSlots; } TEB, *PTEB; After the executable is loaded by the Windows PE loader and before the thread starts running, TEB is saved to fs(x86) or gs(x64 flavor) processor register. ARM systems use different technique which utilize coprocessors scheme (it's unclear whether the coprocessor is real hardware component or emulated). Self field of NT_TIB is the TEB pointer for the current thread.Even not officially documented, this behavior is observed on/for all available Windows operating systems with NT kernel. Acquiring pointer to the TEB is done using Microsoft specific compiler intrinsics: #include <winnt.h> #include <winternl.h> #if defined(_M_X64) // x64 auto pTeb = reinterpret_cast<PTEB>(__readgsqword(reinterpret_cast<DWORD>(&static_cast<NT_TIB*>(nullptr)->Self))); #elif defined(_M_ARM) // ARM auto pTeb = reinterpret_cast<PTEB>(_MoveFromCoprocessor(15, 0, 13, 0, 2)); // CP15_TPIDRURW #else // x86 auto pTeb = reinterpret_cast<PTEB>(__readfsdword(reinterpret_cast<DWORD>(&static_cast<NT_TIB*>(nullptr)->Self))); #endif Among others, one of the fields inside the TEB is pointer to the PEB (Process Environment Block). 3. PEB Process Environment Block is memory area filled with information about a process. PEB is defined inside winternl.h as: typedef struct _PEB { BYTE Reserved1[2]; BYTE BeingDebugged; BYTE Reserved2[1]; PVOID Reserved3[2]; PPEB_LDR_DATA Ldr; PRTL_USER_PROCESS_PARAMETERS ProcessParameters; PVOID Reserved4[3]; PVOID AtlThunkSListPtr; PVOID Reserved5; ULONG Reserved6; PVOID Reserved7; ULONG Reserved8; ULONG AtlThunkSListPtr32; PVOID Reserved9[45]; BYTE Reserved10[96]; PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine; BYTE Reserved11[128]; PVOID Reserved12[1]; ULONG SessionId; } PEB, *PPEB; Pointer to the PEB is read from the TEB: auto pPeb = pTeb->ProcessEnvironmentBlock; 3.1. PEB_LDR_DATAContains information about the loaded modules for the process. Ldr field of the PEB points to PEB_LDR_DATA structure, defined inside winternl.h as: typedef struct _PEB_LDR_DATA { BYTE Reserved1[8]; PVOID Reserved2[3]; LIST_ENTRY InMemoryOrderModuleList; } PEB_LDR_DATA, *PPEB_LDR_DATA; Pointer to the PEB_LDR_DATA is read from the PEB: auto pLdrData = pPeb->Ldr; 3.2. LIST_ENTRYInMemoryOrderModuleList field of the PEB_LDR_DATA is doubly-linked list that contains the loaded modules for the process, defined inside winnt.h as: typedef struct _LIST_ENTRY { struct _LIST_ENTRY *Flink; struct _LIST_ENTRY *Blink; } LIST_ENTRY, *PLIST_ENTRY, *RESTRICTED_POINTER PRLIST_ENTRY; auto pModListHdr = &pLdrData->InMemoryOrderModuleList; 4. LDR_DATA_TABLE_ENTRYEach item in the list is a pointer to an LDR_DATA_TABLE_ENTRY structure, defined inside winternl.h as: typedef struct _LDR_DATA_TABLE_ENTRY { PVOID Reserved1[2]; LIST_ENTRY InMemoryOrderLinks; PVOID Reserved2[2]; PVOID DllBase; PVOID Reserved3[2]; UNICODE_STRING FullDllName; BYTE Reserved4[8]; PVOID Reserved5[3]; union { ULONG CheckSum; PVOID Reserved6; } DUMMYUNIONNAME; ULONG TimeDateStamp; } LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY; DllBase field is the base address of the loaded module.This stucture doesn't give wanted info for the module, being its name. One option is to read FullDllName which includes full path and extract module name from it. However, some independent authors give slightly different definition which include another field - BaseDllName. Modified LDR_DATA_TABLE_ENTRY struct can be defined, including BaseDllName field and freed from superfluous fields. InMemoryOrderLinks will be iterated, so that field is the top of the struct: typedef struct _LDR_DATA_TABLE_ENTRY { /*LIST_ENTRY InLoadOrderLinks;*/ LIST_ENTRY InMemoryOrderLinks; LIST_ENTRY InInitializationOrderList; PVOID DllBase; PVOID EntryPoint; PVOID Reserved3; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; } LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY; 4.1. IterationGoing through the items in the list is straightforward. The last item points to the first, meaning the end is reached, hence it can be written: for (auto pModListCurrent = pModListHdr->Flink; pModListCurrent != pModListHdr; pModListCurrent = pModListCurrent->Flink) { // Get current module in list auto pModEntry = reinterpret_cast<PLDR_DATA_TABLE_ENTRY>(pModListCurrent); //... } 4.2. Reading Module NameThis data is stored in form of UNICODE_STRING. winternl.h definition is: typedef struct _UNICODE_STRING { USHORT Length; USHORT MaximumLength; PWSTR Buffer; } UNICODE_STRING; Module name lookup is case insensitive. Lengths specified inside UNICODE_STRING represent bytes, which means number of WCHAR characters is half of the numbers.One of the ways to make case insensitive comparison of the specified module name and listed one is to turn both to uppercase before comparing them: for (int i = 0; i < pModEntry->BaseDllName.Length / 2 /* length is in bytes */; ++i) { if (sModuleName[i] == '\0') // the end of the string break; else if ((sModuleName[i] & ~' ') != (pModEntry->BaseDllName.Buffer[i] & ~' ')) // case-insensitive break; else if (i == iLenModule - 1) // gone through all characters and they all matched { //... the rest of the code } } iLenModule is length of the wanted module name. It's get by counting number of characters inside the string until null-terminator is encountered: int iLenModule = 0; for (; sModuleName[iLenModule]; ++iLenModule); Comparison written in this manner allows for matching function argument L"kernel32" to listed L"kernel32.dll", which mimics to a decent degree (not completely for brevity) behavior of GetModuleHandle WinAPI function. In case of two different loaded modules whose names differs only in extensions, first listed is matched. 5. PE format walkthrough The Portable Executable (PE) format is a file format for executables, object code, DLLs, etc... It describes how and where inside the file the executable code is, import table, export table, resources, and every other data needed for loader. Exported functions are listed inside the Export Table. Reaching export table is done in few steps parsing the PE data. 5.1. IMAGE_DOS_HEADER The matching module's DllBase points to the first byte of the loaded image. PE starts with legacy DOS header defined inside winnt.h as: typedef struct _IMAGE_DOS_HEADER { // DOS .EXE header WORD e_magic; // Magic number WORD e_cblp; // Bytes on last page of file WORD e_cp; // Pages in file WORD e_crlc; // Relocations WORD e_cparhdr; // Size of header in paragraphs WORD e_minalloc; // Minimum extra paragraphs needed WORD e_maxalloc; // Maximum extra paragraphs needed WORD e_ss; // Initial (relative) SS value WORD e_sp; // Initial SP value WORD e_csum; // Checksum WORD e_ip; // Initial IP value WORD e_cs; // Initial (relative) CS value WORD e_lfarlc; // File address of relocation table WORD e_ovno; // Overlay number WORD e_res[4]; // Reserved words WORD e_oemid; // OEM identifier (for e_oeminfo) WORD e_oeminfo; // OEM information; e_oemid specific WORD e_res2[10]; // Reserved words LONG e_lfanew; // File address of new exe header } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER; Therefore it can be written: auto pImageDOSHeader = reinterpret_cast<PIMAGE_DOS_HEADER>(pModEntry->DllBase); e_lfanew is offset to a NT header. 5.2. IMAGE_NT_HEADERS Another area of PE is NT header. This is effectively the starting point of the portable executable format description. Definition and the size of it depends on bitness. For 32bit it's: typedef struct _IMAGE_NT_HEADERS { DWORD Signature; IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER32 OptionalHeader; } IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32; ...and 64bit version is: typedef struct _IMAGE_NT_HEADERS64 { DWORD Signature; IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER64 OptionalHeader; } IMAGE_NT_HEADERS64, *PIMAGE_NT_HEADERS64; 5.3. IMAGE_NT_HEADERSOptionalHeader field is another structure discribing in detail PE file. It's directly followed by number of IMAGE_DATA_DIRECTORY structures. The exact number of these structures is saved inside IMAGE_NT_HEADERS as NumberOfRvaAndSizes field. For 32bit PE IMAGE_NT_HEADERS is defined as: typedef struct _IMAGE_OPTIONAL_HEADER { // // Standard fields. // WORD Magic; BYTE MajorLinkerVersion; BYTE MinorLinkerVersion; DWORD SizeOfCode; DWORD SizeOfInitializedData; DWORD SizeOfUninitializedData; DWORD AddressOfEntryPoint; DWORD BaseOfCode; DWORD BaseOfData; // // NT additional fields. // DWORD ImageBase; DWORD SectionAlignment; DWORD FileAlignment; WORD MajorOperatingSystemVersion; WORD MinorOperatingSystemVersion; WORD MajorImageVersion; WORD MinorImageVersion; WORD MajorSubsystemVersion; WORD MinorSubsystemVersion; DWORD Win32VersionValue; DWORD SizeOfImage; DWORD SizeOfHeaders; DWORD CheckSum; WORD Subsystem; WORD DllCharacteristics; DWORD SizeOfStackReserve; DWORD SizeOfStackCommit; DWORD SizeOfHeapReserve; DWORD SizeOfHeapCommit; DWORD LoaderFlags; DWORD NumberOfRvaAndSizes; IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; } IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32; ...and for 64bit version it's: typedef struct _IMAGE_OPTIONAL_HEADER64 { WORD Magic; BYTE MajorLinkerVersion; BYTE MinorLinkerVersion; DWORD SizeOfCode; DWORD SizeOfInitializedData; DWORD SizeOfUninitializedData; DWORD AddressOfEntryPoint; DWORD BaseOfCode; ULONGLONG ImageBase; DWORD SectionAlignment; DWORD FileAlignment; WORD MajorOperatingSystemVersion; WORD MinorOperatingSystemVersion; WORD MajorImageVersion; WORD MinorImageVersion; WORD MajorSubsystemVersion; WORD MinorSubsystemVersion; DWORD Win32VersionValue; DWORD SizeOfImage; DWORD SizeOfHeaders; DWORD CheckSum; WORD Subsystem; WORD DllCharacteristics; ULONGLONG SizeOfStackReserve; ULONGLONG SizeOfStackCommit; ULONGLONG SizeOfHeapReserve; ULONGLONG SizeOfHeapCommit; DWORD LoaderFlags; DWORD NumberOfRvaAndSizes; IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; } IMAGE_OPTIONAL_HEADER64, *PIMAGE_OPTIONAL_HEADER64; PE files generated by Microsoft tools allways create IMAGE_NUMBEROF_DIRECTORY_ENTRIES (16) IMAGE_DATA_DIRECTORY structures, 15 of which are documented in this order (winnt.h): #define IMAGE_DIRECTORY_ENTRY_EXPORT 0 // Export Directory #define IMAGE_DIRECTORY_ENTRY_IMPORT 1 // Import Directory #define IMAGE_DIRECTORY_ENTRY_RESOURCE 2 // Resource Directory #define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3 // Exception Directory #define IMAGE_DIRECTORY_ENTRY_SECURITY 4 // Security Directory #define IMAGE_DIRECTORY_ENTRY_BASERELOC 5 // Base Relocation Table #define IMAGE_DIRECTORY_ENTRY_DEBUG 6 // Debug Directory // IMAGE_DIRECTORY_ENTRY_COPYRIGHT 7 // (X86 usage) #define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE 7 // Architecture Specific Data #define IMAGE_DIRECTORY_ENTRY_GLOBALPTR 8 // RVA of GP #define IMAGE_DIRECTORY_ENTRY_TLS 9 // TLS Directory #define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10 // Load Configuration Directory #define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT 11 // Bound Import Directory in headers #define IMAGE_DIRECTORY_ENTRY_IAT 12 // Import Address Table #define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT 13 // Delay Load Import Descriptors #define IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14 // COM Runtime descriptor 5.4. IMAGE_DATA_DIRECTORYDefinition is: typedef struct _IMAGE_DATA_DIRECTORY { DWORD VirtualAddress; DWORD Size; } IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY; It can now be written: auto pExport = reinterpret_cast<PIMAGE_DATA_DIRECTORY>(&pImageNtHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]); VirtualAddress field is RVA of the directory counting from the first byte (base) of the loaded module. If both VirtualAddress and Size fields are filled then the module exports functions. 5.5. IMAGE_EXPORT_DIRECTORY Definition is (winnt.h): typedef struct _IMAGE_EXPORT_DIRECTORY { DWORD Characteristics; DWORD TimeDateStamp; WORD MajorVersion; WORD MinorVersion; DWORD Name; DWORD Base; DWORD NumberOfFunctions; DWORD NumberOfNames; DWORD AddressOfFunctions; // RVA from base of image DWORD AddressOfNames; // RVA from base of image DWORD AddressOfNameOrdinals; // RVA from base of image } IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY; Base is ordinal value of the first exported function.NumberOfFunctions is overall number of exported functions from the module. NumberOfNames is number of functions exported only by name. AddressOfFunctions is RVA of the array of RVAs of exported functions addresses. AddressOfNames is RVA of the array of RVAs of exported functions names. AddressOfNameOrdinals is RVA of the array of WORD values each representing index of function exported by name, into the array of addresses. It's: auto pExports = reinterpret_cast<PIMAGE_EXPORT_DIRECTORY>(reinterpret_cast<ULONG_PTR>(pImageDOSHeader) + pExport->VirtualAddress); 6. Getting function RVAEvery exported function is accessible by odinal value. Functions exported by name are also accessible by name. Finding function by its ordinal value is fairly simple and fast. The lowest ordinal value is Base field of IMAGE_EXPORT_DIRECTORY struct. The highest ordinal value is get by adding the number of exported functions to that number, minus one of course. If the specified ordinal value is within this range, RVA is read from the array of functions addresses: if (iOrdinal) // function is wanted by its ordinal value { // Check to see if valid ordinal value is specified if (iOrdinal >= pExports->Base && iOrdinal < pExports->Base + pExports->NumberOfFunctions) dwExportRVA = pdwBufferAddress[iOrdinal - pExports->Base]; } In case of functions exported by name, name lookup needs to be performed.The code is: // Array of functions names auto pdwBufferNames = reinterpret_cast<LPDWORD>(reinterpret_cast<ULONG_PTR>(pImageDOSHeader) + pExports->AddressOfNames); // Array of functions indexes into array of addresses auto pwBufferNamesOrdinals = reinterpret_cast<LPWORD>(reinterpret_cast<ULONG_PTR>(pImageDOSHeader) + pExports->AddressOfNameOrdinals); And then the loop: // Loop through all functions exported by name for (DWORD j = 0; j < pExports->NumberOfNames; ++j) { // Read the listed function name auto sFunc = reinterpret_cast<LPCSTR>(reinterpret_cast<ULONG_PTR>(pImageDOSHeader) + pdwBufferNames[j]); //... } When the name of the function is matched (case sensitive) the RVA of the function will be read from pdwBufferAddress array at index read from pwBufferNamesOrdinals at loop counter value index: dwExportRVA = pdwBufferAddress[pwBufferNamesOrdinals[j]]; 6.1. Export ForwardingRVA of the function will resolve fonction's pointer. However there is one special case when the RVA offset points to a value inside the exports section and not to the function body which is normally found in some other sections of PE. When that happens, RVA will resolve to a null-terminated ASCII string value. This is called Export Forwarding. RVA is then replaced by the RVA value of the resolved function. if (dwExportRVA > pExport->VirtualAddress && dwExportRVA < pExport->VirtualAddress + pExport->Size) { // Read forwarded data. auto sForwarder = reinterpret_cast<LPCSTR>(reinterpret_cast<ULONG_PTR>(pImageDOSHeader) + dwExportRVA); //... } The format of the forwarding string is: ModuleName.FunctionName or ModuleName.#OrdinalValueTo resolve the RVA of the new exported function a recursive call to this function will be used. ModuleName has to be wide string. WCHAR buffer is allocated and all characters from ModuleName portion of forwarded string copied to it: WCHAR sForwarderDll[MAX_PATH]; // Reinterpret WCHAR buffer as CHAR one auto sForwarderDll_A = reinterpret_cast<CHAR*>(sForwarderDll); // Now go through all characters for (int iPos = 0; sForwarder[iPos]; ++iPos) { // Fill WCHAR buffer reading/copying from CHAR one sForwarderDll_A[2 * iPos] = sForwarder[iPos]; // copy character sForwarderDll_A[2 * iPos + 1] = '\0'; if (sForwarder[iPos] == '.') { sForwarderDll[iPos] = '\0'; // null-terminate the ModuleName string break; } } In case forwarding string specifies function name, pointer to that string is simply a pointer to a character following the dot.For OrdinalValue version the presence of hashtek character after the dot has to be checked and the hashtag string converted to integer value before recursive call made. The full code for this is: // Allocate big enough buffer for the new module name WCHAR sForwarderDll[MAX_PATH]; LPCSTR sForwarderFunc = nullptr; DWORD dwForwarderOrdinal = 0; // Reinterpret WCHAR buffer as CHAR one auto sForwarderDll_A = reinterpret_cast<CHAR*>(sForwarderDll); // Now go through all characters for (int iPos = 0; sForwarder[iPos]; ++iPos) { // Fill WCHAR buffer reading/copying from CHAR one sForwarderDll_A[2 * iPos] = sForwarder[iPos]; // copy character sForwarderDll_A[2 * iPos + 1] = '\0'; if (sForwarder[iPos] == '.') { sForwarderDll[iPos] = '\0'; // null-terminate the ModuleName string ++iPos; if (sForwarder[iPos] == '#') { ++iPos; // skip # character // OrdinalValue is hashtag, convert ASCII string to integer value for (; sForwarder[iPos]; ++iPos) { dwForwarderOrdinal *= 10; dwForwarderOrdinal += (sForwarder[iPos] - '0'); } if (dwForwarderOrdinal > MAX_ORDINAL) // something is wrong return nullptr; // Reinterpret the ordinal value as string sForwarderFunc = reinterpret_cast<LPSTR>(dwForwarderOrdinal); break; } else { sForwarderFunc = &sForwarder[iPos]; // FunctionName follows the dot break; } } } 6.2. FinalizingOnce funcion address RVA is get, it's added to the base address and returned from the function: return reinterpret_cast<LPVOID>(reinterpret_cast<ULONG_PTR>(pImageDOSHeader) + dwExportRVA); 7. ExampleThe attached zip contains two executables compiled from the source of 1K-Mandelbrot project, written by Emil Persson. The source had no explicit License Agreement. It's modified not to use WinAPI, rather to use method desribed here to call functions from used dlls and then compiled. Beautiful examples of visualisation of complex calculations, done in efficient way using OpenGL. Requirement is OpenGL 2.0. Third example is compiled for ARM. It's simple analog Direct2D clock, the original code of which is released under Artistic License/GPL by vckzdd. GetModuleFunc_Examples.zip 8. Conclusion This method isn't usually used by executables ran from user mode. It should be avoided used for production software, because it ommits taking ownership of critical section object used by windows during load/unload actions of the module, which could result in any kind of unhandled exception. Limited speed tests show that it's faster than standard GetModuleHandle/GetProcAddress method. Mimicking WinAPI behavior is achieved to a high level for valid input, with omitted special error handling and reporting. The only major difference is unsupported full-path processing. 8.1. Anti-Virus Software considerations This method enables compiling PE files with empty imports directory. In combination with accessing fs register at TEB/PEB offset it has been observed that 18.2% of AV scanners tend to flag 32bit executables, containing no code other than this function, as malware. 64 bit and ARM executables compiled from the same source never get flagged. References: Microsoft Corporation: Microsoft Portable Executable and Common Object File Format Specification, Revision 6.0 Matt Pietrek: Under The Hood - http://www.microsoft.com/msj/archive/s2ce.aspx An In-Depth Look into the Win32 Portable Executable File Format - http://msdn.microsoft.com/en-us/magazine/bb985992.aspx An In-Depth Look into the Win32 Portable Executable File Format, Part 2 - http://msdn.microsoft.com/en-us/magazine/cc301808.aspx Mark Russinovich, David A. Solomon, Alex Ionescu : Microsoft Windows Internals, 6th edition VirusTotal: Web Service - https://www.virustotal.com/ Emil Persson: 1K-Mandelbrot - http://www.humus.name/index.php?page=3D&ID=85 vckzdd: directxcode - https://code.google.com/p/directxcode/source/browse/#svn/Direct2D/Clock

Now replaced by a new version of the UDF in this link. <hr> [NEW VERSION] - 7 Mar 16 Added: A new option for $iAdded (+ 512) allows you to select just one cell of the ListView rather than the whole row. A new function _GUIListViewEx_SetDefColours allows the user to set the default colours when using either or both the "colour" and "single cell selection" options. Another new function _GUIListViewEx_BlockReDraw which prevents ListView redrawing during looped Insert/Delete/Change calls - this greatly speeds up execution by avoiding lengthy redrawing when using either or both the "colour" and "single cell selection" options, use of which forces the redraw to use a WM_NOTIFY handler within the script. Changed: A number of minor internal changes to speed up the loading of the ListView when using either or both of the "colour" and "single cell selection" options. A slightly modified Example_6 script shows the new functions in use. The LH native ListView can have rows and columns added/removed using both the old and new functions and has a context menu to allow for colour selection. The contents of this ListView can be mirrored to the RH UDF-created ListView which has "single cell selection" enabled and allows the colours of any item (including the selected cell) to be changed programmatically. New UDF in the zip below. Previous changes: ChangeLog.txt Hi, It seemed that I wanted to add, delete, edit or move items in a ListView quite often in my scripts and I got fed up with having to rewrite the code to do it each time. I also wanted to be able to drag items within and between ListViews with the mouse, plus edit the items. So I decided to write a UDF to make life easier and here is the result - GUIListViewEx. If you are interested in how it works, then read this bit - if not, then skip over it: The UDF is pretty easy to use: - You start by creating a ListView (either native or UDF) and passing the returned ControlID/handle and the array you used to fill it to the _Init function of the UDF. You also indicate whether the array has a count in the [0] (or [0][0]) element and if you create an empty ListView, the UDF will still cope and will shadow any items that you insert later. If you have a ListView filled with data but no matching array, there is a function to read that data into an array for you. You can select a colour for the insert mark when dragging items if you are going to use this feature - the default is black - and decide whether to have a shadow of the dragged item follow the mouse. Finally you can set the ListView to be sortable, editable - with various options to determine how the editing process works, determine external drag/drop behaviour and whether user colours are used. - You need to register a few Windows messages, but this is a single call to the _MsgRegister function. If you already have handlers for the relevant messages, there are functions to call within these handlers instead. If you do not want to drag, then you only need the WM_NOTIFY handler loaded. - Then you just need to call the main _Insert($vData), _Delete, _Up, and _Down functions when the appropriate button is pressed, select and drag items, or use one of the edit functions and your ListView responds automatically. - The UDF shadows the contents of the ListView (as explained in the spoiler section above) so you can get its current state at any time with the _ReturnArray function . Many of the functions actually return this data after each call just to help you keep track and there are dedicated Save/Load functions. - If enabled, the user can colour individual items within the ListView - and can set certain elements to be coloured on loading if required. - There are a couple of functions that you need to run in your idle loop if you need the functionality - they detect when items are dragged and edited. - When you have finished with the ListView, you should use the _Close function to clear the memory used by the UDF to shadow its contents. It is not vital, but if you use a lot of ListViews and do not do this, you could end up running out of memory. - You can have as many ListViews as you wish on display at any one time and the same "Insert", "Delete", "Up" and "Down" buttons can be used for them all - you just have to click on the one you want to be active. The UDF also allows you to set the active ListView programatically (_SetActive) - and to determine which is currently active (_GetActive). There are also additional Insert/DeleteSpec functions which allow you to action non-active ListViews. There are 6 example scripts to show the UDF working on native and UDF created ListViews, with single or multiple columns and either filled or empty, along with the UDF itself in this zip file: Credit to martin (for the basic drag code which I found on the forum), the Array UDF authors (for the basis of the array functions) and LarsJ (for the basic colour handler code). Happy for any feedback - hopefully positive! M23

this has been asked in the forum many times, i hope this function "Remarks" section can sum-up the idea with all its considerations and caveats. the thing is, the internal macro @OSVersion is not always up-to-date for the newest versions of windows, notably the preview releases, so a more direct approach is taken here. ; #FUNCTION# ==================================================================================================================== ; Name ..........: _OSVersion ; Description ...: Returns the Windows version as registered in the registry. ; Syntax ........: _OSVersion([$sHostName = @ComputerName]) ; Parameters ....: $sHostName - [optional] The host name (or IP address) of the host to retrieve the informatino for. ; Return values .: Success - Returns a numeric decimal value corrsponding to Windows version. ; Failure - Returns 0 and sets @error to 1. ; Author ........: orbs ; Modified ......: ; Remarks .......: * Continuously updating list of Windows versions is posted at the MSDN link hereunder. Info as per March 2015: ; Operating system Version number ; ----------------- -------------- ; Windows 10 Technical Preview 10.0 ; Windows Server Technical Preview 10.0 ; Windows 8.1 6.3 ; Windows Server 2012 R2 6.3 ; Windows 8 6.2 ; Windows Server 2012 6.2 ; Windows 7 6.1 ; Windows Server 2008 R2 6.1 ; Windows Server 2008 6.0 ; Windows Vista 6.0 ; Windows Server 2003 R2 5.2 ; Windows Server 2003 5.2 ; Windows XP 64-Bit Edition 5.2 ; Windows XP 5.1 ; Windows 2000 5.0 ; * The returned value is numerical, although it is stored in the registry as a string (REG_SZ). This allows for ; numerical comparison, for example _OSVersion()<6 means XP/2003 or earlier, _OSVersion()>6.1 means the new ; and arguably hideous generation of Windows (featuring the "Metro" crap). ; * The relevant registry key is not affected by WOW64 (see 2nd MSDN link hereunder), so no need to use HKLM64. ; * The relevant registry branch contains other useful information, e.g. a string representation of the OS name ; and Service Pack level. For example: ; "Windows 7 Ultimate" data is stored in value "ProductName" ; "Service Pack 1" data is stored in value "CSDVersion" ; * To retrieve the information for another host over network, adequate connectivity and authorization required. ; Related .......: ; Link ..........: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724832.aspx ; https://msdn.microsoft.com/en-us/library/windows/desktop/aa384253(v=vs.85).aspx ; http://stackoverflow.com/questions/14648796/currentversion-value-in-registry-for-each-windows-operating-system ; Example .......: No ; =============================================================================================================================== Func _OSVersion($sHostName = @ComputerName) Local $sOSVersion = RegRead('\\' & $sHostName & '\HKLM\Software\Microsoft\Windows NT\CurrentVersion', 'CurrentVersion') If @error Then Return SetError(1, 0, 0) Return Number($sOSVersion) EndFunc ;==>_OSVersion

HI. I was needing to add a program to Tarkbar(an easy way without using objectcreateinterface ) so I found this. So then I deduced how to add to the StartMenu while I see the shell32 in hex editor search for taskbarunpin|taskbarpin string. I found another two interesting string (startpin|startunpin) So I try out and they work too but to add to StartMenu. This is not an official way to do this, however it works. $sFileLnk parameter must be Link(.lnk) to our program. ;~ Success: True. ;~ Failure: False. Func DeleteFromTaskBar($sFileLnk) Return _WinAPI_ShellExecute($sFileLnk,"","", "taskbarunpin") EndFunc Func AddToTaskBar($sFileLnk) Return _WinAPI_ShellExecute($sFileLnk,"","", "taskbarpin") EndFunc Func AddToStartMenu($sFileLnk) Return _WinAPI_ShellExecute($sFileLnk,"","", "startpin") EndFunc Func DeleteFromStartMenu($sFileLnk) Return _WinAPI_ShellExecute($sFileLnk,"","", "startunpin") EndFunc Saludos

I need that someone help me to eat. Just read a little bit about NET. then, write it yourself. Saludos

I have a SciTE UDF in SciTE Jump

SciTE4AutoIt3 Helpfile has the basics and there are several examples in the forum how to use this. Jos

_GUICtrlListView_GetSelectedColumn returns the select column, not now. Have a look to _GUICtrlListView_GetSelectedIndices

SciTE can be automated by any language as it accept messages on the director interface. Example: ; SendSciTE_Command("goto:,0") SendSciTE_Command("insert:" & "Your text to insert at cursor replacing possible selected text.") ; ; Func SendSciTE_Command($sCmd) Opt("WinSearchChildren", 1) ; Get SciTE DirectorHandle $SciTE_hwnd = WinGetHandle("DirectorExtension") Local $WM_COPYDATA = 74 Local $CmdStruct = DllStructCreate('Char[' & StringLen($sCmd) + 1 & ']') DllStructSetData($CmdStruct, 1, $sCmd) Local $COPYDATA = DllStructCreate('Ptr;DWord;Ptr') DllStructSetData($COPYDATA, 1, 1) DllStructSetData($COPYDATA, 2, StringLen($sCmd) + 1) DllStructSetData($COPYDATA, 3, DllStructGetPtr($CmdStruct)) DllCall('User32.dll', 'None', 'SendMessage', 'HWnd', $SciTE_hwnd, _ 'Int', $WM_COPYDATA, 'HWnd', 0, _ 'Ptr', DllStructGetPtr($COPYDATA)) EndFunc ;==>SendSciTE_Command I have used this in AutoIt3Wrapper, Tidy and Au4Stripper. Jos

I don't know how, I just know what it is. there are many example, just look at scite4autoit, ISN studio, SciTE 3.2.5.99 for AutoIt, the list goes on.

scite

@kosamja I don't know about the problems you'd want removed, but I see one semantics error with your code. When you use FileOpen() then you shouldn't be using anything other than returned handle to do file operations. On top of that FileClose ("Uninstall.txt") does nothing except contributing to global pollution, hurting our mother Earth. And dolphins. To answer the question about who you are - I have no idea. Who? People around here speak good old American. (JohnOne, yes I know, you speak that other language similar to it :P.)

Well a Simple way to launch an advanced association dialog box to easy edit aplication association. Local Const $sCLSID_LaunchAdvancedAssociationUI = "{1968106d-f3b5-44cf-890e-116fcb9ecef1}" Local Const $sIID_ILaunchAdvancedAssociationUI = "{1f76a169-f994-40ac-8fc8-0959e8874710}" Local Const $sTagILaunchAdvancedAssociationUI = "LaunchAdvancedAssociationUI hresult(wstr)" ; Create the object. Local $aRegApp = _GetRegisteredApplications() If IsArray($aRegApp) Then LaunchAdvancedAssociationUI($aRegApp[0]) EndIf Func LaunchAdvancedAssociationUI($AppRegName) Local $oLaunchAdvancedAssociationUI = ObjCreateInterface($sCLSID_LaunchAdvancedAssociationUI, $sIID_ILaunchAdvancedAssociationUI, $sTagILaunchAdvancedAssociationUI) If Not IsObj($oLaunchAdvancedAssociationUI) Then Return False Return SUCCEEDED($oLaunchAdvancedAssociationUI.LaunchAdvancedAssociationUI($AppRegName)) EndFunc ;==>LaunchAdvancedAssociationUI Func _GetRegisteredApplications() Local $sWow64 = "" Local $sString = "" Local $aRegApp[0] Local $i = 1 If @AutoItX64 Then $sWow64 = "\Wow6432Node" Do $sString = RegEnumVal("HKEY_LOCAL_MACHINE\SOFTWARE" & $sWow64 & "\RegisteredApplications", $i) If Not @error Then ReDim $aRegApp[$i] $aRegApp[$i - 1] = $sString $i += 1 EndIf Until @error <> 0 If $i = 1 Then Return 0 Return $aRegApp EndFunc ;==>_GetRegisteredApplications Func SUCCEEDED($hr) Return ($hr >= 0) EndFunc ;==>SUCCEEDED Saludos

But in this function 0 is more sensible because with 1 you would always move the start AND end of the range even if you just wanted to move one of them.

If you do not specify any properties to return then all properties will be returned (default). So WAD. You missed to specify the StoreID. Try: Global $aItems = _OL_ItemGet($oOutlook, 'EF0000009B491F81D6791A47AA9A1EC0758DAA05245A2A00', Default, "Body")

Ah, I remember. With DASL you can't retrieve the whole body. You only get the first 255 bytes of the body: #include <OutlookEX.au3> #include <Array.au3> Global $oOutlook = _OL_Open() $sTerm = "ACS" $sInbox = "*\Posteingang" $sSQL = "@SQL=urn:schemas:httpmail:subject ci_startswith " & "'" & $sTerm & "'" Global $aItems = _OL_ItemSearch($oOutlook, $sInbox, $sSQL, "EntryId,Subject,urn:schemas:httpmail:textdescription") ConsoleWrite(@error & @CRLF) _ArrayDisplay($aItems) _OL_Close($oOutlook)So if you need the full body you would need to call _OL_ItemGet for each found mail item.

? For $i = UBound($array)-1 to 0 step -1 If StringInStr($array[$i], "(must be deleted)") Then _ArrayDelete($array, $i) Next Local $searchfor, $3words For $i = 0 to UBound($array)-1 $3words = StringRegExpReplace($array[$i], '\s*(\S+\s+\S+\s+\S+)\s.*', "$1") $searchfor &= $3words & @crlf Next

That makes it much clearer.. Thanks Understand now what the problem is and a fix will be available later today. Jos

Enjoy watching.

Right clicking the windows "start" button brings up some quick access stuff, including old style cpanel, for me.

Hmmm, You could always add this line to the top of your script which will, At the very least kill any static processes: if ProcessExists("YourCompiledNameHere.exe") > 0 then Do ProcessClose("YourCompiledNameHere.exe") Until ProcessExists("YourCompiledNameHere.exe") = 0 endif Just replace the "YourCompiledNameHere.exe" with the actual name of your compiled script. Note: this method won't work if the script is not compiled, As when running an au3 program, The autoit3Wrapper.exe (or something to that liking) will appear as the process. The issue most likely lies with the SkypeCom.au3 contents, Although I can't really comment as I haven't seen the code. Cheers Javi