Open eugenesvk opened 6 months ago
I am not shure this is a good Idea, I like AltSnap not to interact with anything elevated, with this flag, assuming iI can make it work it would mean that as soon as a user install in Program files it would be forced on, which I do not like.
So this would force to have an extra version. Plus I am not really willing to invest time and mony in purchasing a signing certificate.
Maybe someone else can do it, but I am not sure of the value. Yes it would reduce surface-area for when you do wand to move elevated windows but it would increase the odds of for people on which the behavior would be forced.
If there was a way to decide at runtime this UIAcess without forcing it into the .manifest then would make it optional, but the whole process as it is, is not appealing to me.
I am not sure I fully understand what you sait though, You mean AHK can apply the flag to another progra and it works? If so I could just add the procedure to a txt file for the interested users to apply.
It won't be forced, that depends entirely on your installation options. For example, AutoHotkey can be installed/launched in either variants and you can change it by launching it's installer and changing a tick mark in options. So it's strictly a benefit over the current situation where if you want to interact you have to elevate
If there was a way to decide at runtime
there is, just like currently you're relaunching your app elevated you'd relaunch the UIA-enabled variant of the app
You mean AHK can apply the flag to another progra and it works? If so I could just add the procedure to a txt file for the interested users to apply.
Yes, but only if the app already has a manifest added. The script signs the binary with a self-signed certificate, and toggles the UIA flag in the manifest
The instructions for another app are here and the example manifest that needs to be embedded is here
The only thing this is missing is the dynamic part of easily changing the variant from a context menu, that would need support from your app/installer to have a menu "relaunch AltSnap with UIA" and "relaunch AltSnap without UIA"
there isalready manifest file in altsnap.exe for the usual stuff so it should work after ahk script.
Unfortunately it doesn't since it has some formatting difference, the app doesn't launch after being edited by the script, I guess since AHK script is meant to sign AHK it wasn't made to generally work with any manifest
Think you could either update the manifest to whatever format that script expects or disable the manifest changing part of the script, distribute two binaries with two manifests (with UIAccess flag dis/enabled) and then use the script to just generate self-signed certificates/sing the UIA binary using that certificate
Or maybe there is an better solution, I just only know this one
When reading the ahk script it seems it is expecting the property to be present (but disabled) https://github.com/Milly/AutoHotKey-scripts/blob/master/EnableUIAccess/EnableUIAccess.ahk
So here is a version of AltSnap.exe (x64) with this modified manifest file with the UIAccess=false
, try the ahk script, (I dont have AHK2 installed actually).
In this binary I can't even parse the the manifest with the win tool, get
MT.EXE : general error c101008c: Failed to read the manifest from the resource of file "D:\Downloads\AltSnap1.63test4_x64\AltSnap.exe". Windows was unable to parse the requested XML data.
AHK also fails, though I'm using the script I linked above since don't have AHK1 that's needed for the ancient version you linked
What about this one? AltSnap.zip
this seems to work
Ok, I will see later what to do, for now AltSnap needs to be modified in order to work in the Program Files directory #539.
Here is the latest test version of altsnap that supports being installed for multiple users.
If no .ini
file is present in its directory it will look for %APPDATA%\AltSnap\AltSnap.ini
If there is no ini file it ill try to copy a default ini named "
So for the portable mode you just put the AltSnap.ini
next to AltSnap.exe
for multi-user mode you must rename the .ini file to .dni
and you are set. Each user will be able to have its own congif.
There is a simpler way to manage other admin windows without becoming an admin app yourself (and doing admin task scheduler stuff), thus reducing the risk associated with admin
AutoHotkey does it to allow rebinding hotkeys in admin windows:
uiaccess
flag (disabled)uiaccess
flag onThen AltSnap will be able to run without being admin, yet control other apps even admin
You could add it as part of the installation as AHK does it or just make the users do it manually
You could also sign your binary yourself to avoid this trouble, but then as far as I know there are no free certificates to allow open source devs do that