Umgebungsvariable eines anderen, laufenden Programms ändern

[Tiemo]

Hallo Gemeinde,

ich suche nach einer Lösung, eine Umgebungsvariable in einem schon laufenden Programm zu verändern. Ich meine mich daran erinnern zu können, dass ich irgendwo dazu schon mal Code gefunden hatte, habe aber keine Ahnung mehr, wo das war.

Hintergrund:
Ich starte aus meinem Programm zwei weitere Anwendungen, die asynchron miteinander kommuzieren. Mein Programm und Programm A werden dann irgendwann wieder beendet, Programm B läuft aber weiter. Wenn mein Programm nun wieder ausgeführt wird, möchte ich nicht Programm B erst abschießen und dann mit einer neuen Umgebungsvariable neu starten sondern einfach die Instanze beigehalten und den Wert der Variable XY in der Sitzung ändern.

Es kann davon ausgegangen werden, dass sowohl mein Programm als auch das Programm B unter dem gleichen Benutzer mit dem gleichen Token laufen.

Hat hierzu jemand eine Idee?

Tausend Dank
Tiemo

[Christian Seehase]

Moin Tiemo,

bei der Konstellation wäre es vielleicht einfacher der laufenden Instanz von Programm B einfach auf anderem Wege, z.B., per WM_COPYDATA den gewünschten neuen Wert zu übergeben. Das Programm kann es dann, wenn's denn unbedingt eine Umgebungsvariable sein muss, auch in sein Environment eintragen. Das dürfte dann auch unter Vista funktionieren.
Die Variante direkt das Environment eines fremden Prozesses zu manipulieren habe ich hier in der DP auch schon mal beschrieben, aber wenn alle beteiligten Programme von Dir stammen, lohnt sich der Aufwand hier wohl nicht. Für Vista habe ich da auch noch keine Lösung ;-)

[DeddyH]

Bei so etwas weht auch immer ein leichter Hauch von Virus durch die Luft (zumindest für den Scanner) ;)

[Christian Seehase]

Zitat:

Zitat von DeddyH

Bei so etwas weht auch immer ein leichter Hauch von Virus durch die Luft (zumindest für den Scanner) ;)

Stimmt, aber ist machbar :mrgreen:
Ausserdem gibt es für solche Vorgehensweisen auch legitime Anwendungen. ;-)

[Tiemo]

Ich habe vergessen zu erwähnen, dass Programm A und B nicht von mir sind, so dass ich darauf leider keinen Einfluss nehmen kann.

[Tiemo]

Und noch etwas: Ich möchte natürlich keinen Virus schreiben. Meine Applikation ist ein Konfigurationsprogramm für eine 3D CAD Anwendung. Dieses Konfigurationsprogramm setzt eine Reihe von Voreinstellungen und startet dann das CAD Programm. Abhängig von den Einstellungen zieht das CAD unterschiedliche Lizenzen. Es ist auch möglich, verschiedene Versionen des CAD Programms zu starten.

Programm B wiederum ist eine Helfer-Anwendung für ein dazugehöriges PDM System. B läuft asynchron zum CAD Programm, so dass beim Beenden des CAD Programmes die Daten trotzdem noch auf den Server hochgeschoben werden können. B braucht aber den Pfad zum CAD, der sich wiederum durch mein Programm beim Start auswählen lässt. Wenn B jetzt aber nicht gestartet wird, kann ich den Pfad nicht ändern. Abschießen und Neustarten ist auch Mist, da evtl. noch Daten zum Server geschoben werden.

Das nur zur Beruhigung und Erklärung...

[Christian Seehase]

Moin Tiemo,

das Du einen Virus schreiben willst, haben Detlef und ich auch nicht angenommen, aber die Techniken die erforderlich sind (Manipulation eines fremden Adressraumes) kann von einem Virenscanner durchaus als verdächtig angesehen werden.
Um Umgebungsvariablen eines anderen Prozesses zu manipulieren, müsstest Du den Environmentblock dort überschreiben.
Die einfachste Variante wäre es das eigene Environment zu ändern, und dann diesen Speicherbereich in den korrespondierenden Speicherbereich des Zielprozesses zu kopieren (Wichtig: Ab Windows 2000 muss man hierzu den Block mit Widestrings verwenden)
Eine andere Möglichkeit wäre es, den Code der die Umgebungsvariablen setzt in den Zielprozess zu injizieren und dort zu starten, um gezielt die Umgebungsvariablen zu ändern (das habe ich allerdings noch nicht umgesetzt).

Was ich mich allerdings die ganze Zeit über frage:
Wann zieht das Programm eigentlich die Konfiguration?
Erwarten würde ich, dass dieses bei Programmstart, was die Änderung der Konfiguration bei laufendem Programm natürlich unmöglich machen würde ;-)

[Tiemo]

Hallo Christian,

vielen Dank für die Hilfestellung. Das mit dem EnvironmentBlock hatte ich schon mal probiert, bin aber gescheitert. Hast Du dafür vielleicht ein Beispiel? Wie übergebe ich den Env Block an das laufende Programm?

Zum letzten Punkt, ob das Programm die Env Variable beim Start ausliest und dann als lokale Variable speichert oder ob die Umgebungsvariable a la GetEnvironmentString immer dann ausgelesen wird, wenn sie benötigt wird, weiß ich leider nicht. Das Risiko besteht natürlich, dass das Programm die Variable lokal speichert. Dann wäre ich mit dem Ansatz am Ende.

Versuch macht Kluch. Gibt es vielleich ein Programm wie ProcessExplorer, womit ich die Umgebung eines laufenden Prozesses für diesen Test manipulieren kann, bevor ich es wirklich in meinen Code implementieren?

Besten Dank
Tiemo

[Christian Seehase]

Moin Tiemo,

Zitat:

Zitat von Tiemo

Zum letzten Punkt, ob das Programm die Env Variable beim Start ausliest und dann als lokale Variable speichert oder ob die Umgebungsvariable a la GetEnvironmentString immer dann ausgelesen wird, wenn sie benötigt wird, weiß ich leider nicht. Das Risiko besteht natürlich, dass das Programm die Variable lokal speichert. Dann wäre ich mit dem Ansatz am Ende.

Ich sehe da noch ein anderes Problem.
Es könnte auch sein, dass verschiedene Teile des Programmes sich den Wert unterschiedlich beschaffen.
Der eine Teil liest immer den aktuellen Inhalt der Umgebungsvariablen (da könnte man etwas machen) ein andere Teil greift, z.B., auf einen beim Programmstart zwischengespeicherten Wert zu.
Dann kann dann zu unvorhersehbaren Verhaltensweisen des Programmes kommen, da die Konfiguration inkonsistent ist.

Ein kommentiertes Beispiel für die Manipulation des Environmentes kann ich Dir noch liefern.
Ich muss es nur erst noch zusammenstellen ;-)

[Tiemo]

Zitat:

Zitat von Christian Seehase

Ein kommentiertes Beispiel für die Manipulation des Environmentes kann ich Dir noch liefern.
Ich muss es nur erst noch zusammenstellen ;-)

Christian, das wäre echt super.