Wie kriege ich raus wo meine Anwendung liegt...

[corpsman]

Zusammenfassend kann man also sagen, müsste ich eigentlich meine Anwendung nicht als .zip ausliefern, sondern mit einem Installer, der unter Linux das binary nach /usr/local kopiert und alle Daten im GetAppConfigDir(False), egal ob diese verändert werden oder nicht ablegt. Damit würde sich dann auch mein ursprüngliches Problem direkt erledigen, da es dieses dann schlicht nicht mehr gibt.

[Timm Thaler]

Zusammenfassend kann man also sagen, müsste ich eigentlich meine Anwendung nicht als .zip ausliefern, sondern mit einem Installer, der unter Linux das binary nach /usr/local kopiert und alle Daten im GetAppConfigDir(False), egal ob diese verändert werden oder nicht ablegt. Damit würde sich dann auch mein ursprüngliches Problem direkt erledigen, da es dieses dann schlicht nicht mehr gibt.

Naja, genaugenommen müsstest Du unter Linux so lange betteln, bis Deine Anwendung in die entsprechenden Repos aufgenommen wird. Und wie gut das funktioniert sehen wir ja bei Lazarus, wo die Version in den Repos immer so 2 Jahre hinterherhängt.

Denn ein Installer, der ein Binary nach usr/local kopiert UND ausführbar macht, braucht meines Wissens wieder sudo, darf also auch wieder das System kaputtmachen oder Schadsoftware installieren. Dann gäbe es noch das Verzeichnis /opt für externe Programme, die nicht in den Repos sind.

[kupferstecher]

Zusammenfassend kann man also sagen, müsste ich eigentlich meine Anwendung nicht als .zip ausliefern,

Unter Windows ist das ja ein aehnliches Problem. Bei Portable Apps weiss ich nie wo ablegen. Unter C:Programme passt nicht, weil das Programm dort keine Configs schreiben darf. Trotzdem finde ich es als Nutzer angenehmer, einfach eine Exe zu starten anstatt erst eine Installation durchzufuehren, die sich irgendwie - man weiss nicht wie - ins System eingraebt. Gern mal noch mit Fehlern, weil irgend ein Pfad nicht passt. Selbst die Deinstallation kann noch schief gehen...

[Timm Thaler]

Unter Windows ist das ja ein aehnliches Problem. Bei Portable Apps weiss ich nie wo ablegen. Unter C:Programme passt nicht, weil das Programm dort keine Configs schreiben darf.

Doch, im Prinzip schon. Windows packt die dann in ein "Schattenverzeichnis" ins Userverzeichnis: C:\Users\Ich\AppData\Local\VirtualStore\Program Files (x86)\PonyProg2000

Damit ist die Kombatibilität gegeben für Programme, die noch die ini ins eigene Programmverzeichnis speichern. Eigentlich gar nicht so schlecht gelöst, aber: Wenn man das nicht weiss, sucht man sich nen Wolf, denn im Programmverzeichnis liegt immer noch die alte unangetastete ini - ohne die Änderungen.

[six1]

Da wird wohl jeder für seine Anwendung passend, seinen Weg finden müssen.
Einige meiner Anwendungen werden zentral in großen Netzwerken zur Verfügung gestellt.
Die "Exe" wird also von zentraler Stelle irgendwo in einer Share gestartet und legt dann auf dem jeweiligen Client unter c:\Users\<NAME>\ ein Projektverzeichniss mit den nötigen lokalen Dateien an.

Eigentlich bin ich im Laufe der Zeit dazu über gegangen, das grundsätzlich so zu handhaben.
Einen Ordner mit Projektnamen und darunter die ausführbare Datei und von diesem Root aus die nötigen Unterverzeichnisse.
Dadurch liegt alles in einem Ordner und ist beisammen... ein Löschen der Applikation ist dann nur noch ein Löschen des Basisordners.
Passt natürlich nicht in die Microsoft Philosophie, aber die haben das ja auch ständig geändert über die Jahre, solange ich dabei bin und das ist seit WIN 3
Außerdem ist mein favorisiertes Vorgehen nicht von WIN abhängig! Oftmals habe ich die WIN-EXE und das Linux Binary nebeneinander im Ordner liegen.
Die Struktur funktioniert dann auf WIN und X Systemen...

