AutoHotkey Community

I made a script to automate as much as possible the process of converting C/C++ code into machine code. See here.

Is it possible to make extreme fast hex2txt and txt2hex functions with mcode?

Try the Bin2Hex and Hex2Bin functions posted on page 1 and page 8 of this thread. The search function of the Forum is not very good for finding something in long threads...

Oh yeah, I see.
If you weren't sarcastic I agree with you, AHK forums should upgraded to version where you can use search in threads.

I've discovered something cool!
It is possible to "call" APIs (or really any function) from machine code:

Here is a quick example:



The trick is to call the function by address inside the machine code. This is the C code compiled:



MessageBox is just an example, but you could use this technique for any function. Obviously, you'll have to compile the appropriate C code for functions with different signatures.

After running a few benchmarks, it seems to be faster than calling the target function directly with DllCall. Although I couldn't find a good CPU intensive function to test with (suggestions?). Regardless, we still have to use DllCall in the end, incurring whatever overhead comes with it.

I used a similar technique to implement FileExtract, which runs a compiled C++ function in a separate thread. The function depends on ConnectNamedPipe, ReadFile and GlobalReAlloc, which are passed to it via a structure/parameter.
Another trick is to put the address directly into the machine code, as I did with DebugBIF. The function address has to be called indirectly, unless you want to calculate the offset of the function to the 'call' instruction... One way way to do it is something like:
...then replacing 78563412 in the output. (If you're viewing it as a stream of hexadecimal characters, the least significant bytes come first. DebugBIF uses __mcodeptr to format the pointer this way.) Equivalent assembly is something like:
I presume you were comparing to DllCall("LiteralFunctionName"), which is not direct. It has to call GetProcAddress every time to retrieve the function address, and for quick functions this means a considerable amount of overhead. Well, unless you're using AutoHotkey_L or a derivative, in which case such function names are automatically resolved at load-time if they are present in memory.
Edit: In your example, calling _MessageBoxA instead should be faster.

Yeah, you're right. I did a bit more testing today (this time with MulDiv), and it seems like _MulDiv is the fastest in mainstream AHK, while "MulDiv" is fastest in AHK_L by a slight margin.

If you are after DllCall speedup, you might be interested in DynaCall (AHK_H).

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

Sorry, just doing some speed tests and I know not related to ahk, but why does:



not work? but if i uncomment the highlighted line then it does work. surely that byte (alpha channel) should be left as is when its commented

edit:
sorry for the stupid post Laszlo.....was just a typo. Ill post the code when Ive finished it. Thanks for all the hard work though

What does not work? What values do you see in the original scan0 memory location? What are the values of the other parameters?

Take a look at the array given below:

char addfunc[] = "\x55\x89\xe5\x8b\x55\x0c\x8b\x45\x08\x01\xd0\x5d\xc3\x90";

The above array contains x86 instructions corresponding to

int Add( int a , int b ) {
return a+b;
}

We can include the above declaration in our C/C++ Programs ( 32 bit windows or 32 bit Linux ) and execute those instructions (from addfunc).Need to figure it out how this can be achieved in

a) MS Windows ( 32 bit )
b) GNU Linux ( x86 32 bit )

The Challenge is to generate x86 32 bit instructions for the function given below:

long swap(long *a , long *b ) {
long temp = *a;
long *a = *b;
*b = temp;
}
char swapfunc[] = { <your instruction list goes here> }

Write a ANSI C/C++ program which can run on
b ) under Linux 32 bit
a ) under Windows 32 bit

Provide a single source code base , which can be compiled on both platforms using make files.

Please Help Great guys !

Is the problem that pointers are different in Windows and Linux, or long means different things, or (most likely) parameters are passed to a function differently (registers/stack), or the stack is cleaned up by the caller in one platform and by the function in the other, or different registers/pages need to be preserved? If any of these is true, a universal binary would need assembler programing.

if I create a function that returns an int pointer:



then how can I get the value 7 using NumGet?

In the C function you declare a local variable x. When the fn function returns, this variable does not exist any more, its memory is freed. You probably want to pass an address of an AHK variable to the function, where you store 7.

I changed my OS to my nlited XP and since then I've had problems with bin2hex function:

That example returns me 4 boxes:

And I guess that's not right I've also tried standalone version of bin2hex and not working, also tried the BinToHex.dll. My AHK version is 1.0.48.05.L52H20.