Running different AHK releases in parallel

[BoBo]

Hi, I'd like to run different versions of AHK in parallel, as suggested [here] at the bottom section, and for the mentioned reason.
To accomplish that I'd like to assign a file's extension to its respective executable, eg. ...

*.ahk = AHK 1.0.x
*.ah1 = AHK 1.1.x
*.ah2 = AHK 2.x

... but there's (currently) a single registry setting for AHK that triggers which executable will be used.

Question: is PhiLho's approach [ AHK.reg: registry settings if you didn't installed AHK ] still the (valid) way to go, and (before I start to cripple my registry with trial and error) would you be able to point out how to accomplish the above-mentioned assignment??

Spoiler

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.ahk]
"PerceivedType"="text"
@="AutoHotkeyScript"

; If you keep this section, put a Template.ahk file in %WinDir%\ShellNew
[HKEY_CLASSES_ROOT\.ahk\ShellNew]
"FileName"="Template.ahk"

; Keep this if you want the Search function of Windows
; to look inside AHK scripts when searching a string inside the files.
[HKEY_CLASSES_ROOT\.ahk\PersistentHandler]
@="{5e941d80-bf96-11cd-b579-08002b30bfeb}"

[HKEY_CLASSES_ROOT\AutoHotkeyScript]
; English
@="AutoHotkey Script"
; French
@="Script AutoHotkey"

[HKEY_CLASSES_ROOT\AutoHotkeyScript\DefaultIcon]
; Put AutoHotkey real location, of course
@="C:\\Program Files\\UDev\\AutoHotkey\\AutoHotkey.exe,1"

; Default verb, when double-clicking
;[HKEY_CLASSES_ROOT\AutoHotkeyScript\shell]
;@="Run"

;-- Edit the script with the editor of your choice
[HKEY_CLASSES_ROOT\AutoHotkeyScript\shell\edit]
; Leave empty to get default localized name of the standard verb,
; or use one of the below (or your own!)
; English
@="Edit Script"
; French
@="Éditer le &script"

[HKEY_CLASSES_ROOT\AutoHotkeyScript\shell\edit\command]
; Put here the path to your favorite text editor
; On some old systems (Win95, WinNT4), using %1 may give the short path, using %L always gives the Long path...
@="\"C:\\Program Files\\UTexts\\SciTE\\SciTE.exe\" \"%L\""

;-- Open the script (run it)
[HKEY_CLASSES_ROOT\AutoHotkeyScript\shell\open]
; English
@="Open Script"
; French
@="E&xécuter le script"

[HKEY_CLASSES_ROOT\AutoHotkeyScript\shell\open\command]
; Change path here too
; %1: AHK script; %*: additional (optional) parameters
@="\"C:\\Program Files\\UDev\\AutoHotkey\\AutoHotkey.exe\" \"%1\" %*"

;-- Compile the script
[HKEY_CLASSES_ROOT\AutoHotkeyScript\shell\Compile]
; English
@="Compile Script"
; French
@="&Compiler le script"

[HKEY_CLASSES_ROOT\AutoHotkeyScript\shell\Compile\Command]
; Change path here too
@="\"C:\\Program Files\\UDev\\AutoHotkey\\Compiler\\Ahk2Exe.exe\" /in \"%1\""

