ein Fass nach dem anderen geht auf

[freimatz]

Woanders schrieb ich

Zitat:

Zitat von freimatz

Seit Monaten mache ich an einer Verbesserung rum und ein Fass nach dem anderen geht auf. :cry::kotz: Gibts hier im Forum einen Bereich zum sich ausheulen? ;-)

Ich versuche es mal hier. Doch der Reihe nach:
Ich habe ein Programm entwickelt. Das hat begonnen vor über 30 Jahren mit Turbo-Pascal 3.0 und ist inzwischen bei Delphi Berlin. Es gibt viele Produkte (>100) die auf der Software basieren und man kann alle miteinander auch kombinieren. In ca. 99% der Fälle sind es einzelne PCs, es gibt aber auch Installation in Netzwerken und virtualisierten Umgebungen. Geliefert wurde das Programm früher auf Diskette, dann CD. Inzwischen gibt es auch die Möglichkeit einer Neu- oder Updateinstallation vom Internet. Seit einigen Jahren betreue ich das Projekt nur noch in meiner Freizeit.

Früher wurde das Programm installiert in einen beliebigen Windowsordner z.B. C:\BlaFasel. Das Hauptprogramm hat auf Bedarf noch Dateien nachinstalliert, geändert und Einstellungen in Ini-Dateien geschrieben und diese auch in diesem Ordner abgelegt. Es gab keine Deinstallation, wenn man es loswerden wollte hat man einfach den Ordner gelöscht. So weit so gut - oder eben auch nicht.
Wenn man heutzutage das dann in den Windows Programmordner installieren möchte gibt es natürlich Probleme. Das will ich seit einiger Zeit in Ordnung bringen. Also
1. Fass: Dateien in die jeweiligen Ordner verteilen. Programmdateien in %ProgramFiles%, Anwendungsdaten in CSIDL_APPDATA, Anwenderdaten in CSIDL_PERSONAL oder so ähnlich.
Zum Deinstallieren dann einfach den Ordner löschen ist dann nicht mehr möglich. Also
2. Fass: Ein Deinstallationsprogramm muss her. Das ist weitgehend wie Wasser kochen. Aber das Deinstallationsprogramm muss dann auch bei Windows eingetragen werden. Das geht ja noch aber, aber Widnos mag das nicht so einfach. Also
3. Fass: Setup muss Deinstallation mit Administratorrechte eintragen. Nach wie vor muss aber das Übrige mit "normalen" Rechten laufen. Dazu muss das Programm mit Administratorrechte etwas mitteilen. Also
4. Fass: Interprozesskommunikation. Da bin ich nun
(Dazwischen kamen noch die Fässer: Signierung mit Zertifikate und Manifeste)

Seit fünf Monaten mache ich nun daran rum, dass man das Programm in den Windows Programmordner installieren. Und nach jedem Fass geht ein neues auf.
Was mache ich falsch? Dann bitte ich im Informationen.
Oder ist das halt so ein komplexes Thema? Dann bitte ich um Beileidsbekundungen ;-)
(Und Beiträge von Kathinka sind auch erwünscht.)

[MyRealName]

InnoSetup?
Da geht das doch relativ einfach

[jziersch]

Den Pfad zu Deinen Dateien könntest Du doch mit System.SysUtils.GetHomePath ermitteln.

Nachinstallieren von runtimes ist natürlich schwierig - ich würde ich einfach ein Innosetup script verwenden welches dann im selben Pfad Deine module schreibt. Es wird dies automatisch tun, wenn Du den selben "AppName" verwendest.

InnoSetup ist super. Ich verwende allerdings eine ältere Version da der Windows Defender bei der neuen gemotzt hat.

[Redeemer]

%APPDATA% ist das neue C:\. Viele Programme installieren sich heute in %APPDATA%. Chrome und Firefox (non-ESR), auch Entwickler-Sachen wie Sourcetree. Weder zur Installation noch Deinstallation braucht man Rechte. Dass das ganze Programm dann in einer Domäne bei jedem Login und Logout mit einem Server gesynct wird - drauf geschissen. Die haben wohl auch alle keinen Bock darauf, ihr Programm vernünftig zu schreiben und anzupassen.

[freimatz]