[kupferstecher]

Doch, im Prinzip schon. Windows packt die dann in ein "Schattenverzeichnis" ins Userverzeichnis
[...]
Eigentlich gar nicht so schlecht gelöst, aber

Ja, gehen tut es. Fühlt sich halt nicht richtig an, gerade wenn man darum weiß.
Ändert man die Einstellungen in der Benutzerkontensteuerung, dann wird wieder nicht der Virtual Store verwendet... Ich habe mal einen Audioplayer benutzt, der daraufhin die Einstellungen komplett verworfen hat und auch ein Zurückstellen der Benutzerkontensteuerung hat nichts genutzt. Da muss irgend ein Manipulationsschutz im Programm die Konfigdatei "abgesichert" haben.

[Timm Thaler]

Fühlt sich halt nicht richtig an, gerade wenn man darum weiß.

Welche Möglichkeiten hätte man denn sonst Programme, die noch das alte ini-System nutzen weiter zu verwenden?

Bei Linux sieht das nicht besser aus: Entweder liegen Konfigs in /etc, dann darf die aber auch nur der root bearbeiten. Oder sie liegen wild im /home als .program, in .program/xxx.conf, in .config/program.conf oder .config/program/xxx.conf verteilt. Jeder wie er lustig ist, selbst "große" Anbieter wie Mozilla machen da was sie wollen.

[kupferstecher]

Welche Möglichkeiten hätte man denn sonst Programme, die noch das alte ini-System nutzen weiter zu verwenden?

Man kann direkt unter C: ein eigenes Verzeichnis anlegen, wo das Programm drinliegt (FPCUpDeluxe macht das so) oder irgendwo in den eigenen Dateien, was aber auch wieder nicht schön ist (Trennung Programme/Daten). Der VirtualStore ist natürlich wichtig für Programme, die sich in geschützten Verzeichnissen installieren.

Wie gesagt, grundsätzlich bevorzuge ich nach wie vor so Programme gegenüber einem Installer, zumindest bei kleineren Sachen. Dann gibts halt einen gewissen Wildwuchs mit den Ordnern, ist aber nicht so schlimm...

[Timm Thaler]

Man kann direkt unter C: ein eigenes Verzeichnis anlegen, wo das Programm drinliegt (FPCUpDeluxe macht das so)...

Äh, das ist so richtig häßlich, da hat man dann direkt unter C: einen Haufen Programmverzeichnisse liegen. So war das nicht gedacht.

FPCUpDeluxe installiert bei mir nach C:\Tools\Lazarus_xxx. FPCUpDeluxe könnte direkt nach C:\Programme installieren, denn FPCUpDeluxe verlangt eh nach Admin-Rechten. Wenn da nicht die kleine Macke von Lazarus wäre, mit Leerzeichen im FPC Pfad nicht klarzukommen, und dummerweise ist C:\Programme ein Link auf C:\Program Files. Bämm! Und unter C:\Programme würde Neu-Kompilieren von Lazarus bei der Installation neuer Packages nicht funktionieren.

[corpsman]

Vielen Dank für all eure Anmerkungen,

Ich denke da bleibe ich vorerst bei meiner Variante

Alles im Verzeichnis der Anwendung (.ini und in unterverzeichnissen) Das ist tatsächlich für die Entwicklung am einfachsten.

Die nummer mit den PID's unter Linux probiere ich aber mal aus, wenn das ordentlich geht, wäre das dann eine Linux Sichere Paramstr(0) ersatz variante *g*.

[af0815]

Ich habe unter win ein data Verzeichnis unter der root liegen, das ist genau für solche Sachen. Darunter gibt's es dann die weiteren Verzeichnisse. Das Data wird auch ins Backup einbezogen und damit ist alles gut.