Compile/Run C programs from AHK w/o temp files

AutoHotkey Community
Let's help each other out

FAQ

Memberlist

Profile

Compile/Run C programs from AHK w/o temp files
Goto page Previous 1, 2, 3 Next

AutoHotkey Community Forum Index -> Scripts & Functions

View previous topic :: View next topic

Author

Message

Laszlo

Joined: 14 Feb 2005
Posts: 3943
Location: Pittsburgh

Posted: Sun Apr 29, 2007 8:00 pm Post subject:

majkinetor wrote:

One of those things [callback] that are not possible to do in AHK. Its pity Chris don't want to use C/Invoke in AHK which is used in Lua, Java and some other languages for FFI and it has very nice, dllcall, struct and callback encapsulation.

There is a way to use callbacks in AHK, as Shimanov demonstrated long ago. Basically, you write a C callback function, compile it and copy it with RTLFillMemory dll calls into an AHK variable. I don't have enough time for that, but if someone did it, it would help us all.

majkinetor

Joined: 24 May 2006
Posts: 3600
Location: Belgrade

Posted: Sun Apr 29, 2007 8:16 pm Post subject:

LOL. Now, that is open-minded. It seems that it can be done, I will check it out, Shimanov is really great programmer. Its too bad he isn't with us now. BTW, I wanted to say that #NoEnv problem looked like a bug, but then for some reasons I had doubts that I missed something.... _________________

Sean

Joined: 12 Feb 2007
Posts: 1255

Posted: Mon Apr 30, 2007 12:34 am Post subject:

Laszlo wrote:

Interesting idea. As a matter of fact, I also thought about similar method a while ago, but the obvious obstacle was that I don't know C or ASM. More precisely, I don't know a way to tell the end/size of the compiled code.
In this regard, an interesting app I found so far was this which can execute a machine code when provided as a string.

BTW, I was surprised when realizing how rarely I needed callback actually.
I used it only for EnumWindows, EnumChildWindows, and EnumFontFamiliesEx, even those were for tests.

Sean

Joined: 12 Feb 2007
Posts: 1255

Posted: Mon Apr 30, 2007 12:50 am Post subject:

majkinetor wrote:

So, no ideas for this case, except if Chris support callback which is IMO very needed as it will allow hooks that can be used to automate almost everything in the system.

Well, possibly I've missed the point, but I don't think we can use the callback in AHK for the hook, at least in a standard manner (except those already implemented in AHK, keyboard/mouse LL hook, Jounal Hook).
As far as I can tell, it should be implemented as dll, well again at least to say in a standard way.
I know of an attempt to load the executable itself into other processes by sort of faking, i.e., implementing a DllMain function inside the executable itself, but it appeared to me weird.

Laszlo

Joined: 14 Feb 2005
Posts: 3943
Location: Pittsburgh

Posted: Mon Apr 30, 2007 1:06 am Post subject:

Sean wrote:

an interesting app I found so far was this which can execute a machine code when provided as a string.

TCC supports a gas-like assembler syntax (GNU assembler). A simple example is below, the BSWAP function. You have to know the gas syntax, but it is worth the effort, if you need to achieve the ultimate speed or memory use.

Code:

h = 0x12345678
PROG =
(
typedef unsigned long UInt32;

UInt32 BSWAP(UInt32 x) { // Byte reversal
__asm__("bswap `%0" : "=r" (x) : "0" (x));
return x; }

main() {
char* _result;
sprintf(_result,"ByteSwap of `%x = `%x",%h%,BSWAP(%h%)); }
)

MsgBox % Run("c:\tcclib",PROG)

This can be useful, if you want to convert many little endian words to big endian ones, each conversion requiring just one CPU instruction. (The I/O takes much longer than this.)

Sean wrote:

BTW, I was surprised when realizing how rarely I needed callback actually.
I used it only for EnumWindows, EnumChildWindows, and EnumFontFamiliesEx, even those were for tests.

How did you do it?

Chris
Site Admin

Joined: 02 Mar 2004
Posts: 10465

Posted: Mon Apr 30, 2007 1:42 am Post subject:

I'm still planning to look into callbacks, but I'd like it to be done professionally like DllCall. Unfortunately, that would probably take a lot more development time.

Sean

Joined: 12 Feb 2007
Posts: 1255

Posted: Mon Apr 30, 2007 1:56 am Post subject:

Laszlo wrote:

TCC supports a gas-like assembler syntax (GNU assembler).

So, it supports inline asm... Thanks for the info.

Quote:

Sean wrote:

BTW, I was surprised when realizing how rarely I needed callback actually.
I used it only for EnumWindows, EnumChildWindows, and EnumFontFamiliesEx, even those were for tests.

How did you do it?

Oops, sorry, it was not with AHK, with another app.
When callback was implemented there, I was testing it before released to the public, and wrote example scripts to use it.

