AHK programming on Windows with/without DLL-Calls

[Jovannb]

Hi,

I'm on AHK since more than 10 years now, in that time i avoided instinctively using DLL-calls.
My concern is, that without DLL-calls in my code, i can secure that elderly code runs in future too.

But the longer I'm programming, the more I learn, that some certain things require the use of those DLL-calls from AHK.
I'm sure I'll stay on standard Windows-System (because we use that in our office), so the question is, will DLL-calls somebody makes or made 5 or 10 years ago work in eg. 5 years too ?

Whats your perspective on that, what are the pros and cons of that ?

J.B.

[SOTE]

DllCall would not be an issue unless the Dlls that you are relying on and how to call them have changed. Even if that was the case, you could put the Dlls that you are relying on in the same directory as your program and make sure to call your Dlls specifically. You could also have a notice telling the user which Dlls they need and where to download them from. If you create the Dlls yourself or are using open source Dlls, you can have more control over the situation and can usually include the Dlls with your programs.

The only type of situation that I could see where being so worried could be justified, is that you don't control the environment that your programs are used in and you can't package the correct Dlls that you need due to copyright restrictions. Maybe you want to explain your situation a bit more, as people might be able to offer suggestions.

[Jovannb]

The only type of situation that I could see where being so worried could be justified, is that you don't control the environment that your programs are used in and you can't package the correct Dlls that you need due to copyright restrictions. Maybe you want to explain your situation a bit more, as people might be able to offer suggestions.

I do control the environment we are using our AHK-programs. We do have them on a network share, from which every user (in our company network) starts the same xxxx.ahk, from this point off view it is a controlled secure environment.
Except a few of my AHK-programs - they are used by partner companies e.g. for sharing huge files via dropbox-links - we use AHK for office-automation in our physical Office and nowere else.
All our computers are on more or less the same OS levels. But I learned to know that there are sometimes issues when specialized civil engineering programs (civil engineering - the domain we are in) cause troubles regarding installed Dot-Net releases (those are Dll's too, arent they ?).

J.B.

[SOTE]

I do control the environment we are using our AHK-programs. We do have them on a network share, from which every user (in our company network) starts the same xxxx.ahk, from this point off view it is a controlled secure environment.
Except a few of my AHK-programs - they are used by partner companies e.g. for sharing huge files via dropbox-links - we use AHK for office-automation in our physical Office and nowere else.
All our computers are on more or less the same OS levels. But I learned to know that there are sometimes issues when specialized civil engineering programs (civil engineering - the domain we are in) cause troubles regarding installed Dot-Net releases (those are Dll's too, arent they ?).

J.B.

I'm not quite understanding the issue. The .NET Framework is for .NET programs, usually written in C# (but there are some other programming languages a person can write .NET programs in). Are your civil engineering programs written for .NET, so you need your AutoHotkey scripts to interact with them? Maybe you want to look at this-
.NET Framework Interop (CLR, C#, VB)
https://www.autohotkey.com/boards/viewtopic.php?f=6&t=4633

You might also want to look at Limnor, which is a visual .NET programming language. Maybe you might find it helpful. It seems the Limnor developers were aware of AutoHotkey.
https://www.autohotkey.com/boards/viewtopic.php?f=23&p=314619

If your civil engineering programs are written for .NET, and you must interact with them, then there is probably no avoiding .NET upgrade and other kinds of issues. Microsoft is heavily invested in .NET, so it's not going away any time soon and it can be hard to avoid it. However, I'm not quite sure that what you are describing is a Dll issue, the description of the problem still seems a bit vague. Are you just trying to automate the GUI of a .NET program?

[guest3456]

how do you think AHK is accomplishing its tasks?

when you type WinMove command, the AHK interpreter translates it into a C++ dll call of SetWindowPos(). so if you're afriad of DllCalls obsoleting your program, you should have the same fear of AHK itself.

[Weatherlight]

Using DLLs rather then AHK can also cause problems when faced with advanced security features like Windows Defender Application Control (WDAC) or Windows 10 in S-Mode. Your AHK code would run fine while DLLs will fail to load if they violate configured WDAC policies.