Umgebungsvariablen langfristig setzen

[Christian Seehase]

Moin Himitsu,

reicht es Dir die Umgebungsvariable im Parent-Prozess zu setzen, so dass Du sie aus einem eigenen Konsolenprogramm heraus für die aufrufende Konsole setzen kannst?

[Olli]

Also wie man bspw. bei CreateProcess eine modifizierte Version der Umgebung uebergibt, hatte ich schonmal vor Jahren hier in der DP gepostet.

Zitat von himitsu:

Kenn ich schon, nur müßte ich ja dann woanders die aktuellen Umgebungsvariablen herbekommen.
Also den Befehl zum Ändern hätt ich ja schon gehabt, aber eine "gute" Vorgehensweise wäre da noch wissenswert.

Mir erscheint es sinnvoll, wenn du mal verraetst, was du erreichen willst/

Zitat von himitsu:

OK, selber die nötigen Registry-Pfade abfragen ... aber sind das alle und wie wird da bei gleichen Variablen in den verschiedenen Zweigen vorgegangen?
HKEY_CURRENT_USER\Environment
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\Environment

Ja das sind alle. Soweit ich weiss ueberschreiben deine Variablen die Systemvariablen (also bzgl. der Reihenfolge).

Zitat von himitsu:

Hab es auch schon mit FreeEnvironmentStrings versucht, dachte daß da vielleicht die Kopie im Programm freigegeben wird und dann bei erneuter Abfrage mit GetEnvironmentStrings/GetEnvironmentVariable würde eventuell eine neue Kopie angelegt ... ging aber och nicht.

Nur beim Neustart eines Programms und Uebergabe der Umgebung.

Zitat von himitsu:

In dem Programm wo ich dieses mal mit einbauen wöllte hätt ich dann nur noch ein "Problem" ... wie verwalte ich dann die programminternen mit SetEnvironmentVariable hinzugefügten Variablen, damit die dann beim erneuern des Enviromentblocks nicht verschwinden.

Die Frage verstehe ich nicht. Lokal ueberschreibt global. Wo ist der Konflikt?

Zitat von himitsu:

Ich möchte ja schließlich Funktionen wie ExpandEnvironmentStrings auch noch programminterne Variablen unterjubeln können.

Hast du es mal getestet? Sollte doch gehen, denn eigentlich sollte das auf dem Environment-Block des Prozesses basieren.

Zitat von himitsu:

Und das Programm neuzustarten ist ja mitten im Betrieb auch nicht unbedingt soooo optimal/schön.

SetEnvironmentVariable hilft doch dann. Und die Aenderung wird auch an Kindprozesse weitergegeben.

Zitat von Christian Seehase:

reicht es Dir die Umgebungsvariable im Parent-Prozess zu setzen, so dass Du sie aus einem eigenen Konsolenprogramm heraus für die aufrufende Konsole setzen kannst?

Geht ja auch ohne Konsole, dann eben programmatisch.

[Christian Seehase]

Moin Olli,

Zitat:

Geht ja auch ohne Konsole, dann eben programmatisch.

ich wollte auf etwas anderes raus.
Durch eben dieses Problem bin ich zu Foren gekommen

Wenn ich, um Zuge einer Batchverarbeitung, eine Umgebungsvariable so setzen will, dass sie nach meinem Programm zur Verfügung steht, sieht MS vor, dass man eine Batchdatei mit dem entsprechenden Set-Kommando erstellt, die dann nach dem Programm aufgerufen werden soll.
Das ist natürlich eine gangbare Lösung, aber irgendwie schwebte mir eine andere Lösung vor.
Grober Ablauf (vorausgesetzt, das Environment passt in 4Kb, auch nach dem Setzen einer Umgebungsvariablen)
Man ermittelt den Parent Prozess.
Man ermittelt die Adresse des Environmentblockes (GetEnvrionmentStringsW) (*)
Man setzt die Umgebungsvariable, ganz normal mit SetEnvironmentVariable
Man kopiert den eigenen Environmentblock in den des Parent-Prozesses.

Unter XP-Pro SP 2 hat das, auch mit normalen Benutzerrechten (!), funktioniert.

