Command line switch to execute different script than compiled one

Propose new features and changes
newbieforever
Posts: 444
Joined: 24 Aug 2016, 03:34

Command line switch to execute different script than compiled one

30 Apr 2020, 02:13

.
Passing Command Line Parameters to a Script

[v1.1.33+]: The switch /e can be used to specify a script which should be executed instead of the embedded one.

Could this not be implemented with minimal effort?
(No comparison for example with the introduction of asterisk:
[v1.1.17+]: Specify an asterisk (*) for the filename to read the script text from standard input (stdin).)


Wouldn't that be an enormous improvement of the usage possibilities (for a part of the users)?

ED: A fun without risk & cost! (?) :dance:

newbieforever wrote:
28 Apr 2020, 03:22
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?

newbieforever wrote:
28 Apr 2020, 05:50
HotKeyIt wrote:
28 Apr 2020, 05:04
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 wrote:
28 Apr 2020, 09:24
1. That is what I thought
2. Get rid of bin files to avoid confusion
3. It was not difficult to implement
lexikos
Posts: 7085
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Command line switch to execute different script than compiled one

03 May 2020, 22:21

It will probably happen at some point, but I disagree about it being an "enormous improvement" because:
  1. There is nothing you could do with this that you can't already do by using AutoHotkey.exe.
  2. You can already use AutoHotkey_H in this manner, but with greater flexibility (due to the addScript function).
Compared to using AutoHotkey.exe (or renaming it, e.g. so YourScript.exe runs YourScript.ahk automatically), adding a switch to compiled scripts only offers the dubious benefits that compiling has in general (neater, smaller package; hiding but not truly protecting your source code).

Presumably the user (who may not be the author of the compiled script) is going to be writing the code, and in that case, they're probably better off having the full AutoHotkey package (installed or not). The user cannot benefit from updates to AutoHotkey if they're locked into whatever version you've compiled the script with. If you don't provide both 32-bit and 64-bit versions of your compiled script, the user either cannot benefit from native 64-bit performance or cannot use your script on a 32-bit system. (Although technically the user could "decompile" your script...)

I considered doing this for v2:
  • AutoHotkey.exe may execute an internal or external script; but may also be customized by embedding libraries or header code, which may be combined with an external script.
  • A v2 installation would never include AutoHotkeySC.bin, as the compiler and all related tools would be designed to use the main exe files.
  • There is no chance of conflict with user-defined command line switches since the usage would be defined at day 1 (of the stable release).
newbieforever
Posts: 444
Joined: 24 Aug 2016, 03:34

Re: Command line switch to execute different script than compiled one

04 May 2020, 09:09

@lexikos, thanks for your answer!

I am not an AHK expert, but:

Could it be that you are "logically" unfair to this proposal? ;) You practically only make arguments against compiling scripts, which should not be the question here. Do "standalone" and "single cabinet" in the area of AHK not have a raison d'être for you? To me, this sounds like if someone wrote a wonderful and elegant new compilation program, but you would deny it any value because you personally don't want to compile. For a part of the AHK community there are good reasons to work with compiled scripts. Shouldn't you acknowledge this and then judge the proposal at that level?

Another point: Isn't the question of "dynamic" an important thing with regard to application possibilities of AHK? Wouldn't the /e option be highly relevant to this question (at the level of compiled scripts)?

What would be wrong or inappropriate about it, if an AHK user had the wish to offer a product of him as a convenient and slim standalone program in the web, e.g. a hotkey tool based on something like this (the rudimentary demo allows to define new hotkeys that can be used ad hoc):
EDITED!

Code: Select all

; DynHK.ahk
; !!! NOTE !!!
; For demo purposes this script must be compiled with AutoHotkey.exe, not AutoHotkey.bin.
; As long as there is no /e option for compiled scripts, this is the only simple way 
; to use a compiled script as an interpreter for external scripts.
; (However, the ability to send CL parameters to the embedded script is lost.)

AHKint  := A_ScriptDir . "\AHKint.exe"
Interpr := A_AhkPath
If A_IsCompiled
   Interpr := SubStr(A_ScriptFullPath, 1, -3) . "exe"

DHKfile := A_ScriptDir . "\DHKfile.ini"

FileCopy, %Interpr%, %AHKint%

Gui DHK: Add, Text, , A new hotkey for text modules:
Gui DHK: Add, Edit, w300 vvHoK
Gui DHK: Add, Text, , Text module to be inserted by the hotkey:
Gui DHK: Add, Edit, w300 vvAct
Gui DHK: Add, Button, vvBut ggBut, OK
Gui DHK: Show, Hide w350, A new hotkey...

