Der richtige Platz für die DLL- und LIB-Dateien?

[Werner]

Hi!

Mich würde einmal interessieren, ob man die der jeweiligen xBase++-Version zugehörigen DLL- und LIB-Dateien unbedingt in das zugehörige WINDOWS-Verzeichnis (z.B. in den Ordner: System32) kopieren (lassen) muss oder ob man diese Dateien der Einfachheit halber auch in das jeweilige Programmverzeichnis legen kann, in dem die .EXE liegt.

Ich habe das einmal versucht ... und es schien zu klappen! Aber das kann doch nicht sein! Oder?

Gruß Werner

[Manfred]

Hi Werner,

ich mache das nur so und es klappt schon seit Jahren. (DLL usw. in Programmverzeichnis) Allerdings ist das Programmverzeichnis auch das aktuelle Verzeichnis. Windows sucht ja da zuerst und dann geht es die anderen Verzeichnisse durch, die eingetragen sind.

[brandelh]

Hi,

eine EXE sucht die nötigen DLLs zuerst im EXE Verzeichnis, dann in verschiedenen anderen und somit auch in windows und windows\system32 (die Namen können anders lauten).

Seit Jahren wird es aber - zumindest von mir und was ich so gelesen habe - als unseriös empfunden, wenn eine Anwendung DLLs in die SystemVerzeichnisse kopiert.
Im Übrigen, wenn eine neue Xbase++ Version erscheint und die neue Anwendung diese DLLs braucht, andere aber ältere Versionen ...
Genau das ist der Grund warum es am Besten ist jeder Anwendung im EXE Verzeichnis seine DLLs zu spendieren.
Der Nachteil des erhöhten Speicherplatzverbrauchs ist schon seit Jahren nicht mehr wichtig.

PS: LIB-Datein ... die gehören ausschließlich in das Verzeichnis ?\xppw32\LIB auf dem Entwicklungsrechner und sonst nirgends hin

[Jan]

Ich selber packe die dll in das Programmverzeichnis. Das mag nicht ganz der Sinn der Sache zu sein, denn eine dll mag ja für verschiedene Programme zur Verfügung stehen.

Aber: Die dll müssen zur exe passen, und wenn die Xbase++-Versionen zwischen dll und exe nicht übereinstimmen, dann gibt es einen passenden Laufzeitfehler. Und ich habe Programme auf meinem Rechner, die mit verschiedenen Xbase++-Versionen erstellt wurden. Die dll im Windows-Verzeichnis würden da nur Probleme erzeugen.

Jan

[J.Renseler]

Hallo,

ich handhabe es genauso wie von Jan, brandelh und Manfred beschrieben, DLL's in das Applicationsverzeichniss. Unter Windows7 wirst du ohne das Anfordern von Administrationsrechten auch keine DLL's mehr nach System32/System kopieren können.

Wenn du jedoch mehrere verschiedene Anwendungen hast kannst du auch die DLLs in ein separates Verzeichnis legen und diesem Pfad in der Umgebungsvariable "PATH" eintragen, dann wird die DLL von dort genommen.

Gruß,
Jannik

[Rolf Ramacher]

Hallo Werner

mache es so wie beschrieben. Ich mache dies ebenfalls genauso. alles im Programmverzeichnis, dann kann nix schiefgehen.

[Tom]

So gut wie alle Anwendungen legen die DLLs, die zu ihnen gehören, im Installationsverzeichnis der Applikation selbst ab. Schaut Euch einfach mal an, wie und wo z.B. der Acrobat Reader installiert ist. Das ist auch der einzige sinnvolle Weg. Es mag Programme geben, die DLLs mit gleichem Namen, aber völlig verschiedenen Funktionalitäten beinhalten. Es wäre idiotisch, solche DLLs in irgendwelche Systemverzeichnisse zu kopieren - Chaos im wahrsten Sinne des Wortes vorprogrammiert. Dort gehören nur Betriebssystem-DLLs und Treiber hin. Diese angebliche Anforderung von Microsoft, man solle DLLs immer im Windows- oder gar Windows-System(32)-Verzeichnis installieren, hat es nie gegeben - das ist eine Programmiererlegende, die sich aber wacker hält. Was soll ein anderes Programm mit einer DLL anfangen, die ich z.B. erzeuge, um meine EXE aufzusplitten? Die gemeinsame Nutzung - und damit Verfügbarkeit - von DLLs hat nur dann Sinn, wenn mehrere Programme tatsächlich diese DLLs gemeinsam nutzen. Auf Entwicklungsrechnern kann man solche DLLs irgendwo platzieren, wo sie - einmal erzeugt - über die Pfade gefunden werden. Auf Kundenrechnern gehören sie ins Installationsverzeichnis der App, und nirgendwo sonst. Und, wie hier richtig erklärt wurde: LIBs gehören überhaupt nicht auf Kundenrechner. Die Anwendung benötigt sie nach dem Linklauf überhaupt nicht mehr.

Ich hatte tatsächlich mal den exotischen Fall, dass ein Kunde eine weitere Xbase-Anwendung installiert hatte, für irgendeine Spezialaufgabe. Die Xbase-Version stimmte nicht mit derjenigen meiner Software überein, aber der Programmierer hatte die Laufzeit-DLLs von Xbase großzügig über die Systeme verteilt, es gab mehrere Kopien davon, auch in den Windows-Verzeichnissen. Bis wir auf diese Lösung für das Problem gekommen sind, dass unsere App hin und wieder krachte, das hat eine Weile gedauert (ist aber auch Jahre her).