v2 Beta - installer plans?

Discuss the future of the AutoHotkey language
User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

v2 Beta - installer plans?

18 Apr 2021, 19:04

I was curious what the thoughts were for creating an installer for v2's beta. Is the thought to just ship an updated version of the installer that overwrites any existing installation with the v2 version? Ideally, we'd want to be able to have the co-exist, especially with beta (if there ends up being an installer for the beta version).

I'd be interested in assisting any efforts related to this topic.
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: v2 Beta - installer plans?

18 Apr 2021, 22:35

The plan for final release is to have one installer which manages multiple versions. I am not planning anything special for beta 1, and have not started work on the installer.

I was thinking the installation process would be simplified, with some configuration done post-install. Version selection should not require swapping files around. I have been working on a script to auto detect the version (between v1 and v2) based on syntax, if #requires isn't used. Methods of version selection and default version would be configurable.

The html based GUI would be replaced with v2 Gui().
User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: v2 Beta - installer plans?

19 Apr 2021, 07:54

That definitely seems like it would make the best experience for end users. I find the current install to be quite sufficient.

A thought about post-install configuration is that it then separates things from the installer. The installer currently is nice in the sense that one place contains everything a user would need for setup. Moving things elsewhere may lead to confusion unless there are very clear instructions.
EDIT: The above sentence didn't sound right so re-worded it for clarity.

Removing the dependency on IE for the Gui is probably a good idea. Someday IE will be gone from Windows and while you're in there working on the Installer it makes sense to switch to common controls.
Last edited by kczx3 on 19 Apr 2021, 08:41, edited 1 time in total.
User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: v2 Beta - installer plans?

19 Apr 2021, 08:10

I, for one, use V1 and V2-103, V2-127, V2-129, V2-132 co-existing w/o any installation via Total Commander's inner associations and menus, but
"configuration done post-install" sounds great as well.
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: v2 Beta - installer plans?

19 Apr 2021, 23:14

I'd like to help with this if possible. My AHK Portable Installer (in my signature) checks many of those boxes.
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: v2 Beta - installer plans?

20 Apr 2021, 04:41

kczx3 wrote:A thought about post-install configuration is that it then separates things from the installer.
The idea is to separate configuration tasks from the installation stage, not from the installer script.

The UI for initial installation has all of the options prior to beginning the installation, but most of them can be changed at any time, without (re)installation. The installer can already be used for post-install configuration, but to apply any changes, it runs through the installation process again, skipping copying of the files but maybe making other changes that weren't requested, like deleting and recreating the Start menu folder. The UI for post-install configuration is also based off the installation UI, just with some items renamed or removed.

I expect it will be easier to implement my ideas myself than to explain them and find ways to allow people to help. I might revisit this topic once I have tried some of my ideas.
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: v2 Beta - installer plans?

20 Apr 2021, 09:46

lexikos wrote:
20 Apr 2021, 04:41
I expect it will be easier to implement my ideas myself than to explain them and find ways to allow people to help. I might revisit this topic once I have tried some of my ideas.
Yah that's fair. I can relate ;)
User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: v2 Beta - installer plans?

20 Apr 2021, 11:18

Totally. In most situations related to the development of AHK that statement is true. But I thought maybe the installer was something I might be able to lend a hand with. It was also meant to convey that you’re not alone in the pursuit of developing AHK. At the very least, maybe this thread can serve as a discussion of your ideas for feedback. Thanks much!
iseahound
Posts: 1434
Joined: 13 Aug 2016, 21:04
Contact:

Re: v2 Beta - installer plans?

21 Apr 2021, 09:22

+1 for a single installer. I think that forcefully nudging people to v2 would be the best way to spur adoption.
User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: v2 Beta - installer plans?

21 Apr 2021, 09:44

@iseahound +1

I think if we make it easy to keep using v1 then no one is ever going to make the jump besides those who already have.
gregster
Posts: 8916
Joined: 30 Sep 2013, 06:48

