Umgebungsvariable PATH will nicht gestzt werden

[Muelli 10]

Moin Community,

 

haben von Zeit zu Zeit Probleme bei der Installation einer eigenen Software unter Win2000 die Umgebungsvariable PATH zu editieren.

Unser Programm bringt eigene dll's mit, welche wir nicht ins Systemverzeichnis legen sondern in ein gesondertes bin-Verzeichnis unter unserer Application. Damit er diese findet, editieren wir während der Installationsroutine die Path Variable in der Registry. Bei 99% aller Installationen (sowohl Win98 als auch Win2000 und XP) funzt das auch problemlos und er findet nach einem Neustart alle notwendigen dll's. Nur bei bestimmten Win2000 Umgebungen nimmt er einfach die Änderungen der Path Variablen scheinbar nicht an ohne allerdings eine Fehlermeldung herauszugeben.

 

Hat einer 'ne Ahnung warum?

 

Grüße

Mülli

[macabros 10]

hi,

 

aha registry warum nicht mit set Path=%Path%;c:\eigenerpfad\

 

g

 

MacabroS

[Muelli 10]

wäre wohl 'ne Überlegung wert.

 

z.Zt. nutzen wir für die Installation das Freeware Tool INNO SETUP. Darin wird über den Befehl:

'regquerystringvalue' die path Variable ausgelesen, um erst mal zu sehen, ob hinten ein Semikolon steht oder ergänzt werden muss.

Über 'regwritestringvalue' wird dann der neue string auf die Variable gesetzt.

 

Müssen mal checken, ob man auch reine Command Befehle nutzen kann um dann über set path die Sache zu lösen.

 

Grüße

Mülli

[chs00 10]

Du kannst die auch schon vorher, unter <System - Userenvirement> explizit von Hand eingeben. + 1 * logout/login sowie im cmd prüfen mit: set...

[Finanzamt 73]

Hi!

die Sache mit sem Semikoloncheck könnt Ihr Euch sparen. Setzt eines davor. Sind es dann zwei hintereinander, stört das nicht.

Was ganz anderes ist das mit Eurem Programm: Wenn Ihr Eure DLLs in ein eigenes \Bin - Verzeichnis [sehr löblich bis superhervorragend und sowas wünsch ich mir immer], dann braucht Ihr doch in dem Moment keinen Pfad, wenn Ihr Euch das Verzeichnis der Exe mit GetCurrentDir() in der .EXE selbst holt. Dann bedarf es doch nur noch eines fest verdrahteten Aufrufes nach GlobaleVarMitGetCurrentDir\BIN ... und schon habt Ihr die DLLs.

Gegrüßt und weiter viel Erfolg beim Coden!

[Muelli 10]

Hallo Finanzamt,

 

das ist erst mal 'ne Idee wert.

 

Haben aber in der Zwischenzeit weiter geforscht. Haben den entsprechenden ENVIRONMENT Bereich, der unter anderem die Path Variable enthält, aus der Registry exportiert. Beim Betrachten sahen wir, dass alles in Hexadezimal exportiert wurde. Kurz den Hexeditor zur Hand und alle Zeichen in ASCII übersetzt. Und siehe da, unser neuer Pfad wurde richtig hinzugeschrieben. Doch vor unserem neu angelegten Pfad fanden wir ein 0A 00, was soviel wie eine dezimale 10 bedeutet. Das als ASCII Zeichen ist aber - und nun halt Dich fest - ein LF (line feed). Beim Auslesen der Path Variablen liest er genau bis an die Stelle und bricht beim LF ab. Hexadezimal ist alles zu sehen, im Klartext ist aber für Windows hinter dem LF Schluss und unser neuer Pfad wird nicht eingelesen.

Was macht ein LF bei einer taufrischen Installation an dieser Stelle. Wie gesagt, es ist noch keinerlei andere Software draufgespielt, welche evtl. eigene Pfade setzt.

 

Eine andere Frage ist natürlich nun, wie ich unser Installationsprogramm dazu bringe nach Hex Zeichen zu suchen und ein evtl. vorhandenes LF zu löschen. Als Ausweg bliebe natürlich unseren neuen Pfad an den Anfang der Path Variable zu schreiben und nicht ans Ende.

 

Gruß

Mülli

[Finanzamt 73]

Hallo Muelli,

da stimmt was nicht! Die Registry-Einträge für die Pfade sind in 'HKLM\System\CurrentControlSet\Control\Session Manager\Environment' für AllUsers und in HKCU\Environment für den aktuell angemeldeten User und letzteres entspricht der Position in NTUser.DAT. An diesen Stellen ist es die Variable PATH und der Wertetyp MUSS UNBEDINGT Reg_Expand sein (*). Ich schick mal ein Codeschnipsel Delphi mit, läßt sich ja mit kleineren Änderungen für alles einsetzen, was die Registry-Schnittstelle nutzt:

with registry.Create do begin
 try
   RootKey := HKEY_LOCAL_MACHINE
     if OpenKey('System\CurrentControlSet\Control\Session Manager\Environment', true) then
     begin
        ...
        WriteExpandString('Path',EdPath.Text);   
        // EdPath ist ein EditFeld, 
        // EdPath.Text halt der dort eingetragene Text
        // und es kann natürlich auch eine StringVar sein
      end
 finally
   free;
 end;
end;

(*) Reg_Expand und Reg_Sz sind zwar beides Char-Variable, Reg_Expand bewirkt aber die "expansion" via EnvVar angegebener Werte. Da im Pfad per default %SystemRoot%\%System32%;%SystemRoot% ... angegeben ist, würde ein (Über-)Schreiben mit Reg_SZ mächtig Probleme verursachen.

Ich vermute, Ihr schreibt mit dem falschen Typ, die PfadVar ist schon mit falschem Typ eingetragen oder Ihr selbst hängt CR/LF an die ausgelesene Pfad-Var, bevor Eure Pfaderweiterung hinzu kommt. Falls Ihr mit Delphi programmiert und ein funktionierendes Muster gebrauchen könnt: Schick eine PN mit Eurer EMail.

Gegrüßt!

[Sexbomb 10]

Es gibt ein Tool in Resourcekit. Nennt sich setx. Mit dem kann man Umgebungsvariablen aktualisieren. Am besten PATH auslesen, Sting manipuliern und anschließen wieder über setx einpflegen.

[Muelli 10]

Hallo Finanzamt,

 

leider ist das 'LF' aber schon vor unserer Installation vorhanden. Habe extra das System komplett platt gemacht und ein neues Win2K aufgespielt. Dann noch alle aktuellen Patches von MS drüber. Von diesem Zustand haben wir ein Image gezogen, welches jetzt immer unsere Grundlage für diese Tests ist. Von diesem "sauberen" Zustand haben wir dann den entsprechenden Registry-Abschnitt exportiert und das 'LF' am Ende der Path Variablen gefunden.

Haben allerdings lange gesucht, bevor wir endlich ein Sytem hatten, welches genau diesen Fehler erzeugt, welcher nur von einem ganz geringen Teil unserer Kunden berichtet wird. Es kann also nicht daran liegen, wie wir die Variable falsch schreiben. Es muss eher ein Bug in bestimmten Win2K Chargen sein. Wie gesagt, auf der großen Mehrzahl von Systemen läuft die Installation ja glatt.

Gruß

Mülli

[Finanzamt 73]

Hallo,

tut mir leid, da habe ich ein genau so großes Fragezeichen wie Du.

Bzgl. der Einstellungen zu Eurem Programm habe ich noch einen Hinweis: Üblich ist, entweder in HKLM oder in HKCU den Schlüssel "Software" zu nutzen. Da werden hierarchisch weiterere Schlüssel mit den Namen "UnsererFirma" - "UnsererSoftware" und "Versionsnummer" angelegt. In den letzteren packt Ihr dann alle benötigten Daten und Pfade hinein.

Zu berücksichtigen ist, daß der Eintrag unter HKLM die Installation auf i.d.R. Admins begrenzt und es nicht erlaubt, daß z.B. userspezifische Einstellungen (Fensterposition, Farben, letztes bearbeitetes File...) gespeichert werden. Andererseits verlangte die Beschränkung auf HKCU, daß jeder User an dem Computer die Installation durchführt. Die Kombination aus beidem erlaubte, nach einer Admininstallation (HKLM) eine automatische (und vom User unbemerkte) Nachinstallation beim ersten Aufruf des Programmes durch einen User. Aber auch das hat dann seine Tücken, wenn User mit mandantory Profiles eingerichtet sind. Hier würde die Nachinstallation nach jeder Anmeldung wiederholt.

Aber diese Probleme habt Ihr ja auch, wenn Ihr bestimmte Einstellungen in einer .INI oder vergleichbaren Datei speichert. Nur: Es wird ja irgendwo passieren ... und dann ist es schon sinnvoll, die Registry zu nutzen und vor allem Pfade und so etwas auch an der Stelle unterzubringen. Das ist vielleicht noch ein Tag Programmieraufwand, aber dann sollte wirklich Ruhe im Karton sein.

Gegrüßt!

[Muelli 10]

Hallo Finanzamt,

 

haben die Sache jetzt erst mal gelöst. Das Installationsprogramm liest die Variable hexadezimal aus, sucht nach einem möglichen '0A' am Ende, löscht es, fügt den eigenen neuen Pfad hinzu und schreibt die Path Variable dann neu.

Nun funzt die Installation und das Programm.

 

Soweit erst mal, Dank für Deine und Eure Tipps

 

Grüße

Mülli