Laszlo

Joined: 14 Feb 2005
Posts: 3943
Location: Pittsburgh

Posted: Mon Apr 30, 2007 2:41 am Post subject:

The bug was in the original script, masked by #NoEnv. AHK did not know the new length of x after it was modified by the C program, and got confused. I added an explicit VarSetCapacity(x,-1) instruction to fix it. The example script is updated in the first post, and the assembler example is added. The TEST.ahk in the tcclib.zip is also updated.

majkinetor

Joined: 24 May 2006
Posts: 3600
Location: Belgrade

Posted: Mon Apr 30, 2007 9:11 am Post subject:

Quote:

Yes, global hooks must be in dll, but as you said, there are weird ways to do it in exe, and you can always pack small dll wrapper in AHK resource, extract it to TEMP dir when user needs it for the first time and leave it there.

Quote:

I used it only for EnumWindows, EnumChildWindows, and EnumFontFamiliesEx, even those were for tests.

Oh very basic usage. Hooks allow for mass of kewl system updates, and new automatition features. Also, callbacks not only allow hooks, but subclassing. As you probably know, subclassing is mean to override windows classes (like Buttons, Edits etc...) so this creates new dimension of automatition. For instance, you can set that every button have round corners with Hooks, or that your script is informed before top level window is about to be shown so you can automate its position before it appears on the screen. This will allow DOCKing to be implemented as AHK script (currently impossible without timer which makes bad results as dock window will late). More, with callbacks and hooks together in action, you are able to change Windows Procedure of every program so you can monitor its messages. For instance, you would be able to display coordinate at mouse pointer while you move mouse over PhotoShop canvas.

Now, hard core example is using hooks, callbacks and asm compiling to create so called redirection. It is mechanism to hook on every Windows Function, so your function is called before it, and you can decide if to call original function, change its parameters or anything. Well, this is overkill for AHK and there are like 0.01% programmers in the world that do know how to that, but againk, with callbacks this would be possible too Smile

Maybe Shimanov resurects one day or smb else do it who knows...
You could for instance create simple firewal by hooking Socket functions. I posted more about redirection in the utilities and resources.

So, several classes of automatition are not now possible and would be with callbacks.

2Laszlo
Thx for the asm example.

2Chris

Chris wrote:

I'm still planning to look into callbacks, but I'd like it to be done professionally like DllCall. Unfortunately, that would probably take a lot more development time.

Why don't you do yourself a favor and check out C/Invoke library. This is very proffesionaly done, you just need to create interface for its functionalities, will not introduce performance or size problems, its already tested in Lua and Java. Please check out how this is looks like in Lua here
_________________

Sean

Joined: 12 Feb 2007
Posts: 1255

Posted: Mon Apr 30, 2007 10:38 am Post subject:

majkinetor wrote:

Quote:

I used it only for EnumWindows, EnumChildWindows, and EnumFontFamiliesEx, even those were for tests.

Oh very basic usage.

Yes, that was the point. Even with these basic usages, I seldom feel the need, just once a while, at least with me.

Quote:

Hooks allow for mass of kewl system updates, and new automatition features.

OK, I admit that the subclassing may be appealing to many users (:but not me, I'm usually not interested in GUI stuffs).

BTW, I'm more interested in API hooking etc. But, as you said it requires a dll file, or a driver file for the kernel-level hooking. Who will write the dll file (:I don't like the idea of packing it inside AHK itself, btw)?
And, more importantly, if dll should be used, then the callback should be implemented inside the dll too. There is really no need of callback inside AHK. The dll and AHK can communicate using Messages, say WM_COPYDATA.

Anyway, don't get me wrong. I'm not against the native callback support in AHK. I'm just saying that it may not be that urgent than appears.

majkinetor

Joined: 24 May 2006
Posts: 3600
Location: Belgrade

Posted: Mon Apr 30, 2007 10:45 am Post subject:

Quote:

OK, I admit that the subclassing may be appealing to many users (:but not me, I'm usually not interested in GUI stuffs).

I noticed you don't like GUIs. However this is your limitation. The wise person uses everything it has in its environment. Just look at the Jacky Chain movies - he can pwn U with the toothbrush Very Happy

Quote:

BTW, I'm more interested in API hooking etc. But, as you said it requires a dll file, or a driver file for the kernel-level hooking. Who will write the dll file (:I don't like the idea of packing it inside AHK itself, btw)?

No, not the driver, but hook. It gets much much harder with driver IMO.

I don't know why you don't like packing DLL into AHK executable resource as you will never notice that. Unpacking is done into temp dir only if dll is not there (for instance you deleted entire folder) and if it is there it is normaly used. This also prevent it to be accidently deleted while in use. This dll is only wrapper and it can generaly made to be very small.

Alternative is creating dll inside exe but this will load entire AHK into the process space of every app... not very wise comparing to small 20K dll. There are huge number of apps that do pack additinal files in single executable so to keep single exe even for very advanced stuff. This dll can be even made in ASM (there are some very nice examples in RosAsm already) so resulting dll will be as small as possible.

Well, the thing is not so bright, I must admit, as some form of interprocess communiction must be done between AHK and its dll... ... and it may be impossible dll to be only wrapper but it will probably have to do some number of things on its own... but anyway, some good designs for this can probably be made after more research is done.
_________________

Sean

Joined: 12 Feb 2007
Posts: 1255

Posted: Mon Apr 30, 2007 11:10 am Post subject:

majkinetor wrote:

I noticed you don't like GUIs. However this is your limitation. The wise person uses everything it has in its environment.

Well, I didn't say I don't like GUIs, just not interested in polishing them as it usually requires a lot of patience from me, i.e., I'm lousy with them.

Quote:

There are huge number of apps that do pack additinal files in single executable so to keep single exe even for very advanced stuff. This dll can be even made in ASM (there are some very nice examples in RosAsm already) so resulting dll will be as small as possible.

Yes, I know.
But, I'd like to have it/them as separate files with AHK, assuming we're controlling the loading of it/them from the scripts.
BTW, I noticed the mouse hook dll in RosAsm by Zippo(). It's really excellent.

majkinetor

Joined: 24 May 2006
Posts: 3600
Location: Belgrade

Posted: Mon Apr 30, 2007 12:24 pm Post subject:

Quote:

But, I'd like to have it/them as separate files with AHK, assuming we're controlling the loading of it/them from the scripts.

I assume this dll would be extracted and used only if you use hook features of AHK, in which case you can get it from TEMP folder. Its not big deal to make it be in the AHK folder all the time, which will not reduce portability, but only the facct that you must think about additional file when moving AHK executable. You still didn't tell why do you not like it.

Quote:

BTW, I noticed the mouse hook dll in RosAsm by Zippo(). It's really excellent

Yup, this RosAsm really made asm look easy Very Happy

and example by notorious Zippo() is surely good demonstration.
_________________

Sean

Joined: 12 Feb 2007
Posts: 1255

Posted: Mon Apr 30, 2007 1:54 pm Post subject:

majkinetor wrote:

You still didn't tell why do you not like it.

Basically because I'd like to have a choice.
If one is written, another one could be written too, say, one for both global keyboard/mouse hooks, one for only keyboard or for only mouse, even one for further specialized like MouseMove.
Furthermore, someone may not like the extra modules at all.
So, unless it's absolutely needed one to execute AHK, it'd better be provided as a separate file, IMO.
Of course it's based on the assumption we'll have the control over the modules from the scripts.

majkinetor

Joined: 24 May 2006
Posts: 3600
Location: Belgrade

Posted: Mon Apr 30, 2007 2:35 pm Post subject:

There is nothing you need to write here. There are like 8 or so system hooks and all you need to do is provide activation method, and callback to handle them. For instance:

Code:

Hook, Mouse, MouseFunc
Hook, Keyboard, KeyboardFunc
Hook, HookType, HookFunc

Once you implemented one, you basicly implemented all as it is trivial difference how to add new hook types (I think its only a flag, but I didn't refresh my MSDN memory)

So, this will not introduce anything visible to the public if dll is added to the exe resource and you will be able to control all hooks. Like I said, in combination with subclassing, power is unlimited. You could be able to create almost anything in ahk, and this "almost" is really "almost".

Example: Play with notepad

Code:

Hook, WndProc, MyProc

MyProc(hwnd, msg, wparam, lparam)
{
if msg=WM_CLOSE
return 0 ;forbid closing
else return OldWndProc(hwnd, msg...)

if msg= WM_MOVE
;move my docking window here and call OldWndProc
}

Example: Play with top level windows

Code:

Hook, WndProc, MyProc

MyProc( struct cs, hwnd )
{
if cs.class = Notepad_Class
return 0 ; don't let the system create notepad.
}

As you see this is very powerful, and in automatition domain, so AHK need this as hell.

Even better alternative would be something in AHK spirit:

Code:

Hook, CREATEWND, MyProc, ahk_id Notepad

but I beleive this is much harder to implment, although I am not sure.

I was working a lot with hooks before some time... so I have pretty much XP in this. If Chris ever desires to have this, I can devote my time for to design this or help at any manner.

Jump to Reference
_________________

Last edited by majkinetor on Mon Apr 30, 2007 3:04 pm; edited 1 time in total

Display posts from previous:

	AutoHotkey Community Forum Index -> Scripts & Functions	All times are GMT Goto page Previous 1, 2, 3 Next
Page 2 of 3

You can post new topics in this forum
You can reply to topics in this forum