AHK Connection to WinBatch

[JFord]

One of the reasons that it took me so long to find AHK (I started working with it in 2015) was that since the early Windows 3.1 days I had been using a tool called WinBatch (from Wilson Windoware at the time) which performed many of the desktop automation tasks I normally needed. The upside of this story is that it was easy for me to learn AHK because the legacy syntax of AHK was so similar to WinBatch, including %Variables% and pseudo arrays, that I was certain that the development efforts were somehow related. However, a Google search does not return many pages where AHK and WinBatch are both mentioned.

Can anyone shed any light as to the ancestor of the somewhat unique syntax used by AHK?

[wolf_II]

from AutoIt3 Help:

AutoIt and Developer History
This section is for those interested in how the AutoIt project began, and how the various developers got involved. Devs should add their own thoughts when they get time

Jon
October 1998

I was working on a project to create an automated Windows NT 4 build for a company in the UK. It became clear that around half the applications required featured no way to silently install them. Searched around for a while for some way to force button presses and came across Microsoft ScriptIt which was a compiled WinBatch script designed for clicking buttons in automated builds.

ScriptIt worked OK but it was extremely unreliable. It was notoriously fussy about the speed of the machine it was used on and had no way to control the key delays between keystrokes. Another feature that caused problems was that there was no way to specify a working directory when running a program which caused loads of problems with many of the applications I was scripting. Also, some of the functions didn't work under NT 5 beta (i.e. Windows 2000).



Xmas 1998

To escape the torment that was Xmas I decided to have a go at a C program that would send keystrokes hoping that I could then control the delay.



January 1999

AutoIt version 1 released on the old winfiles.com site. Syntax was similar to ScriptIt (for Send) and featured the functions Send, Run, RunWait, WinWait, WinWaitClose, WinWaitActive, WinHide, WinActivate, WinClose, WinRestore, Sleep and SetKeyDelay. From the v1.0 helpfile:

Advantages
- It's much smaller at 40Kb (600Kb smaller than ScriptIt).
- It will be updated if problems are found.
- The "Reveal" function is much better.
- Non-active as well as active windows can be waited for.
- Variable delays are possible (defined in milliseconds).
- The time in between keystrokes can be altered.
- When running an application, a working directory can be specified.
- Will force Windows to be active under Win98/NT 5.0 (Use "WinActivate")

Disadvantages
- The "[ADLIB]" section is not implemented
- The script file must be formatted correctly (no white spaces allowed on lines
containing a command).
- None of the Wilson WinBatch commands are featured.
(But who used them anyway? )
- Due to the command names I've used, the scripts tend to be a little larger.

from AutoHotkey-Help:

Acknowledgements

A special thanks to Jonathan Bennett, whose generosity in releasing AutoIt v2 as free software in 1999 served as an inspiration and time-saver for myself and many others worldwide. In addition, many of AutoHotkey's enhancements to the AutoIt v2 command set, as well as the Window Spy and the old script compiler, were adapted directly from the AutoIt v3 source code. So thanks to Jon and the other AutoIt authors for those as well.

Finally, AutoHotkey would not be what it is today without these other individuals.

~ Chris Mallett

[jeeswg]

AutoHotkey is a fork of AutoIt. Cheers.

AutoIt and Developer History
https://www.autoitscript.com/autoit3/docs/intro/dev_history.htm

Searched around for a while for some way to force button presses and came across Microsoft ScriptIt which was a compiled WinBatch script designed for clicking buttons in automated builds.

History - AutoIt Wiki
https://www.autoitscript.com/wiki/History

[SOTE]

One of the reasons that it took me so long to find AHK (I started working with it in 2015) was that since the early Windows 3.1 days I had been using a tool called WinBatch (from Wilson Windoware at the time) which performed many of the desktop automation tasks I normally needed.

Can anyone shed any light as to the ancestor of the somewhat unique syntax used by AHK?

Edit- It appears WinBatch was first. ScriptIt was a free tool that once was promoted by Microsoft for Windows installation, which was a compiled Winbatch exe.
https://www.itprotoday.com/devops-and-software-development/scriptit

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/Miscellaneous+Scriptit~is~a~Compiled~Winbatch~EXE.txt