(*)
Leider hat die Sache hier einen unschönen Haken:
Bei allen Versuchen, die ich gemacht hatte lag das Environment immer an der gleichen Adresse, unabhängig davon, welchen Prozess ich mir angeschaut habe. Leider ist das aber nicht zwingend erforderlich , so dass man an dieser Stelle scheitern kann.
Bevor man versucht dort etwas reinzuschreiben, sollte man also genau prüfen, das der angesprochene Speicherbereich auch wirklich das Environment enthält.

Die Begrenzung auf 4Kb ergibt sich dadurch, dass sich bei überschreiten der Grenze die Startadresse verschieben kann.

[himitsu]

Zitat von Christian Seehase:

reicht es Dir die Umgebungsvariable im Parent-Prozess zu setzen, so dass Du sie aus einem eigenen Konsolenprogramm heraus für die aufrufende Konsole setzen kannst?

Das wäre natürlich ideal.

Zitat von Olli:

Mir erscheint es sinnvoll, wenn du mal verraetst, was du erreichen willst

ich hab mir sozusagen ein kleines Programm erstellt, welches global eine Variable mit einem Installationsverzeichnis erstellt, so daß dieses auch von Batchdateien genutzt werden kann.

Für kleine Tools wäre es schon praktisch, wenn man da mit 'ner winzigen BatchFile arbeiten könnte, anstatt da gleich ein rießiges Setup erstellen zu müssen.

Tja, da es aber sein kann, daß dieses Verzeichnis noch nicht eingerichtet ist, wird halt von den "Setup"-Scripten vorher diese Prgrämmchen versucht aufzurufen und nachdem dieses das Verzeichnis eingerichtet hat, bräuchte ich ja nach dessen aufruf dn Pfad in dem Script.

Zitat von Olli:

Ja das sind alle. Soweit ich weiss ueberschreiben deine Variablen die Systemvariablen (also bzgl. der Reihenfolge).

Das war schon klar, also:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\Environment
- HKEY_CURRENT_USER\Environment
- und dat Eigene
in der Reinfolge eingelesen (mit Überschreiben)
und zwischendurch noch einiges Anderes...

Nur ob die Reihenfolge so auch richtig ist, war ich mir nicht ganz sicher. (abgesehn daß dieses nicht alles ist ... siehe weiter unten)

Zitat von Olli:

Nur beim Neustart eines Programms und Uebergabe der Umgebung.

Bei einem Programm gibt es ja Wege dieses zu machen aber ein Befehlsscript samt CMD aus sich selber raus neu zu starten wird wohl schwer.

Wenn ich nun innerhalb des Scripts CMD und das Script selber neu starte, dann wird da leider auch nur wieder nur der "alte" EnviromentBlock weitergegeben.

Code:

%ComSpec% /c %0

Zitat von Olli:

Die Frage verstehe ich nicht. Lokal ueberschreibt global. Wo ist der Konflikt?

Da es ja so eh keine Möglichkeit gibt rauszufinden welche Variablen/Werte von der Anwendung selber definiert wurden und vorallem welche nicht erneuert werden dürfen, bin ich da 'nen anderen/einfachen Weg gegangen.

Der Konflikt lag eigentlich mehr darin was sich nun innerhalb des Programms geändert hat und möglicher Weise bei einem Update nicht geändert werden dürfte....


Hab gestern abend mal angefangen 'ne winzige Klasse zu erstellen, welche den EnviromentBlock updatet.
Und dort eine Liste eingebaut, wo Werte registriert werden können, welche nicht geändert werden sollen.


Da sind dann nochmals die "bekannten" Funktionen zum Setzen/Auslesen der Umgebungsvariablen drin.
Die WinAPIs können aber dennoch genutzt werden, allerdings müßten dann über ReloadEnvironmentStrings(False) die geänderten Werte eingelesen werden.

Die Prozedur zum Updaten "ReloadEnvironmentStrings" kennt da 2 Varianten:
True=aktuelles aus'm System auslesen
False=aktuellen Enviromentblock des Programms auslesen (falls z.B. irgendwo im Programm direkt über die WinAPI was geändert wurde ... damit die Werte in der StringList "EnvironmentStrings" auch stimmen)

ReloadEnvironmentStrings wird über WM_SETTINGCHANGE und über Button1 [Reload] ausgeführt.