; DropHandler, allowing to drag'n'drop a file on a script
; It is the same handler as batfile... (.exe drop target)
[HKEY_CLASSES_ROOT\AutoHotkeyScript\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"

Thx 4 listening,
BoBo

[Drugwash]

Would you want different/separate extensions for ANSI and for Unicode versions of AHK 1.1, 2.0 or would a unique extension suffice for each version (as per your list above)?

[BoBo]

Would you want different/separate extensions for ANSI and for Unicode versions of AHK 1.1, 2.0 or would a unique extension suffice for each version (as per your list above)?

TBH, I'll take what I can get - and of course, if that's the best/easiest way to do it, perfect!
Thank U for listening.
Much appreciated

[Drugwash]

Theoretically it shouldn't be hard at all to register separate extensions based on ANSI/Unicode/Unicode64 (forgot about the x64 versions ), it would just make it harder to manage for the user. First of all there should be clearly different icons for each file type/extension, otherwise it would be impossible to distinguish in a file explorer which script belongs to which AHK version. I don't know if the file icons in AHK v2 and AHK_H differ in a visible way (if at all) from those in AHK Basic/1.1 so I might have to create/modify and provide a set of icons with the script, for the user to choose (or just accept the defaults).

There still are a few details to be taken care of and of course the actual registration/unregistration part which I have not yet coded. For now here's a preview. Don't thank me yet, wait for it to be finished and released.
Ideas are welcome, just don't make them too… fancy.

AHK file association (preview)

20170602004124.png (30.09 KiB) Viewed 5156 times

[BoBo]

Theoretically it shouldn't be hard at all to register separate extensions [...] First of all there should be clearly different icons for each file type/extension [...] so I might have to create/modify and provide a set of icons with the script, for the user to choose (or just accept the defaults)

Holy cow! I'm impressed

[jeeswg]

I've provided some information re. the AutoHotkey registry entries here:

list of every command/function/variable from across all versions - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 65#p151665

The information in your original link is from April 2006 and is a bit out-of-date.

[Drugwash]

Thank you, jeeswg. And I thought it would be easy… It's never easy (for me)!

Now, I know HKLM\Software\Classes is always duplicated in HKCR (or the other way around, nevermind). Question is, which of the two locations is better/proper for manipulating the AHK-specific keys? I was going for HKCR but I don't know about permissions on a non-admin Vista+ system so I'd need a hand here since I have no access to anything but 98SE and XP.

Then:
- Are all keys really necessary on all OS versions?
- Are all options (such as 'Run with UI access') really necessary and on which OS versions exactly?
- Are there any different or extra registry keys for AHK 2.0 and AHK_H 1/2 as compared to AHK 1.1?
- Are there any different or extra registry keys for an x64 installation?
Maybe I should consult installer.ahk (again) for some of the answers but still some help would be nice.

In the mean time, another question for both users and developers of various AHK flavors:
would you agree to having the icons of different AHK versions and flavors color coded by default?

Each major version (1.0, 1.1, 2.0, H1 and H2 at the time being) would sport a different primary color with slight shading variations for its executables and file types (scripts). This way scripts run as-is without their own icon would be quickly distinguished and also script files with different extensions associated to different AHK versions and flavors would be more easily spotted in a file manager.

That would be a challenge for the 16-color icon in icon_filetype.ico but that one is probably there for historical reasons (Win95/98/ME in Safe Mode or with no video driver would fall back to 16 colors display) so raising it to 256 colors or completely eliminating it should be enough.
Colored file type icons sample:

AHK file type icons.png (79.92 KiB) Viewed 5110 times

[wolf_II]

In the mean time, another question for both users and developers of various AHK flavors:
would you agree to having the icons of different AHK versions and flavors color coded by default?

My answer as a user of various AHK flavours to the question: I would love to have colour coding for the icons.

I wish you success for your work on this project. When you complete it, I will certainly be a regular user of it.

Finally, if I can be of any assistance, I will do so. But I guess my contribution might be limited to test on two systems: Win10 64-bit and a virtual WinXP 32-bit.

[Drugwash]

Thank you for your offer, I guess some testing on 10-64 might come in handy but that will happen after I gather enough information and sort it in the script. In the mean time I'd be interested in the registry keys created by the installer for a 64-bit installation of AHK 2.0, AHK H1 and AHK H2. That would assume complete uninstall of any and all previous AHK versions before installing a different one and also watching registry with the tool mentioned by jeeswg in his reply above.

I've been working on coloring the official icons for both file types and main executables. If everything works out the way I envision it anybody would be able to associate user-defined script extensions to different AHK versions and select their desired icons for script files and executables. There will be some limitations due to the nature of the registry but hopefully everything will work normally.

One small issue may be with paused scripts which by default sport a red icon in all AHK versions. It would be ideal if every AHK version and flavor got officially a unique color and their internal icons respected that color for all modes (that is only replacing the H with an S for paused/suspended scripts but keeping the same background color for the icon). But that would be asking too much, especially considering AHK 1.0 is no longer being developed. We may just have to accept a few limitations.

[wolf_II]

Prep: I usually have running scripts with AHK 1.0 and with AHK 1.1. I stopped all my running scripts.
(verified with "Process Explorer - Sysinternals: http://www.sysinternals.com")
I spotted an "InternalAHK.exe" from my SciTE, which I also stopped. The toolbar in SciTE disappears but SciTE continues to work.

1 - I used "AutoHotkey Setup" from my Startmenu\Programs\AutoHotkey
2 - This started a new process visible in Process Explorer (as expected)
3 - I selected "Uninstall" inside the "AutoHotkey Setup"
4 - I confirmed one message with "OK"
5 - I start "AutoHotkey_1.1.25.02_setup.exe" from my Download folder.
6 - I start 64bit version of RegFromApp.exe from NirSoft to monitor the setup.
error: can't monitor privileged process, I go back to start 64bit version of RegFromApp.exe as admin.
error: can't monitor 32bit process, which the setup.exe obviously is, but I did not know.
I start 32bit version of RegFromApp.exe from NirSoft as admin.
7 - I choose "Express installation" (Default: 64bit AHK Unicode, Install in: C:\Program Files\AutHotkey
8 - I close the setup.

I get nothing from RegFromApp but an empty window.

Next I try to use RegFromApp's menu, where I find "Start new process Ctrl+N"
I put a tick in "Start tracing immediately", start it and get this message:

Code: Select all

---------------------------
RegFromApp
---------------------------
Failed to start with the new selected process. Error code: 299

Only part of a ReadProcessMemory or WriteProcessMemory request was completed.


---------------------------
OK
---------------------------

I have to kill "AutoHotkey_1.1.25.02_setup.exe" with Process Explorer, it somehow got started but never became visible.
Next I try to use RegFromApp's "Start new process Ctrl+N" again but, I DON'T put a tick in "Start tracing immediately".

Same error message, but setup is visible. I repeat "Express installation", Result: nothing. Empty window.

My conclusion: I need to be instructed how to properly use RegFromApp or how to "properly" completely uninstall AHK.
Me thinks it is also possible that I get empty results because nothing needs to be written to the registry, since every entry is still there.

Sorry for negative results, I just report them as they happen over here.

[Drugwash]

Thank you for trying and sorry for all the trouble you had to go through. I'm not familiar with Nir Sofer's application either, was just hoping it'll work as it did for jeeswg. Maybe he could shed more light on the matter.

Theoretically the uninstall feature of the (recent, as in 1.1+) AHK installer should remove any and all traces of the registry entries it created. However if an older version was installed through an installer there may be leftovers, such as the ahk_auto_file class in HKCR and HKLM\Software\Classes as being created by the AHK 1.0 installer. That shouldn't interfere with tracing of a recent install though.

Well, I just hope you'll be able to recreate the original AHK environment, wouldn't want you to lose your settings and enhancements. It may be best to conduct such experiments in a virtual machine.

[wolf_II]

All good for me:

1- I offered my help in the first place, no worries please. My offer still stands. I will help you to finish this project if I can, which I might not be able to.
2- I just logged out of Windows and back in, and all my scripts were back and working, no worries there either.
3- regarding AHK 1.0 and my Win10 System: I never used the installer, I have manually copied the files for AHK 1.0.48.03 and AHK 1.0.48.05 from my Win7 after that machine died last year. Hard disk still worked. I have only "Portable Ac'tive Aid" running that uses it, and it even uses its own executable.

Your are right with experiments in a virtual machine, but I have zero fear for my settings and enhancements.
I wait and see if jeeswg can instruct me.

EDIT: the installer from AHK 1.1 is the best installer I have ever seen. It updates or just puts the missing files back, and restarts all my scripts. Updates were a blast every time.
It is an utter delight to use, very impressive stuff. Thank you Lexikos from here.

[Drugwash]

Ah, all's well then, I'm relieved. Hopefully there will come some help along.

[jeeswg]

The notes on my post said:
- installation of AutoHotkey 'U32' v1.1.25.02 on Windows 7 64-bit:
- installed via 'AutoHotkey_1.1.25.02_setup.exe', which is a 32-bit exe,
- [generated via NirSoft RegFromApp (32-bit), run in Admin mode, monitoring temporary file 'setup.exe' (32-bit)]

So what I did was:
- I uninstalled AutoHotkey via the Control Panel
- (I have 64-bit Windows 7)
- I started AutoHotkey_1.1.25.02_setup.exe (32-bit)
- which starts setup.exe (32-bit) in the Temp folder
- I ran RegFromApp (32-bit) in Admin mode
- I latched onto setup.exe
- and saved the .reg file at the end

You could also try Regshot.

[wolf_II]

Thank you jeeswg, I guess I should have read everything, but I just looked for the name of the tool that was mentioned earlier in this thread. My bad, sorry.

Result for Win10, AHK 64-bit for me:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\AutoHotkey]
"InstallDir"="C:\\Program Files\\AutoHotkey"
"Version"="1.1.25.02"
"StartMenuFolder"="AutoHotkey"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ahk]
@="AutoHotkeyScript"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ahk\ShellNew]
"FileName"="Template.ahk"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript]
@="AutoHotkey Script"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript\DefaultIcon]
@="C:\\Program Files\\AutoHotkey\\AutoHotkey.exe,1"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript\Shell\Open]
@="Run Script"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript\Shell\Edit]
@="Edit Script"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript\Shell\Compile]
@="Compile Script"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript\Shell]
@="Open"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript\Shell\Edit\Command]
@="notepad.exe %1"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript\Shell\Compile\Command]
@="\"C:\\Program Files\\AutoHotkey\\Compiler\\Ahk2Exe.exe\" /in \"%l\""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript\Shell\Open\Command]
@="\"C:\\Program Files\\AutoHotkey\\AutoHotkey.exe\" \"%1\" %*"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript\Shell\RunAs\Command]
@="\"C:\\Program Files\\AutoHotkey\\AutoHotkey.exe\" \"%1\" %*"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript\ShellEx\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AutoHotkey.exe]
@="C:\\Program Files\\AutoHotkey\\AutoHotkey.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Ahk2Exe.exe]
@="C:\\Program Files\\AutoHotkey\\Compiler\\Ahk2Exe.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\AutoHotkey]
"DisplayName"="AutoHotkey 1.1.25.02"
"UninstallString"="\"C:\\Program Files\\AutoHotkey\\AutoHotkey.exe\" \"C:\\Program Files\\AutoHotkey\\Installer.ahk\""
"DisplayIcon"="C:\\Program Files\\AutoHotkey\\AutoHotkey.exe"
"DisplayVersion"="1.1.25.02"
"URLInfoAbout"="https://autohotkey.com/"
"Publisher"="Lexikos"
"NoModify"="1"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Explorer]
"GlobalAssocChangedCounter"=dword:00000015