Wilson WindowWare was founded in 1989 with the product Command Post.
In 1991, the menuing language in Command Post became WinBatch.
Shortly after that, a corporate version was released which included a code binder (a program that combines a bytecode version of a program along with an interpreter).

WinBatch -> ScriptIt -> AutoIt -> AutoHotkey

You can see the similarities in the old versions of WinBatch, AutoIt, and ScriptIt. In fact, AutoIt might have been named in honor of ScriptIt, though I don't have confirmation on that. However, the way AutoIt is named, it does appear to be making that connection. From the ScriptIt commands, you can see where AutoIt commands came from or were inspired by. The original ScripIt was a free automation tool for Microsoft Windows, though maybe that backfired on WinBatch, as AutoIt was inspired by it. Seeing how AutoIt originated, it makes you wonder why certain people from that group get so "triggered" by AutoHotkey, as the hypocrisy is quite obvious.

ScriptIt Commands, link- https://docs.microsoft.com/en-us/previous-versions//cc723493(v=technet.10)

Code: Select all

~exit
Exits the script immediately. For example:
Untitled – Notepad=~exit
Tells your script to exit when it sees the Untitled – Notepad window.

~wait
Causes a five-second delay in the execution of the script (this is the same as using ##). For example: Network=~wait
Causes ScriptIt to pause for five seconds when the Control Panel's Network window appears. The line Network=## has the same result.

~winwaitclose
Causes the script to pause until the window is closed. For example:
Setup=~winwaitclose
Causes the script to pause until the Setup window closes. This is very useful when setup programs have multiple windows open. ScriptIt will want to continue when it sees a window title that it needs to send keystrokes to; however, a previous step may not have finished. Using ~winwaitclose allows you to pause your script until the previous step completes.

~winclose
Causes ScriptIt to close the window and terminate the executable that created it. For example:
Untitled – Notepad=~winclose
causes ScriptIt to shut down the Notepad instance that created that window.

~winhide
Causes ScriptIt to make the specified window invisible. For example:
Untitled – Notepad=~winhide
causes ScriptIt to hide the window titled Untitled – Notepad. The window is still there, but the user cannot see it.

~winshow
Causes ScriptIt to show the specified window if it is currently hidden. For example:
Untitled – Notepad=~winshow
causes ScriptIt to make the hidden Untitled – Notepad window visible again.

~winmin
Causes ScriptIt to display the specified window as an icon. For example:
Untitled – Notepad=~winmin
causes ScriptIt to minimize the specified Notepad window.

~winmax
Causes ScriptIt to display the specified window as a full-screen window. For example:
Untitled – Notepad=~winmax
causes ScriptIt to maximize the specified Notepad window.

When I was first exposed to an automation tool, it was WinBatch. Some friends in IT were using it. But back then Wilson WindowWare were charging something crazy for their full version to make executables. I eventually came upon AutoHotkey, and thought it good enough for my purposes because it was open source, did automation, and could make executables too. The new owners of WinBatch are charging more reasonable prices, but AutoIt and AutoHotkey are so advanced now, the incentive to play with WinBatch might not be there unless someone is overly concerned about software license issues. Wilson WindowWare/WinBatch, makes it explicitly clear that you can sell programs made with their compiler. Also, if someone had a lot of old scripts in WinBatch, they might want to keep using it. But, even then, the jump to AutoHotkey is probably not that big to make.

It appears that the WinBatch community is much smaller and less active than that of AutoHotkey or AutoIt, despite it being much older. Though that can be a plus or minus. Some might prefer support to come directly from the company, as opposed to fellow users. While others might prefer to see what other users are doing with the scripting language, versus being more closed off and isolated.

The upside of this story is that it was easy for me to learn AHK because the legacy syntax of AHK was so similar to WinBatch, including %Variables% and pseudo arrays, that I was certain that the development efforts were somehow related.

I find that the syntax of WinBatch is something in between that of AutoIt and AutoHotkey. Definitely, an intermediate to advanced script writer from either AutoHotkey or AutoIt would be able to easily understand it.

AutoIt clearly has "kept pace with WinBatch", because there are many other superficial similarities, and based on various comments in the AutoIt forums. Such as AutoIt using the same name for UDFs (User Defined Functions), which serve the same purpose. In AutoHotkey, such types of files use the same .ahk extension and their functions are utilized using #Include (which can refer to a library in a folder or a file). Early on, if WinBatch did something useful, it seemed someone wanted or put it into AutoIt. Though that's not to say that AutoIt or AutoHotkey did not have different ideas, or do innovative and different things. Probably there were occasions when WinBatch developers were forced to copy or provide similar functionality to what AutoIt or AutoHotkey came up with, in order to keep up.

Looking at the help documents, in many cases you can do the same things between the 3 languages (WinBatch, AutoIt, AutoHotkey), except they can be named somewhat differently. Sometimes the names for commands or functions are similar, sometimes a bit different, but they do the same. As automation orientated languages, with various connections to each other and facing similar issues, there tends to be similar solutions. There are areas where one language is a bit stronger than the others, but they tend to be in the same ball park. However, I find AutoHotkey tends to be a bit better or easier to create utility or useful programs with.

Interestingly, I don't know of any large WinBatch programs or commercial programs that are sold, which are written in the language. A possible issue is that the Interpreter source code is closed, though you can distribute royalty free and sell programs, after buying the compiler. In customer comments about the program, a few people have mentioned selling their programs, though it's not clear how common that is. WinBatch seems more installation and network administration orientated, as oppose to quick utility or general purpose. Also, in various IT and business environments, they might not like the Interpreter being closed source out of fears of backdoors or that they can't customize it. Thus an open source tool might make them more comfortable.

I've also read material about decompiling, where WinBatch tech support appeared to have foolishly made a bold claim of superiority to AutoIt. However, AutoIt people quickly proved such claims false and showed how a WinBatch exe, and any .dlls they used, could be decompiled. Even exposing the technique that WinBatch used. When it comes to all 3 (WinBatch, AutoIt, or AutoHotkey) the level of security for the exe is about the same. These languages bind the source code to an Interpreter, as oppose to true compiling. More specifically, if a person knows what they are doing, they will get the source code. But to be fair, the following other popular programming languages have such issues too: Java, C#, Python, and JavaScript.

However, a Google search does not return many pages where AHK and WinBatch are both mentioned.

I think WinBatch and AutoHotkey aren't usually mentioned together because AutoHotkey is open source freeware, where WinBatch is closed source payware. More so now than before, as AutoHotkey has become so advanced, I don't think they want or like the comparison. The customers that they appeal to might also have some significant differences, particularly over license issues about selling their programs and how they want to get support.

WinBatch, as well as AutoIt, also have a wealth of ideas and scripts that can inspire creating similar or new kinds of scripts in AutoHotkey (and vice versa). An advanced level AutoHotkey script writer could possibly have a field day (for free) in the WinBatch archives and with Wil extenders .dlls, to include with sample scripts in their tech database. Possibly call the .dlls from AutoHotkey scripts, export the functions from the .dlls (many of which are well documented), or make similar functions and scripts using AutoHotkey. On the flip, a WinBatch progammer could make use of or get ideas from AutoIt and AutoHotkey libraries and forums. Though in many cases, there are already scripts among the automation languages that do similar, as often they come up with similar solutions to solve similar problems.

Note- minor changes for clarity were made.

[JFord]

Wow, the members of this forum are truly inspirational. Thanks for the narratives and links.

I can certainly testify that converting my several dozen Winbatch (wbt) scripts was like changing different flavors of the same language. I swear some scripts just ran as is.

And certainly there are different capabilities at the edges of all of these tools, but I was particularly interested in the language syntax itself, and for grins lets say specifically the examples I used (% enclosures and pseudo arrays) which I have never seen anywhere else and clearly came from a single source. How were some of these basic constructs not protected by copyright or IP?

And I'm sure I'm dense, but I am still confused by the relationship between WinBatch and ScriptIt

Microsoft ScriptIt which was a compiled WinBatch script

makes it sound like an app written in WinBatch, but clearly it was also it's own scripting language. Did it use the WinBatch code base?

[SOTE]

And I'm sure I'm dense, but I am still confused by the relationship between WinBatch and ScriptIt
makes it sound like an app written in WinBatch, but clearly it was also it's own scripting language. Did it use the WinBatch code base?

It appears to have been a specially made free WinBatch exe for Microsoft, to do installation tasks. You wrote the commands in an ini file and the ScriptIt.exe (a WinBatch interpreter) would run it. Instead of a .wbt extension, of a normal WinBatch script, it used an .ini extension.

Wow, the members of this forum are truly inspirational. Thanks for the narratives and links.

I can certainly testify that converting my several dozen Winbatch (wbt) scripts was like changing different flavors of the same language. I swear some scripts just ran as is.

And certainly there are different capabilities at the edges of all of these tools, but I was particularly interested in the language syntax itself, and for grins lets say specifically the examples I used (% enclosures and pseudo arrays) which I have never seen anywhere else and clearly came from a single source.

WinBatch syntax is weirdly in the middle between AutoIt and AutoHotkey. I find it much easier to read WinBatch scripts than AutoIt scripts, as their syntax is closer. It retains the kind of intuitiveness that AutoHotkey syntax still has, where it's more obvious what the syntax will do or what's going on.

How were some of these basic constructs not protected by copyright or IP?

The C and C++ source code of WinBatch is protected, but not the syntax. Probably the language syntax could not be copyrighted, because these terms were too general or were in use by other programs for quite some time. There is no telling how deep the borrowing of syntax goes. Wilson WindowWare might have borrowed a lot of the syntax and terminology from other programs and languages. Based on their Wiki and other references, WinBatch has borrowed syntax from Microsoft Batch Scripting, Fortran, and C. Also, ScriptIt was a freeware tool being promoted by Microsoft. If Wilson WindowWare had copyrighted terminology and syntax, this could have caused trouble for Microsoft, thus they might have got dropped or never got promoted. There was no way for WinBatch developers to foresee AutoIt. Probably like AutoIt's creator couldn't foresee AutoHotkey.

AutoIt appears to have borrowed various syntax, but not any of the actual source code, so suing probably wouldn't have been possible. In the situation of AutoHotkey, AutoIt was open source, thus forking the code under the GPL was legally allowed.

As a comparative reference, for those interested, this WinBatch manual shows the language and example usage.
https://web.archive.org/web/20170710090254/techsupt.winbatch.com/techsupt/PDFs/wil-lang20170412.pdf

[SOTE]

The upside of this story is that it was easy for me to learn AHK because the legacy syntax of AHK was so similar to WinBatch, including %Variables% and pseudo arrays, that I was certain that the development efforts were somehow related...

...but I was particularly interested in the language syntax itself, and for grins lets say specifically the examples I used (% enclosures and pseudo arrays) which I have never seen anywhere else and clearly came from a single source.

In regards to the use of the double %% around variables, this doesn't come from WinBatch, but was a feature of Microsoft batch files (.bat and .cmd), going all the way back to the days of MS-DOS.

I think it's a good idea to include it's use in AutoHotkey (particularly on the Windows OS), because Microsoft uses it. Oddly, there are some "purist" programmers that don't like it or want to get rid of it's use, despite the fact that Microsoft uses it. Possibly such programmers aren't using the command line or aren't familiar with .bat and .cmd files. Arguably, as long as Microsoft is using it, then so should AutoHotkey.

Pseudo arrays is another touchy subject, where "purist" seem to flip out on, and want to go on language purges about it. Here, I think this has more to do with the tastes of the individual programmer. I think it was good that Chris, the creator of AutoHotkey, put it in and think AutoHotkey should keep both (pseudo and real arrays). Thus giving AutoHotkey users more options.

. Newer and non-programmers will usually understand pseudo arrays easier and put them to use sooner
. What is great about pseudo arrays is you can make up the index or key to be whatever
. You don't have to initialize a pseudo array
. Real arrays, associative arrays, and objects can be overkill for what a person wants to do
. Forcing complexity on scripts that can be simpler, is a disservice to users of the language
. Users should be allowed the flexibility to choose which type they want to use

[jeeswg]

@SOTE: Interesting pdf, thanks for sharing. The language is quite ambitious in the scope of functions, and even includes StrCmp and StrCnt functions (string compare and string count).