Re: v2 Beta - installer plans?

21 Apr 2021, 10:54

I think we should focus on the advantages of v2 to get users to switch.

Hindering people to use v1 will just create an enormous amount of user requests and questions in 'Ask For Help'.
After all, there are so many scripts, functions and libraries in v1 code currently in use... and only a small part of these scripts will actually be replaced by v2 versions.
I personally will only write new scripts in v2, I have no plans whatsoever to change all my well-functioning scripts to v2.
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: v2 Beta - installer plans?

21 Apr 2021, 22:36

Using a single installer will not make it more difficult to use v1. It will make it easier to keep using v1 while also using v2.
User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: v2 Beta - installer plans?

22 Apr 2021, 05:49

So they’d be installed and usable side-by-side? Or you have to use the installer to switch?
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: v2 Beta - installer plans?

22 Apr 2021, 17:22

I wrote:I have been working on a script to auto detect the version (between v1 and v2) based on syntax, if #requires isn't used.
Of course, the point is to run the script, not to switch default versions based on one script's syntax. v1 and v2 are usable side by side, without changing the extension. I think it is 100% reliable if you include #Requires, and I was working on improving the reliability of syntax detection, although there will still be cases where a script could be interpreted as either version, sometimes with different results.

A simpler method is to try launching the script with a preferred version, and if a load time error occurs, try launching with another version. I've used stdout redirection to detect and combine the error messages without showing them immediately. However, this doesn't work for the UI Access executables since attempting to run them with CreateProcess always gives a "requires elevation" error.
iseahound
Posts: 1434
Joined: 13 Aug 2016, 21:04
Contact:

Re: v2 Beta - installer plans?

25 Apr 2021, 12:16

Since both versions are being run side by side, would it be possible to create something like:

Code: Select all

#include *i class_v2.ahk ; #Requires AutoHotkey v2
#include *i class_v1.ahk ; #Requires AutoHotkey v1
where #Requires won't throw an error if include is optional? The implementation needs to only be simple enough to permit very simple demonstration scripts. The idea would be to reduce end user friction, and avoid having two demonstration scripts for two libraries.
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: v2 Beta - installer plans?

25 Apr 2021, 20:39

No.

#Include doesn't work that way. Optional includes are either present or not. Files which contain syntax errors or anything else that causes a load-time error are still included.

#Requires doesn't work that way - it just raises a load-time error or does nothing. If #Requires is being evaluated, the file was already included. If it doesn't raise an error, the rest of the file will be parsed and included too. Whether or not the include was optional is irrelevant.

The launcher, which is just a script, doesn't work that way - it just launches the script based on the content of the main script file. And it only uses the first requirement it finds.

But this should work.

Code: Select all

