AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

ein Fass nach dem anderen geht auf

Ein Thema von freimatz · begonnen am 14. Nov 2020 · letzter Beitrag vom 19. Nov 2020
Antwort Antwort
Seite 2 von 3     12 3   
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
914 Beiträge
 
Delphi 10.3 Rio
 
#11

AW: ein Fass nach dem anderen geht auf

  Alt 18. Nov 2020, 09:41
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
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.235 Beiträge
 
Delphi 10.4 Sydney
 
#12

AW: ein Fass nach dem anderen geht auf

  Alt 18. Nov 2020, 10:22
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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.144 Beiträge
 
Delphi 10.4 Sydney
 
#13

AW: ein Fass nach dem anderen geht auf

  Alt 18. Nov 2020, 11:01
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.

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.)
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.235 Beiträge
 
Delphi 10.4 Sydney
 
#14

AW: ein Fass nach dem anderen geht auf

  Alt 18. Nov 2020, 11:33
Wie gesagt, aus der Erinnerung. Ist ja auch schon 25 Jahre her Aber:
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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.144 Beiträge
 
Delphi 10.4 Sydney
 
#15

AW: ein Fass nach dem anderen geht auf

  Alt 18. Nov 2020, 12:34
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.

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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.235 Beiträge
 
Delphi 10.4 Sydney
 
#16

AW: ein Fass nach dem anderen geht auf

  Alt 18. Nov 2020, 12:54
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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden

Geändert von Codehunter (18. Nov 2020 um 13:06 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
38.717 Beiträge
 
Delphi 10.4 Sydney
 
#17

AW: ein Fass nach dem anderen geht auf

  Alt 18. Nov 2020, 13:02
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (18. Nov 2020 um 13:07 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.235 Beiträge
 
Delphi 10.4 Sydney
 
#18

AW: ein Fass nach dem anderen geht auf

  Alt 18. Nov 2020, 13:44
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?

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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
38.717 Beiträge
 
Delphi 10.4 Sydney
 
#19

AW: ein Fass nach dem anderen geht auf

  Alt 18. Nov 2020, 14:04
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (18. Nov 2020 um 14:22 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.144 Beiträge
 
Delphi 10.4 Sydney
 
#20

AW: ein Fass nach dem anderen geht auf

  Alt 18. Nov 2020, 15:00
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...

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.

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...

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.

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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!

Geändert von jaenicke (18. Nov 2020 um 15:03 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:34 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf