I spent some time last week looking at some alternative execution methods for the scriptlets. Yesterday in particular, I looked at separate processes and also execution as DLL functions. Yes, DLL functions. I saw that running dll’s accomplishes a lot of what I’m after for the scriptlets to be run in the greasegeek/better windows app, but in it’s own process or thread. The trouble is, how practical is it? I’m still looking.
In my tests, I could not simply compile a script and then start it by doing a DlllCall to the exe’s “Main” function or any explicit function for that matter. I also could not just rename it to a .dll file and get anything to happen that way. There are other ways of getting things to run with the DllCall method, which is why I’ll still be investigating it. I’ll have to look at the AHK forums and see if anybody has been able to get AHK compiled exe’s to run from that command. The method supports running EXE’s so in theory it should be a clear possibility to run an AHK that’s compiled.
Another thing I looked into was multiple threads for the scriptlets. The problem with that is that AHK is not multi-threaded in the traditional sense. It simply pauses separate threads to run parts of another for the moment that it needs to run, then resumes the other that it was currently processing. In short, it runs only one thread at a time, and will put as many as there are aside from one that gets processed now, on hold indefinitely until that thread is done with what it’s doing.
As you can see, turning on and off the separate threads of each scriptlet is not in the least ideal, and I would say completely unacceptable for most scripts. This is why I’ve looked at ways of running each scriptlet in it’s own process (via either by autohotkey.exe, or by a DllCall, or otherwise). This is my main focus at the moment, but perhaps I should just go ahead and settle for the AutoHotKey.exe approach for now and worry about getting it more ideal later.
Like