DLLs, Windows-Path Variable

[Jochen Reichenberg]

Hallo Leute,

folgender Sachverhalt:<BR>
Ich habe mehrere Applikationen in denen identische Formulare verwendet werden. Diese wollte ich nun in DLLs bereitstellen, damit nach Änderungen an diesen Formularen das Neucompilieren aller Applicationen nicht mehr nötig ist. Weiterhin möchte ich DLLs nicht in jedem Programmpfad hinterlegen, sondern in einem bestimmten Verzeichnis (unter Programme) und ich möchte die DLLs auch nicht dynamisch laden.<BR>
* Zuerst mal: Geht das überhaupt? Muß ich bei statisch geladenen DLLs, nach Änderungen an der DLL die Applikationen trotzdem neu compilieren?<BR>
* Müssen DLL zwangsläufig im Windows- oder Systemverzeichnis stehen, oder reicht es diese in ein Verzeichnis zu legen, und dieses der Windows-Path-Variable hinzuzufügen?<BR>

Bei den Vorbereitungen bin ich außerdem auf folgende Probleme gestoßen:<BR>
* Ich habe keine Funktion gefunden, mit der ich den Pfad für Programme ermitteln kann (SHGetSpecialFolderLocation kann es nicht).
* Ich habe keine Funktion gefunden, um die Windows-Path-Variable zu modifizieren (putenv()und SetEnvironmentString() modifizieren nur eine Kopie der Variablen, die nur zur Laufzeit des Programms gültig ist). Muß / kann ich das über die Registry machen?

Das ganze soll unter Win 98, Win NT4.0, Win 2000 und Win XP funktionieren. Bei Win 98 könnte ich das Notfalls über die Autoexec.bat machen.

Falls es wichtig ist: Ich hab' den BCB6 Ent.

Schon mal Danke,

Jochen

[Armini]

Hi Jochen,<BR>
soweit ich das richtig verstehe sind statisch gelinkte DLLs fest mit deinem Programm verbunden, aber das läßt sich sicher einfach ausprobieren, ob sich Änderungen an der DLL ohne neu linken an Deinem Programm auswirken.<BR>
Das Ermitteln vom Pfad eines Programmes (wie "type" im UNIX, oder??) kannst Du eigentlich im Windows nur selbst machen: Environment PATH auslesen und nach dem Programmnamen in jedem Directory im PATH suchen (opendir() etc ;-))<BR>
Na und eine bleibende Environment Variable muss in die Registry geschrieben werden, ansonsten ist sie nur im Kontext deines Programmes verfügbar - und nach dem neu-Anmelden muss sie auch neu gesetzt werden.<BR>
Das mit dem Pfad für DLLs läßt sich ja auch leicht ausprobieren.<BR>
Gruß
Armi

[Jochen Reichenberg]

Hallo Armin,

danke für die Hinweise, aber daß ich das ausprobieren kann ist mir schon klar. Ich hatte eigentlich gehofft, daß das schon mal jemand ausprobiert hat und mir seine Erfahrungen mitteilen kann.

Ich will vermeiden, etliche Stunden in einen Lösungsansatz zu stecken, der von vorne herein zum Scheitern verurteilt ist. ;-)

Aber wenn's keiner weiß, werde ich das wohl in Angriff nehmen müssen.

Joche

[Christian Marquardt]

"Zuerst mal: Geht das überhaupt? Muß ich bei statisch geladenen DLLs, nach Änderungen an der DLL die Applikationen trotzdem neu compilieren?"

Nein

"Müssen DLL zwangsläufig im Windows- oder Systemverzeichnis stehen, oder reicht es diese in ein Verzeichnis zu legen, und dieses der Windows-Path-Variable hinzuzufügen?"

Es gibt eine Reihenfolge in der Windows nach DLL's sucht
- im Verzeichnis der Anwendung

- in Windir

- in Windir/system32/

- in Windir/system/

- in PATH

"Ich habe keine Funktion gefunden, mit der ich den Pfad für Programme ermitteln kann (SHGetSpecialFolderLocation kann es nicht). "
<pre>
char htext[MAXPATH];
memset(htext,0,MAXPATH);
GetModuleFileName(NULL,htext,MAXPATH);
String AktVerz=ExtractFilePath(htext);

</pre&gt

[Jochen Reichenberg]

Hallo Christian,

danke, das ist genau was ich wissen wollte. :-)

Aber ich hab' mich da wohl etwas unklar ausgedrückt, ich suche nicht den Pfad der laufenden Anwendung, sondern den Pfad, in den Windows die Programme installiert. Bei uns ist das meist C:\Programme, teilweise aber auch D:\Programme. Und da man den Pfad ja auch ändern kann, muß man Windows diese Info doch abringen können. (Ich möchte ein Setupprogramm schreiben, das auf dem Server liegt, aber die DLLs lokal installiert und auch gleich den Path korrekt setzt...)

Falls Dir dazu noch was einfällt...

Danke,

Joche

[Christian Marquardt]

Das sollte glaube ich mit SHGetSpecialFolderLocation gehen. Schau mal bitte hier

http://home.snafu.de/christian.marquardt/komponenten.2/2_specialfolder.html

in den Quelltext. (bin auf Arbeit, komme nicht ran, und auswendig weiß ich das nicht)

Muss noch was berichtigten:

Wenn du in der DLL neue Funktonen oder Methoden einführst, muss die Applikation natürlich neu compiliert werden. Also immer dann, wenn die Header-Datei sich ändert.

Warum speicherst du die DLL nicht beim Programm? Finde ich besser, da weiß man was wozu gehört

[Jochen Reichenberg]

Hallo Christian,

>Das sollte glaube ich mit SHGetSpecialFolderLocation gehen.

Das geht ja eben nícht. Man kann nur den Pfad zur 'Program Group' ermitteln -> Startmenü/Programme. Aber wenn es das tatsächlich nicht gibt, mach ich es halt auf die harte Tour: auf den lokalen Platten suchen. Ich finde nur, daß das aber keine elegante Lösung ist.

>Wenn du in der DLL neue Funktonen oder Methoden einführst...

Das ist klar, ich muß die Funktionen im Programm ja auch verwenden. :-) Ich hatte halt nur befürchtet, daß wenn ich in einer Funktion der DLL etwas anpasse, ich dann auch die Apps neu compilieren muß. Aber wenn ich dich richtig verstehe, muß ich nur die DLL tauschen, solange Funktionsname und Parameter identisch bleiben.

>Warum speicherst du die DLL nicht beim Programm?

Eben weil ich hier ca 10 Anwendungen habe, die die selben Formular verwenden (z.B. um die Qualitätsmerkmale eines Artikels anzuzeigen, um die Stückliste anzuzeigen usw). Ab und zu kommt es halt vor, daß gewünscht wird, da noch ein Feld mehr oder weniger anzuzeigen. Dann muß ich immer hingehen und alle Apps neu compilieren und verteilen. Bei 35 Arbeitsplätzen ist das auf Dauer sehr aufwendig. Deshalb wollte ich einmal ein Basispaket mit den entsprechenden DLLs erzeugen und diese dann installieren. Zusätzlich wollte ich auf dem Server einen Pfad anlegen, in den geänderte DLLs gelegt werden. Dann noch eine kleine App, die als Autostart-Programm prüft, ob dort eine neuere Version liegt, als die lokale. Ich hoffe auf diese Art und Weise mindestens zwei Paar Schuhe pro Jahr zu sparen. :-)

Joche

[Christian Marquardt]

CSIDL_BITBUCKET Recycle bin ¾ file system directory containing file objects in the user's recycle bin. The location of this directory is not in the registry; it is marked with the hidden and system attributes to prevent the user from moving or deleting it.

CSIDL_CONTROLS Control Panel ¾ virtual folder containing icons for the control panel applications.

CSIDL_DESKTOP Windows desktop ¾ virtual folder at the root of the name space.

CSIDL_DESKTOPDIRECTORY File system directory used to physically store file objects on the desktop (not to be confused with the desktop folder itself).

CSIDL_DRIVES My Computer ¾ virtual folder containing everything on the local computer: storage devices, printers, and Control Panel. The folder may also contain mapped network drives.

CSIDL_FONTS Virtual folder containing fonts.

CSIDL_NETHOOD File system directory containing objects that appear in the network neighborhood.

CSIDL_NETWORK Network Neighborhood ¾ virtual folder representing the top level of the network hierarchy.

CSIDL_PERSONAL File system directory that serves as a common respository for documents.

CSIDL_PRINTERS Printers folder ¾ virtual folder containing installed printers.

CSIDL_PROGRAMS File system directory that contains the user's program groups (which are also file system directories).

CSIDL_RECENT File system directory that contains the user's most recently used documents.

CSIDL_SENDTO File system directory that contains Send To menu items.

CSIDL_STARTMENU File system directory containing Start menu items.

CSIDL_STARTUP File system directory that corresponds to the user's Startup program group.

CSIDL_TEMPLATES File system directory that serves as a common repository for d

[Christian Marquardt]

Dann solltest du die DLL's in der Umgebungsvariable 'windir'+/system32/ speichern???

Ja, in SHGetSpecialFolderLocation gibt es das nicht. Habe jetzt mal geschaut

[dschensky]

Jochen,

wenn gar nichts mehr geht, kannst Du auch in der Registry wühlen:
http://www.winguides.com/registry/display.php/1137/

Ich bezweifle sogar, daß es etwas in der Art einer Umgebungsvariable gibt, die diesen Pfad enthält. Mein Pfad liegt z.B. auf d:\programme und der wurde irgendwie automatisch bei einer meiner ersten Programm-Installtionen so eingestellt. Demzufolge ist er frei definierbar und hat nicht wirklich Gewicht im System - will heißen, da könnte dann auch mal <I>irgendwas</I> drin stehen. Man kann sich einfach nicht darauf verlassen.

Zum Problem an sich:

Der größte Aufwand an Zeit scheint Dir durch das Rumlaufen und Installieren zu entstehen, falls ich das richtig verstanden habe. Also ist die prinzipielle Frage 'DLL oder nicht DLL bzw. welche Art DLL?' eher zweitrangig, da Du ja auch die veränderten DLL's herumtragen und installieren mußt.
Ich finde das Arbeiten mit DLL's oft nervig - insbesondere dann, wenn sich deren Versionen häufig ändern. Wenn ich die Wahl habe, stopfe ich lieber alles in das Programm. Das vereinfacht Installation und Administration ungemein. Das Programm, an dem ich gerade herumwerkele hat rund 90000 Zeilen Code und das komplette Compilieren dauert ca. 250 Sekunden - damit kann ich leben.
Aber das ist natürlich nur meine persönliche Meinung und das Thema ist äusserst kontrovers. Meiner Meinung nach sollten DLL's entweder Schittstellen zu Programmen darstellen oder nur elementare, relativ unveränderliche Funktionalitäten enthalten, die daher naturgemäß von verschiedensten Programmen genutzt werden können. DLL's, die vom Hersteller ständig geändert werden, sind häufig ein Zeichen für unausgereifte Programmierung, was Microsoft mit seinen unzähligen Sicherheits-Patches (Bug-Fix ist das passendere Wort) auch überzeugend unter Beweis stellt.

Gruß,
Ja

[Jochen Reichenberg]

@Christian:
Eigentlich wollte ich vermeiden, die Dateien in das System32 zu legen, aber es scheint die beste Alternative zu sein. Wenn es mir nicht gelingt, die Path-Variable permanent zu verändern, bleibt mir nicht viel anderes übrig.
Die Auswahl für das Laufwerk und den Installationspfad kann man auch anders lösen.

@Jan:
Vielleicht habe ich es ein bißchen übertrieben dargestellt. Aber dennoch muß ich das ca. 2 Mal die Woche machen...<BR>
Zum Hintergrund:<BR>
Meine Programme 'rüsten' im Prinzip einige Funktionen für unser PPS-System nach. Da sind in verschiedenen dieser Applikationen immer gleiche Ansichten auf die Daten gewünscht. Manchmal werden Änderungen am Verhalten des Formulars, oder den angezeigten Informationen gewünscht. Also habe ich so eine Art Formular-Pool angelegt, den ich in verschiedenen Applikationen verwende. Zur Zeit muß ich die gewünschten Änderung an dem Formular vornehmen und alle Applkationen, die es verwenden, neu compilieren und verteilen.<BR>
Deshalb dachte ich, DLLs wären für diesen Zweck geradzu prädestiniert, weil ich die Änderungen nur an der DLL vornehmen muß, diese eine Datei verteilen muß und alle Programme zeigen die Daten wie gewünscht an...

Auf jeden Fall schon Mal herzlichen Dank an alle!

Grüße Joche

[dschensky]

Jochen,
was ist ein PPS-System ?

Gruß,
Ja

[Jochen Reichenberg]

@Jan, mit unserem PPS-System wird hier intern alles erledigt. Vom Angebot, über Auftrag, Fertigungsaufrag, Bestellung, Disposition, Lieferschein und Rechnung... Kunderverwaltung, alles mit drin.
Da unser System aber schon ein bißchen älter ist, wir aber zur Zeit keine zig hunderttausende Euro in neue Soft- und Hardware investieren wollen, werden die 'fehlenden' Funktionen von mir nachgerüstet. Alles Datenbankzeugs...

Grüße Joche

[Jochen Reichenberg]

@Jan: hab' ich vergessen: PPS steht für Produktionsplanung- und Steuerung