ein Fass nach dem anderen geht auf

[TigerLilly]

Mit Inno-Setup geht das wirklich gut:

https://jrsoftware.org/ishelp/index....ldeletesection
https://jrsoftware.org/ishelp/index...._uninstallable
https://jrsoftware.org/ishelp/index....criptuninstall

[Codehunter]

Windows hat irgendwo eine eigene API um Dateien, die aktuell verwendet werden, für die Löschung beim nächsten Systemstart vorzumerken. Vor unendlich langer Zeit hatte ich dafür in DelphiWorks eine Funktion gemacht. Keine Ahnung ob das heute noch funktioniert.

Die Unsitte, ganze Programme nach %APPDATA% zu installieren, kenne ich auch von vielen Programmen. Meist sind es solche, die X-Plattform sind und sich kaum an die historisch verworrene Ordnerstruktur von Windows anpassen lassen.

Letztendlich hat Microsoft das Problem aber selbst geschaffen! Historischer Rückblick aus meiner Erinnerung:

• 1985: Programme installieren sich unter DOS nach C:\Programmname
• 1990: Programme unter Windows 2.x installieren sich nach C:\Programmname
• 1995: Programme unter Windows 95 installieren sich nach C:\Programmname
• 1999: Programme unter Windows 98 installieren sich unter C:\Programme\Programmname
• 2001: Programme unter Windows XP installieren sich unter C:\Program Files\Programmname und werden über Symlinks nach C:\Programme\Programmname gemappt
• 2007: 32-Bit-Programme unter Windows Vista installieren sich unter C:\Program Files (x86)\Programmname, werden über Symlinks nach C:\Programme (x86)\Programmname gemappt und von der UAC gegängelt
• 2007: 64-Bit-Programme unter Windows Vista installieren sich unter C:\Program Files\Programmname, werden über Symlinks nach C:\Programme\Programmname gemappt und von der UAC gegängelt
• 2009: Programme unter Windows 7 installieren sich häufiger unter C:\Program Files\Programmname, weil beide Systemvariablen %PROGRAMFILES% und %ProgramW6432% dorthin verweisen und die UAC dort nicht drauf schaut
• 2012: Programme unter Windows 8 (insbesondere Treiber-Installer) installieren sich unter C:\Programmname, weil die UAC mittlerweile auch auf %PROGRAMDATA% und %PROGRAMFILES% achtet
• 2015: Programme installieren sich unter %APPDATA% und damit auf Multi-User-Arbeitsplätzen gleich mehrfach, weil die UAC bei Installern anschlägt, die Pfade wie C:\Programmname verwenden

Also ich finde das alles Quark im Quadrat. Mittlerweile ist sogar die halbe Systemordnerstruktur gemappt. Teilweise erscheinen im Explorer Einträge wie C:\Programme sogar doppelt (!!!) wobei einer auf C:\Program Files mappt und der andere mit einem "Zugriff verweigert" versandet.

Das einzig Gute an der heutigen Situation ist, dass nach und nach alle älteren Windows-Installationen abgelöst werden und sich auf Windows 10 vereinheitlicht. Doch was soll das Theater mit der UAC in den Programmordnern? Was hat es bitteschön mit Sicherheit zu tun, sich an bestimmten Ordnernamen hochzuziehen? Eigentlich ein Armutszeugnis an Microsoft, dass es da überhaupt Unterscheidungen braucht. Für mich die logische Konsequenz, dass entweder A) die Softwareanbieter auf weniger supportanfällige Ordnerstrukturen ausweichen oder B) die Anwender die UAC abklemmen oder C) beides eintritt.

Persönliche Meinung: Beruflich entwickle ich für Windows und sehe all die praktischen Probleme. Privat nutze ich nur noch Linux. @Embarcadero: Packt endlich den Linux-Compiler in alle Delphi-Editions rein und übernehmt CrossVCL ins RAD Studio! Zum Bsp. im öffentlichen Bereich, bei Verwaltungssoftware, wo Delphi noch häufig zum Einsatz kommt, geht der Trend eindeutig weg von Windows. Da wartet keine Softwarebude mehr, dass sich Emba irgendwann mal auskekst, sondern da wird bei älteren Projekten entweder auf Lazarus migriert oder bei neueren Projekten gleich auf Java o.ä. gesetzt.

[jaenicke]

Zitat von Codehunter:

Letztendlich hat Microsoft das Problem aber selbst geschaffen!
[..]

C:\Program Files bzw. c:\programme kam mit Windows 95 parallel mit der Registry (und danach kam dann das Mapping und intern wurde nur noch das englische Verzeichnis verwendet). Hätten damals alle Entwickler die vom System vorgegebenen Möglichkeiten zur dynamischen Bestimmung des Ordners für die Installation von Programmen verwendet, wären danach auch keine Anpassungen nötig gewesen, auch nicht durch die Umleitungen. Auch die Speicherung von Daten im Programmverzeichnis war schon mit Windows 95 nicht mehr vorgesehen. Es haben nur viele trotzdem gemacht und sich dann gewundert als mit Vista der Pfusch dann aufgefallen ist...

Die Ursache ist nicht nur bei Microsoft zu suchen, sondern vielmehr bei Unwissenheit oder Ignoranz vieler Entwickler. Denn viele haben es ja auch noch weiter so gemacht als man es ihnen schon längst gesagt hatte. Das sieht man ja an den diversen Fragen zu Workarounds statt richtiger Lösungen.

Zitat von Codehunter:

Also ich finde das alles Quark im Quadrat. Mittlerweile ist sogar die halbe Systemordnerstruktur gemappt. Teilweise erscheinen im Explorer Einträge wie C:\Programme sogar doppelt (!!!) wobei einer auf C:\Program Files mappt und der andere mit einem "Zugriff verweigert" versandet.

Dann ist Windows einfach ungünstig konfiguriert. Standardmäßig ist das nicht so.
Wenn man nicht nur versteckte Dateien und Ordner anzeigen lässt, sondern auch geschützte Systemdateien, dann bekommt man eben auch Einträge, mit denen man nichts anfangen kann...

(Das hat sich aber auch geändert. Anfangs fielen auch Einträge unter Systemdateien, die man vielleicht mal sehen wollte. Aber seit Windows 7 oder 8 gibt es so gut wie nie einen Fall, in dem es sinnvoll ist auch geschützte Systemdateien einzublenden.)

[Codehunter]

Wie gesagt, aus der Erinnerung. Ist ja auch schon 25 Jahre her Aber:

Zitat von jaenicke:

C:\Program Files bzw. c:\programme kam mit Windows 95 parallel mit der Registry (und danach kam dann das Mapping und intern wurde nur noch das englische Verzeichnis verwendet).

Einspruch! Eben mal fix ein deutsches Win 95 in der VM installiert. Geht ja schnell auf einem heutigen Ryzen Der DOS-Pfad lautet C:\PROGRA~1 (die DOS-Shell konnte noch kein VFAT und verwendete die 8.3-Namen) und in der VFAT-Tabelle heißt der Eintrag C:\Programme. Leerzeichen in Ordnernamen wie bei C:\Program Files waren damals ganz und gar unmöglich.

Aber ganz egal, die Ordnerschluderei wurde ja nicht durch die Ordnernamen begründet. Die waren seit eh und je abhängig von der Lokalisierung. Die Ursache war/ist die UAC und der Defender, die Dateioperationen im Programmordner sabotieren. In meinen Augen darf es keinen Unterschied machen, WO ein Programm installiert ist. Die Systemsicherheit muss sich immer gleich verhalten. Dann hätte es das Ausweichverhalten der Entwickler ja nie gebraucht.

[jaenicke]

Zitat von Codehunter:

Eben mal fix ein deutsches Win 95 in der VM installiert.

Das führt in dem Thread etwas weit, aber wenn du ein englisches Windows 95 nimmst, hast du c:\Program Files. Lediglich das Mapping und die Verwendung des englischen Verzeichnisnamens im deutschen Windows kamen später.
Und Leerzeichen in Ordnernamen gingen bei Windows 95 durchaus schon.

Zitat von Codehunter:

In meinen Augen darf es keinen Unterschied machen, WO ein Programm installiert ist. Die Systemsicherheit muss sich immer gleich verhalten.

Wie das rein theoretisch funktionieren sollte erschließt sich mir nicht. Unterschiedliche Rechte auf unterschiedliche Ordner und das entsprechende Handling sind doch grundlegend wichtig.

[Codehunter]

Zitat von jaenicke:

Zitat von Codehunter:

In meinen Augen darf es keinen Unterschied machen, WO ein Programm installiert ist. Die Systemsicherheit muss sich immer gleich verhalten.

Wie das rein theoretisch funktionieren sollte erschließt sich mir nicht. Unterschiedliche Rechte auf unterschiedliche Ordner und das entsprechende Handling sind doch grundlegend wichtig.

Da bin ich vllt. inzwischen etwas von Linux verwöhnt Stark vereinfacht gesagt, überwacht Windows das Laufzeitverhalten von Anwendungen und greift gelegentlich in u.a. Dateioperationen ein. Wenn ich z.B. in %PROGRAMFILES%\Programmname eine Datei erstellen will, geht das nicht ohne Adminrechte. Nur dummerweise geht das ohne Exception o.ä. vonstatten. Der Schreibversuch geht einfach ins Nirvana (bei Linux würde man sagen /dev/null). Da sucht man schon mal bis man das Problem findet. Genau dieses Verhalten dürfte auch der Grund für diesen Thread hier gewesen sein. Das kann bei großen, alten Projekten mit zugekauften Libs richtig in Arbeit ausarten. Ich erinnere mich noch mit Grausen an BDE-Programme mit Paradox-Datenbanken, die mit im Programme-Ordner lagen, wo selbst bei reinen Lesezugriffen immer noch in irgendwelchen Indexdateien geschrieben wurde.

