 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
Glasso2
Guest
|
 Posted: Fri Feb 13, 2009 7:05 am Post subject: |
 |
|
Ah, thank you. However, still have problem, through it has improved the situation. I am still getting some glitches in the output.
Maybe below will better illustrate what I see. Laszlo, please try running HOTKEY 1 (below). Then try running HOTKEY 2 which has two consecutive instances where this same function is called. However, the identical bit of HEX
| Code: |
434F4D5055544552205049524143592049532057524F4E470D0A
|
... seems to have picked up a little bit extra, appended to it.  How do I handle this?
| Code: |
1::
; COMPUTER PIRACY IS WRONG
SAMPLE_HEX=
(
434F4D5055544552205049524143592049532057524F4E470D0A
)
SIZE_OF_ZONE:=ceil(StrLen(SAMPLE_HEX)/2)
MCode(Hex2Bin,"568b74240c8a164684d2743b578b7c240c538ac2c0e806b109f6e98ac802cac0e10"
. "4880f8a164684d2741a8ac2c0e806b309f6eb80e20f02c20ac188078a16474684d275cd5b5f5ec3")
VarSetCapacity(UN_HEX, 0)
VarSetCapacity(UN_HEX, SIZE_OF_ZONE)
DllCall(&Hex2Bin, "UInt",&UN_HEX, "UInt",&SAMPLE_HEX, "CDECL")
VarSetCapacity(UN_HEX, -1)
FileAppend, %UN_HEX%,CHECK_ME_3.TXT
Return
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2::
; THE COW JUMPED OVER THE MOON
SAMPLE_HEX=
(
54484520434F57204A554D504544204F56455220544845204D4F4F4E
)
SIZE_OF_ZONE:=ceil(StrLen(SAMPLE_HEX)/2)
MCode(Hex2Bin,"568b74240c8a164684d2743b578b7c240c538ac2c0e806b109f6e98ac802cac0e10"
. "4880f8a164684d2741a8ac2c0e806b309f6eb80e20f02c20ac188078a16474684d275cd5b5f5ec3")
VarSetCapacity(UN_HEX, 0)
VarSetCapacity(UN_HEX, SIZE_OF_ZONE)
DllCall(&Hex2Bin, "UInt",&UN_HEX, "UInt",&SAMPLE_HEX, "CDECL")
VarSetCapacity(UN_HEX, -1)
FileAppend, %UN_HEX%,CHECK_ME_1.TXT
; COMPUTER PIRACY IS WRONG
SAMPLE_HEX=
(
434F4D5055544552205049524143592049532057524F4E470D0A
)
SIZE_OF_ZONE:=ceil(StrLen(SAMPLE_HEX)/2)
MCode(Hex2Bin,"568b74240c8a164684d2743b578b7c240c538ac2c0e806b109f6e98ac802cac0e10"
. "4880f8a164684d2741a8ac2c0e806b309f6eb80e20f02c20ac188078a16474684d275cd5b5f5ec3")
VarSetCapacity(UN_HEX, 0)
VarSetCapacity(UN_HEX, SIZE_OF_ZONE)
DllCall(&Hex2Bin, "UInt",&UN_HEX, "UInt",&SAMPLE_HEX, "CDECL")
VarSetCapacity(UN_HEX, -1)
FileAppend, %UN_HEX%,CHECK_ME_2.TXT
Return
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MCode(ByRef code, hex) { ; allocate memory and write Machine Code there
VarSetCapacity(code,StrLen(hex)//2)
Loop % StrLen(hex)//2
NumPut("0x" . SubStr(hex,2*A_Index-1,2), code, A_Index-1, "Char")
}
|
|
|
| Back to top |
|
 |
Laszlo
Joined: 14 Feb 2005
Posts: 4514
Location: Boulder, CO
|
| Posted: Fri Feb 13, 2009 7:14 am Post subject: |
|
|
| AHK Help for VarSetCapacity() wrote: | | GrantedCapacity: The length of string that Var can now hold, which will be greater or equal to RequestedCapacity. |
There is no easy way to enforce an exact allocation size in AHK. If the slack disturbs you, specify 0 as the third parameter of VarSetCapacity, which at least sets the tail to NULs. In general, when working with binary buffers, you must not use the allocation size or StrLen, but keep the length of the buffer in another variable. |
|
| Back to top |
|
|
TheGood
Joined: 30 Jul 2007
Posts: 398
|
| Posted: Sun Mar 08, 2009 2:14 am Post subject: |
|
|
| Can anyone reproduce the functionality of RtlMoveMemory in MCode? I ask because I have a loop using the API for (possibly) thousands of passes. Therefore, even the smallest overhead reduction would be greatly beneficial. |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4514
Location: Boulder, CO
|
| Posted: Sun Mar 08, 2009 4:37 am Post subject: |
|
|
| Look here, although the #chars parameter has to be one larger in case of non-string copy. |
|
| Back to top |
|
|
TheGood
Joined: 30 Jul 2007
Posts: 398
|
| Posted: Sun Mar 08, 2009 5:38 am Post subject: |
|
|
| Laszlo wrote: | | Look here, although the #chars parameter has to be one larger in case of non-string copy. |
Thank you!
But surprisingly, the performance between the API and the MCode is exactly the same. To the millisecond! |
|
| Back to top |
|
|
tinku99
Joined: 03 Aug 2007
Posts: 309
Location: Houston, TX
|
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4514
Location: Boulder, CO
|
| Posted: Sun Mar 29, 2009 12:54 am Post subject: |
|
|
You want to use an external function (written in AHK or as a dll) to convert symbolic assembler constructs to machine code, one-by-one, store it in an AHK variable and run the resulting code. The traditional way is easier: write your assembler function in a file or in an AHK variable, and feed it to a symbolic assembler saving the resulting code in an AHK variable. It was demonstrated with a C compiler already.
These methods don’t allow easy debugging of the code. The typical use of machine code is to speed up time critical or hard to program low level functions. You spend a lot of time developing the assembler/machine code, but many of us can use it. |
|
| Back to top |
|
|
tinku99
Joined: 03 Aug 2007
Posts: 309
Location: Houston, TX
|
|
| Back to top |
|
|
Lenrius
Joined: 25 Dec 2008
Posts: 23
Location: 50° lat.
|
| Posted: Sat Jul 04, 2009 9:20 pm Post subject: Machine code of a DLL? |
|
|
Laszlo, I know that you are still following this topic.
Is the TinyCCompiler capable of compiling into memory what would be a DLL? Y/N |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4514
Location: Boulder, CO
|
|
| Back to top |
|
|
Lenrius
Joined: 25 Dec 2008
Posts: 23
Location: 50° lat.
|
| Posted: Sun Jul 05, 2009 6:00 pm Post subject: Go-ahead |
|
|
| TCC wrote: | | [It] supports the native Win32 executable file format (PE-i386). |
| Together with what Wikipedia wrote: | | The file formats for DLLs are the same as for Windows exe files — that is, Portable Executable (PE) for 32-bit and 64-bit Windows |
on DLLs we are given green light.
My excuses for bothering you, Laszlo, but I have never compiled one because alleged special compiler settings deter me from attempting it.
While DllCall() has eradicated the rationale behind your original post, a use case can be made for hooks. The necessitated (DLL) code can be compiled on the fly from within AHK and Writte-n to another Process' Memory, thereby having injected it.
Ponder about it: AHK gained an edge by hooking the mouse and keyboard. Soon, even financiers of my kind will be able to have whatever on the hook. |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4514
Location: Boulder, CO
|
| Posted: Sun Jul 05, 2009 6:30 pm Post subject: |
|
|
The DllCall() AHK function loads a dll from a file if needed, then passes control to the selected function. If you use a compiler to execute the dll code it created, it might load it to the memory, so AHK’s DllCall can find its functions. Most likely, though, the compiler uses a temporary file, which would be the easier way from AHK, anyway: compile your code to a temporary dll file and tell AHK to use it. I don’t think there will be any noticeable time lost. At the end, you can delete the temporary file, which could actually have stayed in the Windows disk cache all the time.
Nevertheless, this is not, how machine code functions were intended to be used. It may make sense if you want to run the generated C code once (e.g. if it depends on user input), but in this thread I described how to include already compiled (static) code snippets in AHK scripts, to speed up certain operations and/or reduce code size. |
|
| Back to top |
|
|
Lenrius
Joined: 25 Dec 2008
Posts: 23
Location: 50° lat.
|
| Posted: Mon Jul 06, 2009 12:05 am Post subject: Elaboration |
|
|
Roger. Now try to read into my previous post that just in the same manner as AHK loads any DLL not previously loaded into its address space, I plan on intruding another process' address space and writing my DLL's machine code therein so as to enslave it. OLE automation the harsh way.
As for your post: Programmatically, you say, AHK calls LoadLibrary(), saves the returned HandleMODULE only to feed it on the fly into GetProcAddress() whose second parameter is DllCall's Function. AHA, this is why it "may also consist solely of an an integer".
Sometimes I think to myself: What took them so long? And the compelling answer is ignorance of the circumstance that kernel32.dll (and ntdll.dll) have a priori known base addresses.
| Laszlo wrote: | | Most likely, though, the compiler uses a temporary file |
This is worth investigating. Still, TCC can be commanded by a script. |
|
| Back to top |
|
|
infogulch
Joined: 27 Mar 2008
Posts: 376
|
| Posted: Thu Oct 22, 2009 2:55 am Post subject: |
|
|
I've been wanting to compile some inefficient code (specifically the loop in AvgBitmap) with c for a long time, and am finally un-lame enough to actually write the dll (that works, nk). 
However, disasm isn't wanting to disassemble it. :-/
I'm using msvc '08 to compile, and that's probably the issue.
I'm clueless as to how I would go about setting up gcc to compile it, so I was hoping someone would do it for me. If not, a tiny tut would be awsm.  If not that, "ask around" would be fine too. xD
Code and description: | Code: | #include <math.h>
typedef unsigned long uint;
typedef unsigned long long uint64;
//
// function SumIntBytes
// individually sums the bytes from each element in x and returns the results in
// a, b, c, and d
// Parameters:
// x: pointer to an array of 32-bit uint
// l: length of array x
// a: [out, retval] sum of first byte of all uint in x
// b: [out, retval] sum of second byte of all uint in x
// c: [out, retval] sum of third byte of all uint in x
// d: [out, retval] sum of fourth byte of all uint in x
//
__declspec(dllexport) void SumIntBytes( uint* x, uint l, uint64* a, uint64* b, uint64* c, uint64* d )
{
uint i;
for(i = 0; i < l; i = i + 1)
{
*a = *a + (x[i] >> 24);
*b = *b + (x[i] >> 16 & 0xff);
*c = *c + (x[i] >> 8 & 0xff);
*d = *d + (x[i] & 0xff);
}
} |
Thanks!
_________________
Scripts - License |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4514
Location: Boulder, CO
|
| Posted: Thu Oct 22, 2009 5:10 pm Post subject: |
|
|
| msvc'08 provides assembler listing in hex, so you don't need a disassembler. The link is in the first post. |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
