I'm posting some comments here relating to both the installer and
Ahk2Exe, to avoid derailing that topic.
TheArkive wrote: ↑19 Apr 2021, 05:52
In this case I'm thinking of a folder structure like this:
Code: Select all
root\
\Ahk2Exe
\AutoHotkey v1.1.32
\AutoHotkey v1.1.33
\AutoHotkey v2-a120
\AutoHotkey v2-a130
\... and so on ...
So am I.
For the moment, assume something like
AutoHotkey\v*\*.bin and
AutoHotkey\v*\AutoHotkey*.exe. I'll probably remove the "U" from the v2 files to help distinguish v1 and v2 processes, and because there won't be an ANSI version. Assume there will only be one AutoHotkey.exe (without suffix), at
AutoHotkey\AutoHotkey.exe, and it will actually be a compiled script (the version-selecting launcher), but that might be up to a user preference.
Ahk2Exe already includes code for detecting the version of an AutoHotkey bin or exe, so you can match them up regardless of name.
I will probably not include Ahk2Exe with v2, as I have no desire to convert it to v2 or maintain it myself, or to include a v1 binary in the v2 download. Instead, the installer may provide an option to automate downloading and installing Ahk2Exe and any required bin files. I would like to leave the official Ahk2Exe releases to
@TAC109.
Along those lines, I was thinking to remove the requirement for bin files altogether. Changing AutoHotkey.exe to support using it as the basis for a compiled script isn't much work, and based on what I've got so far (FileInstall and A_AhkPath are the uncompiled versions, and other things need tweaking), it will probably only increase the size by a few KB. (The difference between the current exe and bin is more significant, but still not very much.) I think it's worth it, especially because combining embedded scripts with the full interpreter opens up further possibilities.
For instance, a simple test script:
Code: Select all
if (f := FileSelect(,, "Select Script", "AutoHotkey Scripts (*.ahk)")) != ""
Run Format('"{1}" /execute "{2}"', A_AhkPath, f) ; In this test build, A_AhkPath = A_ScriptFullPath when compiled.
if false
FileInstall "Lib\D.ahk", "nul"
I compiled this with the current Ahk2Exe, by giving both
/ahk and
/bin the path of the exe, producing compiletest.exe. When executed, compiletest.exe shows a file dialog; if the user selects a script file and confirms, that file is executed by running
compiletest.exe /execute (a new reserved arg, because just passing the filename would make it a parameter of the embedded script).
Furthermore, the script it executes can
#include *LIB\D.AHK. Technically
compiletest.exe /execute *LIB\D.AHK should also work, but D is just a function in this case. The need for capitalization is one of the things that need tweaking. At the moment any path other than "*" itself or "*i " (with the space) is assumed to be a resource name.
A little more work should allow an embedded script to be automatically "#included" prior to the main script, as a standard header for all scripts executed by the executable. In that case, the "compiled script" resource may be absent, in which case the executable would act more like a normal AutoHotkey.exe. This would allow for more portable uncompiled setups, or for patching the interpreter without having to write or know C++ or install Visual Studio.
I am also going to explore other ideas relating to reimplementing parts of AutoHotkey as embedded script.
A_AhkPath, if it continues to get its value from the registry (in compiled scripts), might read from a registry value specific to the version of AutoHotkey. That way, A_AhkPath is more likely to return an interpreter relevant to the version of the compiled script (or return nothing rather than an incompatible version). However, that isn't necessarily helpful (especially if v2 compiled scripts can execute scripts on their own), and I'm really not sure how much A_AhkPath is used in compiled scripts, or what for.
A_AhkPath might instead be changed to A_ExePath to signify that it is always the path of the current executable (even for compiled scripts), and scripts can just read
HKLM\Software\AutoHotkey, InstallDir or whatever the new/appropriate registry value is. (A_AhkPath in compiled scripts just appends "\AutoHotkey.exe" to that.) Or I might not even rename it, so adjustment would only be needed for v2
compiled scripts.
Going back to the directory structure;
The installer can migrate an existing v1 install into the appropriate subdirectory.
Installing an older v1 version afterward might break some things. To mitigate that, the multi-version installer might use different registry keys/values, and/or have the facility to automate installation of older versions. Non-admin installs might be a possibility, in which case different registry keys will be used anyway.
Newer v1 installers (if there are any) can detect the presence of the multi-version installer and use it to manage the installation.