Wobei, WENN man schon mit einer DLL arbeitet, man diese auch so in ein Script "einbauen" kann, dass diese im Scriptablauf direkt in den Speicher geladen und angesprochen werden kann, OHNE den Umweg über ein Speichern in den Verzeichnispfad (und Starten von dort aus).
Ich weiß, wollte aber diesen Punkt nicht noch zusätzlich in's Spiel bringen .
Gleichwohl ist das eine nützliche Info für alle, die es nicht wissen.
Mit den systemweiten .dll's ist das wirklich so eine Sache.
Folgendes Szenario ist mir z.B. schon häufiger untergekommen :
-> Programm A installiert die VC Runtimes über die entsprechenden Installer (z.B. vcredist_x86.exe und vcredist_x64.exe). Danach sind sie systemweit für alle Programme verfügbar - so soll es ja auch sein.
-> Programm B, welches die Runtimes ebenfalls benötigt, stellt bei der Installation fest, dass diese bereits vorhanden sind und nicht erneut installiert werden müssen (genauer, die vcredist_x*.exe machen das).
-> Programm A wird mittels eines (schlecht geschriebenen) Uninstallers deinstalliert, inkl. der Runtimes.
==> Programm B steht nun im Regen !
Soweit ich weiß (lasse mich aber gerne korrigieren), sucht eine .exe benötigte .dll's zuerst im eigenen Verzeichnis. Um das obige Szenarion zu entschärfen, packen daher viele Programme die Runtime-dll's (z.B. msvcp140.dll und vcruntime140.dll) noch mal gesondert in z.B. das \bin Verzeichnis.
Das ist natürlich nicht im Sinne des Erfinders, aber was soll's .
Gruß Musashi