[qwerty12]

Now, I know HKLM\Software\Classes is always duplicated in HKCR (or the other way around, nevermind). Question is, which of the two locations is better/proper for manipulating the AHK-specific keys? I was going for HKCR but I don't know about permissions on a non-admin Vista+ system so I'd need a hand here since I have no access to anything but 98SE and XP.

I ain't Lexikos, but if you look at Installer.ahk, HKCR is exclusively used. (As I understand it, HKCR is a "virtual folder", an amalgamation of HKLM\Software\Classes and HKCU\Software\Classes. Modifications to the latter take priority and, of course, can be written to by a standard / non-elevated user. But of course the changes there aren't system-wide, although IMHO, changes there are more easily reverted.)

- Are all options (such as 'Run with UI access') really necessary and on which OS versions exactly?

I don't know about the rest of the options, but I don't think it's worth the time dealing with UI Access support; the AutoHotkey executable you switch to needs to be signed with the certificate the AutoHotkey installer creates during install. And the executable must be in Program Files ((x86)) or system32.

- Are there any different or extra registry keys for AHK 2.0 and AHK_H 1/2 as compared to AHK 1.1?

I've never used 2.0, but AHK_H doesn't appear to have an installer.
[/quote]

[jeeswg]

What is the difference between Admin mode/UAC (User Account Control) etc, and the significance of the UIA (UI Access) exes. If anyone wants to shed some light or post a few links.