Soweit scheint es schonmal zu gehn ... nur fehlen bisher nach dem Reload noch ein Paar der Werte, also HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\Environment und HKEY_CURRENT_USER\Environment ist nicht alles.

Folgendes fehlt bei mir noch:

Zitat:

ALLUSERSPROFILE=C:\Dokumente und Einstellungen\All Users
APPDATA=C:\Dokumente und Einstellungen\Frank\Anwendungsdaten

CLIENTNAME=Console
CommonProgramFiles=C:\Programme\Gemeinsame Dateien
COMPUTERNAME=FRANK

DELPHI=c:\programme\borland\delphi7

HOMEDRIVE=C:
HOMEPATH=\Dokumente und Einstellungen\Frank
LANGUAGE=English
LOGONSERVER=\\FRANK

ProgramFiles=C:\Programme

SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS

USERDOMAIN=FRANK
USERNAME=Frank
USERPROFILE=C:\Dokumente und Einstellungen\Frank

"DELPHI" ist klar: dieses scheint eine Variable zu sein, welche das Programm aus dem EnviromentBlock von Delphi mitbekommt.
Denn diese ist nur vorhanden, wenn über den Debugger gestartet wurde.

Und damit alles stimmt, wäre es ja besser, wenn ich nun die selben Quellen nutze, welche dafür original auch erwendet wurden.


Ach ja: Eigentlich wollt ich erst über Application.OnMessage gehn, da sich dort die Klasse hätte selber einklinken könne ... nur kommt da kein WM_SETTINGCHANGE an.
Also mußte ich sie von Hand in das Hauptfenstern schleußen.
Procedure WMSettingChange(Var Msg: TMessage); Message WM_SETTINGCHANGE;

Zitat von Olli:

Hast du es mal getestet? Sollte doch gehen, denn eigentlich sollte das auf dem Environment-Block des Prozesses basieren.

SetEnvironmentVariable hilft doch dann. Und die Aenderung wird auch an Kindprozesse weitergegeben.

Also im eigenem Programm verwenden und Weitervererben geht ... nur halt nicht rückwärts.

Zitat von Christian Seehase:

Wenn ich, um Zuge einer Batchverarbeitung, eine Umgebungsvariable so setzen will, dass sie nach meinem Programm zur Verfügung steht, sieht MS vor, dass man eine Batchdatei mit dem entsprechenden Set-Kommando erstellt, die dann nach dem Programm aufgerufen werden soll.

Na sowas klingt doch auch nicht schlecht.



PS: weiß zufällig jemand, was der 1. Eintrag '=::=::\' in Windows.GetEnvironmentStrings zu bedeuten hat?
Name = ""
Value = "::=::\"
Der ist immer vorhanden und ging auch nicht zu löschen (SetEnvironmentVariable).
(hab ihn, oder besser gesagt alles was keinen Namen hat, einfach mal ignoriert)
Wer sowas nicht ausblenden will, der kann mal dieses auskommentieren/entfernen:
If Pos('=', P2) > 1 Then
PSS: falls es keinem augefallen ist ... mir fiel zufällig eine praktische/schöne Umkehrfunktion zu ExpandEnvironmentStrings in die Händchen.





Oder wie wäre ein anderer "einfacher" Ansatz, welcher aber nur innerhalb eines selbstgeschriebenen Programmes und den nachfolgenden Kindprozessen geht.

Das Programm startet eine neue Instanz von sich selber (ohne Übergabe des eigenen EnviromentBlocks), daber dafür mit 'nem netten Parameter.
Diese Instanz schickt eine Kopie des eigenen EnviromentBlocks an die erste Instanz und beendet sich wieder.
In der Ursprungsinstanz wird dann der empfangene Block einfach reingeladen.

> würde zumindestens das "eigenhändige" Zusammensuchen der nötigen Daten ersparen.




Anhang:
Project1 = ein Testporgramm mit der Updateklasse
InitializeDefaultDir = das Programm welches die Umgebungsvariable erstellt
und im FileSplitter die BatchFiles, welche diese Variable nutzen.

- die zu erwartenden Registry einträge sind aus den .reg-Dateien zu ersehen und natürlich er eintrag unter HKEY_CURRENT_USER\Environment ... wo dann auch das Installationsverzeichnis herkommt
Installationsverzeichnis is auch noch über _test.cmd rauszubekommen ^^