Is Windows Defender heavily impairing the speed of AHK scripts?

[AHKStudent]

What do you mean? ... I don't understand the question. You know my project from my other topic. I am developing a script with an integrated small script editor to be able, from this compiled script, to write new small scripts, which later should be compiled for further use. But prior to this I have to test them in an easy way ('on the fly') during writing. Since AutoHotkey.exe will not be available for this, I use another available compiled script and replace its script resource. As I said at the beginning of my other topic, this is working, but it takes too long; 3500 ms instead of 35 ms, plus a first-run effect of xx seconds--that's not 'on the fly'. I know now that the reason is WD. With WD deactivated my solution would be perfect, but... That's all.
(Thank you very much for your comment to the question of the first-run behavior! I wasn't aware that this is associated to WD too. I will use your information to work on a solution for my problem.)

hope you share it with us when done, sounds interesting

[gregster]

For myself, this is my real concern and problem! I'm wondering: All others here seems not to be worried about this. Would all of your scripts work as expected when some techiques used in them suddenly (on the system of a user, after a new WD definition update) would take two or three (or perhaps even 100) times longer? Are you using no techniques where increasing execution time by a factor of 2 would cause usability problems?

For my many applications I rarely compile (and that is probably the case for many of the users here - but of course there are also exceptions) - and had not one AV false positive problem in 10+ years with AHK (with other - compiled - software, yes), as far as I remember.

I don't use it for gaming though, but for a lot of productive/work stuff and hobby - so why should I compile? I do it sometimes for friends, but I don't compress. There was perhaps once a problem with Avast a few years ago (Avast was notorious for causing AHK problems in the past), but I am not sure.

In the end we cannot tell Microsoft (or others) what to do - we can only complain and submit what we think are false positives - AHK is probably not high on their priority list, anyway. I think, I don't know any AHK malware programmers personally (but they seem to exist) - so I cannot argue with them. We could cripple the abilities of AHK... but then you would probably have to learn a more complex language for your use cases.

In the end, I would just disable shitty WD or other AV software if it would bother me. Of course, in many companies that might not be so easy (aka impossible). But usually they only allow ancient versions of AHK, anyway, if at all.

[newbieforever]

At the moment I am unable to invoke any new trojan detection associated to mpress! ... Is somebody other here observing the same change? Theoretically it would be possible that after my submission at MS (in which I described the problem associated to tmp files and AHK/mpress) the WD definitions were changed already; and there was a new update last night...)

If somebody here uses WD with the newest definition:
- Does WD still detect a trojan when using Ahk2Exe.exe with compression?
- How many seconds needs Ahk2Exe to compile a simple script with compression, on your system, with WD's real-time protection enabled/disabled?

[AHKStudent]

At the moment I am unable to invoke any new trojan detection associated to mpress! ... Is somebody other here observing the same change? Theoretically it would be possible that after my submission at MS (in which I described the problem associated to tmp files and AHK/mpress) the WD definitions were changed already; and there was a new update last night...)

If somebody here uses WD with the newest definition:
- Does WD still detect a trojan when using Ahk2Exe.exe with compression?
- How many seconds needs Ahk2Exe to compile a simple script with compression, on your system, with WD's real-time protection enabled/disabled?

Its no longer detecting it but I don't know if its because I approved it several times manually or because they updated their definitions.

Its taking less than 2 seconds to compile, im on win 10

[newbieforever]

AHKStudent: "Its taking less than 2 seconds to compile, im on win 10"

With WD activated??? With compression??? On my system the time is less than 2 seconds only with real-time protection disabled; if it is enabled, the time is > 20 s!!!

[Guest]

Why compile at all?

[newbieforever]

Why compile at all?

A day will come when this question will be answered!

[AHKStudent]

AHKStudent: "Its taking less than 2 seconds to compile, im on win 10"

With WD activated??? With compression??? On my system the time is less than 2 seconds only with real-time protection disabled; if it is enabled, the time is > 20 s!!!

Yes, sometimes a second more, tested on a windows 8 machine just now with similar results (always using mpress). My experience last week was different, defender would popup a toast message, then I would have to open defender, see the temp file they caught, manually approve things etc, I did not record the time it took until that message popped up but it certainly was way longer than what im experiencing now.

[AHKStudent]

Why compile at all?

A day will come when this question will be answered!

In that day you will no longer ask me anything. John 16:23 - NIV

[SoVieTing]

i have the same issue since v1.1.29.00+ .
v1.1.28.02- works fine
@Lexikos

[SOTE]

Why compile at all?

A day will come when this question will be answered!

I'm amazed that there are AutoHotkey users that don't understand the necessity to compile scripts or respect those that do. Well, outside of those that are trolling or joking.

1) Sharing scripts with people that don't have AutoHotkey

Many people don't know about AutoHotkey nor are interesting in screwing around with .ahk files. They prefer that the .exe do whatever the author, friend, or co-worker says it will do. This file "whatever.exe" does X. 1 file, 1 task or 1 solution, and finish.

2) There are AuthHotkey people that sell their programs.

a) Most customers are not used to dealing with anything but .exe files. Sending them a collection of "stuff" and .ahk files is unacceptable.

b) Authors that sell programs will not want to so easily expose their code. This is not to say that high level hackers and security experts could be stopped by compiled .ahk scripts, but rather they don't want their programs so obviously exposed that anybody can tamper with them.

c) Speaking of tampering, it's also to dissuade casuals from using their code for purposes other than what it was intended for or unauthorized selling of their programs.

d) True, there are other ways to protect sold programs such as registration or gathering computer information to link the program to a specific computer or charging for services and support, but the expectation from customers is often they will receive an .exe that automates the install process or allows the program to run via a simple click.

3) Configuring applications on Windows

Example, using "Open With" or "Choose Default Program" in Windows Explorer to open certain databases or file types (particularly unique ones like .kanto or .rentu) that work with a specific .exe. It's not to say you can't get them to work with an .ahk script, but that isn't the usual practice.

I'm sure more experienced or high level AutoHotkey users can think of more reasons, but those are a few that came to mind.

[SOTE]

In the end we cannot tell Microsoft (or others) what to do - we can only complain and submit what we think are false positives - AHK is probably not high on their priority list, anyway. I think, I don't know any AHK malware programmers personally (but they seem to exist) - so I cannot argue with them. We could cripple the abilities of AHK... but then you would probably have to learn a more complex language for your use cases.

In the end, I would just disable shitty WD or other AV software if it would bother me. Of course, in many companies that might not be so easy (aka impossible). But usually they only allow ancient versions of AHK, anyway, if at all.

I agree. Probably the best response is to report the false positives to the AV company, to include Microsoft. Get them to stop being lazy, and specifically identify what are true threats as opposed to negatively labeling entire scripting languages or free executable packers. I don't think the intentions of various AV companies or Microsoft is always "pure", because of money being involved or types of bureaucracy that they wish to impose.

If reporting the false positive doesn't work, then personally or telling users to make an exception for the file in WD or other AV software seems like the next best option.

https://support.microsoft.com/en-us/hel ... -antivirus
(adding an exclusion in Windows Defender)