Btw qwerty12 is SysTracer much good? Cf. RegFromApp and Regshot. I.e. there are free/paid versions, so can much be done with the free one.

Re. RegFromApp:
- Since Admin mode is needed to change the certain registry entries, I expected the exes to be in Admin mode, so RegFromApp would need Admin mode.
- I could check in Task Manager to see what bitness an exe was.
- So the question was whether the x32 and x64 versions would both work.

2 registry entries I missed out from my list, if anyone has any ideas:
This was changed in one install, although it may be irrelevant (i.e. changed by something else):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\########################################][characters replaced with hashes]
"Blob"
This was changed in both installs I recorded:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\explorer]
"GlobalAssocChangedCounter"

Cheers.

[EDIT:] It would be interesting to see the RegFromApp .reg file from an installation on a 32-bit machine, there would be no mention of 'Wow6432Node'.

[Drugwash]

@ wolf_II:
This time you nailed it. Looks like nothing different apart from GlobalAssocChangedCounter which doesn't seem to be of any importance at first sight but nevertheless should be kept in mind.
The entries in App Paths should probably be omitted because they can't be duplicated for each executable version/type.

@ qwerty12:
Changes to HKCU would take effect only for the current user, which may have both advantages and disadvantages depending on how the machine is used and by whom. So it may probably be better to run the script elevated and deal directly with HKCR the same way the installer does. Hopefully I'll manage to do that.

