ein Fass nach dem anderen geht auf

[Codehunter]

Zitat von himitsu:

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 von jaenicke:

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

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

Zitat von jaenicke:

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.

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 von Codehunter:

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 von Codehunter:

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

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

[freimatz]

Zitat von Codehunter:

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.

[Codehunter]

Zitat von jaenicke:

... 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 von jaenicke:

Zitat von Codehunter:

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

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 von freimatz:

Zitat von Codehunter:

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.

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

[jaenicke]

Zitat von Codehunter:

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 von Codehunter:

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 von himitsu:

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