Ach so ist das. Das habe ich sogar schon bei einem Microsoft-Tool so gesehen. :wall:

@jziersch: das Fass habe ich schon geleert

@MyRealName: InnoSetup u.a. taugen für mich nicht. Spätestens bei der Deinstallation ist das das Problem, dass die gar nicht wissen (können) welche Dateien alle weg müssen. Das hängt sehr von der Art der Instllation und weiss allein mein Code. Klar, auch mit den Tools kann man scripten, aber dann muss ich ja wieder das lernen. Zu Beginn hat ich auch ein Installationstool eingesetzt.

[dummzeuch]

Vielleicht einfach als "Portable App" bezeichnen (it's a feature, stupid!) und Installation nach Program Files nicht erlauben, da Windows dann motzt. Vorgabe sollte c:\PortableApps\DeinProgramm sein. Ansonsten braucht man dann nichts zu ändern und alle sind glücklich.

(OK, ist schon zu spät, ist mir auch gerade aufgefallen. Dann bleibt mir nur noch zu sagen: "Armer schwarzer Kater" ;-) )

[Delphi.Narium]

Nur mal so hingedaddelt:

Kann Dein Programm sich nicht selbst deinstallieren?

Eine Option dafür einbauen, die alles, was zur Laufzeit entfernt werden kann, entfernt.

Für die Sachen, die nicht entfernt werden können ein Script / Batch, ... schreiben und diese in der Registry unter

Code:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

oder 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

eintragen. (Run and RunOnce Registry Keys)

Was dort steht, wird einmalig beim nächsten Systemstart ausgeführt.

Wenn's z. B. 'ne Batch ist, kann die sich selbst zur Laufzeit löschen und damit wäre alles restlos weg.

Sie könnte auch ein von Dir erstelltes Deinstallationsprogramm starten, warten bis das fertig ist, es löschen und sich dann selbst löschen.

Wenn's sehr anwenderspezifisch ist, kann man auch ein Programm in den Autostartordner legen, beim nächsten Systemstart / Anmelden wird das dann ausgeführt. Es muss halt "nur" sichergestellt werden, dass sich das dann selbst aus dem Autostartordner löscht.

Achso: Das sind nur unausgereifte Ideen, die eventuell 'nen Ansatz liefern könnten (oder aber auch nicht ;-))

[Michael II]

Ich nutze die aktuelle InstallAware Developer und bin zufrieden damit.
Das Ding kann natürlich installieren, deinstallieren, signieren, automatisch (auch im Hintergrund) updaten.

Es gibt sicher andere gute...

(MSIX Packaging Tool ist je nach Umfang u.U. auch interessant. Das Tool kann auch ein bestehendes Setup in ein MSIX File wandeln.)

[TurboMagic]

Zitat:

Zitat von freimatz (Beitrag 1477311)

Ach so ist das. Das habe ich sogar schon bei einem Microsoft-Tool so gesehen. :wall:

@jziersch: das Fass habe ich schon geleert

@MyRealName: InnoSetup u.a. taugen für mich nicht. Spätestens bei der Deinstallation ist das das Problem, dass die gar nicht wissen (können) welche Dateien alle weg müssen. Das hängt sehr von der Art der Instllation und weiss allein mein Code. Klar, auch mit den Tools kann man scripten, aber dann muss ich ja wieder das lernen. Zu Beginn hat ich auch ein Installationstool eingesetzt.

InnoSetup benutzt Pascal Skript und ein Ereignis zum Deinstallationszeitpunkt sollte einfach sein. Evtl. ein eigenes kleines Konsolenprogramm schreiben welches das Löschen dieser Zusatzmodule macht. Das dann in dem Event aufrufen. Sollte eine Skriptzeile sein.

[generic]

Ich persönlich bin ein Fan vom Windows Installer und dem WIX-Toolset.

https://wixtoolset.org/

Tutorial:
https://www.youtube.com/watch?v=m3lDzMl3Hq0