Bei Linux erbt eine Programminstanz ihre Zugriffsrechte ausgehend vom ELF-Objekt. Versucht man aus so einer Instanz einen schreibenden Resourcenzugriff auf ein Objekt, das keine Übereinstimmung bei den schreibenden Zugriffsrechten hat (User und/oder Gruppe), wird das verweigert. So ein "geht ein bisschen" Schreiben wie bei Windows gibts da nicht. Geht oder geht nicht, mit geordnetem Fehler-Handling.

EDIT als Ergänzung zum Verständnis, worin der Vorteil von Linux in dem Fall liegt: Wenn mein Programm seine Konfigurationsdateien ablegt, egal wo, dann erben die die selben Zugriffsrechte vom ELF-Objekt. Wenn jetzt ein fremdes Programm daher kommt, das in seinem eigenen Userspace agiert (Standardverhalten), dann kann es auf die Konfigurationsdateien meines Programms nicht zugreifen. Und dieser programmübergreifende Schutz ist bei Windows eben abhängig vom Installationspfad mehr oder weniger stringent, bei Linux überall gleich.

[himitsu]

Zitat:

einfach ins Nirvana

Nein?

Erstmal kann man im System, sowie auch im Programm derartige Redirections deaktivieren
und auch nicht immer wird umgeleitet. Das hängt z.B. vom Manifest ab (oder vom Dateinamen, wie z.B. "Setup") ob und welche "Abwärtskompatibilitäten" aktiv sind.


Und das ganze wurde nunmal eingebaut, damit alte "schrottige" Programme weiterhin funktionieren, wovon es leider zuviel gab/gibt.
Dass viele Entwickler und auch Endanwender damals oft mit Adminrechten arbeiteten und somit schon lange existierende Sicherheitsmaßnahmen/Beschränkungen umgangen, das war bissl blöd.
Und dass es zuviele "schlaue" Programmmierer gab, die Pfade hartgecoded hatten, zu einer Zeit als Pfade lokalisiert wurden und die sich über die Zeit auch mal änderten ... tja, pech.

[Codehunter]

Zitat von himitsu:

Das hängt z.B. vom Manifest ab (oder vom Dateinamen, wie z.B. "Setup")

Noch so eine Seuche! Stell dir mal vor wie es wäre, wenn eine Setup.exe SELBST nachprüft ob sie Adminrechte (vgl. "su" bei Linux) hat, anstatt ein Pappschild (Manifest) mit der Aufschrift "Bitte liebes System, gib mir mal Adminrechte" vor sich her zu tragen. Und wenns diese Rechte nicht hat, verlangt es danach. Diese Rechte vergäbe der User (bei Linux mit einem "sudo") und nicht das System.

Ein solches Setup würde die Dateien auf die verschiedenen Ordner verteilen und mit den korrekten Zugriffsrechten versehen (geerbt vom sudo aufrufenden Benutzer). Dann wäre es völlig Banane, ob diese Dateien nun in C:\Program Files oder C:\Users\... liegen, dein Programm hätte überall Zugriff darauf.

Damit sind wir nämlich beim entscheidenden Punkt: Bei Windows gibt es inzwischen Instanzen (z.B. SYSTEM) mit höheren Rechten, als jemals ein Anwender erlangen kann. Selbst als Admin stößt du immer wieder auf Dinge, wo dir der "Zugriff verweigert" wird. Ein Unding.

Schreibst du Systemdienste, dann laufen die bei Windows im SYSTEM-Kontext. Schreibst du einen Daemon für Linux, dann läuft der mit genau den Rechten, die ihm auf Dateiebene zugewiesen wurden. Schon mal versucht, mit einem Non-Admin-Programm unter Windows auf Dateien schreibend zuzugreifen, die dein eigener (!!!) Dienst erstellt hat?

Zitat von himitsu:

Und das ganze wurde nunmal eingebaut, damit alte "schrottige" Programme weiterhin funktionieren, wovon es leider zuviel gab/gibt.

Exakt. Windows NT 3.1 hatte das ursprünglich nicht und IMHO bis NT 5.0 (das gabs wirklich! Irgendwo habe ich noch eine Installation aus 1997 davon) auch nicht. Erst mit Windows 2000 wurde das Sicherheitskonzept abgeschwächt, um die 9x-User rüber zu locken. Ein harter Schnitt wäre damals die bessere Wahl gewesen, den man aus Marketinggründen nicht gewagt hat. Über die Jahre wurde dann ungleich mehr Supportaufwand reingesteckt als nötig gewesen wäre, hätte man es gleich richtig gemacht (ist ja oft so)

Deshalb finde ich es unfair, diesen inkonsistenten Murks den Entwicklern vorzuwerfen, die wie in diesem Fall seit 30 Jahren ein Projekt pflegen und das evtl. schon wie vom TE beschrieben ein eigenes Ökosystem bildet.

Um wieder auf das Eingangsthema zurück zu kommen und mich einigen Vorrednern anzuschließen: Mit Innosetup lässt sich das recht elegant lösen. Es gibt auch grafische IDEs dafür, z.B. Inno Script Studio (kostenlos) oder Install Designer (50 Euro), sodass der Lernaufwand überschaubar bleibt.

[himitsu]

Wie gesagt, das kommt drauf an.

Kleines Beispiel zum Selbstausprobieren:
* neue VCL-Anwendung erstellen und Setup.exe nennen
* in den Projektoptionen das Manifest entfernen (Ohne)
* kompilieren
* und ins Verzeichnis gucken C:\Users\%Username%\Documents\Embarcadero\Studio\Projekte\Win32\Debug
* Es wird im Programm-Icon vom Explorer ein Overlay eingeblendet (das Schutzschild) und beim Start geht der UAC auf
* nun das Manifest wieder aktivieren (Automatisch)
* neu erzeugen
* im Explorer verschwindet das Schutzschild-Overlay und der UAC meldet sich auch nicht mehr
* jetzt im Manifest die Ausführungsebene ändern (Admnistrator erforderlich)
* neu erzeugen
* schon ist UAC und Overlay wieder da, aber nicht wegen dem Namen, sondern weil du es beantragt hast

Emba hat inzwischen das Manifest aufgemotzt und unter Anderem auch die <supportedOS>-Abschnitte aufgenommen, wodurch diese Heuristiken nicht aktiviert werden.



Auch ohne Admin-Manifest kann man auch im Windows sowas selbst machen.
Wie sudo gibt es hier das runas oder auch andere Dinge.

[jaenicke]

Zitat von Codehunter:

Noch so eine Seuche! Stell dir mal vor wie es wäre, wenn eine Setup.exe SELBST nachprüft ob sie Adminrechte (vgl. "su" bei Linux) hat, anstatt ein Pappschild (Manifest) mit der Aufschrift "Bitte liebes System, gib mir mal Adminrechte" vor sich her zu tragen. Und wenns diese Rechte nicht hat, verlangt es danach. Diese Rechte vergäbe der User (bei Linux mit einem "sudo") und nicht das System.

Das ist ja möglich, wird nur in der Regel nicht gemacht, weil es meistens keinen Sinn hätte die Rechte selbst zu prüfen. Und eine Adminkonsole vorher aufmachen und dann das Setup starten oder runas aufrufen um den Nutzer anzugeben kann man auch unter Windows. Einfacher ist aber, wenn man schlicht den Dialog von Windows bestätigt. Und deshalb ist das auch der Standard für normale lokale Installationen...

Zitat von Codehunter:

Ein solches Setup würde die Dateien auf die verschiedenen Ordner verteilen und mit den korrekten Zugriffsrechten versehen (geerbt vom sudo aufrufenden Benutzer).

Wer bestimmt denn, dass das "korrekt" ist? Ich möchte z.B. nicht, dass die beim Setup gesetzten Voreinstellungen durch den Benutzer geändert werden können, die des Benutzers darf er aber ändern. Möglich ist so etwas mit dem Windows Installer durchaus.
Und es gibt ja auch extra die Trennung zwischen Daten für alle Benutzer und für bestimmte, wenn du ein Setup erstellst.

Zitat von Codehunter:

Damit sind wir nämlich beim entscheidenden Punkt: Bei Windows gibt es inzwischen Instanzen (z.B. SYSTEM) mit höheren Rechten, als jemals ein Anwender erlangen kann. Selbst als Admin stößt du immer wieder auf Dinge, wo dir der "Zugriff verweigert" wird. Ein Unding.

Besitzer ändern, fertig...

Zitat von Codehunter:

Schreibst du Systemdienste, dann laufen die bei Windows im SYSTEM-Kontext.

Wenn du das so einstellst, ja. Unsere Dienste laufen nicht alle im System-Kontext, sondern teilweise auch im Benutzerkontext.

Zitat von Codehunter:

Schon mal versucht, mit einem Non-Admin-Programm unter Windows auf Dateien schreibend zuzugreifen, die dein eigener (!!!) Dienst erstellt hat?

Ja, machen wir öfter. Damit hatten wir bisher keine Probleme. Man muss halt die Rechte entsprechend vergeben oder den Dienst im gewünschten Kontext ausführen, egal ob unter Windows oder Linux. Nur die Logik ist eben je nach System unterschiedlich.