Kleine Programme als Portable Anwendungen programmieren?



  • Hallo, ich habe gemerkt das immer mehr portable Anwendungen bevorzugt werden, also solche die ihre Einstellungen Lokal im Verzeichnis speichern und nicht an Orten wie der Registry. Was meint Ihr welche Art von Anwendungen lohnt es sich als Portable zu programmieren?



  • kleine.

    BTW bin ich immer ein Freund von Anwendungen gewesen, die diesen Microsoft-Schwachsinn der zentralen Konfigurationsstelle nicht mitgemacht haben.

    greetz, Swordfish



  • also ich habe schon recht viele mini-tools programmiert und ich schwöre auch dadrauf, dass ich sie aufm usb-stick umhertragen kann...



  • Anwendungen, die ihre Daten im Anwendungsverzeichnis speichern, laufen unter korrekt administrierten Systemen nicht richtig, weil sie dort keine Schreibrechte haben.
    Am besten ist es, wenn du dem Anwender die Wahl läßt, ob er die Programmdaten im Anwendungs- oder im AppData-Verzeichnis haben will, z.B. über eine .INI-Datei.



  • Also meiner meinung nach kommt es auf das prog an, aber finde auch, dass man dem nutzer die Wahl lassen sollte, zum beispiel prüft man, of die Datei im AppData existiert, wenn nicht, ob im Programmverzeichnis, wen nicht, fragt man, wo sie erstellt werden sollte.



  • audacia|off schrieb:

    Anwendungen, die ihre Daten im Anwendungsverzeichnis speichern, laufen unter korrekt administrierten Systemen nicht richtig, weil sie dort keine Schreibrechte haben.
    Am besten ist es, wenn du dem Anwender die Wahl läßt, ob er die Programmdaten im Anwendungs- oder im AppData-Verzeichnis haben will, z.B. über eine .INI-Datei.

    Anwendungsverzeichnis ist doch /Documents and Settings/User/ ? Wieso sollte der User dort keine Schreibrechte haben?



  • mit anwendungsverzeichnis ist das verzeichnis gemeint, wo die exe drin liegt, denke ich



  • Die Sache mit dem home-Verzeichnis sollte man immer bevorzugen, schon allein, um sich eine User-Verwaltung für die Konfigurations-Daten zu ersparen. Außerdem geht das auf fast allen Systemen gut, nur die Umgebungsvariablen heißen uU anders.
    Sinnvoll finde ich einen Fallback-Mechanismus, der zuerst versucht, Einstellungen aus dem User-Verzeichnis zu laden, und falls das fehlschlägt Einstellungen aus einer (globalen) Datei lädt (auf die vielleicht nur der Administrator Schreibzugriff hat -- aber das geht den Programmierer nichts an).



  • Ich würde globale meine Einstellungen grundsätzlich aus /etc/appname und benutzerspezifische Einstellungen aus $HOME/.appname lesen. Gespeichert wird immer in $HOME/.appname. Das geht dann auf praktisch jedem Betriebssystem. Lediglich Windows bleibt dann aussen vor 😃 .



  • Na na, Windows hat auch sowas wie $HOME! Weiß nur nicht wie die Variable dazu heißt. 😉



  • %USERPROFILE%



  • Artchi schrieb:

    Na na, Windows hat auch sowas wie $HOME! Weiß nur nicht wie die Variable dazu heißt. 😉

    %HOMEDRIVE%%HOMEPATH%

    %HOMEDRIVE% ist in der Regel C:, %HOMEPATH% dann "\Dokumente und Einstellungen\%USERNAME%" bei XP, bzw. "\Users\%USERNAME%" bei Vista.
    Alternativ existiert noch %USERPROFILE%, das den selben Wert wie die beiden obigen beinhaltet

    @T: Lass dem User die Wahl. Vor allem bei Konfigurationsdateien ist es auf Multi-User-Systemen ärgerlich, wenn man diese nicht personalisieren kann. Außerdem bleibt da noch der Punkt mit den fehlenden Schreibrechten im Programmverzeichnis. Es zeugt von schlechten Stil, wenn ein Programm nur wegen der konsequenten Missachtung der Sicherheitsrichtlinien Admin-Rechte benötigt um zu funktionieren.
    Wo du derartige Dateien speichern solltest, kannst du ganz einfach aus der Registrierung auslesen. Der Schlüssel befindet sich unter HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\AppData . Wenn du keine Lust hast, die dortigen Umgebungsvariablen selbst zu übersetzen, steht unter ..\Shell Folders\AppData der entsprechend bereits übersetzte Wert bereit. Microsoft rät aber von der Verwendung dieses Schlüssels ab.

    Ansonsten solltest du dir das mal durchlesen...



  • Artchi schrieb:

    Na na, Windows hat auch sowas wie $HOME! Weiß nur nicht wie die Variable dazu heißt.

    für 'richtige' windoze-programme: %SystemRoot%
    🙂



  • Machine schrieb:

    also ich habe schon recht viele mini-tools programmiert und ich schwöre auch dadrauf, dass ich sie aufm usb-stick umhertragen kann...

    dito. einfach das verzeichnis auf den stick kopieren und man nimmt gleich alle settings mit. mache ich auch immer so.
    🙂



  • zwutz schrieb:

    Artchi schrieb:

    Na na, Windows hat auch sowas wie $HOME! Weiß nur nicht wie die Variable dazu heißt. 😉

    %HOMEDRIVE%%HOMEPATH%

    %HOMEDRIVE% ist in der Regel C:, %HOMEPATH% dann "\Dokumente und Einstellungen\%USERNAME%" bei XP, bzw. "\Users\%USERNAME%" bei Vista.
    Alternativ existiert noch %USERPROFILE%, das den selben Wert wie die beiden obigen beinhaltet

    Das ist so typisch MS. Wieso einfach, wenn es auch kompliziert geht? Ansatt ins %HOMEPATH% einfach den Pfad (C:/DuE/Username) anzugeben, braucht man auch noch %HOMEDRIVE%.

    Da goenn ich doch ds Unix-Filesystem. Ich schreib einfach alles ins /home/user und mir ist es egal, ob /home/user in einem Netzwerk, auf einem Bandlaufwerk oder auf dem Mond liegt.



  • DEvent schrieb:

    Das ist so typisch MS. Wieso einfach, wenn es auch kompliziert geht? Ansatt ins %HOMEPATH% einfach den Pfad (C:/DuE/Username) anzugeben, braucht man auch noch %HOMEDRIVE%.

    Da goenn ich doch ds Unix-Filesystem. Ich schreib einfach alles ins /home/user und mir ist es egal, ob /home/user in einem Netzwerk, auf einem Bandlaufwerk oder auf dem Mond liegt.

    deswegen existiert auch %USERPROFILE%, wie ich aber oben bereits erwähnt habe

    die Trennung besteht, da man dann zum Beispiel innerhalb einer Batch-Datei mittels

    %HOMEDRIVE%
    cd %%HOMEPATH%
    

    in den Benutzerordner gelangt, auch wenn man sich auf nem anderen Laufwerk befindet. ( cd kann nur innerhalb eines Laufwerkes navigieren)



  • SHGetFolderPath



  • DEvent schrieb:

    Da goenn ich doch ds Unix-Filesystem. Ich schreib einfach alles ins /home/user und mir ist es egal, ob /home/user in einem Netzwerk, auf einem Bandlaufwerk oder auf dem Mond liegt.

    Besser man nimmt die Umgebungsvariable HOME. Schade, daß Microsoft nicht die Mühe macht und einfach HOME auf %HOMEDRIVE%/%HOMEPATH% oder was auch immer zu setzen. Dann könnte man selbst unter Windows einfach HOME nehmen und braucht sich nicht darum zu kümmern, daß ein völlig anderes Betriebssystem vorliegt.

    Übrigens fürchte ich, daß das I/O selbst für einfache Konfigurationsdateien ungenügend ist, wenn mein Homeverzeichnis auf dem Mond liegt 😃 .



  • zwutz schrieb:

    DEvent schrieb:

    Das ist so typisch MS. Wieso einfach, wenn es auch kompliziert geht? Ansatt ins %HOMEPATH% einfach den Pfad (C:/DuE/Username) anzugeben, braucht man auch noch %HOMEDRIVE%.

    Da goenn ich doch ds Unix-Filesystem. Ich schreib einfach alles ins /home/user und mir ist es egal, ob /home/user in einem Netzwerk, auf einem Bandlaufwerk oder auf dem Mond liegt.

    deswegen existiert auch %USERPROFILE%, wie ich aber oben bereits erwähnt habe

    die Trennung besteht, da man dann zum Beispiel innerhalb einer Batch-Datei mittels

    %HOMEDRIVE%
    cd %%HOMEPATH%
    

    in den Benutzerordner gelangt, auch wenn man sich auf nem anderen Laufwerk befindet. ( cd kann nur innerhalb einhttp://www.german-bash.org/action/latestes Laufwerkes navigieren)

    Das stimmt nicht cd kann auch das Laufwerk wechseln. Gib einfach mal cd /? ein und schau dir die Flags an.



  • lolz_ausgeloggt schrieb:

    Das stimmt nicht cd kann auch das Laufwerk wechseln. Gib einfach mal cd /? ein und schau dir die Flags an.

    der parameter /D ist mir durchaus bekannt, aber cd ohne Parameter, so wie er oft verwendet wird, kann nur innerhalb des Laufwerkes navigieren.

    tntnet schrieb:

    Besser man nimmt die Umgebungsvariable HOME. Schade, daß Microsoft nicht die Mühe macht und einfach HOME auf %HOMEDRIVE%/%HOMEPATH% oder was auch immer zu setzen. Dann könnte man selbst unter Windows einfach HOME nehmen und braucht sich nicht darum zu kümmern, daß ein völlig anderes Betriebssystem vorliegt.

    das würde schon aus dem Grund schiefgehen, da beide Systeme unterschiedliche Methoden nutzen, Umgebungsvariablen zu kennzeichen. Unter Windows sind sie mit Prozentzeichen eingeschlossen, Unix verwendet das Dollarzeichen am Beginn der Variable


Log in to reply