[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:

Zitat von Codehunter (Beitrag 1477452)

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:

Zitat von Codehunter (Beitrag 1477452)

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:

Zitat von jaenicke (Beitrag 1477456)

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 :-D 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:

Zitat von Codehunter (Beitrag 1477459)

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:

Zitat von Codehunter (Beitrag 1477459)

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:

Zitat von jaenicke (Beitrag 1477462)

Zitat:

Zitat von Codehunter (Beitrag 1477459)

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:

Zitat von himitsu (Beitrag 1477469)

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:

Zitat von himitsu (Beitrag 1477469)

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:

Zitat von Codehunter (Beitrag 1477475)

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:

Zitat von Codehunter (Beitrag 1477475)

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:

Zitat von Codehunter (Beitrag 1477475)

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:

Zitat von Codehunter (Beitrag 1477475)

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:

Zitat von Codehunter (Beitrag 1477475)

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.

[Codehunter]

Zitat:

Zitat von himitsu (Beitrag 1477477)

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

Lach... Ja das sind so lustige Eigenheiten die mich von Windows vertrieben haben. Ist ein Programm automatisch böser, nur weil es Setup.exe heißt? Warum zeigt sich dieses Verhalten nicht, wenn ich es Malware.exe nenne? Oder umgekehrt, warum wird ein böseres Programm als weniger böse dargestellt, nur weil es nicht Setup.exe heißt? Irgendwie ist das doch eine Mischung aus Pseudosicherheit und Benutzerkomfort.

Gut bei Linux gibt es etwas ähnliches wie das Manifest. Hier wird z.B. eine Datei dadurch zur ausführbaren Datei, dass man ihr ein bestimmtes Dateiattribut gibt. Der Name ist dagegen völlig irrelevant. So kannst du auch reine Textdateien ausführbar machen und das System versucht dann anhand des Dateiinhaltes, die entsprechende Laufzeitumgebung (bash, perl, python u.ä.) zu finden.

Aber wir kommen vom Thema ab. Ich kritisiere ja nur das seltsame Windows-Verhalten, die Sicherheit von bestimmten Ordnern abhängig zu machen. Dann versucht man bei Altprojekten genau das, was der TE beschrieben hat: Anpassung an die Microsoft-Vorgaben. Was bei Altprojekten aber oft schwierig ist und in der Folge mehr als nötig in Ordnern mit weniger Sicherheit landet, eben %APPDATA% usw. Das ja, wie schon richtig bemerkt, in Domänenumgebungen dazu führt, dass die Serverprofile vollgemüllt werden und die Windowsanmeldung ewig dauert, weil erstmal alles gesynct werden muss.

Zitat:

Zitat von jaenicke (Beitrag 1477483)

Zitat:

Zitat von Codehunter (Beitrag 1477475)

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

Das meine ich nicht. Geh mal als Admin in die Systemverwaltung und versuche, gewisse Microsoft-Dienste zu beenden. Keine Chance. Und mir soll keiner erzählen, die wären "systemrelevant". :twisted:

Zitat:

Zitat von jaenicke (Beitrag 1477483)

Zitat:

Zitat von Codehunter (Beitrag 1477475)

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.

Das soll, zumindest was den Desktop-Datenaustausch angeht, demnächst nicht mehr möglich sein. Der Trend geht eher zu Hintergrundprogrammen, die per Taskplaner verwaltet werden. Wieder so eine Baustelle, die sich für die Betreuer von Altprojekten auftun wird.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1477485)

Lach... Ja das sind so lustige Eigenheiten die mich von Windows vertrieben haben. Ist ein Programm automatisch böser, nur weil es Setup.exe heißt? Warum zeigt sich dieses Verhalten nicht, wenn ich es Malware.exe nenne? Oder umgekehrt, warum wird ein böseres Programm als weniger böse dargestellt, nur weil es nicht Setup.exe heißt?

Es geht doch nicht um gut oder böse. Es wird nur davon ausgegangen, dass eine Setup.exe ohne aktuelles Manifest eventuell Adminrechte benötigt, aber zu alt ist um das passende Manifest zu haben, und deshalb werden diese dann automatisch angefordert. Das geht doch nur darum, dass der Benutzer ältere, nicht für das neue System erstellte, Software weiter nutzen kann.

Eine Setup.exe mit aktuellem Manifest, sprich eine, die für das aktuelle System gemacht wurde, bekommt diese Kompatibilitätsanpassung nicht.

Es hat halt alles Vor- und Nachteile. Bei macOS oder Linux funktioniert ein Tool ggf. einfach ein paar Jahre (oder auch schon bei anderen Distributionen^^) nicht mehr (oft genug selbst erlebt), bei Windows wird es mit der Abwärtskompatibilität dafür schon eher übertrieben. Aber dafür kann man selbst 16-Bit Windows 1.0 Programme noch 35 Jahre später unter Windows 10 32-Bit nutzen... und auch noch ältere MS-DOS Programme funktionieren grundsätzlich noch.

Zitat:

Zitat von Codehunter (Beitrag 1477485)

Das meine ich nicht. Geh mal als Admin in die Systemverwaltung und versuche, gewisse Microsoft-Dienste zu beenden. Keine Chance. Und mir soll keiner erzählen, die wären "systemrelevant". :twisted:

Wo ist da aber der praktische Anwendungsfall? Also wozu sollte man das können?

[freimatz]

Zitat:

Zitat von Codehunter (Beitrag 1477475)

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.

Danke. Hilft zwar nicht tut aber gut. :-D

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1477496)

... bei Windows wird es mit der Abwärtskompatibilität dafür schon eher übertrieben. Aber dafür kann man selbst 16-Bit Windows 1.0 Programme noch 35 Jahre später unter Windows 10 32-Bit nutzen... und auch noch ältere MS-DOS Programme funktionieren grundsätzlich noch.

Das meine ich ja. Irgendwann hat mich diese Mischung aus Kompatibilitätsballast, wiederkehrende Update-Probleme, Microsofts Misstrauen ggü. dem User und das zunehmende "Phoning Home" von Windows vertrieben (privat wie gesagt). Anfangs war es schwierig aber dann machte der harte Cut richtig Spaß. Bei Linux hilft bei störrischen Altprogrammen auch schon mal ein simples Recompile und Linken gegen die aktuellen Bibliotheken. Hängt natürlich stark vom Einzelfall ab. Shellprogramme sind da unkomplizierter als GTK und Qt.

Zitat:

Zitat von jaenicke (Beitrag 1477496)

Zitat:

Zitat von Codehunter (Beitrag 1477485)

Das meine ich nicht. Geh mal als Admin in die Systemverwaltung und versuche, gewisse Microsoft-Dienste zu beenden. Keine Chance. Und mir soll keiner erzählen, die wären "systemrelevant". :twisted:

Wo ist da aber der praktische Anwendungsfall? Also wozu sollte man das können?

Warum sollte man das nicht dürfen? Das meine ich mit Misstrauen ggü. dem User. Der praktische Anwendungsfall? Ein Beispiel: Dualboot auf einem betagten Laptop, Windows 10 und Linux Mint 20. Die selbe Maschine läuft mit einer Akkuladung unter Windows 90 Minuten und unter Linux 8,5 Stunden, Leerlauf, einfach nur das nackte System jeweils frisch installiert. Also guckt man, was da die lieben Stromtierchen verscheucht und landet bei diversen Hintergrunddiensten, die man weder braucht noch dass sie für den Systembetrieb (die Hauptaufgabe eines Betriebssystems!) notwendig sind. Mit Bordmitteln sind sie durch Normaluser nicht abschaltbar, muss man mit Fachwissen über die Registry machen. Am Ende läuft das Windows 5 Stunden über den Akku. Und die Moral von der Geschicht: Der alte Rechner ist nicht perse ungeeignet für Windows 10, sondern es ist nur out of the Box viel zu fett und unflexibel. Die Philosophie ist maximaler Funktionsumfang, notfalls um den Preis einer Neuanschaffung. Und die Querverzahnung zwischen den Diensten macht es zunehmend schwerer, daran noch etwas zu ändern, selbst wenn man das notwendige Fachwissen hat. Im privaten Bereich mag das Spielerei sein, im professionellen Bereich sind das handfeste Argumente in Bezug auf die TCO.

Zitat:

Zitat von freimatz (Beitrag 1477514)

Zitat:

Zitat von Codehunter (Beitrag 1477475)

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.

Danke. Hilft zwar nicht tut aber gut. :-D

Ich denke wir hatten nur beide mal das Bedürfnis uns auszukotzen :?

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1477518)

Also guckt man, was da die lieben Stromtierchen verscheucht und landet bei diversen Hintergrunddiensten, die man weder braucht noch dass sie für den Systembetrieb (die Hauptaufgabe eines Betriebssystems!) notwendig sind.

Das ist genau der Punkt:
Für das System an sich braucht man vieles nicht. Zum Beispiel könnte man unter Windows auch das Netzwerk deaktivieren oder Netzwerkfreigaben deaktivieren oder die linke oder rechte Windows-Taste deaktivieren. Während ersteres wohl vielen auffallen würde, würden Netzwerkfreigaben schon weniger Nutzern fehlen und die Windows-Taste links nutzen noch weniger. Die rechte wiederum nutzt fast niemand.

Aber wo zieht man da die Grenze? Was braucht "der Nutzer" und was nicht? Und das ist der Unterschied zu Linux. Bei Windows soll das System einfach vieles können ohne dass man davon etwas wissen muss, bei Linux muss man vieles explizit installieren oder konfigurieren, dafür ist ein Basis-System sehr schlank.

Leider gibt es zu einigen der "unnötigen" Dienste aber trotzdem Abhängigkeiten. Könnte man diese also auch heute noch einfach abschießen, würde bei manchen das gleiche passieren wie damals als das noch ging: Es gibt einen Fehler. Bei Windows 98 gab es dann einen Bluescreen, heute würde vielleicht nur etwas nicht mehr gehen, weil die Prozesse besser voneinander getrennt sind.
Ich vermisse die Zeit nicht, in der man bei Win 9x ziemlich einfach mit ein paar Klicks Windows zum Absturz bringen konnte...

Deshalb sehe ich solche Schutzmaßnahmen etwas differenzierter.

[generic]

Zitat:

Zitat von Codehunter (Beitrag 1477452)

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

Abhängig von der Übersetzung natürlich habe ich in Erinnerung das es

Code:

c:\programme\<Firmenname>\<Programmname>

sein sollte (in der Registry übrigens auch).
Bezüglich des UAC bzw. der Virtualisierung hat sich Microsoft keinen gefallen getan. Unter Win95 und ähnlichen Heimprodukten gab es keine Probleme mal was in den o.g. Ordner zu schreiben.
Unter den NT Betriebssystem also auch NT4 durften bereits Benutzer da nicht mehr hinschreiben.
Das Problem war aber das viele Programmierer das nicht verstanden haben und somit unter Win7 vieles nicht mehr lief und MS sich daher entschieden hat den Mist einzubauen, damit die Programmierer nicht umdenken müssen.

Unter %APPDATA% zu Installieren finde ich nicht schlimm, da der Benutzer somit in der Domäne die Software auf jeden PC zur Verfügung hat.

Da kommt aber das andere Problem, welches du beschreibst. Programme sind dann mehrfach auf der Platte.
Meine Antwort: Dann verschwendet nicht soviel Platz mit euren Programmen. Warum ist Office 3GB Groß? Vor 10 Jahren war das noch im MBytebereich.
Alternativ: Spielt Größe heute noch eine Rolle mit de-duplizierenden Dateisystemen wie REFS?

[himitsu]

Zitat:

Stromhunger

Genauso kann man auch ein passendes OS Windows benutzen.
Starter, Embedded, IoT, Core, ...

Selbst von Android gibt es inzwischen eine sparsame "Go"-Variante für "kleine" Systeme.



Mam muß nicht immer die Home/Professional-Editionen verwenden, wo alles Mögliche idiotensicher vorinstalliert/-aktiviert ist.

[Codehunter]

Zitat:

Zitat von himitsu (Beitrag 1477534)

Mam muß nicht immer die Home/Professional-Editionen verwenden, wo alles Mögliche idiotensicher vorinstalliert/-aktiviert ist.

Stimmt wohl. Nur wenn dir da wiederum die eine Kleinigkeit [Name einer beliebigen Windows-Komponente einsetzen] fehlt, kannst du die dort nicht einfach nachinstallieren. Irgendwie beißt sich die Katze da immer in den Schwanz.

Seltsam, heute ist doch noch gar nicht Freitag und wir philosophieren schon :lol: