Systemvariable setzen/übergeben an Programmaufruf in Startmenü
Uwe Premer
Eine Frage an die Spezialisten.
Ich möchte (per Adminrechte) ein Eintrag im Windows-Startmenü (W7
64-Bit) wie folgt gestalten:
unter Eigenschaften soll
in Ziel: set %home%= |"C:\Program Files (x86)\XPN\xpn.exe" --home_dir
stehen.
Kurze Erläuterung dazu:
es soll die Variable $home gelöscht werden bzw. auf den Default gesetzt
werden und mit dem Programmaufruf des Newsreaders XPN (mit einer
Startoption) per Piping erfolgen.
Leider mosert Win 7, wenn ich das da oben so abspeichern will, dass das
Set im Programmaufruf flscha sei.
Welche Möglichkeiten hätte ich denn, das so simpel wie möglich zu
machen, wobei unbedingt die xpn.exe beibehalten werden soll und eben
nicht eine .bat dafür verwendet werden soll?
Uwe
Claus Reibenstein
> Tach.
> Eine Frage an die Spezialisten.
> Ich möchte (per Adminrechte) ein Eintrag im Windows-Startmenü (W7
> 64-Bit) wie folgt gestalten:
> unter Eigenschaften soll
> in Ziel: set %home%= |"C:\Program Files (x86)\XPN\xpn.exe" --home_dir
> stehen.
> Kurze Erläuterung dazu:
> es soll die Variable $home gelöscht werden bzw. auf den Default gesetzt
> werden und mit dem Programmaufruf des Newsreaders XPN (mit einer
> Startoption) per Piping erfolgen.
>
> Leider mosert Win 7, wenn ich das da oben so abspeichern will, dass das
> Set im Programmaufruf flscha sei.
Was höchstwahrscheinlich daran liegen dürfte, dass "set" ein internes
Kommando der cmd.exe ist.
Außerdem verwendest Du die Pipeline nicht richtig. Die nutzt Dir an
dieser Stelle sowieso nichts, denn Du möchtest ja nicht set und xpn
gleichzeitig starten und die Ausgabe des set-Kommandos von xpn
weiterverarbeiten lassen, sondern erst per set die Umgebung verändern
und dann xpn starten.
> Welche Möglichkeiten hätte ich denn, das so simpel wie möglich zu
> machen, wobei unbedingt die xpn.exe beibehalten werden soll und eben
> nicht eine .bat dafür verwendet werden soll?
Auch wenn Dir die Antwort nicht gefällt: Gar nicht. Um mehrere Befehle
hintereinander auszuführen, ist .bat (oder .cmd) das Mittel der Wahl,
denn genau dafür sind sie da.
Was ist denn so schlimm an Batchfiles, dass Du die nicht verwenden möchtest?
Gruß. Claus
Wolfgang Bauer
> Tach.
> Kurze Erläuterung dazu:
> es soll die Variable $home gelöscht werden bzw. auf den Default gesetzt
> werden und mit dem Programmaufruf des Newsreaders XPN (mit einer
> Startoption) per Piping erfolgen.
Welchen Wert hat denn die Variable home vor der angestrebten Aktion und
welcher Wert ist default? Brauch XPN überhaupt einen Eintrag in $home?
Mit freundlichen Grüßen
Wolfgang Bauer
--
Das 40tude Dialog Skript - Archiv! http://kh-rademacher.de/4d/
Die 40tude-Dialog FAQ http://www.wolfgang-bauer.at/4td_faq/
Tabby ist abgängig http://www.wolfgang-bauer.at/katze/katze2.png
Hans-Peter Matthess
> Was ist denn so schlimm an Batchfiles, dass Du die nicht verwenden möchtest?
Na, ich kenne Leute, die UAC abschalten, um ihre Batchfiles zum Laufen
zu bekommen.
SCNR, hpm
Uwe Premer
> Uwe Premer schrieb:
>
>> Tach.
>> Kurze Erläuterung dazu:
>> es soll die Variable $home gelöscht werden bzw. auf den Default gesetzt
>> werden und mit dem Programmaufruf des Newsreaders XPN (mit einer
>> Startoption) per Piping erfolgen.
>
> Welchen Wert hat denn die Variable home vor der angestrebten Aktion und
> welcher Wert ist default? Brauch XPN überhaupt einen Eintrag in $home?
Richtig erkannt, Wolfgang.
Ich habe wegen Gnus die $home so gesetzt, und zwar systemweit:
| C:>set home
| home=C:\Users\[$Username]\AppData\Roaming\Gnus
Das Problem damit war natürlich, dass der Datenordner ".xpn" in jenem
obigen Gnus-Ordner landete und ich mir einen Wolf gesucht habe, wo der
Ordner hingegangen wäre.
Der Default, also wenn die Variable $home leer ist, wäre
C:\Users\[$Username]
Und genau darunter *muß* auch ".xpn" hin, wenn alles richtig sein sein soll.
Uwe
Uwe Premer
> Uwe Premer schrieb:
>> machen, wobei unbedingt die xpn.exe beibehalten werden soll und eben
>> nicht eine .bat dafür verwendet werden soll?
>
> Auch wenn Dir die Antwort nicht gefällt: Gar nicht. Um mehrere Befehle
> hintereinander auszuführen, ist .bat (oder .cmd) das Mittel der Wahl,
> denn genau dafür sind sie da.
>
> Was ist denn so schlimm an Batchfiles, dass Du die nicht verwenden möchtest?
Im Grunde nix.
Und in der Tat hatte ich gestern bereits ein passendes Batch angelegt,
ausserdem hab ich mir ein XPN.ico für den Eintrag im Startmenü gebastelt,
so dass ich jetzt auch als User einfach nur folgenden Eintrag im Startmenü
zu starten brauche:
"XPN --home_dir"
mit Ziel "C:\Program Files (x86)\XPN\xpn.bat",
klappt auch einwandfrei.
Achja, die Batchdatei sieht so aus:
| @echo off
| REM xpn.bat
| REM XPN so starten, dass die Konfiguration im User-Ordner angelegt und
| REM verwendet wird.
| REM
| REM Home-Directory-Variable auf den Default setzen
| REM
| set home=
| REM
| REM XPN so starten, dass Ordner %Userverzeichnis%\.xpn benutzt wird
| REM
| xpn.exe --home_dir
Uwe
Uwe Premer
Claus Reibenstein schrieb am 28.05.2011 11:02 Uhr:
> Uwe Premer schrieb:
>> Welche Möglichkeiten hätte ich denn, das so simpel wie möglich zu
>> machen, wobei unbedingt die xpn.exe beibehalten werden soll und eben
>> nicht eine .bat dafür verwendet werden soll?
>
> Auch wenn Dir die Antwort nicht gefällt: Gar nicht. Um mehrere Befehle
> hintereinander auszuführen, ist .bat (oder .cmd) das Mittel der Wahl,
> denn genau dafür sind sie da.
>
> Was ist denn so schlimm an Batchfiles, dass Du die nicht verwenden möchtest?
Was mich daran stört, ist, dass dabei cmd geladen wird und mitläuft.
Geht das auch irgendwie "unsichtbar"?
Hans-Peter Matthess
> Was mich daran stört, ist, dass dabei cmd geladen wird und mitläuft.
Was sich bei einem CMD-Skript ja auch kaum vermeiden lässt. ;-)
> Geht das auch irgendwie "unsichtbar"?
set WSHShell = CreateObject("WScript.Shell")
WSHShell.Run "X:\blah.cmd", 0, vbTrue
sollte völlig unsichtbar ablaufen.
hpm
Wolfgang Bauer
> Wolfgang Bauer schrieb am 28.05.2011 11:54 Uhr:
>> Welchen Wert hat denn die Variable home vor der angestrebten Aktion und
>> welcher Wert ist default? Brauch XPN überhaupt einen Eintrag in $home?
>
> Richtig erkannt, Wolfgang.
> Ich habe wegen Gnus die $home so gesetzt, und zwar systemweit:
>
> | C:>set home
> | home=C:\Users\[$Username]\AppData\Roaming\Gnus
Bei mir ist die Variable $home auf den Wert D:\Home\wolfgang gesetzt.
> Das Problem damit war natürlich, dass der Datenordner ".xpn" in jenem
> obigen Gnus-Ordner landete und ich mir einen Wolf gesucht habe, wo der
> Ordner hingegangen wäre.
> Der Default, also wenn die Variable $home leer ist, wäre
> C:\Users\[$Username]
> Und genau darunter *muß* auch ".xpn" hin, wenn alles richtig sein sein soll.
Weiter kann ich Dir aber nicht folgen. Ich habe XPN hier in Win7/64 mit
xpn_setup.exe installiert und da wird nicht gefragt wo die Daten
gespeichert werden sollen.
Mit freundlichen Grüßen
Wolfgang Bauer
--
Die 40tude-Dialog FAQ http://www.wolfgang-bauer.at/4td_faq/
Raady's 40tude-Dialog - Archiv! http://kh-rademacher.de/4d/
http://www.wolfgang-bauer.at
Gerhard Austaller
Uwe Premer schrieb:
Versuch START xpn.exe --home_dir , was das Programm startet und dann in
die Batchdatei weiterabarbeitet und evtl. gefolgt von exit, wenn das
Batch-Datei-Fenster offen bleibt.
VG
Gerhard
Gerhard Austaller
Uwe Premer schrieb:
> Tach.
> Eine Frage an die Spezialisten.
> Ich möchte (per Adminrechte) ein Eintrag im Windows-Startmenü (W7
> 64-Bit) wie folgt gestalten:
> unter Eigenschaften soll
> in Ziel: set %home%= |"C:\Program Files (x86)\XPN\xpn.exe" --home_dir
> stehen.
Ich würde sowas probieren:
cmd.exe /c "set %home%= & "C:\Program Files (x86)\XPN\xpn.exe" --home_dir"
VG
Gerhard
Uwe Premer
> Uwe Premer wrote: schrieb:
>> Wolfgang Bauer schrieb am 28.05.2011 11:54 Uhr:
>
>>> Welchen Wert hat denn die Variable home vor der angestrebten Aktion und
>>> welcher Wert ist default? Brauch XPN überhaupt einen Eintrag in $home?
>>
>> Richtig erkannt, Wolfgang.
>> Ich habe wegen Gnus die $home so gesetzt, und zwar systemweit:
>>
>> | C:>set home
>> | home=C:\Users\[$Username]\AppData\Roaming\Gnus
>
> Bei mir ist die Variable $home auf den Wert D:\Home\wolfgang gesetzt.
Das ist dann der Default.
>> Das Problem damit war natürlich, dass der Datenordner ".xpn" in jenem
>> obigen Gnus-Ordner landete und ich mir einen Wolf gesucht habe, wo der
>> Ordner hingegangen wäre.
>
>> Der Default, also wenn die Variable $home leer ist, wäre
>> C:\Users\[$Username]
>> Und genau darunter *muß* auch ".xpn" hin, wenn alles richtig sein sein soll.
>
> Weiter kann ich Dir aber nicht folgen. Ich habe XPN hier in Win7/64 mit
> xpn_setup.exe installiert und da wird nicht gefragt wo die Daten
> gespeichert werden sollen.
Bei der Installation selbst wird ja auch noch kein persönlicher Ordner
angelegt.
Erst, wenn du XPN startest und nach dem ersten Start bei der Abfrage Daten
eingegeben hast, wird ein persönlicher Ordner angelegt.
Und, wenn du XPN ohne Optionen gestartet hast, wird mittels UAC der
persönliche Ordner in
C:\Users\[$Username]\AppData\Local\VirtualStore\Program Files (x86)\XPN
angelegt, was zwar durchaus funktioniert, aber leider nicht exakt den
eigentlichen Konventionen entspricht.
Besser und richtiger wäre der persönliche Ordner in
C:\Users\[$Username]\.xpn
aufgehoben, und das geht halt nur mit der Startoption XPN --home_dir.
XPN hat nämlich in der Hinsicht einen leichten Bug bzgl. des Speicherorts
des persönlichen Ordners.
Uwe
Wolfgang Bauer
> Bei der Installation selbst wird ja auch noch kein persönlicher Ordner
> angelegt.
> Erst, wenn du XPN startest und nach dem ersten Start bei der Abfrage Daten
> eingegeben hast, wird ein persönlicher Ordner angelegt.
Ich habe XPN neu installiert und konfiguriert.
> Und, wenn du XPN ohne Optionen gestartet hast, wird mittels UAC der
> persönliche Ordner in
> C:\Users\[$Username]\AppData\Local\VirtualStore\Program Files (x86)\XPN
> angelegt, ...
Trotzdem gibt es solchen Ordner hier nicht.
C:\Users\wolfgang\AppData\Local\VirtualStore\ProgramData
Mehr nicht.
> Besser und richtiger wäre der persönliche Ordner in
> C:\Users\[$Username]\.xpn
> aufgehoben, und das geht halt nur mit der Startoption XPN --home_dir.
Probiere ich dann mal.
Uwe Premer
> Hallo
Hallo Gerhard,
Wenn ich das in die Windows 7-Startmenüsuche einpaste oder in einem
vorhandenen cmd-Fenster so starte, erscheint diese Fehlermeldung:
| Das Programm kann nicht gestartet werden, da libglib-2.0-0.dll auf dem
| Computer fehlt. Installieren Sie das Programm erneut, um das Problem
| zu beheben.
Ich nehme an, dass da dann der Pfad zum Programmordner irgendwie nicht
gefunden wird.
Uwe
Uwe Premer
> Uwe Premer schrieb:
>
>> Bei der Installation selbst wird ja auch noch kein persönlicher Ordner
>> angelegt.
>> Erst, wenn du XPN startest und nach dem ersten Start bei der Abfrage Daten
>> eingegeben hast, wird ein persönlicher Ordner angelegt.
>
> Ich habe XPN neu installiert und konfiguriert.
Ich hab einfach die Daten aus "VirtualStore" ins richtige Verzeichnis
kopiert und starte XPN mit "--home_dir".
>> Und, wenn du XPN ohne Optionen gestartet hast, wird mittels UAC der
>> persönliche Ordner in
>> C:\Users\[$Username]\AppData\Local\VirtualStore\Program Files (x86)\XPN
>> angelegt, ...
>
> Trotzdem gibt es solchen Ordner hier nicht.
> C:\Users\wolfgang\AppData\Local\VirtualStore\ProgramData
> Mehr nicht.
VirtualStore. Also hat hier bereits UAC zugeschlagen.
Uwe
Uwe Premer
> Hallo
Hallo Gerhard,
> Uwe Premer schrieb:
>> Achja, die Batchdatei sieht so aus:
[...]
>> | xpn.exe --home_dir
>
> Versuch START xpn.exe --home_dir , was das Programm startet und dann in
> die Batchdatei weiterabarbeitet und evtl. gefolgt von exit, wenn das
> Batch-Datei-Fenster offen bleibt.
Danke, hab ich gemacht (auch mit exit), das funktioniert: das
cmd-Fenster ist dann weg und XPN läuft weiter.
Super!
Uwe
Hans-Peter Matthess
> Und, wenn du XPN ohne Optionen gestartet hast, wird mittels UAC der
> persönliche Ordner in
> C:\Users\[$Username]\AppData\Local\VirtualStore\Program Files (x86)\XPN
> angelegt, was zwar durchaus funktioniert, aber leider nicht exakt den
> eigentlichen Konventionen entspricht.
Und was darauf zurückzuführen ist, dass XPN offensichtlich diesen Ordner
in "ProgramFiles" anlegen will, was darauf zurückzuführen ist, dass der
Entwickler wohl wat anner Waffel hat. <eg>
hpm
Stefan Kanthak
> [Supersedes]
> Und in der Tat hatte ich gestern bereits ein passendes Batch angelegt,
> ausserdem hab ich mir ein XPN.ico für den Eintrag im Startmenü gebastelt,
> so dass ich jetzt auch als User einfach nur folgenden Eintrag im Startmenü
> zu starten brauche:
> "XPN --home_dir"
> mit Ziel "C:\Program Files (x86)\XPN\xpn.bat",
Statt "C:\Program Files (x86)" solltest Du IMMER "%ProgramFiles(x86)%"
schreiben.
Und CMD.EXE steht MIT vollstaendigem Pfadnamen in %COMSPEC%.
> klappt auch einwandfrei.
>
> Achja, die Batchdatei sieht so aus:
>
> | @echo off
> | REM xpn.bat
> | REM XPN so starten, dass die Konfiguration im User-Ordner angelegt und
> | REM verwendet wird.
> | REM
> | REM Home-Directory-Variable auf den Default setzen
> | REM
> | set home=
Falsch. Du loeschst die Variable HOME!
Wenn Du sie auf den Standardwert setzen willst:
Set HOME=%HomeDrive%%HomePath%
> | REM
> | REM XPN so starten, dass Ordner %Userverzeichnis%\.xpn benutzt wird
> | REM
> | xpn.exe --home_dir
Hier solltest Du ".\xpn.exe", "%CD%\xpn.exe" oder "%~dp0xpn.exe"
verwenden. Oder hast Du noch nie etwas von "binary planting" gehoert?
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Stefan Kanthak
> Uwe Premer:
>
>> Was mich daran stört, ist, dass dabei cmd geladen wird und mitläuft.
>
> Was sich bei einem CMD-Skript ja auch kaum vermeiden lässt. ;-)
>
>> Geht das auch irgendwie "unsichtbar"?
>
> set WSHShell = CreateObject("WScript.Shell")
> WSHShell.Run "X:\blah.cmd", 0, vbTrue
Igitt˛, wie umstaendlich!
WScript.CreateObject("WScript.Shell").Run "X:\blah.cmd", 0, vbTrue
> sollte völlig unsichtbar ablaufen.
Igittł, wie umstaendlich!
Ein *.LNK startet ein *.VBS das ein *.CMD aufruft!
Geht's ueber NOCH mehr Ecken?
--- .VBS ---
Option Explicit
With WScript.CreateObject("WScript.Shell")
Dim strHOME
strHOME = .Environment("USER").Item("HOME")
.Environment("USER").Item("HOME") = ""
.Run """" & .Environment("SYSTEM").Item("ProgramFiles(x86)") & "\XPN\xpn.exe"" --home_dir", 1, vbFalse
.Environment("USER").Item("HOME") = strHOME
End With
--- EOF ---
Einziger "Nachteil": die kurzzeitige Aenderung von HOME ist nicht auf
das VBSkript beschraenkt, sondern wird anderen Programmen per WM_MESSAGE
mitgeteilt.
ABER: kaum ein Programm (ausser dem Explorer) reagiert darauf!
Hans-Peter Matthess
> Igittł, wie umstaendlich!
> Ein *.LNK startet ein *.VBS das ein *.CMD aufruft!
> Geht's ueber NOCH mehr Ecken?
Haja, die Dummy-Variante für Leute wie mich.
> --- .VBS ---
> Option Explicit
>
> With WScript.CreateObject("WScript.Shell")
> Dim strHOME
> strHOME = .Environment("USER").Item("HOME")
> .Environment("USER").Item("HOME") = ""
> .Run """" & .Environment("SYSTEM").Item("ProgramFiles(x86)") & "\XPN\xpn.exe"" --home_dir", 1, vbFalse
>
> .Environment("USER").Item("HOME") = strHOME
> End With
> --- EOF ---
Schön, ich fürchte nur, er wird das nicht zu würdigen wissen.
hpm
Wolfgang Bauer
> Besser und richtiger wäre der persönliche Ordner in
> C:\Users\[$Username]\.xpn
> aufgehoben, und das geht halt nur mit der Startoption XPN --home_dir.
Der Ordner .xpn wird nun bei mir in D:\home\wolfgang angelegt was hier
$home ist.
Stefan Kanthak
Jein*. Aber zuerst: AUTSCH!
Wer hat diesen SONDERMUELL von Programm verbrochen!
* 1. Wenn Du im Explorer eine Datei per Doppelklick "oeffnest", dann
setzt der Explorer das "current working directory" (cwd) auf den
Ordner, in dem sich die Datei befindet.
CMD.EXE dagegen macht das nicht!
2. DOS [R.I.P.] und auch Windows hatten bis 2003/2004 'cwd' alias
"." IMMER als erstes (implizites) Verzeichnis im Suchpfad.
Windows hat seit 2003/2004 "." weiter hinten im Suchpfad; als
erstes (implizites) Verzeichnis steht seither das Anwendungs-
verzeichnis drin, in Deinem Fall als "%ProgramFiles(x86)\XPN".
Siehe <http://support.microsoft.com/kb/306850/en-us> und
<http://support.microsoft.com/kb/959426/en-us> sowie
<http://support.microsoft.com/kb/905890/en-us>, vor allem aber
<http://support.microsoft.com/kb/2264107/en-us>
3. Windows 95 und spaeter kennen anwendungsspezifische Pfade;
siehe <http://msdn.microsoft.com/en-us/library/ee872121.aspx>
Trage Dein Programm folgendermassen in der Registry ein:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\XPN.EXE]
@="%ProgramFiles(x86)\XPN\XPN.EXE"
"Path"="...;..."
Anschliessend kannst Du XPN.EXE unter Start->Ausfuehren (oder in
Verknuepfungen) einfach per "XPN" oder "XPN.EXE" starten, und in
der Eingabeaufforderung per "Start XPN" oder "Start XPN.EXE".
Dabei wird der unter "Path"= eingetragene Wert (durch ein ';'
getrennt) im Environment des gestarteten Programms vor den PATH
gesetzt.
JFTR: <http://support.microsoft.com/kb/888470/en-us> und
<http://support.microsoft.com/kb/891398/en-us> zeigen,
welche Schweinereien damit moeglich sind.-P
Uwe Premer
> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>
>> Gerhard Austaller schrieb am 28.05.2011 15:41 Uhr:
>
>>> cmd.exe /c "set %home%= & "C:\Program Files (x86)\XPN\xpn.exe" --home_dir"
>>
>> Wenn ich das in die Windows 7-Startmenüsuche einpaste oder in einem
>> vorhandenen cmd-Fenster so starte, erscheint diese Fehlermeldung:
>>
>> | Das Programm kann nicht gestartet werden, da libglib-2.0-0.dll auf dem
>> | Computer fehlt. Installieren Sie das Programm erneut, um das Problem
>> | zu beheben.
>>
>> Ich nehme an, dass da dann der Pfad zum Programmordner irgendwie nicht
>> gefunden wird.
>
> 3. Windows 95 und spaeter kennen anwendungsspezifische Pfade;
> siehe <http://msdn.microsoft.com/en-us/library/ee872121.aspx>
>
> Trage Dein Programm folgendermassen in der Registry ein:
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\XPN.EXE]
> @="%ProgramFiles(x86)\XPN\XPN.EXE"
Fe lt da nicht noch ein "%"?
Des weiteren:
wenn ich mir andere Programmeinträge an der Stelle in der Registry so
anschaue, sehen die aber anders aus. Beispiel Thunderbird:
Name Standard, Wert C:\Program Files (x86)\Lanikai
(64-bit)\thunderbird.exe
Path Wert C:\Program Files (x86)\Lanikai (64-bit)
Einer der Einträge, die deinem Vorschlag entgegenkommen, wäre der von
wmplayer.exe:
(Standard) Wert %ProgramFiles(x86)%\Windows Media Player\wmplayer.exe
Path %ProgramFiles(x86)%\Windows Media Player
Gut, ich versuchs dann mal analog zu letzterem Eintrag.
> "Path"="...;..."
Was genau muß da rein?
Path=%ProgramFiles(x86)%\XPN;? Oder noch was dahinter?
> Anschliessend kannst Du XPN.EXE unter Start->Ausfuehren (oder in
> Verknuepfungen) einfach per "XPN" oder "XPN.EXE" starten, und in
> der Eingabeaufforderung per "Start XPN" oder "Start XPN.EXE".
Das löst dann aber nicht das eigentliche Problem, nämlich den Bug, das
xpn.exe nicht das korrekte Homeverzeichnis einträgt/nutzt.
> Dabei wird der unter "Path"= eingetragene Wert (durch ein ';'
> getrennt) im Environment des gestarteten Programms vor den PATH
> gesetzt.
Ich hab das erstmal so in die Registry eingetragen wie oben.
Uwe
Uwe Premer
> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>
>> [Supersedes]
>
>> Und in der Tat hatte ich gestern bereits ein passendes Batch angelegt,
>> ausserdem hab ich mir ein XPN.ico für den Eintrag im Startmenü gebastelt,
>> so dass ich jetzt auch als User einfach nur folgenden Eintrag im Startmenü
>> zu starten brauche:
>> "XPN --home_dir"
>> mit Ziel "C:\Program Files (x86)\XPN\xpn.bat",
>
> Statt "C:\Program Files (x86)" solltest Du IMMER "%ProgramFiles(x86)%"
> schreiben.
done.
>> klappt auch einwandfrei.
>>
>> Achja, die Batchdatei sieht so aus:
>>
>> | @echo off
>> | REM xpn.bat
>> | REM XPN so starten, dass die Konfiguration im User-Ordner angelegt und
>> | REM verwendet wird.
>> | REM
>> | REM Home-Directory-Variable auf den Default setzen
>> | REM
>> | set home=
>
> Falsch. Du loeschst die Variable HOME!
Und genau das funktioniert aber im Fall von XPN.
Kann also als Lösung durchgehen. Imho
> Wenn Du sie auf den Standardwert setzen willst:
>
> Set HOME=%HomeDrive%%HomePath%
Das hab ich jetzt erstmal nicht geändert.
>> | REM
>> | REM XPN so starten, dass Ordner %Userverzeichnis%\.xpn benutzt wird
>> | REM
>> | xpn.exe --home_dir
>
> Hier solltest Du ".\xpn.exe", "%CD%\xpn.exe" oder "%~dp0xpn.exe"
> verwenden. Oder hast Du noch nie etwas von "binary planting" gehoert?
Ähm, aufgrund des anderen Tipps im anderen Posting steht jetzt
START xpn.exe --home_dir
exit
Ist das auch akzeptabel oder sollte ich besser
START .\xpn.exe --home_dir
exit
reintun?
Danke auch für die Tipps übrigens. ;-)
Uwe
Uwe Premer
"Hatte", hpm.
Er hat mir erzählt, dass er XPN nicht mehr weiterentwickelt.
Uwe
Stefan Kanthak
[...]
>> Hier solltest Du ".\xpn.exe", "%CD%\xpn.exe" oder "%~dp0xpn.exe"
>> verwenden. Oder hast Du noch nie etwas von "binary planting" gehoert?
>
> Ähm, aufgrund des anderen Tipps im anderen Posting steht jetzt
>
> START xpn.exe --home_dir
Alles Anfaenger, die gerne Sicherheitsluecken einbauen! ARGH!
START ruft ShellExecuteEx() auf, und das sucht unter
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\XPN.EXE],
dann im PATH.
Es kann also ein ganz anderes xpn.exe gestartet werden!
Du solltest die Links lesen, die ich poste (vor allem, wenn
ich noch schreibe, dass "Schweinereien" moeglich sind).
> exit
>
> Ist das auch akzeptabel oder sollte ich besser
>
> START .\xpn.exe --home_dir
> exit
>
> reintun?
Das solltest Du jetzt selbst entscheiden koennen.
> Danke auch für die Tipps übrigens. ;-)
Bitte. Es gibt schon genuegend Software und Skripte mit nicht
wohldefiniertem Verhalten, aus dem dann Sicherheitsluecken entstehen.
S.o.
Das ist vermeidbar.
Stefan Kanthak
> Stefan Kanthak schrieb:
>> 3. Windows 95 und spaeter kennen anwendungsspezifische Pfade;
>> siehe <http://msdn.microsoft.com/en-us/library/ee872121.aspx>
>>
>> Trage Dein Programm folgendermassen in der Registry ein:
>>
>> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\XPN.EXE]
>> @="%ProgramFiles(x86)\XPN\XPN.EXE"
>
> Fe lt da nicht noch ein "%"?
Ja. Genau wie das 'h'.-P
> Des weiteren:
> wenn ich mir andere Programmeinträge an der Stelle in der Registry so
> anschaue, sehen die aber anders aus. Beispiel Thunderbird:
>
> Name Standard, Wert C:\Program Files (x86)\Lanikai
> (64-bit)\thunderbird.exe
>
> Path Wert C:\Program Files (x86)\Lanikai (64-bit)
Ich setze beim Leser SOVIEL Transferleistung voraus, entweder die
Umgebungsvariablen selbst zu erweitern, oder den Datentyp REG_EXPAND_SZ
zu verwenden!
> Einer der Einträge, die deinem Vorschlag entgegenkommen, wäre der von
> wmplayer.exe:
>
> (Standard) Wert %ProgramFiles(x86)%\Windows Media Player\wmplayer.exe
> Path %ProgramFiles(x86)%\Windows Media Player
Wobei der "Path="..." (nicht nur) hier eigentlich ueberfluessig ist.
> Gut, ich versuchs dann mal analog zu letzterem Eintrag.
>
>> "Path"="...;..."
>
> Was genau muß da rein?
> Path=%ProgramFiles(x86)%\XPN;? Oder noch was dahinter?
Genau dieser Wert, aber OHNE das ';'. Mit einem ';' am Ende baust Du
nur eine potentielle Sicherheitsluecke ein: ";;" im Pfad bedeutet
soviel wie ";.;", also 'cwd', und das will man nicht!
>> Anschliessend kannst Du XPN.EXE unter Start->Ausfuehren (oder in
>> Verknuepfungen) einfach per "XPN" oder "XPN.EXE" starten, und in
>> der Eingabeaufforderung per "Start XPN" oder "Start XPN.EXE".
>
> Das löst dann aber nicht das eigentliche Problem, nämlich den Bug, das
> xpn.exe nicht das korrekte Homeverzeichnis einträgt/nutzt.
ARGH! Ich erklaere Dir gerade, was diese Eintraege machen.
Damit, nur falls Du auf die Idee kommen solltest, Deine XPN.bat zu
nehmen und dann "das geht nicht zu meckern" ich Dir sagen kann: lies,
was ich geschrieben habe.-P
>> Dabei wird der unter "Path"= eingetragene Wert (durch ein ';'
>> getrennt) im Environment des gestarteten Programms vor den PATH
>> gesetzt.
>
> Ich hab das erstmal so in die Registry eingetragen wie oben.
Ist der Fehler damit verschwunden?
In jedem Fall ist dieses XPN schrottig!
Uwe Premer
> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>> exit
>>
>> Ist das auch akzeptabel oder sollte ich besser
>>
>> START .\xpn.exe --home_dir
>> exit
>>
>> reintun?
>
> Das solltest Du jetzt selbst entscheiden koennen.
Noch eine Frage:
als ich das mit dem "START" in der xpn.bat drin hatte, wurde das
cmd-Fenster wie gewünscht geschlossen beim Aufruf von XPN.
Nun aber bleibt mit ".\xpn..." das cmd-Fenster geöffnet, allerdings
befindet sich noch das "exit" in der Folgezeile.
Wie kann ich das machen, dass auch mit .\xpn das cmd-Fenster geschlossen
wird?
Uwe
Uwe Premer
> Ich setze beim Leser SOVIEL Transferleistung voraus, entweder die
> Umgebungsvariablen selbst zu erweitern, oder den Datentyp REG_EXPAND_SZ
> zu verwenden!
Hier habe ich noch ein anderes Problem:
wenn ich, wie ich das nach deinem Rat gemacht habe, einen neuen Schlüssel
"xpn.exe" anlege, wird dort sofort ein REG_SZ angelegt, welches ich nicht
löschen kann, auch nicht, wenn ich ein solches REG_EXPAND_SZ anlege.
Wie lösche ich also das REG_SZ bzw. wie lege ich den Schlüssel ohne das an?
>> Gut, ich versuchs dann mal analog zu letzterem Eintrag.
>>
>>> "Path"="...;..."
>>
>> Was genau muß da rein?
>> Path=%ProgramFiles(x86)%\XPN;? Oder noch was dahinter?
>
> Genau dieser Wert, aber OHNE das ';'. Mit einem ';' am Ende baust Du
> nur eine potentielle Sicherheitsluecke ein: ";;" im Pfad bedeutet
> soviel wie ";.;", also 'cwd', und das will man nicht!
Ist jetzt entfernt.
>>> Dabei wird der unter "Path"= eingetragene Wert (durch ein ';'
>>> getrennt) im Environment des gestarteten Programms vor den PATH
>>> gesetzt.
>>
>> Ich hab das erstmal so in die Registry eingetragen wie oben.
>
> Ist der Fehler damit verschwunden?
Meinst du den Fehler:
| Das Programm kann nicht gestartet werden, da libglib-2.0-0.dll auf dem
| Computer fehlt. Installieren Sie das Programm erneut, um das Problem
| zu beheben.
beim Aufruf von
cmd.exe /c "set %home%= & "C:\Program Files (x86)\XPN\xpn.exe" --home_dir"
Ja, der Fehler ist immer noch da.
Uwe
Stefan Kanthak
> Stefan Kanthak schrieb:
>
>> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>>> exit
>>>
>>> Ist das auch akzeptabel oder sollte ich besser
>>>
>>> START .\xpn.exe --home_dir
>>> exit
>>>
>>> reintun?
>>
>> Das solltest Du jetzt selbst entscheiden koennen.
>
> Noch eine Frage:
OK, also doch nicht.-(
> als ich das mit dem "START" in der xpn.bat drin hatte, wurde das
> cmd-Fenster wie gewünscht geschlossen beim Aufruf von XPN.
>
> Nun aber bleibt mit ".\xpn..." das cmd-Fenster geöffnet,
Wieso willst Du "START .\xpn.exe --home_dir" nicht verwenden?
> allerdings befindet sich noch das "exit" in der Folgezeile.
> Wie kann ich das machen, dass auch mit .\xpn das cmd-Fenster geschlossen
> wird?
S.o.
Oder dieses ganze Gewuerge mit .BAT plus Registry-Eintraegen durch das
bereits gepostete VBScript ersetzen.
Stefan Kanthak
> Stefan Kanthak schrieb:
>
>> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>>> | set home=
>>
>> Falsch. Du loeschst die Variable HOME!
>
> Und genau das funktioniert aber im Fall von XPN.
> Kann also als Lösung durchgehen. Imho
Zufall!
>> Wenn Du sie auf den Standardwert setzen willst:
>>
>> Set HOME=%HomeDrive%%HomePath%
>
> Das hab ich jetzt erstmal nicht geändert.
Damit Du 'was lernst: Windows (und richtige Windows-Programme)
verwenden keine Umgebungsvariable HOME, sondern HOMEDRIVE und HOMEPATH,
deren Konkatenation den gewuenschten (ggf. im Benutzerkonto als Basis-
Verzeichnis eingetragenen) Pfad enthaelt.
Du solltest daher HOME dann und nur dann unter Windows setzen, wenn Du
(typischerweise auf *ix-Umgebungen) portierte Programme nutzt, die HOME
kennen und verwenden.
Verwendest Du solche portierten Programme dagegen unter POSIX-Umgebungen
wie "Services for UNIX" alias Interix, CygWin oder MSYS, dann solltest
Du HOME ausschliesslich in deren Umgebung setzen, z.B. in deren
/etc/profile oder ~/.profile
Uwe Premer
> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>>>> | set home=
>>>
>>> Falsch. Du loeschst die Variable HOME!
>>
>> Und genau das funktioniert aber im Fall von XPN.
>> Kann also als Lösung durchgehen. Imho
>
> Zufall!
OK.
>>> Wenn Du sie auf den Standardwert setzen willst:
>>>
>>> Set HOME=%HomeDrive%%HomePath%
>>
>> Das hab ich jetzt erstmal nicht geändert.
Nunmehr jedoch doch.
Funktioniert. Gut ist.
Uwe
Uwe Premer
> "Uwe Premer" <u...@wiki.usenet-abc.de> schrieb:
>> als ich das mit dem "START" in der xpn.bat drin hatte, wurde das
>> cmd-Fenster wie gewünscht geschlossen beim Aufruf von XPN.
>>
>> Nun aber bleibt mit ".\xpn..." das cmd-Fenster geöffnet,
>
> Wieso willst Du "START .\xpn.exe --home_dir" nicht verwenden?
Done.
Funktioniert.
Tnx.
Uwe
Stefan Kanthak
> Stefan Kanthak schrieb am 28.05.2011 23:32 Uhr:
>> Ich setze beim Leser SOVIEL Transferleistung voraus, entweder die
>> Umgebungsvariablen selbst zu erweitern, oder den Datentyp REG_EXPAND_SZ
>> zu verwenden!
>
> Hier habe ich noch ein anderes Problem:
> wenn ich, wie ich das nach deinem Rat gemacht habe, einen neuen Schlüssel
> "xpn.exe" anlege, wird dort sofort ein REG_SZ angelegt, welches ich nicht
> löschen kann, auch nicht, wenn ich ein solches REG_EXPAND_SZ anlege.
> Wie lösche ich also das REG_SZ bzw. wie lege ich den Schlüssel ohne das an?
Im GUI von RegEdit.exe: gar nicht. Der Fehler ist seit 10 Jahren bekannt,
aber MOFT will ihn nicht beheben.
--- XPN.EXE ---
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\XPN.EXE]
@=hex(2):00
--- EOF ---
traegt einen leeren REG_EXPAND_SZ ein, den Du anschliessend nach Belieben
aendern kannst.
[...]
> Meinst du den Fehler:
>
> | Das Programm kann nicht gestartet werden, da libglib-2.0-0.dll auf dem
> | Computer fehlt. Installieren Sie das Programm erneut, um das Problem
> | zu beheben.
>
> beim Aufruf von
> cmd.exe /c "set %home%= & "C:\Program Files (x86)\XPN\xpn.exe" --home_dir"
>
> Ja, der Fehler ist immer noch da.
Kein Wunder. Ich schrieb doch extra fuer Dich, das CMD.EXE diese
Registry-Eintraege NICHT beachtet.
Wenn's unbedingt diese einzeilige Kruecke sein muss:
%COMSPEC% /C Set HOME= && Start "" "%ProgramFiles(x86)%\XPN\xpn.exe" --home_dir
oder (besser)
%COMSPEC% /C Set HOME= && Start "" /D"%ProgramFiles(x86)%\XPN" .\xpn.exe --home_dir
Wolfgang Bauer
> Das Problem damit war natürlich, dass der Datenordner ".xpn" in jenem
> obigen Gnus-Ordner landete und ich mir einen Wolf gesucht habe, wo der
> Ordner hingegangen wäre.
Ich muß nochmal nachhaken.
Geht es darum XPN zu zwingen seinen Datenordner in %AppData%
(C:\Users\Benutzer\AppData\Roaming) anzulegen und dort die Daten zu
speichern? Wenn das der Grund ist,
D:\Programme(x86)\XPN\xpn.exe --custom_dir %AppData%
macht genau das.
Uwe Premer
> Uwe Premer schrieb:
>
>> Das Problem damit war natürlich, dass der Datenordner ".xpn" in jenem
>> obigen Gnus-Ordner landete und ich mir einen Wolf gesucht habe, wo der
>> Ordner hingegangen wäre.
>
> Ich muß nochmal nachhaken.
> Geht es darum XPN zu zwingen seinen Datenordner in %AppData%
> (C:\Users\Benutzer\AppData\Roaming) anzulegen und dort die Daten zu
> speichern?
Nein, XPN soll seinen Datenordner ".xpn"
in C:\Users\[$Username]
anlegen.
Genau das wäre der korrekte Speicherort.
Korrekt deshalb, weil XPN in der Linux- und OS X-Version ebenfalls einen
Ordner .xpn anlegt und zwar direkt im Home (~).
Ein Aufruf von XPN ohne jegliche Optionen offenbart den Bug von XPN, dass
es seine Daten eigentlich direkt im Programmordner anlegen will, und nur
durch UAC (unter Vista und Win7) davon abgehalten wird und dann unter
C:\Users\[$User]\AppData\Local\VirtualStore\Program Files (x86)
abspeichert, was nicht ganz richtig ist.
Richtig macht es XPN nur mit *seiner* Startoption "--home_dir".
Uwe
Uwe Premer
> --- XPN.EXE ---
> REGEDIT4
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\XPN.EXE]
> @=hex(2):00
> --- EOF ---
>
> traegt einen leeren REG_EXPAND_SZ ein, den Du anschliessend nach Belieben
> aendern kannst.
Hier nochmal die Frage:
gehe ich da richtig,
dass bei Benutzung von "REG_SZ" besser mit "%" gearbeitet werden sollte und
mit "REG_EXPAND_SZ" ein Eintrag ohne die "%" genügt?
Oder muß in jedem Fall "REG_EXPAND_SZ" verwendet werden?
> Wenn's unbedingt diese einzeilige Kruecke sein muss:
>
> %COMSPEC% /C Set HOME= && Start "" "%ProgramFiles(x86)%\XPN\xpn.exe" --home_dir
>
> oder (besser)
>
> %COMSPEC% /C Set HOME= && Start "" /D"%ProgramFiles(x86)%\XPN" .\xpn.exe --home_dir
Ah, prima, das war meine eigentlich Frage im OP.
Ich habe folgenden Eintrag jetzt erfolgreich getestet:
Ziel:
%COMSPEC% /C Set HOME=%HomeDrive%%HomePath%&& Start ""
/D"%ProgramFiles(x86)%\XPN" .\xpn.exe --home_dir
(muß aber wirklich ohne " hinten und vorne sein)
Uwe
Wolfgang Bauer
> Wolfgang Bauer schrieb am 29.05.2011 09:17 Uhr:
>> Ich muß nochmal nachhaken.
>> Geht es darum XPN zu zwingen seinen Datenordner in %AppData%
>> (C:\Users\Benutzer\AppData\Roaming) anzulegen und dort die Daten zu
>> speichern?
> Nein, XPN soll seinen Datenordner ".xpn"
> in C:\Users\[$Username]
> anlegen. Genau das wäre der korrekte Speicherort.
Da bin ich nicht Deiner Meinung. In C:\Users\[$Username] gibt es hier
nicht eine einzige Datendatei.
> Korrekt deshalb, weil XPN in der Linux- und OS X-Version ebenfalls einen
> Ordner .xpn anlegt und zwar direkt im Home (~).
Wenn Du in der Beziehung kompatibel zu Linux sein willst. Da bei mir
aber $home /nicht/ C:\Users\[$Username] ist sondern D:\home\wolfgang
wird .xpn mit --home_dir da angelegt.
> Ein Aufruf von XPN ohne jegliche Optionen offenbart den Bug von XPN, dass
> es seine Daten eigentlich direkt im Programmordner anlegen will, und nur
> durch UAC (unter Vista und Win7) davon abgehalten wird ...
UAC steht bei mir auf der Defaulteinstellung "Nicht benachrichtigen,
wenn *ich* Änderungen an den Windows-Einstellungen vornehme. Trotzdem
wird beim Start von XPN /ohne/ Startoption .xpn im Programmordner
angelegt.
Wobei IMHO in Win7 der Ordner für Programmdaten %AppData% ist. Da sind
die Daten z.B. von Firefox, Thunderbird(mit den Profilen), \Microsoft\
Excel und Word, Skype usw. gespeichert.
Mit freundlichen Grüßen
Wolfgang Bauer
--
Das 40tude Dialog Skript - Archiv! http://kh-rademacher.de/4d/
Die 40tude-Dialog FAQ http://www.wolfgang-bauer.at/4td_faq/
Tabby ist abgängig http://www.wolfgang-bauer.at/katze/katze2.png
Uwe Premer
> Uwe Premer schrieb:
>> Wolfgang Bauer schrieb am 29.05.2011 09:17 Uhr:
>
>>> Ich muß nochmal nachhaken.
>>> Geht es darum XPN zu zwingen seinen Datenordner in %AppData%
>>> (C:\Users\Benutzer\AppData\Roaming) anzulegen und dort die Daten zu
>>> speichern?
>
>> Nein, XPN soll seinen Datenordner ".xpn"
>> in C:\Users\[$Username]
>> anlegen. Genau das wäre der korrekte Speicherort.
>
> Da bin ich nicht Deiner Meinung. In C:\Users\[$Username] gibt es hier
> nicht eine einzige Datendatei.
Hmh.
>> Korrekt deshalb, weil XPN in der Linux- und OS X-Version ebenfalls einen
>> Ordner .xpn anlegt und zwar direkt im Home (~).
>
> Wenn Du in der Beziehung kompatibel zu Linux sein willst. Da bei mir
> aber $home /nicht/ C:\Users\[$Username] ist sondern D:\home\wolfgang
> wird .xpn mit --home_dir da angelegt.
Dann stimmt es aber doch wieder, weil dein Home halt unter home und nicht
unter Users abgelegt ist. Wenn das komplett unter deinem Windows so
eingestellt ist, ist ja alles imho in Ordnung.
Ich bin halt vom Default ausgegangen.
>> Ein Aufruf von XPN ohne jegliche Optionen offenbart den Bug von XPN, dass
>> es seine Daten eigentlich direkt im Programmordner anlegen will, und nur
>> durch UAC (unter Vista und Win7) davon abgehalten wird ...
>
> UAC steht bei mir auf der Defaulteinstellung "Nicht benachrichtigen,
> wenn *ich* Änderungen an den Windows-Einstellungen vornehme. Trotzdem
> wird beim Start von XPN /ohne/ Startoption .xpn im Programmordner
> angelegt.
Hmh, ich hab grad nachgesehen: Standard ist:
immer benachrichtigen...
Steht jedenfalls dort als Standard.
> Wobei IMHO in Win7 der Ordner für Programmdaten %AppData% ist. Da sind
> die Daten z.B. von Firefox, Thunderbird(mit den Profilen), \Microsoft\
> Excel und Word, Skype usw. gespeichert.
Ist zwar durchaus so, allerdings halten das Programme aus der *ix-Szene
eher so mit ".Programmname" im Home-Ordner.
So z.B. bei tin, VirtualBox, Evolution und andere.
Uwe
Wolfgang Bauer
> Wolfgang Bauer schrieb am 29.05.2011 14:57 Uhr:
>> Da bin ich nicht Deiner Meinung. In C:\Users\[$Username] gibt es hier
>> nicht eine einzige Datendatei.
> Hmh.
Weil das eben hier nicht $home ist.
>> Wenn Du in der Beziehung kompatibel zu Linux sein willst. Da bei mir
>> aber $home /nicht/ C:\Users\[$Username] ist sondern D:\home\wolfgang
>> wird .xpn mit --home_dir da angelegt.
> Dann stimmt es aber doch wieder, weil dein Home halt unter home und nicht
> unter Users abgelegt ist. Wenn das komplett unter deinem Windows so
> eingestellt ist, ist ja alles imho in Ordnung.
> Ich bin halt vom Default ausgegangen.
Ist das default? Die Variable %home% habe ich hier als Benutzervariable
erst setzen müssen.
>> UAC steht bei mir auf der Defaulteinstellung "Nicht benachrichtigen,
>> wenn *ich* Änderungen an den Windows-Einstellungen vornehme. Trotzdem
>> wird beim Start von XPN /ohne/ Startoption .xpn im Programmordner
>> angelegt.
> Hmh, ich hab grad nachgesehen: Standard ist:
> immer benachrichtigen...
> Steht jedenfalls dort als Standard.
Ich habe den Schieber jetzt mal hochgesetzt. Ich wüßte nicht, daß ich
das mal geändert hätte.
>> Wobei IMHO in Win7 der Ordner für Programmdaten %AppData% ist. Da sind
>> die Daten z.B. von Firefox, Thunderbird(mit den Profilen), \Microsoft\
>> Excel und Word, Skype usw. gespeichert.
> Ist zwar durchaus so, allerdings halten das Programme aus der
> *ix-Szene eher so mit ".Programmname" im Home-Ordner. So z.B. bei
> tin, VirtualBox, Evolution und andere.
Das ist klar und die legen ihre Daten dann hier auch in D:\home\wolfgang
ab. ~/.emacs, ~/.gnus, ~/.tin, ~/.newsrc usw. Ich habe aber XPN nicht in
der Unixversion sondern in der Win32 Version installiert und deswegen
meine ich ist der Datenordner in %AppData% richtig.
Uwe Premer
> Uwe Premer schrieb:
>>> Wenn Du in der Beziehung kompatibel zu Linux sein willst. Da bei mir
>>> aber $home /nicht/ C:\Users\[$Username] ist sondern D:\home\wolfgang
>>> wird .xpn mit --home_dir da angelegt.
>
>> Dann stimmt es aber doch wieder, weil dein Home halt unter home und nicht
>> unter Users abgelegt ist. Wenn das komplett unter deinem Windows so
>> eingestellt ist, ist ja alles imho in Ordnung.
>> Ich bin halt vom Default ausgegangen.
>
> Ist das default?
Ja. Ich habe Win 7 so gelassen, wie erstmal installiert und bei der
Installation kann man in der Hinsicht erstmal nix ändern.
> Die Variable %home% habe ich hier als Benutzervariable
> erst setzen müssen.
Also nachträglich geändert.
>>> UAC steht bei mir auf der Defaulteinstellung "Nicht benachrichtigen,
>>> wenn *ich* Änderungen an den Windows-Einstellungen vornehme. Trotzdem
>>> wird beim Start von XPN /ohne/ Startoption .xpn im Programmordner
>>> angelegt.
>
>> Hmh, ich hab grad nachgesehen: Standard ist:
>> immer benachrichtigen...
>> Steht jedenfalls dort als Standard.
>
> Ich habe den Schieber jetzt mal hochgesetzt. Ich wüßte nicht, daß ich
> das mal geändert hätte.
Wie gesagt, ich hab so gut wie garnix geändert, zumindest nicht beim UAC.
>>> Wobei IMHO in Win7 der Ordner für Programmdaten %AppData% ist. Da sind
>>> die Daten z.B. von Firefox, Thunderbird(mit den Profilen), \Microsoft\
>>> Excel und Word, Skype usw. gespeichert.
>
>> Ist zwar durchaus so, allerdings halten das Programme aus der
>> *ix-Szene eher so mit ".Programmname" im Home-Ordner. So z.B. bei
>> tin, VirtualBox, Evolution und andere.
>
> Das ist klar und die legen ihre Daten dann hier auch in D:\home\wolfgang
> ab. ~/.emacs, ~/.gnus, ~/.tin, ~/.newsrc usw. Ich habe aber XPN nicht in
> der Unixversion sondern in der Win32 Version installiert und deswegen
> meine ich ist der Datenordner in %AppData% richtig.
Wenn du mal den Source von XPN nimmst, entpackst und dann im Ordner
xpn-1.2.6\xpn_src
die Datei UserDir.py anschaust, ist dort zu lesen:
----------X---------------------------------------------------------------
class UserDir:
def __init__(self,cwd=False,userHome=False,customPath=""):
'''Init user dir.
Arguments:
cwd :if True XPN will use it's own directory
userHome :if True XPN will create a .xpn directory inside user's
home directory.
customPath:if True XPN will create a .xpn directry inside user's
defined path.
----------X---------------------------------------------------------------
Wobei die erste Möglichkeit, nämlich "cwd" genau den Bug demonstriert, den
XPN hat: er schreibt per Start mit einem einfachen "XPN" seine Daten ins
Programmverzeichnis, zumindest will er das.
Erst UAC bei Vista und Win 7 leiten das dann in den VirtualStore um.
Ansonsten, also bei gesetztem userHome, soll er nach .xpn schreiben. Tut er
aber doch nur, wenn er mit der Option "--home_dir" gestartet wird.
Uwe
Wolfgang Bauer
> Wolfgang Bauer schrieb am 29.05.2011 16:18 Uhr:
>> Die Variable %home% habe ich hier als Benutzervariable
>> erst setzen müssen.
> Also nachträglich geändert.
Was heißt nachträglich? Wenn die Variable $home im Windows Programmcode
festverdrahtet ist, Als Umgebungsvariable in
Systemsteuerung\Alle Systemsteuerungselemente\System\Erweitert\Umgebungsvariablen
gab es $home nicht.
>> Das ist klar und die legen ihre Daten dann hier auch in D:\home\wolfgang
>> ab. ~/.emacs, ~/.gnus, ~/.tin, ~/.newsrc usw. Ich habe aber XPN nicht in
>> der Unixversion sondern in der Win32 Version installiert und deswegen
>> meine ich ist der Datenordner in %AppData% richtig.
> Wenn du mal den Source von XPN nimmst, entpackst und dann im Ordner
> xpn-1.2.6\xpn_src
> die Datei UserDir.py anschaust, ist dort zu lesen:
Eine Anleitung steht auch im xpn.exe.log.
Usage: python xpn.exe [-d] [-cCUSTOM_DIR]
With command line options you can decide where XPN will save config files and articles.
If you don't use any option, the current working directory will be used.
If you use the '--home_dir' option, XPN will create a .xpn directory inside your home directory, and will store informations inside that directory.
If you use the '--custom_dir' option, XPN will create a .xpn directory inside that custom_directory.
NOTE: If you set the '--home_dir' option, XPN will ignore the '--custom_dir' option (if you used it).
Examples:
python xpn.py
python xpn.py -d
python xpn.py --custom_dir /home/user/custom
Ich starte XPN jetzt in der Verknüpfung mit
D:\Programme\XPN\xpn.exe --custom_dir %home%
Uwe Premer
> Uwe Premer schrieb:
>>> Das ist klar und die legen ihre Daten dann hier auch in D:\home\wolfgang
>>> ab. ~/.emacs, ~/.gnus, ~/.tin, ~/.newsrc usw. Ich habe aber XPN nicht in
>>> der Unixversion sondern in der Win32 Version installiert und deswegen
>>> meine ich ist der Datenordner in %AppData% richtig.
>
>> Wenn du mal den Source von XPN nimmst, entpackst und dann im Ordner
>> xpn-1.2.6\xpn_src
>> die Datei UserDir.py anschaust, ist dort zu lesen:
>
> Eine Anleitung steht auch im xpn.exe.log.
>
> Usage: python xpn.exe [-d] [-cCUSTOM_DIR]
>
> With command line options you can decide where XPN will save config files and articles.
> If you don't use any option, the current working directory will be used.
> If you use the '--home_dir' option, XPN will create a .xpn directory inside your home directory, and will store informations inside that directory.
> If you use the '--custom_dir' option, XPN will create a .xpn directory inside that custom_directory.
>
> NOTE: If you set the '--home_dir' option, XPN will ignore the '--custom_dir' option (if you used it).
>
> Examples:
> python xpn.py
> python xpn.py -d
> python xpn.py --custom_dir /home/user/custom
Ah, schön, danke für den Hinweis. (Ich möchte die Erkenntnisse aus
diesem Thread nämlich noch in den XPN-usenet-abc-Wiki-Beitrag
verarbeiten, daher eigentlich auch mein OP hier.
> Ich starte XPN jetzt in der Verknüpfung mit
> D:\Programme\XPN\xpn.exe --custom_dir %home%
Ja, das ist auch vollkommen logisch.
Ich habe übrigens jetzt 3 verschiedene XPN-Windows-Installationen, eine
davon in Windows XP.
Hier bin ich einen ganz anderen Weg gegangen:
zuerst habe ich die Installationsdatei ganz normal ausgeführt und das
Programm nach C:\Programme\XPN installiert.
Dann habe ich den Inhalt jenes Ordners gelöscht, aber die Links im
Startmenü von Windows gelassen.
Danach habe ich die Source-Version von XPN runtergeladen, entpackt und
den Inhalt dort in das leere Programmverzeichnis kopiert.
Ausserdem habe ich Python und GTK separat installiert, damit ich die
xpn.py ausführen kann.
Anschliessend habe ich im Programmverzeichnis eine Batch wie folgt
geschrieben:
| REM xpn.bat
| @echo off
| xpn.py --home_dir
Anschliessend habe ich mir
http://www.computerhope.com/download/utility/Bat_To_Exe_Converter.zip
runtergeladen und damit diese Batchdatei zu einer xpn.exe kompiliert.
Da im Windows-Startmenü immer noch der Start-Link zu C:\Programme\xpn.exe
vorhanden ist, kann ich damit jetzt bequem die Python-Version von XPN
starten.
Zwar etwas umständlich, aber nachher sehr komfortabel.
Uwe
Stefan Kanthak
> Hier nochmal die Frage:
> gehe ich da richtig,
> dass bei Benutzung von "REG_SZ" besser mit "%" gearbeitet werden sollte und
> mit "REG_EXPAND_SZ" ein Eintrag ohne die "%" genügt?
Nein, genau andersherum: REG_EXPAND_SZ ist der Datentyp, der das
Expandieren von Umgebungsvariablen im Wert unterstuetzt, REG_SZ
dagegen nicht.
ABER: diese Datentypen sind keineswegs "streng", sondern eher als
Indikator zu betrachten.
> Oder muß in jedem Fall "REG_EXPAND_SZ" verwendet werden?
I.A. kannst Du statt REG_SZ auch REG_EXPAND_SZ verwenden.
ABER: nicht alle Anwendungen verstehen den Hinweis und expandieren
dort verwendete Umgebungsvariablen.
UND: es gibt genuegend Stellen, wo Umgebungsvariablen auch in REG_SZ
verwendet werden.
Eben der windows-typische Pfusch schon an der Basis...
Ich habe folgenden Eintrag jetzt erfolgreich getestet:
>
> Ziel:
> %COMSPEC% /C Set HOME=%HomeDrive%%HomePath%&& Start ""
> /D"%ProgramFiles(x86)%\XPN" .\xpn.exe --home_dir
UDIAGS
Stefan Kanthak
> Wolfgang Bauer schrieb am 29.05.2011 16:18 Uhr:
>> Die Variable %home% habe ich hier als Benutzervariable
>> erst setzen müssen.
>
> Also nachträglich geändert.
Falsch.
Siehe <news:4de17d92$0$6641$9b4e...@newsspool2.arcor-online.net>
> Wenn du mal den Source von XPN nimmst, entpackst und dann im Ordner
> xpn-1.2.6\xpn_src
> die Datei UserDir.py anschaust, ist dort zu lesen:
> ----------X---------------------------------------------------------------
> class UserDir:
> def __init__(self,cwd=False,userHome=False,customPath=""):
> '''Init user dir.
>
> Arguments:
> cwd :if True XPN will use it's own directory
> userHome :if True XPN will create a .xpn directory inside user's
> home directory.
> customPath:if True XPN will create a .xpn directry inside user's
> defined path.
> ----------X---------------------------------------------------------------
Wieso verwendest Du dann nicht folgende Kommandozeile in Deiner
Verknuepfung:
"%ProgramFiles(x86)%\XPN\xpn.exe" --custom_dir "%USERPROFILE%"
Uwe Premer
> "Uwe Premer" <m...@uwe-premer.de> schrieb:
>
>> Hier nochmal die Frage:
>> gehe ich da richtig,
>> dass bei Benutzung von "REG_SZ" besser mit "%" gearbeitet werden sollte und
>> mit "REG_EXPAND_SZ" ein Eintrag ohne die "%" genügt?
>
> Nein, genau andersherum: REG_EXPAND_SZ ist der Datentyp, der das
> Expandieren von Umgebungsvariablen im Wert unterstuetzt, REG_SZ
> dagegen nicht.
> ABER: diese Datentypen sind keineswegs "streng", sondern eher als
> Indikator zu betrachten.
Gut, habe inzwischen den Registry-Eintrag mit "REG_SZ" wieder gelöscht und
mit der Datei XPN.Reg, die du beschrieben hattest, mit neuen Einträgen
"REG_EXPAND_SZ" neu angelegt.
Uwe
Hans-Peter Matthess
> Nein, XPN soll seinen Datenordner ".xpn"
> in C:\Users\[$Username]
> anlegen.
> Genau das wäre der korrekte Speicherort.
Nö, das wäre grober Unfug. Der Ordner gehört nach %Appdata%
hpm
Wolfgang Bauer
> Uwe Premer:
Was auch ohne alle Klimmzüge geht.
D:\Programme\XPN\xpn.exe --custom_dir %AppData%
Mit freundlichen Grüßen
Wolfgang Bauer
--
Das 40tude Dialog Skript - Archiv! http://kh-rademacher.de/4d/
Die 40tude-Dialog FAQ http://www.wolfgang-bauer.at/4td_faq/
Hans-Peter Matthess
>> Nö, das wäre grober Unfug. Der Ordner gehört nach %Appdata%
> Was auch ohne alle Klimmzüge geht.
> D:\Programme\XPN\xpn.exe --custom_dir %AppData%
Das wären dann immer noch unnötige Klimmzüge. Wenn man nicht nach
%ProgramFiles% installiert, kann man das Programm den Datenordner auch
im eigenen Programmverzeichnis anlegen lassen, so wie es z.B. Dialog
macht. Der ist dort dann auch gut aufgehoben.
hpm
Uwe Premer
> Hans-Peter Matthess schrieb:
>> Uwe Premer:
>
>>> Nein, XPN soll seinen Datenordner ".xpn"
>>> in C:\Users\[$Username]
>>> anlegen.
>>> Genau das wäre der korrekte Speicherort.
>
>> Nö, das wäre grober Unfug. Der Ordner gehört nach %Appdata%
>
> Was auch ohne alle Klimmzüge geht.
> D:\Programme\XPN\xpn.exe --custom_dir %AppData%
Ja, damit kann ich mich anfreunden.
Die Frage allerdings ist, ob noch weiter in
.\Local
.\LocalRow oder
.\Roaming?
Ich glaube, das wäre sogar die beste Lösung, wenn man XPN mit einer
Defaultinstallation (C:\Program Files (x86)) macht.
Ich werde aber im Wiki-Beitrag auch die Möglichkeit mit "--home_dir"
beschreiben.
Uwe
Andreas Kästner
> --- XPN.EXE ---
> REGEDIT4
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\XPN.EXE]
> @=hex(2):00
> --- EOF ---
http://support.microsoft.com/kb/310516/en-us :
"Note the registry file should contain a blank line
at the bottom ofthe file."
Gruß - Andreas
Stefan Kanthak
Ist das denn die Moeglichkeit?!
Kommst Du durch eigenes Nachdenken darauf, wieso dort
1. "should" und nicht "must" steht,
2. warum dieser Satz dort steht,
3. warum dieser Satz (der wie bei Microsoft leider so oft nicht die
Problemursache nennt) in dieser Form eigentlich falsch ist?
Gvcc: rf ung zvg "Grkgqngrvra", Rqvgbera haq Mrvyraraqra mh gha.
Stefan Kanthak
> Wolfgang Bauer schrieb am 30.05.2011 01:52 Uhr:
>> Hans-Peter Matthess schrieb:
>>> Uwe Premer:
>>
>>>> Nein, XPN soll seinen Datenordner ".xpn"
>>>> in C:\Users\[$Username]
>>>> anlegen.
>>>> Genau das wäre der korrekte Speicherort.
>>
>>> Nö, das wäre grober Unfug. Der Ordner gehört nach %Appdata%
>>
>> Was auch ohne alle Klimmzüge geht.
>> D:\Programme\XPN\xpn.exe --custom_dir %AppData%
>
> Ja, damit kann ich mich anfreunden.
> Die Frage allerdings ist, ob noch weiter in
> .\Local
> .\LocalRow oder
> .\Roaming?
AUTSCH!
%APPDATA% ist %USERPROFILE\Application Data\Roaming
%LOCALAPPDATA% ist %USERPROFILE\Application Data\Local
> Ich glaube, das wäre sogar die beste Lösung, wenn man XPN mit einer
> Defaultinstallation (C:\Program Files (x86)) macht.
Programme, die die inzwischen ueber 15 Jahre alten "Designed for Windows"
Richtlinien nicht beachten, sind Schrott!
> Ich werde aber im Wiki-Beitrag auch die Möglichkeit mit "--home_dir"
> beschreiben.
Beschreiben schadet erst mal nichts.
ABER: der deutliche Hinweis auf die richtige Ablage tut Not!
Hans-Peter Matthess
> %APPDATA% ist %USERPROFILE\Application Data\Roaming
> %LOCALAPPDATA% ist %USERPROFILE\Application Data\Local
Wenn du "application data" durch "appdata" ersetzt, kommt's hin.
hpm
Uwe Premer
Ahja, dank' an Euch 2. ;-)
@Stefan:
> Beschreiben schadet erst mal nichts.
> ABER: der deutliche Hinweis auf die richtige Ablage tut Not!
Mittlerweile enthält dieser Thread eine geballte Ladung an Wissen, die ich
dann halt verarbeiten werde.
Uwe
Jörg Tewes
>> Korrekt deshalb, weil XPN in der Linux- und OS X-Version ebenfalls
>> einen Ordner .xpn anlegt und zwar direkt im Home (~).
> Wenn Du in der Beziehung kompatibel zu Linux sein willst. Da bei
> mir aber $home /nicht/ C:\Users\[$Username] ist sondern
> D:\home\wolfgang wird .xpn mit --home_dir da angelegt.
Dir ist nicht aufgefallen das [$Username] nur eine Variable für den
eigentlichen Usernamen, bei dir Wolfgang und beim TE Uwe, ist? Guten
Morgen!
>> Ein Aufruf von XPN ohne jegliche Optionen offenbart den Bug von
>> XPN, dass es seine Daten eigentlich direkt im Programmordner
>> anlegen will, und nur durch UAC (unter Vista und Win7) davon
>> abgehalten wird ...
> UAC steht bei mir auf der Defaulteinstellung "Nicht
> benachrichtigen, wenn *ich* Änderungen an den Windows-Einstellungen
> vornehme. Trotzdem wird beim Start von XPN /ohne/ Startoption .xpn
> im Programmordner angelegt.
Wieso kannst du als eingeschränkter User in %ProgramFiles%\WPN
schreiben? Eigentlich kann man da nur mit Adminrechten schreiben.
Bye Jörg
--
"All this does is get us out of the way so the Centauri can move in on the
other worlds. Earth wants peace and they're willing to sacrifice everybody
else in order to get it."
(Ivanova, "The Fall of Night")
Wolfgang Bauer
> Wolfgang Bauer schrub
>> Wenn Du in der Beziehung kompatibel zu Linux sein willst. Da bei
>> mir aber $home /nicht/ C:\Users\[$Username] ist sondern
>> D:\home\wolfgang wird .xpn mit --home_dir da angelegt.
> Dir ist nicht aufgefallen das [$Username] nur eine Variable für den
> eigentlichen Usernamen, bei dir Wolfgang und beim TE Uwe, ist? Guten
> Morgen!
Was willst Du mir eigentlich sagen? Ich verstehe den Hinweis nicht.
Was meinst Du mit TE?
>> UAC steht bei mir auf der Defaulteinstellung "Nicht
>> benachrichtigen, wenn *ich* Änderungen an den Windows-Einstellungen
>> vornehme. Trotzdem wird beim Start von XPN /ohne/ Startoption .xpn
>> im Programmordner angelegt.
> Wieso kannst du als eingeschränkter User in %ProgramFiles%\WPN
> schreiben? Eigentlich kann man da nur mit Adminrechten schreiben.
Was ist WPN?
Wolfgang Bauer
> Wolfgang Bauer:
>> Was auch ohne alle Klimmzüge geht.
>> D:\Programme\XPN\xpn.exe --custom_dir %AppData%
> Das wären dann immer noch unnötige Klimmzüge. Wenn man nicht nach
> %ProgramFiles% installiert, kann man das Programm den Datenordner auch
> im eigenen Programmverzeichnis anlegen lassen, so wie es z.B. Dialog
> macht. Der ist dort dann auch gut aufgehoben.
Äh, klingt mir da etwas im Ohr, "Programmdaten gehören nicht in den
Programmordner"?
Hans-Peter Matthess
>>> Was auch ohne alle Klimmzüge geht.
>>> D:\Programme\XPN\xpn.exe --custom_dir %AppData%
>> Das wären dann immer noch unnötige Klimmzüge. Wenn man nicht nach
>> %ProgramFiles% installiert, kann man das Programm den Datenordner auch
>> im eigenen Programmverzeichnis anlegen lassen, so wie es z.B. Dialog
>> macht. Der ist dort dann auch gut aufgehoben.
> Äh, klingt mir da etwas im Ohr, "Programmdaten gehören nicht in den
> Programmordner"?
Es klingt einem immer irgendwas im Ohr. Wenn man Programme nicht nach
%ProgramFiles% installiert, kann man auch alle anderen üblichen Orte
ignorieren. Letztlich muss es jeder so machen wie es ihm passt.
Im Falle Newsreader hab ich die Daten lieber in meinen Anwenderdaten,
also weder in %Appdata% noch in %ProgramFiles%. Streng genommen ist das
auch Murks.
hpm
Jörg Tewes
> Jörg Tewes schrieb:
>> Wolfgang Bauer schrub
>>> Wenn Du in der Beziehung kompatibel zu Linux sein willst. Da bei
>>> mir aber $home /nicht/ C:\Users\[$Username] ist sondern
>>> D:\home\wolfgang wird .xpn mit --home_dir da angelegt.
>> Dir ist nicht aufgefallen das [$Username] nur eine Variable für
>> den eigentlichen Usernamen, bei dir Wolfgang und beim TE Uwe, ist?
>> Guten Morgen!
> Was willst Du mir eigentlich sagen? Ich verstehe den Hinweis nicht.
Das dein D:\home\Wolfgang dasselbe ist wie Uwes C:\Users\[$Username].
Nur das du dein Home Verzeichnis auf D\Home abgelegt hat und Uwe seins
dem Standard von Win7 entspricht.
> Was meinst Du mit TE?
Threadersteller.
>>> UAC steht bei mir auf der Defaulteinstellung "Nicht
>>> benachrichtigen, wenn *ich* Änderungen an den
>>> Windows-Einstellungen vornehme. Trotzdem wird beim Start von XPN
>>> /ohne/ Startoption .xpn im Programmordner angelegt.
>> Wieso kannst du als eingeschränkter User in %ProgramFiles%\WPN
>> schreiben? Eigentlich kann man da nur mit Adminrechten schreiben.
> Was ist WPN?
XPN war gemeint. Also das Programmverzeichnis des Programms XPN
unterhalb von C:\Program Files(x86)
Bye Jörg
--
IcH fInDe AuCh, dAsS eS nIcHt So WiChTig IsT, eInEn TeXt In KoRrEcKtEr
gRoSs- Und KlEiNsChReIbUnG zU vErFaSsEn, Da DiEs DeR LeSbArKeIt KaUm
AbBrUcH tUt UnD zUdEm AuSdRuCk MeInEr InDiViDuAlItAeT iSt.
[Joachim Kromm, de.soc.netzkultur.umgangsformen, 31.7.2001 ]
Wolfgang Bauer
> Wolfgang Bauer schrub
>> Was willst Du mir eigentlich sagen? Ich verstehe den Hinweis nicht.
> Das dein D:\home\Wolfgang dasselbe ist wie Uwes C:\Users\[$Username].
> Nur das du dein Home Verzeichnis auf D\Home abgelegt hat und Uwe seins
> dem Standard von Win7 entspricht.
Daß es da einen vorgegebenen Standard gibt, wenn die Variable nicht
gesetzt ist, wußte ich gar nicht. Bei mir war es so ziemlich das Erste
was ich gemacht habe die Variable $home auf D:\home\wolfgang zu setzen.
Ich habe wenn möglich anwenderspezifische Programmdaten runter von der
Systempartition.
>> Was meinst Du mit TE?
> Threadersteller.
Kenne ich sonst als OP.
>> Was ist WPN?
> XPN war gemeint. Also das Programmverzeichnis des Programms XPN
> unterhalb von C:\Program Files(x86)
Und auch die Programme sind hier in D:\Programme\ installiert. Was auch
bei 90% der Programme, mindestens bei custom Installation, möglich ist.
Stefan Kanthak
> Und auch die Programme sind hier in D:\Programme\ installiert. Was auch
> bei 90% der Programme, mindestens bei custom Installation, möglich ist.
Und grober Unfug!
Kaum ein Programm installiert sich OHNE Registry-Eintraege zu erstellen;
manche installieren zudem DLLs etc. unter %SystemRoot% oder
%CommonProgramFiles%.
Dummerweise liegen diese Verzeichnisse wie auch die Registry aber auf
%SystemDrive%.
In Zukunft musst Du sowohl %SystemDrive% als auch D:\Programme\ sichern,
und das in konsistentem Zustand.
Wolfgang Bauer
> "Wolfgang Bauer" <bau...@aon.at> schrieb:
>> Und auch die Programme sind hier in D:\Programme\ installiert. Was auch
>> bei 90% der Programme, mindestens bei custom Installation, möglich ist.
> Und grober Unfug!
> Kaum ein Programm installiert sich OHNE Registry-Eintraege zu erstellen;
> manche installieren zudem DLLs etc. unter %SystemRoot% oder
> %CommonProgramFiles%.
> Dummerweise liegen diese Verzeichnisse wie auch die Registry aber auf
> %SystemDrive%.
> In Zukunft musst Du sowohl %SystemDrive% als auch D:\Programme\ sichern,
> und das in konsistentem Zustand.
Das mache ich nicht nur /in Zukunft/.
Von %SystemDrive% wird regelmäßig ein Image auf eine externe Platte
gemacht und D:\Programme\ wird ebenfalls regelmäßig dahin kopiert.
Stefan Kanthak
> Stefan Kanthak schrieb:
>> "Wolfgang Bauer" <bau...@aon.at> schrieb:
>
>>> Und auch die Programme sind hier in D:\Programme\ installiert. Was auch
>>> bei 90% der Programme, mindestens bei custom Installation, möglich ist.
>
>> Und grober Unfug!
>> Kaum ein Programm installiert sich OHNE Registry-Eintraege zu erstellen;
>> manche installieren zudem DLLs etc. unter %SystemRoot% oder
>> %CommonProgramFiles%.
>> Dummerweise liegen diese Verzeichnisse wie auch die Registry aber auf
>> %SystemDrive%.
>
>> In Zukunft musst Du sowohl %SystemDrive% als auch D:\Programme\ sichern,
>> und das in konsistentem Zustand.
>
> Das mache ich nicht nur /in Zukunft/.
> Von %SystemDrive% wird regelmäßig ein Image auf eine externe Platte
> gemacht und D:\Programme\ wird ebenfalls regelmäßig dahin kopiert.
Also hast Du mit der willkuerlichen Trennung nur mehr Aufwand und
Nachteile! q.e.d
Claus Reibenstein
> "Wolfgang Bauer" <bau...@aon.at> schrieb:
>
>> Stefan Kanthak schrieb:
>>
>>> In Zukunft musst Du sowohl %SystemDrive% als auch D:\Programme\ sichern,
>>> und das in konsistentem Zustand.
Ja. Und?
>> Das mache ich nicht nur /in Zukunft/.
>> Von %SystemDrive% wird regelmäßig ein Image auf eine externe Platte
>> gemacht und D:\Programme\ wird ebenfalls regelmäßig dahin kopiert.
>
> Also hast Du mit der willkuerlichen Trennung nur mehr Aufwand und
> Nachteile! q.e.d
Der zusätzliche Aufwand besteht darin, ein einziges Mal dem
Backup-Programm zu sagen, was es zu tun hat. Dieser klitzekleine
Nachteil ist sicher vernachlässigbar angesichts der immensen Vorteile
eines kleinen und deshalb im Ernstfall schnell eingespielten Images der
Systempartition und einer sauberen Trennung zwischen Betriebssystem und
Daten.
Ich habe mein System übrigens in 7 Partitionen unterteilt:
Betriebssystem, Anwendungsprogramme, Daten, Installationsmedien, CD- und
DVD-Images, Virtuelle Maschinen, Backup. Sollte es auf einer der
Partitionen mal zu eng werden, kann ich entweder mit einem geeigneten
Tool die Grenzen verschieben (kommt selten vor) oder einfach eine
weitere Festplatte dazuhängen und die Partitionen nach Belieben verteilen.
In der Unix-Welt sind solche Partitionierungen schon seit Jahrzehnten
gang und gäbe. Das hat sicher seinen Grund ...
Gruß. Claus
Stefan Kanthak
> Stefan Kanthak schrieb:
>
>> "Wolfgang Bauer" <bau...@aon.at> schrieb:
>>
>>> Stefan Kanthak schrieb:
>>>
>>>> In Zukunft musst Du sowohl %SystemDrive% als auch D:\Programme\ sichern,
>>>> und das in konsistentem Zustand.
>
> Ja. Und?
>
>>> Das mache ich nicht nur /in Zukunft/.
>>> Von %SystemDrive% wird regelmäßig ein Image auf eine externe Platte
>>> gemacht und D:\Programme\ wird ebenfalls regelmäßig dahin kopiert.
>>
>> Also hast Du mit der willkuerlichen Trennung nur mehr Aufwand und
>> Nachteile! q.e.d
>
> Der zusätzliche Aufwand besteht darin, ein einziges Mal dem
> Backup-Programm zu sagen, was es zu tun hat. Dieser klitzekleine
> Nachteil ist sicher vernachlässigbar angesichts der immensen Vorteile
> eines kleinen und deshalb im Ernstfall schnell eingespielten Images der
> Systempartition und einer sauberen Trennung zwischen Betriebssystem und
> Daten.
Wie schoen, dass Du die unter D:\Programme\ abgelegten Dateien als
"Daten" ansiehst! MERKST DU UEBERHAUPT NOCH WAS?
> Ich habe mein System übrigens in 7 Partitionen unterteilt:
Mein Beileid!
Uebrigens: "volume manager" existieren.
> In der Unix-Welt sind solche Partitionierungen schon seit Jahrzehnten
> gang und gäbe. Das hat sicher seinen Grund ...
Genau.
0. Im Mittelalter war Kleinstaaterei auch ueblich.
1. Kleine Platten, und kleine Dateisysteme. LFS und Platten groesser
2GB gibt's erst seit etwa 20 Jahren.
2. Windows hat selbstverstaendlich dieselbe Verzeichnisstruktur wie
UNIX, u.a. mit /etc, /bin, /sbin und /lib, daneben /usr/bin,
/usr/sbin und /usr/lib, sowie /var, /opt und /home, worunter die
*.exe, *.dll etc. fein saeuberlich getrennt abgelegt sind.
Und gar keine Registry.
MERKST DU UEBERHAUPT NOCH WAS?
Wolfgang Bauer
> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
>> Der zusätzliche Aufwand besteht darin, ein einziges Mal dem
>> Backup-Programm zu sagen, was es zu tun hat. Dieser klitzekleine
>> Nachteil ist sicher vernachlässigbar angesichts der immensen Vorteile
>> eines kleinen und deshalb im Ernstfall schnell eingespielten Images der
>> Systempartition und einer sauberen Trennung zwischen Betriebssystem und
>> Daten.
> Wie schoen, dass Du die unter D:\Programme\ abgelegten Dateien als
> "Daten" ansiehst! MERKST DU UEBERHAUPT NOCH WAS?
Es gibt in D:\Programme\ Anwendungen die ihre Daten im
Programmverzeichnis speichern. Ob das gut ist oder nicht soll jetzt
nicht das Thema sein. Wo steht denn da übrigens etwas von abgelegten
Dateien? *Daten* sind gemeint z.B. Konfigurationsdaten der Anwendungen
in D:\Programme.
Und wenn es die Möglichkeit gibt die etwa in D:\home\ zu speichern
bleiben sie unberührt von einer möglichen Neuinstallation. Außerdem
werden *Programmdaten* auch in Dateien gespeichert.
Jörg Tewes
> Jörg Tewes schrieb:
>> Wolfgang Bauer schrub
>>> Was willst Du mir eigentlich sagen? Ich verstehe den Hinweis
>>> nicht.
>> Das dein D:\home\Wolfgang dasselbe ist wie Uwes
>> C:\Users\[$Username]. Nur das du dein Home Verzeichnis auf D\Home
>> abgelegt hat und Uwe seins dem Standard von Win7 entspricht.
> Daß es da einen vorgegebenen Standard gibt, wenn die Variable nicht
> gesetzt ist, wußte ich gar nicht. Bei mir war es so ziemlich das
> Erste was ich gemacht habe die Variable $home auf D:\home\wolfgang
> zu setzen.
Es gibt standardmäßig keine Variable $home unter Windows. Es gibt nur
eine Variable die immer auf Homeverzeichnis des angemeldeten Users
zeigt, egal wo sich das gerade befindet. Diese Variable lautet
%Homepath%
> Ich habe wenn möglich anwenderspezifische Programmdaten runter von
> der Systempartition.
Habe ich auch.
>>> Was ist WPN?
>> XPN war gemeint. Also das Programmverzeichnis des Programms XPN
>> unterhalb von C:\Program Files(x86)
> Und auch die Programme sind hier in D:\Programme\ installiert. Was
> auch bei 90% der Programme, mindestens bei custom Installation,
> möglich ist.
Ja, darum kann bei dir auch jedes Programm unter einem eingeschränkten
Account amoklaufen. D:\Programme ist als eingeschränkter User nicht
schreibgeschützt.
Bye Jörg
--
"Mollari, the grievances between my people and yours will never be resolved
except with Centauri blood. Accept that as a given." "Well, its good to know
we're appreciated."
(G'Kar and Londo, "Revelations")
Stefan Kanthak
> Stefan Kanthak schrieb:
>> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
| sauberen Trennung zwischen Betriebssystem und Daten.
>> Wie schoen, dass Du die unter D:\Programme\ abgelegten Dateien als
>> "Daten" ansiehst! MERKST DU UEBERHAUPT NOCH WAS?
>
> Es gibt in D:\Programme\
KAPUTTE
> Anwendungen die ihre Daten im Programmverzeichnis speichern.
Wegwerfen!
> Ob das gut ist oder nicht soll jetzt nicht das Thema sein. Wo steht
> denn da übrigens etwas von abgelegten Dateien? *Daten* sind gemeint
> z.B. Konfigurationsdaten der Anwendungen in D:\Programme.
Falsch! Programme sind keine Daten.
Du solltest aufmerksamer lesen und die referenzierten Texte zitieren!
S.o.
> Und wenn es die Möglichkeit gibt die etwa in D:\home\ zu speichern
> bleiben sie unberührt von einer möglichen Neuinstallation. Außerdem
> werden *Programmdaten* auch in Dateien gespeichert.
0. In dem System, auf das sich mein Vorposter bezog, ist ALLES eine
Datei.-P
1. Umkehrschluesse sind nicht immer richtig!
Wolfgang Bauer
> Ja, darum kann bei dir auch jedes Programm unter einem eingeschränkten
> Account amoklaufen. D:\Programme ist als eingeschränkter User nicht
> schreibgeschützt.
Eben, darum gerade D:\Programme.
Was ist das wenn ein Programm amok läuft, kenne ich nicht.
Hans-Peter Matthess
> Ja, darum kann bei dir auch jedes Programm unter einem eingeschränkten
> Account amoklaufen. D:\Programme ist als eingeschränkter User nicht
> schreibgeschützt.
Sofern man es eben nicht mit den gleichen Rechten wie bei %Programfiles%
vorhanden einrichtet. Die Möglichkeit hat man ja jederzeit.
hpm
Claus Reibenstein
> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
>
>> Der zusätzliche Aufwand besteht darin, ein einziges Mal dem
>> Backup-Programm zu sagen, was es zu tun hat. Dieser klitzekleine
>> Nachteil ist sicher vernachlässigbar angesichts der immensen Vorteile
>> eines kleinen und deshalb im Ernstfall schnell eingespielten Images der
>> Systempartition und einer sauberen Trennung zwischen Betriebssystem und
>> Daten.
>
> Wie schoen, dass Du die unter D:\Programme\ abgelegten Dateien als
> "Daten" ansiehst!
Was sollen sie denn sonst sein?
> MERKST DU UEBERHAUPT NOCH WAS?
Schrei mich nicht an! Wer schreit, hat Unrecht!
Ich merke, dass Du nicht allzuviel Ahnung von dem hast, worüber Du
schreibst.
>> Ich habe mein System übrigens in 7 Partitionen unterteilt:
>
> Mein Beileid!
Wieso denn "Beileid"?
> Uebrigens: "volume manager" existieren.
Ja. Und? Was willst Du mir mitteilen?
>> In der Unix-Welt sind solche Partitionierungen schon seit Jahrzehnten
>> gang und gäbe. Das hat sicher seinen Grund ...
>
> Genau.
>
> 0. Im Mittelalter war Kleinstaaterei auch ueblich.
Off topic.
> 1. Kleine Platten, und kleine Dateisysteme. LFS und Platten groesser
> 2GB gibt's erst seit etwa 20 Jahren.
Es geht nicht um die Größen der Partitionen und/oder Platten. Es geht um
die Strukturierung der Daten. Dachte eigentlich, dass ich das deutlich
gemacht hätte. Aber offensichtlich (für Dich) nicht deutlich genug.
> 2. Windows hat selbstverstaendlich dieselbe Verzeichnisstruktur wie
> UNIX
Jetzt ist es wohl an mir, "Blödsinn!" zu rufen.
Natürlich hat Windows nicht dieselbe Struktur. Aber es hat eine
Struktur, die eine problemlose Trennung zwischen Betriebssystem,
Anwendungsprogrammen und Benutzerdaten ermöglicht.
Der wesentliche Unterschied zu Unix besteht darin, dass Microsoft per
Default alles in eine einzige, riesige Partition klatscht. Hier ist also
mühselige Handarbeit angesagt, un daran etwas zu ändern, und hierzu sind
leider auch gewisse Systemkenntnisse erforderlich.
> Und gar keine Registry.
Die ist sowieso die schwachsinnigste Erfindung seit Windows.
> MERKST DU UEBERHAUPT NOCH WAS?
Du schreist ja schon wieder!
Gruß. Claus
Hans-Peter Matthess
>> MERKST DU UEBERHAUPT NOCH WAS?
> Du schreist ja schon wieder!
Immerhin wirfst du Leute in dein Killfile, wenn sie dir höflich zu
verstehen geben, dass man UAC nicht deaktivieren muss, um Batchfiles
ausführen zu können. Leute hingegen, die dich anschreien und dich für
dämlich erklären, sind weiterhin willkommen. Da hab ich damals wohl
komplett den falschen Ton gewählt. :-)
hpm
Uwe Premer
Das Schöne an NTFS ist, dass man, wie du schon sagst, die Rechte
individuell setzen kann. Das geht natürlich auch in D:\Programme.
Allerdings stimme ich mit Wolfgang überein, dass die einfachste Methode, um
ein älteres Programm unter Win 7 zum Laufen zu bekommen, wenn es an den
Rechten hakt, es auf Laufwerk D: zu installieren. Dann hat es halt volle
Rechte und kann in sein Verzeichnis nach Herzenslust reinschreiben.
Im Übrigen habe ich auch ich ein "D:\Programme" von Windows XP Pro her. Leider.
Der Grund war einfach nur der, dass Laufwerk C:\ dicht war und ich auf
einen neue Festplatte gewartet habe.
Bei Gelegenheit allerdings kann ich die dort installierten Programme mal
wieder deinstallieren und korrekt nach C:\Programme neu installieren.
Bisher allerdings sind noch keinerlei Probleme damit aufgetreten.
Eines dieser Programme ist übrigens KDE for Windows.
Uwe
Uwe Premer
Es ist Psychologie:
man muß halt rausfinden, ob es der Gegenüber lieber LAUT haben möchte oder
ob er bereits bei leisen Tönen aussteigt.
Jedem seine eigene Vorgehensweise. ;-)
Uwe, scnr & da OT -> Fup2P
Hans-Peter Matthess
>>> Ja, darum kann bei dir auch jedes Programm unter einem eingeschränkten
>>> Account amoklaufen. D:\Programme ist als eingeschränkter User nicht
>>> schreibgeschützt.
>> Sofern man es eben nicht mit den gleichen Rechten wie bei %Programfiles%
>> vorhanden einrichtet. Die Möglichkeit hat man ja jederzeit.
> Das Schöne an NTFS ist, dass man, wie du schon sagst, die Rechte
> individuell setzen kann. Das geht natürlich auch in D:\Programme.
Ebent. :o)
> Allerdings stimme ich mit Wolfgang überein, dass die einfachste Methode, um
> ein älteres Programm unter Win 7 zum Laufen zu bekommen, wenn es an den
> Rechten hakt, es auf Laufwerk D: zu installieren. Dann hat es halt volle
> Rechte und kann in sein Verzeichnis nach Herzenslust reinschreiben.
Oder nach C:\Programme2 oder wohin auch immer oder man gibt der
betreffenden Datei allein die passenden Rechte oder oder oder....
Wenn ich bei Testinstallationen feststelle, dass Teile des Programms
virtualisiert werden, mache ich mir für den alten Schrott nicht viel
Mühe und installiere ihn dann halt nicht nach %ProgramFiles%.
hpm
Stefan Kanthak
> Stefan Kanthak schrieb:
>
>> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
>>> Systempartition und einer sauberen Trennung zwischen Betriebssystem und
>>> Daten.
>>
>> Wie schoen, dass Du die unter D:\Programme\ abgelegten Dateien als
>> "Daten" ansiehst!
>
> Was sollen sie denn sonst sein?
Nur Vollidioten legen Daten in ein D:\Programme\ genanntes Verzeichnis.
Oder interpretieren einen solchen Verzeichnisnamen falsch.
Stefan Kanthak
> Es gibt standardmäßig keine Variable $home unter Windows. Es gibt nur
> eine Variable die immer auf Homeverzeichnis des angemeldeten Users
> zeigt, egal wo sich das gerade befindet. Diese Variable lautet
> %Homepath%
Falsch. Es ist die Konkatenation von %HOMEDRIVE%%HOMEPATH%
> Ja, darum kann bei dir auch jedes Programm unter einem eingeschränkten
> Account amoklaufen. D:\Programme ist als eingeschränkter User nicht
> schreibgeschützt.
Das laesst sich aendern.-P
Beispielsweise so:
"%SystemRoot%\System32\XCopy.Exe" /F /I /K /O /X "%ProgramFiles%" "D:\Progamme"
Claus Reibenstein
> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
>
>> Stefan Kanthak schrieb:
>>
>>> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
>>>
>>>> Systempartition und einer sauberen Trennung zwischen Betriebssystem und
>>>> Daten.
>>>
>>> Wie schoen, dass Du die unter D:\Programme\ abgelegten Dateien als
>>> "Daten" ansiehst!
>>
>> Was sollen sie denn sonst sein?
>
> Nur Vollidioten legen Daten in ein D:\Programme\ genanntes Verzeichnis.
Du hast mich falsch verstanden.
Programme sind auch nur Daten. Darauf zielte meine Bemerkung.
> Oder interpretieren einen solchen Verzeichnisnamen falsch.
Ich interpretiere ihn durchaus richtig.
Gruß. Claus
Claus Reibenstein
> Hans-Peter Matthess schrieb am 04.06.2011 13:28 Uhr:
>
>> Immerhin wirfst du Leute in dein Killfile, wenn sie dir höflich zu
¯¯¯¯¯¯¯
*LOL* Der war gut ;-)
>> verstehen geben, dass man UAC nicht deaktivieren muss, um Batchfiles
>> ausführen zu können. Leute hingegen, die dich anschreien und dich für
>> dämlich erklären, sind weiterhin willkommen. Da hab ich damals wohl
>> komplett den falschen Ton gewählt. :-)
In der Tat.
Allerdings geht es mir mehr um Inhalte als um Form.
> Es ist Psychologie:
Nein. Es ist die Unfähigkeit von Herrn Matthess, zu erkennen, warum er
in meinem Killfile gelandet ist.
> Uwe, scnr & da OT -> Fup2P
Warum? Herr Matthess lästert hier öffentlich (was ich ohne Deine Antwort
wahrscheinlich gar nicht mitbekommen hätte), also antworte ich auch
öffentlich.
Gruß. Claus
Hans-Peter Matthess
> Allerdings geht es mir mehr um Inhalte als um Form.
Dann schreibe halt mal, was dir inhaltlich so unerhört daran scheint,
wenn jemand darauf hinweist, dass man UAC nicht deaktivieren muss, um
Batchfiles ausführen zu können. IMHO ist deshalb in der gesamten
Geschichte des Usenets noch nie jemand gefiltert worden.
Das kannst du jetzt natürlich nur dann lesen, wenn du's in einem Zitat
findest, ich weiß. <bg>
hpm
Detlef Meißner
> Nur Vollidioten legen Daten in ein D:\Programme\ genanntes Verzeichnis.
> Oder interpretieren einen solchen Verzeichnisnamen falsch.
Mal sehen, wie viele Methoden es noch gibt, sich zum Vollidioten zu machen.
Ich kenne eine.
Detlef
Stefan Kanthak
> Stefan Kanthak schrieb:
>> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
[ Trennung Betriebssystem von Daten ]
>> Nur Vollidioten legen Daten in ein D:\Programme\ genanntes Verzeichnis.
>
> Du hast mich falsch verstanden.
>
> Programme sind auch nur Daten. Darauf zielte meine Bemerkung.
Ein Betriebssystem ebenfalls.
Willst Du dem Herrn Hullen Konkurrenz machen?
>> Oder interpretieren einen solchen Verzeichnisnamen falsch.
>
> Ich interpretiere ihn durchaus richtig.
Die Schoenheit liegt im Auge des Betrachters.-(
Claus Reibenstein
> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
>
>> Programme sind auch nur Daten. Darauf zielte meine Bemerkung.
>
> Ein Betriebssystem ebenfalls.
> Willst Du dem Herrn Hullen Konkurrenz machen?
Mitnichten. Ich heiße nicht Stefan Kanthak ...
Mit solchen Haarspaltereien kommen wir nicht weiter.
>>> Oder interpretieren einen solchen Verzeichnisnamen falsch.
>>
>> Ich interpretiere ihn durchaus richtig.
>
> Die Schoenheit liegt im Auge des Betrachters.-(
Was hat das jetzt mit Schönheit zu tun?
Gruß. Claus
Stefan Kanthak
> Stefan Kanthak schrieb:
[ D:\Programme\ ]
>>>> Oder interpretieren einen solchen Verzeichnisnamen falsch.
>>>
>>> Ich interpretiere ihn durchaus richtig.
>>
>> Die Schoenheit liegt im Auge des Betrachters.-(
>
> Was hat das jetzt mit Schönheit zu tun?
Nur Vollidioten interpretieren X:\Programme\ (im englischen Original
deutlich besser: "X:\Program Files\") als moeglichen Ablageort fuer
Daten.
Ab eNTe 6.x begluecken Dich Bill G^HBo und Kumpane zur deutlichen
Abgrenzung noch mit einem "C:\ProgramData\".
Claus Reibenstein
> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
>
>> Stefan Kanthak schrieb:
>>
>>> Die Schoenheit liegt im Auge des Betrachters.-(
>>
>> Was hat das jetzt mit Schönheit zu tun?
>
> Nur Vollidioten interpretieren X:\Programme\ (im englischen Original
> deutlich besser: "X:\Program Files\") als moeglichen Ablageort fuer
> Daten.
Womit der Kreis geschlossen wäre. Herzlichen Glückwunsch!
Was das mit Schönheit zu tun haben soll, weiß ich allerdings immer noch
nicht. Aber egal.
Für mich ist hier jedenfalls EOD.
Gruß. Claus
Uwe Premer
> Claus Reibenstein:
>
>> Allerdings geht es mir mehr um Inhalte als um Form.
>
> Das kannst du jetzt natürlich nur dann lesen, wenn du's in einem Zitat
> findest, ich weiß. <bg>
Er kann's ja bei Groups-Google nachlesen, ein XNA hast du ja nicht gesetzt.
Uwe, EOD für mich an der Stelle. ;-)
Stefan Kanthak
> Stefan Kanthak schrieb:
>
>> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
>>
>>> Stefan Kanthak schrieb:
>>>
>>>> Die Schoenheit liegt im Auge des Betrachters.-(
>>>
>>> Was hat das jetzt mit Schönheit zu tun?
Der Zweck von Verzeichnissen wie X:\Programme\, "C:\Program Files\"
und C:\ProgramData\ ist durch den "sprechenden" Verzeichnisnamen jedem
Betrachter sofort klar, oder auch augenblicklich erfassbar... es sei
denn, der Blick ist durch den ebenso sprichwoertlichen Balken im Auge
oder das Brett vorm Kopf verstellt/vernagelt.
Wolfgang Bauer
> Der Zweck von Verzeichnissen wie X:\Programme\, ...
Und was spricht gegen X:ßProgramme, in meinem Fall D:\Programme?
Für Programme, nicht für Daten (soweit das Programm es ermöglicht)
Jörg Tewes
>> Ja, darum kann bei dir auch jedes Programm unter einem
>> eingeschränkten Account amoklaufen. D:\Programme ist als
>> eingeschränkter User nicht schreibgeschützt.
> Das laesst sich aendern.-P
Ich weiß. Hat Wolfgang aber nicht gemacht.
Bye Jörg
--
Diskutiere nie mit Idioten, Ignoranten oder Pers÷nlichkeitsgest÷rten - zuerst
ziehen sie dich auf ihr Niveau herab und dann schlagen sie
dich mit ihrer Erfahrung!
Jörg Tewes
> Jörg Tewes:
Ich schrieb ja explizit "bei dir". Da Wolfgang als eingeschränkter
User in das Programmverzeichnis schreiben kann hat er die Möglichkeit
nicht genutzt.
Bye Jörg
--
"I never thought there could be anything worse than being all alone in the
night." "But there is, being all alone in a crowd."
(Sheridan and Delenn, "There All The Honor Lies")
Stefan Kanthak
> Stefan Kanthak schrieb:
>
>> Der Zweck von Verzeichnissen wie X:\Programme\, ...
>
> Und was spricht gegen X:ßProgramme, in meinem Fall D:\Programme?
Dass die dort installierten Programme OHNE ihre Registry-Eintraege
i.A. nicht funktionieren und diese willkuerliche Trennung daher nicht
sinnvoll ist!
Wolfgang Bauer
> "Wolfgang Bauer" <bau...@aon.at> schrieb:
>> Und was spricht gegen X:ßProgramme, in meinem Fall D:\Programme?
> Dass die dort installierten Programme OHNE ihre Registry-Eintraege
> i.A. nicht funktionieren und diese willkuerliche Trennung daher nicht
> sinnvoll ist!
Nach einer Neuinstallation des Systems sind auch die Registry Einträge
von C:\Programme weg.
Auf der anderen Seite habe ich immer ein aktuelles Image der
Systempartition und beim Restore auch die Registryeinträge wieder.
Wolfgang Bauer
> Stefan Kanthak schrub
>>> Ja, darum kann bei dir auch jedes Programm unter einem
>>> eingeschränkten Account amoklaufen. D:\Programme ist als
>>> eingeschränkter User nicht schreibgeschützt.
>> Das laesst sich aendern.-P
> Ich weiß. Hat Wolfgang aber nicht gemacht.
Was habe ich nicht gemacht? Und was soll da amok laufen?
Mir scheint es eher gefährlich wenn ich einem Programm erhöhte Rechte
geben muß damit es seine Daten in C:\Programme schreiben kann.
Ja, mein lokaler Server Hamster und mein Newsclient Dialog schreiben
ihre Daten in den Programmordner.
Hans-Peter Matthess
>> Ich weiß. Hat Wolfgang aber nicht gemacht.
> Was habe ich nicht gemacht?
D:\Programme die gleichen Rechte wie %Programfiles% gegeben.
> Und was soll da amok laufen?
Das erkennst du, wenn du dir vor Augen führst, warum man %Programfiles%
die besagten Rechte gegeben hat.
> Mir scheint es eher gefährlich wenn ich einem Programm erhöhte Rechte
> geben muß damit es seine Daten in C:\Programme schreiben kann.
Das eine ist so dämlich/gefährlich wie das andere.
> Ja, mein lokaler Server Hamster und mein Newsclient Dialog schreiben
> ihre Daten in den Programmordner.
Dialog schreibt seine Daten hier nicht in den Programmordner.
hpm
Wolfgang Bauer
> Wolfgang Bauer:
>> Was habe ich nicht gemacht?
> D:\Programme die gleichen Rechte wie %Programfiles% gegeben.
In %Programfiles% gibt es, ohne explizit erhöhte Rechte, was ich nicht
gemacht habe, keine Schreibrechte ohne am UAC Promt zu bestätigen.
Die Rechte auf %Programfiles% sind als Benutzer hier standardmäßig
"Lesen, Ausführen", "Ordnerinhalt anzeigen" und "Lesen", *nicht "schreiben"*
>> Und was soll da amok laufen?
> Das erkennst du, wenn du dir vor Augen führst, warum man %Programfiles%
> die besagten Rechte gegeben hat.
Auf D:\Programme habe ich Vollzugriff.
>> Ja, mein lokaler Server Hamster und mein Newsclient Dialog schreiben
>> ihre Daten in den Programmordner.
> Dialog schreibt seine Daten hier nicht in den Programmordner.
Wie hast Du das gemacht?
Hans-Peter Matthess
>>> Was habe ich nicht gemacht?
>> D:\Programme die gleichen Rechte wie %Programfiles% gegeben.
> In %Programfiles% gibt es, ohne explizit erhöhte Rechte, was ich nicht
> gemacht habe, keine Schreibrechte ohne am UAC Promt zu bestätigen.
> Die Rechte auf %Programfiles% sind als Benutzer hier standardmäßig
> "Lesen, Ausführen", "Ordnerinhalt anzeigen" und "Lesen", *nicht "schreiben"*
So ist das gewollt.
>>> Und was soll da amok laufen?
>> Das erkennst du, wenn du dir vor Augen führst, warum man %Programfiles%
>> die besagten Rechte gegeben hat.
> Auf D:\Programme habe ich Vollzugriff.
Eben - und alle Programme inkl. Malware ebenfalls.
>>> Ja, mein lokaler Server Hamster und mein Newsclient Dialog schreiben
>>> ihre Daten in den Programmordner.
>> Dialog schreibt seine Daten hier nicht in den Programmordner.
> Wie hast Du das gemacht?
Ganz einfach, ich habe "data" in meine Anwenderdaten verschoben und im
Programmverzeichnis von Dialog eine gleichnamige Junction gesetzt.
hpm
Wolfgang Bauer
> Wolfgang Bauer:
>> Auf D:\Programme habe ich Vollzugriff.
> Eben - und alle Programme inkl. Malware ebenfalls.
Kann denn da das System/Systemdateien betroffen werden? Kann da ein
Trojaner Schaden anrichten, sich ein Keylogger breitmachen? Wie gesagt
ich bin kein Experte.
>> Wie hast Du das gemacht?
> Ganz einfach, ich habe "data" in meine Anwenderdaten verschoben und im
> Programmverzeichnis von Dialog eine gleichnamige Junction gesetzt.
Hm, mit Junction habe ich micht noch nicht befaßt, muß ich mal
nachholen.
Hans-Peter Matthess
>> Eben - und alle Programme inkl. Malware ebenfalls.
> Kann denn da das System/Systemdateien betroffen werden? Kann da ein
> Trojaner Schaden anrichten, sich ein Keylogger breitmachen? Wie gesagt
> ich bin kein Experte.
Du solltest dir halt mal vor Augen führen, warum man %programfiles" die
Rechte gab, die es hat. Malware überall das machen, was die Rechte
erlauben.
>> Ganz einfach, ich habe "data" in meine Anwenderdaten verschoben und im
>> Programmverzeichnis von Dialog eine gleichnamige Junction gesetzt.
> Hm, mit Junction habe ich micht noch nicht befaßt, muß ich mal
> nachholen.
Es funktioniert bestens, nur nach Komprimieren der Datenbank benennt
Dialog den Ordner data immer um und erstellt einen neuen.
Da muss man dann manuell nachbessern. Aber ich komprimiere nur alle
Jubeljahre mal.
hpm
Hans-Peter Matthess
> Malware ... überall das machen
Ich kaufe ein "kann".