Best Programming Language for Windows Applications (non-metro)

[JustinC721]

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.


TL;DR: If you want to understand more, check the spoiler.

Spoiler

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.
The program itself is pretty simple. It just allows for faster navigation of our somewhat poorly organized network drives via command prefixes. We know the name of the file we're looking for most of the time, it's just that getting there can be tedious. So instead clicking through a rabbit hole of folders and sorting down a list to find 'item94688.pdf' you would just type 'doc//94688' and hit enter to do the same thing. I even included a search function in case you don't know the full name. So if I knew the first 3 numbers I would type 'doc??946*" and a search window would open showing all of the files that include 'item946' in the file name.

I wrote the app just for myself so I stuck with an ultra lightweight interface.

[Masonjar13]

C/C++. It will natively be the most lightweight, unless you include a plethora of libraries. It is not dependent on anything and is cross-platform, if designed to be so. It's also what AHK is written in.

[nnnik]

Yes C++ is the best programming language. So you can proceed with it.

No
It's not even close. It all comes down to personal preference and what you want to achieve.

[Trogluddite]

My advice would be to have a quiet word with your IT guys before making a whole load more work for yourself. You may find that an AHK script would actually be more acceptable to them rather than less so. From their point of view, an .exe is just a 'black box' that they can't look inside to see what it gets up to (it might act benignly now, but how can they tell there isn't a remote 'self destruct' button?). On the other hand, an AHK script is source code that they can check for themselves to see if it looks malicious or not. All the system admins I've ever worked with have been 'scriptaholics', and AHK scripts are not a million miles away from .bat syntax (if you're system admin can't handle that, then you need a new system admin! ). You might just find that they have more confidence about your code if they can actually see it, and can advise you how to make your script safer and more secure.

[SOTE]

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.