JustinC721 wrote: ↑06 Aug 2016, 11:36
I want to take a couple of my AHK scripts and rewrite them as truly standalone Windows apps (yes, I know of AHK2exe), so I would like to know of the best programming language to use in that regard. I would prefer something that is lightweight and doesn't depend on things like .NET framework, Java, VBS, etc.
...I have a few AHK scripts that I wrote for work and they have turned out to be immensely useful in ways that I hadn't anticipated. As a result co-workers are asking about using them on their PCs and what not.
I know about the AHK2exe tool, but I don't think my IT dept will go for an app that was based around an AHK script, so what I would like to try is see if I can rewrite it to be a truly standalone Windows app. If I did this, I could probably get them to be more receptive in regards to authorizing it for use...
I see no reason not to just stick with using AutoHotkey, as it's arguably more suitable for many work related tasks in Windows due to it's
automation foundation. Other programming languages often lack the automation commands, are more complex, or need a lot of extra coding to do the same tasks. Consequently, AutoHotkey is a tremendous time saver and a very utility type language, as oppose to others. The languages on the same level of AutoHotkey are WinBatch and AutoIt, and if an IT department is going to allow them, then they should allow using AutoHotkey as well.
In an IT environment or even inside a business, AutoHotkey can actually be
much safer than other tools. To include writing it entirely in C, C++, using .NET, or Java. This is because you
WANT to be able to access all source code, and be able to compile it yourself. You want to minimize unknown code as much as possible, and be clear as to what is in everything.
As AutoHotkey is open source,
all of it's code can be inspected, where WinBatch and AutoIt are closed source. When you write in other program languages and compile, other people can't be sure what's in the executable, if there are any
backdoors, and decompiling can be extremely difficult or not possible. As AutoHotkey_L just "binds" your script when "compiling", you can easily decompile AutoHotkey executables to get the source, in addition to full inspection of the source code. Using AutoHotkey is much like using .bat, .cmd, or VBScripts that you just happen to able to compile into executables for convenience. Except, AutoHotkey is a much more powerful language than just using bat or VBScripts.
There are several decompiler tools for AutoHotkey, if you need to see what's in an exe. Garry's decompiler is an example, (exe2ahk) and is written entirely in AHK and does not use any 3rd party DLLs or closed source 3rd party tools.
Refer to:
https://autohotkey.com/boards/viewtopic.php?t=59015
https://autohotkey.com/boards/viewtopic ... 52#p248552
https://autohotkey.com/boards/viewtopic.php?t=42494
If this method does not work, the
AHK decompiler by Uberi (and oringinally created by IsNull), can also work. It uses a DLL to help decompile.
https://gist.github.com/Uberi/3334552 Uberi's version is on Github, with full source code, and appears more up to date. However, payload.dll and payload64.dll from IsNull at dl.securityvision.ch can no longer be found. A moderator for the AutoHotkey website, joedf, has made a copy of the DLLs available for download.
https://autohotkey.com/joe_df/autohotk ... ompiler.7z( contains the needed payload.dll and payload64.dll).
When you write the application in Assembly, Pascal, C, C++, etc... the IT department can't see what's in the compiled program. This may or may not create a security issue, depending on the situation. Now it might be that the IT department or business wants to hide the application's source code, but you can do that with AutoHotkey and other programming languages by using
encryption or
obfuscation.
In the case of C# and Java (to include Python depending on implementation), they compile to
intermediate code, which means they are easily reversed engineered just like AutoHotkey. There are many
decompilers for C# (like
dotPeek), Java (like
Java Decompiler), and Python (
uncompyle6). There is little advantage to using C#, Java, or arguably Python if you are just going to stick to Windows and making applications. You can make the application using AutoHotkey to do the same thing. And to protect C# or Java source code, they use
encryption and obfuscation too. Which is what you can do with AutoHotkey.
The advantage of languages like Java and C# is suppose to be in cross-compiling and cross platform applications. In the case of C#, that's not really the case, as Microsoft has dragged it's feet in making .NET and Mono viable on the macOS, iOS, Android, or Linux for fear of competition. Java has never really lived up to it's promises and hype. Many argue that Python is a mess. Note- Pascal (which is an interesting mix of high and low level programming) is arguably better for cross-compiling and cross platform applications than either C#, Java, or Python. However, if the point is to just write time saving applications on Windows, then there is no need to fall down the rabbit hole of all that additional complexity that writing for multiple OSes would bring.
The advantage of languages like C or Assembly, is you can do low level programming, directly manage memory, or code for various types of hardware. But somebody writing scripts and applications to save time on tasks at work, is unlikely to need to go so low. Learning to write the application for tasks at work entirely in C or Assembly is likely to be a waste of time. Even if you learned it, writing applications in those languages will involve lots of pain and time. Think about the point of AutoHotkey and AutoIt. Both were written in C++, but why not just use C++ instead? Because clearly C++ was a pain, so easier shortcuts to doing tasks were preferred.
Additionally, because AutoHotkey is an easier language to understand, if a new co-worker needs to learn it or read scripts written by a previous person, they can have a much easier time to understand it. This is better for the IT department or inside a company, where people can understand what the scripts are doing and make changes as needed, versus needing to hire formally trained programmers to write code.
So final opinion, stick with AutoHotkey, if you can and convince your IT dept or company to go along with you. Will likely make life much easier. If you absolutely must learn a "real" programming language on Windows and outside of AutoHotkey, then arguably you should learn Pascal or C#. Pascal being the easier language, cross-compiling, and cross-platform for multiple OSes. But, C# being the more corporate acceptable, more well known among laymen and managers, comparatively easier to switch to C++ if a person needs to learn it, and backed by Microsoft.