Extracting Autohotkey.dll (or other "strange" ideas)

[newbieforever]

Hi!

I suppose Autohotkey.dll is somehow embedded in a compiled AHK script.

If this is correct, is there a way to extract Autohotkey.dll from the compiled script, or get and save it during the compiled script is running?

ED:
But this is just another attempt of mine with a very concrete concern (for which no relevance has been seen here so far: "strange" ideas...).

[boiler]

AutoHotkey.dll is not part of the main release of AutoHotkey and is not embedded in a compiled script. It can be downloaded as part of HotKeyIt’s AHK_H fork.

[HotKeyIt]

In AutoHotkey_H the AutoHotkey.dll is included in resource of AutoHotkey.exe which is also used for compilation.

[newbieforever]

An answer from HotKeyIt... what an honor. Thanks a lot!

I don't have the deeper knowledge and competence to really judge this (old) question. Nevertheless:

(I) In AHK_L there are still two interpreter executables used, AutoHotkey.exe and AutoHotkeySC.bin. The reason for this duality in grey prehistoric times was probably that the BIN used for compilation is leaner. But the difference between EXE and BIN today is only 882 vs 817 kB, for compressed files 372 vs 336 kB (U32 in 1.1.32). That doesn't make sense anymore, does it?!

(II) To launch compiled scripts (i.e. AutoHotkeySC.bin) command lines must have the following structure:
CompiledScript.exe [Switches] [Script Parameters]
It would be, I think, so easy for Lexikos & Co. to slightly change a tiny spot in the source code by inserting really only a few simple lines, which would allow the use of an additional (optional) switch:
CompiledScript.exe [/scr:Script Filename] [Switches] [Script Parameters]
I believe that the (so far) usual use of AutoHotkey would not be influenced by this in any way. However, it would be possible to use any compiled script as an interpreter to execute any script!!!
The only thing that would have to be changed in the source code would be that if /scr:... is used in the command line, the interpreter should not process the embedded script, but the script specified in the CL (as in the case of AutoHotkey.exe).

But I know everyone here will immediately cry out that there is absolutely no need for this. Do you think so too, HotKeyIt?

[HotKeyIt]

No, that is why AutoHotkey_H has the /E (also /Execute) switch to execute a different script than compiled.

[newbieforever]

No, that is why AutoHotkey_H has the /E (also /Execute) switch to execute a different script than compiled.

Thanks a million, HotKeyIt!

Forgive me for seeking further approval from you:

- Wouldn't that be an enormous improvement of the usage possibilities (for a part of the users)?
- Wouldn't this be possible without any disturbance of the usual usage?
- Wouldn't that be possible with minimal effort? (If the source code was written in AHK, even I would be able to do it. (1) Identify the switch /e or /scr in the CL. (2) Read not the embedded file, but the one specified in the CL.)

[HotKeyIt]

1. Wouldn't that be an enormous improvement of the usage possibilities (for a part of the users)?
2. Wouldn't this be possible without any disturbance of the usual usage?
3. Wouldn't that be possible with minimal effort? (If the source code was written in AHK, even I would be able to do it. (1) Identify the switch /e or /scr in the CL. (2) Read not the embedded file, but the one specified in the CL.)

1. That is what I thought
2. Get rid of bin files to avoid confusion
3. It was not difficult to implement

[newbieforever]

@HotKeyIt

Thank you, I find your answer very comforting. I was seriously thinking that I...

This is going to be my last question to you:
How come nobody else here recognizes it?

.

[boiler]

How come nobody else here recognizes it?

Have you requested it on the Wish List sub-forum?

If the source code was written in AHK, even I would be able to do it.

If you want a fork with this capability, why not use AHK_H?