I was wondering about those extra _UIA executables mentioned in the registry. Since some AHK versions may just be unzipped or transferred without a proper installation such files would not exist so the registry entries would be useless at best. However the user may fully install one or more versions and then run this assignment script to modify settings, in which case such entries - if existing - should be dealt with accordingly. Otherwise they should be ignored.

AHK 2.0 doesn't have an installer either as of yet but at some point it may have. For now I'll focus on 1.0 and 1.1 registry entries.
Thank you so much for your help!

@ jeeswg:
No idea about UAC, ever since I heard about that crap I swore I'd never touch such system.
No idea about those applications either.
The root certificates key was probably created/modified by the installer when the UI Access option was enabled; as qwerty12 briefly explained above the installer creates self-signed executables with UI access on-the-fly and most likely stores related data in that blob.
Been wondering myself too about that GlobalAssocChangedCounter key. It may trigger a rescan of the file association classes or a refresh of Explorer, dunno. I may use it after applying (re)association, just to be on the safe side, if anyone doesn't strongly advise against it.

[EDIT] I just upgraded to 1.1.25.02 Unicode on XP (32bit) and there was no GlobalAssocChangedCounter key created. I assume it's only being created on a x64 system and it may not even be created by the installer itself.

[qwerty12]

What is the difference between Admin mode/UAC (User Account Control) etc, and the significance of the UIA (UI Access) exes. If anyone wants to shed some light or post a few links.

Funnily enough, at this point in time, if your account is an admin one and there's at least one elevated process running as you on the same desktop, UAC is useless (even at the highest "warn me everywhere" level): https://tyranidslair.blogspot.com/2017/ ... art-1.html

You should Google "UIPI". I don't want to post my understanding of the differences and why it's needed because it's most likely flawed and I'd rather not spread bad info and look like a knob...

Btw qwerty12 is SysTracer much good?

The output is far easier to look at, IMHO. If you've not installed it before and its trial is still valid then, give it a go. But Regshot is free (though I have no idea which fork of it is the best to use...)

Cf. RegFromApp and Regshot. I.e. there are free/paid versions, so can much be done with the free one.

- So the question was whether the x32 and x64 versions would both work.

RegFromApp is one of a kind: it doesn't rely on snapshots of the entire registry, but instead loads a DLL into the target process and hooks the registry functions there. And of course, don't forget procmon (which uses a driver instead, but can filter by process!)

This was changed in one install, although it may be irrelevant (i.e. changed by something else):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\########################################]
"Blob"

You might've had the uiAccess option enabled - the installer creates a certificate then.

I was wondering about those extra _UIA executables mentioned in the registry. Since some AHK versions may just be unzipped or transferred without a proper installation such files would not exist so the registry entries would be useless at best. However the user may fully install one or more versions and then run this assignment script to modify settings, in which case such entries - if existing - should be dealt with accordingly. Otherwise they should be ignored.

IMHO, you might consider adding an option to hide the UI Access entry if present, just to avoid confusion of someone starting the script with an executable that wasn't desired. As far as I can tell, when the UI Access option is enabled, Lexikos' installer creates a certificate on the fly, duplicates the AutoHotkey executables, signs then and modifies their manifests then and there. It's cool stuff and it's all there in Installer.ahk (related: https://github.com/Milly/AutoHotKey-scr ... Access.ahk), but whether you want to do the same depends on whether you consider it worth your time I guess... (And, again, the signed programs are useless unless they're in Program Files or system32)

Good luck with your script!

[Drugwash]

IMHO, you might consider adding an option to hide the UI Access entry if present, just to avoid confusion of someone starting the script with an executable that wasn't desired. As far as I can tell, when the UI Access option is enabled, Lexikos' installer creates a certificate on the fly, duplicates the AutoHotkey executables, signs then and modifies their manifests then and there. It's cool stuff and it's all there in Installer.ahk (related: https://github.com/Milly/AutoHotKey-scr ... Access.ahk), but whether you want to do the same depends on whether you consider it worth your time I guess... (And, again, the signed programs are useless unless they're in Program Files or system32)

Good luck with your script!

Yeah, the presence of UIA-enabled executables may well lead to confusion. I'll have to look into that a bit deeper. Everything looked easy at first: just associate a few user-defined extensions with different executables. Apparently it's more than that. But still, I don't intend to build a wonder-tool - just something to make dealing with multi-AHK a wee easier.

Thanks for all the help so far and for the good wishes. I'll wrap it up earlier for today, just went to sleep at 5AM this morning after working on this script all night.