RETURN

^9::
  Gui DHK: Show
  RETURN
  
gBut:
  Gui DHK: Submit
  If (vHoK && vAct) {
	Process, Close, %PID%
    FileAppend, `r`n%vHoK%::`r`nSend %vAct%`r`nReturn`r`n, %DHKfile%
    Run, %AHKint% %DHKfile%, , , PID			; Run, %AHKint% /e %DHKfile%, , , PID
    }
  Return

^8::
  ExitApp
  Return
One more point: Wouldn't the /e option also enable a new programming style, possibly with performance improvements in some standalone applications?

A simple demo example: 2 x 10**7 calculations should be performed as quickly as possible. On my computer here the calculation time with the conventional method is about 30 seconds, with the "smart" method, which uses an auxiliary script generated and executed by the compiled script, the calculation time is reduced to about 8 seconds.
:bravo:

Code: Select all

; Calc.ahk
; !!! NOTE !!!
; For demo purposes this script must be compiled with AutoHotkey.exe, not AutoHotkey.bin.
; As long as there is no /e option for compiled scripts, this is the only simple way 
; to use a compiled script as an interpreter for external scripts.
; (However, the ability to send CL parameters to the embedded script is lost.)

AHKint  := A_ScriptDir . "\AHKint.exe"
Interpr := A_AhkPath
If A_IsCompiled
   Interpr := SubStr(A_ScriptFullPath, 1, -3) . "exe"
FileCopy, %Interpr%, %AHKint%

AuxScr := A_ScriptDir . "\AuxScr.ahk"

IniF := A_ScriptDir . "\Calc.ini"
FileDelete, %IniF%
FileAppend, , %IniF%

IniWrite, 0, %IniF%, Tim, TimSim
IniWrite, 0, %IniF%, Tim, TimMas
IniWrite, 0, %IniF%, Tim, TimAux
IniWrite, 0, %IniF%, Sum, SumSim
IniWrite, 0, %IniF%, Sum, SumMas
IniWrite, 0, %IniF%, Sum, SumAux

; SIMPLE METHOD

SoundBeep
T := A_TickCount

S := 0
Loop, % 10**7 
  S := S + A_Index

S := 0
Loop, % 10**7
  S := S + A_Index

T := A_TickCount - T
IniWrite, %T%, %IniF%, Tim, TimSim
IniWrite, %S%, %IniF%, Sum, SumSim
Tsim := T , Ssim := S
SoundBeep

; SMART METHOD (using an auxiliary script)

SoundBeep
T := A_TickCount

; Creating and running the aux script