/**/
#include class_v2.ahk
"
(
*/
#include class_v1.ahk
/*
)")
/*
*/
If you use *i and both files are missing, the user probably won't get a meaningful error message.

Another hack will work as long as you don't have files literally named as below, including percent signs, and I don't add validation of the type of value.

Code: Select all

#include *i class_v2%A_TrayMenu%.ahk  ; "class_v2.ahk" on v2 and literally "class_v2%A_TrayMenu%.ahk" on v1
#include *i class_v%true%.ahk  ; "class_v1.ahk" on v1 and literally "class_v%true%.ahk" on v2
;#include *i class_v1%A_Gui%.ahk  ; "class_v1.ahk" on v1 and literally "class_v1%A_Gui%.ahk" on v2
If each version has its own folder, it can have its own Lib folder. But that's only helpful if the scripts are installed into the appropriate library.
... and avoid having two demonstration scripts for two libraries.
Personally, I think it's a waste of time trying to write one script for both versions.
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: v2 Beta - installer plans?

02 May 2021, 07:19

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.
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: v2 Beta - installer plans?

02 May 2021, 11:18

This sounds like some cool stuff :D

Just wondering, is the idea for the multi-version installer to install multiple keys, one per version, to orchestrate how a multi-version setup would operate? Or is there a single "launcher" that would somehow determine what version of AutoHotkey.exe to run?

My portable installer does the latter, when functioning as an installer. The only down side to this is getting a different PID as a result of using the launcher, but that is easy enough to work around, for most of my uses.

I also remember you mentioning that you planned on adding a component to scan the syntax of the script to attempt to determine version. I'm just wondering how this is looking now, and how it might come together.
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: v2 Beta - installer plans?

02 May 2021, 20:44

TheArkive wrote:
02 May 2021, 11:18
Or is there a single "launcher" that would somehow determine what version of AutoHotkey.exe to run?
I'm sure you already read what I wrote about that, because:
I also remember you mentioning that you planned on adding a component to scan the syntax of the script to attempt to determine version.

But here it all is again:
lexikos wrote:
18 Apr 2021, 22:35
I have been working on a script to auto detect the version (between v1 and v2) based on syntax, if #requires isn't used. Methods of version selection and default version would be configurable.
lexikos wrote:
22 Apr 2021, 17:22
Of course, the point is to run the script, not to switch default versions based on one script's syntax. v1 and v2 are usable side by side, without changing the extension. I think it is 100% reliable if you include #Requires, and I was working on improving the reliability of syntax detection, although there will still be cases where a script could be interpreted as either version, sometimes with different results.

A simpler method is to try launching the script with a preferred version, and if a load time error occurs, try launching with another version. I've used stdout redirection to detect and combine the error messages without showing them immediately. However, this doesn't work for the UI Access executables since attempting to run them with CreateProcess always gives a "requires elevation" error.
lexikos wrote:
25 Apr 2021, 20:39
The launcher, which is just a script, [...] just launches the script based on the content of the main script file. And it only uses the first requirement it finds.
lexikos wrote:
02 May 2021, 07:19
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.
I have not done any work on the launcher since posting about it, other than to fix some issues relating to how Ahk2Exe uses AutoHotkey.exe.

When you run the launcher, it is designed to exit immediately after determining whether or not the launch failed due to a syntax error. It does this by detecting any windows created by the new process, such as ahk_class AutoHotkey or a warning/error dialog. Syntax errors are redirected to stderr, so if a dialog is displayed, it is assumed there are no syntax errors. Technically it might be possible for loading to fail after displaying a warning, but warnings are displayed at a late stage, so it's unlikely to be an issue for the purpose of the launcher (see "simpler method" above).

Stderr is read by the launcher so that it can display the error(s) only after trying both AutoHotkey versions (if it is using the "simpler method"), but is also echoed back to the parent process if stderr has been redirected. If the launcher itself has stdin or stdout redirected, it is assumed the parent process wants the output of the child process, so these are passed along and the launcher does not exit until the child process exits. However, Ahk2Exe only redirects stderr, not stdin/stdout, so I had to change the launcher to also wait if the /iLib switch was used.

When the launcher (as AutoHotkey.exe) is executed by SciTE4AutoHotkey, the output is correctly displayed in the output pane (along with some additional lines showing what the launcher is doing).

If the parent process has passed a stdout handle and is reading from it, it might not even matter whether the launcher exits, since the handle remains open until the child process exits. However, waiting allows the launcher to pass the exit code back to the parent process.

TheArkive wrote:is the idea for the multi-version installer to install multiple keys, one per version
The idea for the installer is to simplify the installation and use of multiple versions. The idea for the launcher is to allow the user to just execute a script without choosing between versions in any way (no separate context menu items, no changing default version back and forward, etc.). The launcher already exists; the installer doesn't.

There are several registry keys used for different purposes, but you can only have one file type key and one default action active at a time for a single filename extension. Exactly what do you mean by "install multiple keys, one per version"?

As I said,
lexikos wrote:
02 May 2021, 07:19
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.
Benefits of using multiple keys might be:
  • The user can install an old version by running its installer directly, without overwriting a multi-version installation. However, running the old uninstaller would still delete the .ahk key even if all other keys are separate, so maybe it's better to support this scenario by requiring the user to use the new installer to manage old versions.
  • HKLM\SOFTWARE\AutoHotkey, InstallDir can be left set to a v1 directory, such as C:\Program Files\AutoHotkey\v1.1.33. InstallDir is used by A_AhkPath in current compiled scripts, and by the Help and Window Spy options if the necessary files aren't found locally. However, that also applies to all v2-alpha releases up to now.
TheArkive wrote: The only down side to this is getting a different PID as a result of using the launcher, but that is easy enough to work around, for most of my uses.
If I've ever used the PID of an AutoHotkey script that I'm launching, I don't recall it... other than in the launcher itself.

I think the cases where that is an issue will be a minority. They will just have to be updated to account for the new structure, which would probably need to happen anyway if there was no launcher, unless AutoHotkey.exe happens to be the expected version. If only v2 is installed, how likely is it that such scripts would work anyway?
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: v2 Beta - installer plans?

03 May 2021, 09:36

lexikos wrote:
02 May 2021, 20:44
I'm sure you already read what I wrote about that, because:
...
But here it all is again:

My apologies. I didn't intend for you to repeat yourself. I was just wondering if some aspect of your vision for this project had either changed, or taken a more concrete form.

lexikos wrote:
02 May 2021, 20:44
(regarding the multi-version installer) ... To mitigate that, the multi-version installer might use different registry keys/values...
...
There are several registry keys used for different purposes, but you can only have one file type key and one default action active at a time for a single filename extension. Exactly what do you mean by "install multiple keys, one per version"?

I was thinking the same thing about having a single key related to a specific action for a specific file extension. I just had difficulty understanding what you meant by "different registry keys". Clearly I was over-thinking it.

lexikos wrote:
02 May 2021, 20:44
(PID and launcher stuff...)
...
I think the cases where that is an issue will be a minority.
...
If only v2 is installed, how likely is it that such scripts would work anyway?

I definitely agree this shouldn't be an issue. I use a launcher on my system for a multi-AHK-version setup, and I've used the PID significantly less in the solutions I've come up with as a result. It's just usually not necessary, and even not the best way to do whatever I'm trying to do in general. Does this answer your question here?

lexikos wrote:
02 May 2021, 20:44
Of course, the point is to run the script, not to switch default versions based on one script's syntax. v1 and v2 are usable side by side, without changing the extension. I think it is 100% reliable if you include #Requires, and I was working on improving the reliability of syntax detection, although there will still be cases where a script could be interpreted as either version, sometimes with different results.
...
The launcher, which is just a script, [...] just launches the script based on the content of the main script file. And it only uses the first requirement it finds.
...
When you run the launcher, it is designed to exit immediately after determining whether or not the launch failed due to a syntax error.

I have my launcher setup to do exactly all these things, except for #Requires for the reason highlighted in red.

I think #Requires serves it's purpose well as general guardrails for running a script, but as long as it is not required to spell out a complete version string, there's always going to be some ambiguity.

And trying to scan the syntax, unless the scanner script completely catalogs all versions of AHK syntax there will be ambiguity there as well.

If you like I can post some examples (more detailed than what I have already posted) of how my Launcher / GUI works for config. I am able to seamlessly run any version of AHK I have setup with no ambiguity, and no need for the user to pick a version on launch, and no need to switch the "default version" installed. The only time I have to manually modify this config is when I add/remove a version of AHK on my system. And even then, the maintenance is quite minimal.

The only thing I can do to improve my setup, that I can see, is to implement HTTP connections to allow the user to browse for more versions and download them directly with the Launcher GUI.

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: lexikos and 40 guests