AuxStr =                    ; % must be escaped!
(
SoundBeep
T := A_TickCount
IniF := A_ScriptDir . "\Calc.ini"

S := 0
Loop, `% 10**7
  S := S + A_Index

T := A_TickCount - T
IniWrite, `%T`%, `%IniF`%, Tim, TimAux
IniWrite, `%S`%, `%IniF`%, Sum, SumAux
SoundBeep
)

FileAppend, %AuxStr%, %AuxScr%

Run, %Interpr% %AuxScr%

; Running master part

S := 0
Loop, % 10**7 
  S := S + A_Index

T := A_TickCount - T
IniWrite, %T%, %IniF%, Tim, TimMas
IniWrite, %S%, %IniF%, Sum, SumMas
Tmas := T , Smas := S
SoundBeep

; COMPARING

Loop {
  IniRead, Taux, %IniF%, Tim, TimAux
  IniRead, Saux, %IniF%, Sum, SumAux
  If (Taux && Saux)
    Break
  }

Tsma := Tmas
If (Tmas < Taux)
  Tsma := Taux

MsgBox Simple method: %Tsim% ms`r`nSmart method:  %Tsma% ms`r`nSums:`r`n%Ssim%`r`n%Smas%`r`n%Saux%
CalcTime.jpg
CalcTime.jpg (18.02 KiB) Viewed 1652 times


Could you at least confirm that the /e switch would be very easy to implement?


Of course I know that formally the same functionality can be achieved by including the AutoHotkey.exe in a compiled script. But of course at the cost of doubling the size of the executable. A doubling that is pointless, since the compiled script in principle already contains the interpreter...
Last edited by newbieforever on 04 May 2020, 16:03, edited 3 times in total.
User avatar
nnnik
Posts: 4470
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Command line switch to execute different script than compiled one

04 May 2020, 10:19

Defining ad hoc Hotkeys and highly dynamic code are already a thing without /e.
/e could be used in peoples script and would break them on addition (mentioned by lexikos implicitly).
v2 might be a better point to add something like /e.
There are downsides to compiling and those downsides apply to /e as well.
Recommends AHK Studio
newbieforever
Posts: 444
Joined: 24 Aug 2016, 03:34

Re: Command line switch to execute different script than compiled one

04 May 2020, 10:36

Thanks, nnnik!
nnnik wrote:
04 May 2020, 10:19
Defining ad hoc Hotkeys and highly dynamic code are already a thing without /e.
/e could be used in peoples script and would break them on addition (mentioned by lexikos implicitly).
Could you briefly explain what you mean by that?
nnnik wrote:
04 May 2020, 10:19
There are downsides to compiling and those downsides apply to /e as well.
Not this again, please! :sick:

"I have invented a better method for hip operations."
"This is not good, hospital stays and operations can be dangerous!" :headwall:
User avatar
nnnik
Posts: 4470
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Command line switch to execute different script than compiled one

04 May 2020, 12:22

You don't need to write a new code when you can just the Hotkey command with new parameters to create new Hotkeys.
You can use arrays with functions to create custom executed code. In combination with bind you can create fairly powerful effects.
Lastly there is the option to make your own compiler for a language - e. G. You could make a compiler for some other language in AHK to execute dynamic code.
Of coirse it seems easier for new people to just write AutoHotkey scripts however there are some strict limitations for communication.


If someone made a script that relies on a launch parameter /e it would break when we add a special parameter named /e.

So generally speaking its a nice-to-have that is easier to add to v2 than v1 thus it won't get added to v1.
Recommends AHK Studio
newbieforever
Posts: 444
Joined: 24 Aug 2016, 03:34

Re: Command line switch to execute different script than compiled one

04 May 2020, 14:26

nnnik wrote:
04 May 2020, 12:22
You don't need to write a new code when you can just the Hotkey command with new parameters to create new Hotkeys.
Are you saying that with the currently available resources of AHK you can write a script that would only be 400 kB in size when compiled (and compressed) and would do exactly what my demo script DynHK.ahk does? Can you write this in a hurry or maybe give me a link to the right place?
:bravo:
nnnik wrote:
04 May 2020, 12:22
If someone made a script that relies on a launch parameter /e it would break when we add a special parameter named /e.
??? :wtf:
If someone made a script that relies on the switch /f it would break when we add a special parameter named /f.
If someone made a script that relies on the switch /r it would break when we add a special parameter named /r.
User avatar
Delta Pythagorean
Posts: 567
Joined: 13 Feb 2017, 13:44
GitHub: DelPyth
Location: Somewhere in the US

Re: Command line switch to execute different script than compiled one

05 May 2020, 02:18

Is there a problem with using the ExecScript function that's in the documentation for AHK_L? Besides requiring the AutoHotkey executable somewhere on the PC to execute it, it works just fine. It just can't communicate with the main script it was run from as easily as you would probably want it to be.
It still does execute the code as if it was run from a file, but it does not require to write to the disk directly.
There is also a way to run via a pipe but I haven't seen a difference in performance.

Code: Select all

; Run AHK as if it was done through the file system.
ExecScript(Script) {
	Static Shell := ComObjCreate("WScript.Shell")
	Exec := Shell.Exec("""" A_AhkPath """ /ErrorStdOut *")
	Exec.StdIn.Write(Script)
	Exec.StdIn.Close()
	Return, (Exec.StdOut.ReadAll())
}

; Run AHK through a pipe.
DynaRun(TempScript, AhkPath := "", PipeName := "") {
	Static PIPE_ACCESS_OUTBOUND		:= 0x2
	Static PIPE_UNLIMITED_INSTANCES	:= 255
	Static Params := [
	(LTrim Join
		"UInt",	PIPE_ACCESS_OUTBOUND,
		"UInt",	0,
		"UInt",	PIPE_UNLIMITED_INSTANCES,
		"UInt",	0,
		"UInt",	0,
		"Ptr",	0,
		"Ptr",	0,
		"Ptr"
	)]
		, BOM := Chr(0xFEFF)

	AhkPath := ((AhkPath == Null) ? (A_AhkPath) : (AhkPath))
	PipeName := ((PipeName == Null) ? ("AHK_" . A_TickCount) : (PipeName))

	Loop, % (1) {
		For K, V in ["PipeGA", "Pipe"] {
			%V% := DllCall("CreateNamedPipe", "Str", "\\.\pipe\" . PipeName, Params*)
		}
		If ((Pipe = -1 || PipeGA = -1) && (Error := "Can't create pipe """ . pipeName . """`nLastError: " . A_LastError)) {
			Break
		}
		Run, % AhkPath . " ""\\.\pipe\" . pipeName . """",, UseErrorLevel HIDE, PID
		If ((ErrorLevel) && (Error := "Can't open file:`n ""\\.\pipe\" . pipeName . """")) {
			Break
		}
		For K, V in ["PipeGA", "Pipe"] {
			DllCall("ConnectNamedPipe", "Ptr", %V%, "Ptr", 0)
		}
		TempScript := BOM . tempScript
		TempScriptSize := (StrLen(tempScript) + 1) << !!A_IsUnicode
		If (!DllCall("WriteFile", "Ptr", Pipe, "Str", TempScript, "UInt", TempScriptSize, "UIntP", 0, "Ptr", 0)) {
			Error := "WriteFile failed, LastError: " . A_LastError
		}
	}
	For K, V in ["PipeGA", "Pipe"]
		((%v% != -1) && (DllCall("CloseHandle", "Ptr", %V%)))
	If (Error != Null) {
		Throw Exception(Error, -1)
	}
	Return, (PID)
}
Both work in the same way but as far as I've read in other threads, running through a pipe allows for Unicode characters while WScript.Shell doesn't. I could be wrong.

- [AHK].......: 1.1.33.02 Unicode 64-bit
- [OS].........: Windows 10.0.18362
- [GITHUB]...: github.com/DeltaPyth
- [PAYPAL]....: paypal.me/DelPyth
- [DISCORD]..: Delta#3324

Remember to use [code]CODE[/code] for your multi-line scripts.
Stay safe, stay inside, and remember to wash your hands for 20 seconds!
newbieforever
Posts: 444
Joined: 24 Aug 2016, 03:34

Re: Command line switch to execute different script than compiled one

05 May 2020, 02:28

Delta Pythagorean wrote:
05 May 2020, 02:18
Is there a problem with using the ExecScript function that's in the documentation for AHK_L? Besides requiring the AutoHotkey executable somewhere on the PC to execute it, ...
Again, you ignore the fact that this point (a new switch /e or /scr) is only about extending the capabilities of compiled scripts (in a standalone setting where no AHK executable is available anywhere on the PC).
User avatar
nnnik
Posts: 4470
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Command line switch to execute different script than compiled one

05 May 2020, 05:53

Having a small file size is not an argument.
Data of several MB are neglecteable considering modern day standards.
Recommends AHK Studio
User avatar
Delta Pythagorean
Posts: 567
Joined: 13 Feb 2017, 13:44
GitHub: DelPyth
Location: Somewhere in the US

Re: Command line switch to execute different script than compiled one

05 May 2020, 09:26

newbieforever wrote:
05 May 2020, 02:28
... extending the capabilities of compiled scripts ...
If you're wanting to extend the capabilities of a compiled script by executing AHK code using AHK itself, why not creating your own programming language yourself? I've been trying and working on doing it for the past few months since I have nothing to do. It's not impossible, but since no one (that I know of) has created a reliable way of creating a new "scriptlet" using AHK, it might be a little difficult to find a way to do it.
newbieforever wrote:
05 May 2020, 02:28
... no AHK executable is available anywhere on the PC)
Is there a problem with that? You can use the FileInstall command to install a file into a compiled script. So when the compiled script is ran, it can write the installed file onto the disk when needed. I use this for installing important and otherwise missing DLLs or images that are too cumbersome to push into the script as a Base64 to HBITMAP styled function.
If you want the up-to-date version of AHK, you can download the executable needed using UrlDownloadToFile.


I can see what you're wanting, and I completely understand. I've been wanting something like this for a while but I know that it'd be mostly useless to do so in the long run.
Besides, there are plenty of ways around this idea.
Sorry to burst your bubble, but I don't see this as a 100% useful feature to implement from my point of view on the matter.

- [AHK].......: 1.1.33.02 Unicode 64-bit
- [OS].........: Windows 10.0.18362
- [GITHUB]...: github.com/DeltaPyth
- [PAYPAL]....: paypal.me/DelPyth
- [DISCORD]..: Delta#3324

Remember to use [code]CODE[/code] for your multi-line scripts.
Stay safe, stay inside, and remember to wash your hands for 20 seconds!
lexikos
Posts: 7085
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Command line switch to execute different script than compiled one

22 May 2020, 19:44

newbieforever wrote:
04 May 2020, 09:09
Do "standalone" and "single cabinet" in the area of AHK not have a raison d'être for you?
What impression did the words "dubious benefits" leave with you? ;)

In the specific context of a script designed to run other scripts, why would you need to have the interpreter and script in a single file? Will you also somehow integrate documentation and sample scripts into this one exe? What about the other scripts that it's going to run?

I can think of two general use cases:
  • Run scripts defined by the user (not necessarily the author) of your compiled script.
  • Run scripts retrieved dynamically from some source (example: some kind of copy protection or licensing system).
In the first case, I would prefer that the user had AutoHotkey, and to a lesser degree, the source code of the main script. If they are capable of writing scripts to be used by the main script, they are capable of modifying or learning from the main script. Depending on how the user-defined scripts relate to the main script, having the main script as a reference may be important. The GPL permits you to redistribute AutoHotkey (and you're already doing that when you distribute a compiled script); of course, you can utilize AutoHotkey without necessarily including it in your download.

In the second case, I can only see this really being needed (as a compiled script) by authors who are trying to hide their source code. I'm not outright opposed to that, but I'm happy to let them put in a little more effort and find or build their own solution.

Most compiled scripts don't need /E, and scripts that run other scripts don't necessarily need to be compiled. This would be at best a "niche" feature, not an "enormous improvement".
newbieforever wrote:
04 May 2020, 14:26
If someone made a script that relies on the switch /f it would break when we add a special parameter named /f.
The difference between /F and /E is that /F already exists. We aren't breaking the user's compiled script by changing the base program they use to compile it; the user is breaking their own script by compiling it. If the script is designed to be compiled, it won't use /F or /R because those are already reserved by AutoHotkey.


It may be "simple", but it's not just a case of programming "if /E x, then run x instead of the embedded script". C pre-processing directives are used to load the script from an embedded resource instead of a file, and strip out much of the load-time error checking and the implementation of #Include. Although it doesn't save much space for a single file after compression, it can add up for a large library of compiled scripts or after thousands of downloads.

Anyway, I'm almost certain AutoHotkey_H already has this capability; you can compile using the exe instead of a bin.
newbieforever
Posts: 444
Joined: 24 Aug 2016, 03:34

Re: Command line switch to execute different script than compiled one

31 May 2020, 06:04

Dear lexikos, thank you for your detailed answer. I must confess that I do not understand your basic rejection, but I appreciate that you have taken so much trouble with my request.

But, of course, I have now realized that I am completely and finally in a lost cause.

PS: I wanted to make the topic related to my request more interesting by means of a funny speed competition:
https://www.autohotkey.com/boards/viewtopic.php?f=17&t=75586
Unfortunately, that also proved to be the end in emptiness...
lexikos
Posts: 7085
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Command line switch to execute different script than compiled one

31 May 2020, 23:21

My "basic rejection" of what? Your opinion about the worth of the feature? I said at the beginning
lexikos wrote:
03 May 2020, 22:21
It will probably happen at some point, but I disagree about it being an "enormous improvement"
"It will probably happen" does not mean "I won't do it".
newbieforever
Posts: 444
Joined: 24 Aug 2016, 03:34

Re: Command line switch to execute different script than compiled one

01 Jun 2020, 03:32

lexikos wrote:
31 May 2020, 23:21
... but I disagree about it being an "enormous improvement"
... Your opinion about the worth of the feature?
I am not expert enough to present the advantages as conclusively, briefly and concisely as you can with the counterarguments. I try to express myself precisely, but unfortunately that somehow doesn't come across.

For example: I did talk about "enormous improvements", but with the addition "for a part of the users"; if you leave out this addition, "enormous improvements" are of course nonsense.

Or: I wrote: "Wouldn't the /e option also enable a new programming style, possibly with performance improvements in some standalone applications?" And I tried, with my modest knowledge, to demonstrate this with a few examples, but obviously only convincing for me. For me it speaks for the "worth of the feature", if the feature would allow a reduction of the processing time to e.g. 1/3 or 1/10 (Prime.ahk).

A similar reference to the "worth of the feature" of mine was: "Isn't the question of 'dynamic' an important thing with regard to application possibilities of AHK? Wouldn't the /e option be highly relevant to this question (at the level of compiled scripts)?" But as I am not very familiar with these things, I could not demonstrate this point sufficiently.

I also wanted to bring in the aspect of "elegance" (or "aesthetics", "economy"?) as an argument for the "worth of the feature": "Of course I know that formally the same functionality can be achieved by including the AutoHotkey.exe in a compiled script. But of course at the cost of doubling the size of the executable. A doubling that is pointless, since the compiled script in principle already contains the interpreter..." However, I obviously could not argue this aspect convincingly either.

But of course I know that my approach to this whole subject is very special. The fact that you, dear lexikos, now emphasize at the end, "it will probably happen at some point", gives me hope again!

Thank you very much for the enormous work you are doing!!!

Return to “Wish List”

Who is online

Users browsing this forum: No registered users and 1 guest