[honx]

heute gab es wieder ein "update" von steam, wo wir wieder beim thema downgrade wären.
denn seit dem heutigen downgrade funktioniert der -no-browser-parameter nicht mehr.
bislang konnte ich nach dem bloatware-anschlag im oktober 2019 den bullshit mit folgender .bat-datei umgehen:

start "" "C:\Program Files (x86)\Valve\Steam\Steam.exe" -no-browser +open steam://open/minigameslist

doch wie gesagt, funktioniert besagter workaround nach dem neuesten downgrade nicht mehr.
also, welche lösung gibt es denn nun ab heute für den verdammten bloatware-bullshit-terror?
wie starte ich steam ab 2023 ohne browser-bloatware?

ich hab damals in 2019 ja bereits befürchtet (und besagte befürchtung auch irgendwo hier gepostet), dass diese arschlöcher bei valve irgendwann auf die seltendämliche schnapsidee kommen würden, auch das feature noch rauszupatchen. wie sich herausgestellt hat, sollte ich damit wohl leider rechtbehalten, nun haben uns diese arschlöcher auch noch den letzten rettungsanker weggenommen! der fette valve-chef (gabe newell) will uns wohl mit aller macht diese scheiss bloatware aufs auge drücken! der typ muss wohl irgendwas kompensieren...

[Homerclon]

Ich hab leider keine Lösung, aber mich wundert es auch nicht. Denn schon seit einer ganzen weile, sind u.a. die Einstellungen, Spiel-Eigenschaften etc. nur noch zugänglich gewesen, wenn man Steam mit dieser "Browser-Bloatware" gestartet hat.

Warum also ein Feature integriert lassen, wenn bei deren Nutzung elementare Funktionen nicht mehr gehen?
Wenn es nach mir gegangen wäre - aber mich fragte niemand, die fragen nur immer wieder wegen der Hardware-Umfrage -, wäre für die Darstellung der Einstellungen etc., nicht auf die Browser-Engine umgestellt worden.

Eine Zeitlang hatte ich auch mit der no-browser-Erweiterung Steam genutzt. Aber immer wieder hin und her wechseln zu müssen, nur um eine Einstellung zu ändern, oder auch nur zu prüfen, nervte mich durchaus.

[honx]

das ist scheisse. denn wegen dieser browser-erfordernis sehe ich das nächste problem auf mich zukommen. denn chrome-basierte browser unterstützen ab sofort ja nur noch spyware 10 oder das noch schlimmere spyware-account gebundene spyware 11. und dieser steam-bloatware-browser basiert ja bekanntlich auch auf dieser google chrome spyware. das heisst im umkehrschluss, dass steam auf meinen windows 7 bzw. 8.1 rechnern nicht mehr laufen wird. dann werd ich wohl oder übel raubkopien meiner bei steam gekauften games ziehen müssen, wenn ich diese weiterhin starten und zocken will...

//edit: ich vermute mal wegen dem vermehrten ram-verbrauch der nicht mehr abschaltbaren steam-bloatware, muss ich bei einigen games vermutlich jetzt schon auf "alternative" versionen ausweichen. denn ich hab ja nur 6gb ram!

[Homerclon]

Zwischen Chrome (der Browser) und Chromium (dem Framework) liegt aber ein Unterschied, und Chromium muss nicht 1:1 übernommen werden sondern kann angepasst werden. Zudem ist Valve selbst dafür verantwortlich welche Chromium-Version genutzt wird.
Bis diese also auf eine Version umstellen die Win7 nicht mehr unterstützt, könnte noch eine weile vergehen.

Früher oder später wird Win7 eh nicht mehr unterstützt, so wurde bspw. die Unterstützung für WinXP und Vista von Valve am 1. Januar 2019 eingestellt.
Ich denke das Valve sich anschauen wird wie viele der Steam-Nutzer noch auf Win7 setzen, von WinXP und Vista waren es damals nur noch sehr wenige (<0,5%).

[honx]

in einem alten von mir 2019 in der steam diskussion erstellten thread hab ich folgenden kommentar gefunden, offenbar vom 22. januar:

With the latest update, -no-browser no longer works.
I wrote a script that allows you to return this behavior:
start-mini.cmd

@echo off
cd /d D:\Games\Steam
rename .\bin\cef\cef.win7x64\steamwebhelper.exe2 steamwebhelper.exe
rename .\steamerrorreporter.exe2 steamerrorreporter.exe
rename .\steamerrorreporter64.exe2 steamerrorreporter64.exe
runas /trustlevel:0x20000 "steam.exe +open steam://open/minigameslist"

:search
tasklist|find "steamwebhelper.exe"
IF %ERRORLEVEL% == 0 GOTO :found
TIMEOUT /T 5
GOTO :search

:found
rename .\bin\cef\cef.win7x64\steamwebhelper.exe steamwebhelper.exe2
rename .\steamerrorreporter.exe steamerrorreporter.exe2
rename .\steamerrorreporter64.exe steamerrorreporter64.exe2
taskkill /f /im steamwebhelper.exe
del .\bin\cef\cef.win7x64\steamwebhelper.exe
del .\steamerrorreporter.exe
del .\steamerrorreporter64.exe

start-full.cmd

@echo off
cd /d D:\Games\Steam
rename .\bin\cef\cef.win7x64\steamwebhelper.exe2 steamwebhelper.exe
rename .\steamerrorreporter.exe2 steamerrorreporter.exe
rename .\steamerrorreporter64.exe2 steamerrorreporter64.exe
runas /trustlevel:0x20000 "steam.exe +open steam://open/largegameslist"

You must change D:\Games\Steam to your steam path.
If steam is in program files then you must run the scripts with admin rights.
At the same time, due to runas /trustlevel:0x20000, Steam will start with drop admin rights.
Zuletzt bearbeitet von NightFox; 22. Jan. um 13:33

was genau macht das script konkret, ist es vertrauenswürdig? wie wende ich es korrekt an?
sind jene beiden geposteten .cmd-dateien einfach nur batch dateien mit der endung .cmd?
und wie hat die pfadangabe im script korrekt auszusehen, wenn wie bei mir steam hier liegt:

"C:\Program Files (x86)\Valve\Steam\Steam.exe"

und vor allem, wo haben jene beiden dateien zu liegen? einfach irgendwo, auch am desktop?

nach diesem workaround, falls das einer ist, ist der thread übrigens gleich geschlossen worden, mit folgender fadenscheiniger begründung:

This thread was quite old before the recent post, so we're locking it to prevent confusion.

da hat die steam-typische zensur-keule wieder zugehauen. so dass man dort bloss keine fragen zum script stellen kann... naja, ich hätte dort ohnehin nicht fragen können, denn aus steam diskussion bin ich seit 2020 dauerhaft ausgeschlossen, eben wegen diesem hässlichen ramfressenden, werbeverseuchten bloatware-downgrade im oktober 2019. mein einziges "vergehen" war eine wiederholte petition, den bullshit rückgängig zu machen und jenen usern den guten alten client zurückzugeben, welchen den bloatware-bullshit nicht haben wollen...

[Homerclon]

Ja, .cmd-Dateien und .bat-Dateien sind meines Wissens quasi das Gleiche - ohne Gewähr.

Ich mache nur sehr, sehr wenig über Kommandozeilen, daher kenne ich auch nur ein Bruchteil der Befehle. Und die meisten die ich da interpretieren kann, erklären sich durch ihren Namen selbst.

CD bedeutet: Change Directory - also wechsel in den nachfolgend angegebenen Ordner.
/D = Wird benötigt wenn auf eine andere Partition gewechselt werden soll.
/trustlevel:0x20000 = Adminrechte; in Kombination mit runas also "mit Adminrechte ausführen".
. = iirc Platzhalter bei Dateipfadangaben.


Vorläufige Einschätzung: Außer das Steam vielleicht hinterher nicht mehr funktioniert, dürfte es nichts schlimmes machen. Hauptsächlich weil Steam-Dateien umbenannt, und gelöscht werden.
Aber es schaut bestimmt noch jemand hier rein, der Ahnung davon hat.

[jabu]

.cmd und .bat als Dateinamenserweiterung bewirken jeweils überwiegend dasselbe, aber leider nicht immer, siehe den folgenden Beitrag von foobar. Die Wirkung unterschiedlicher Namen ergibt sich zusätzlich. Man sollte hier mit .cmd nichts falsch machen. Vermutlich funktioniert es auch mit .bat, wäre aber vorsichtshalber gründlich auszutesten, wenn man (so wie ich) die Altlastenspezialitäten nicht auswendig weiß.

Die Pfadangabe mit Leerzeichen hat inklusive Anführungszeichen zu erfolgen, also in dem von dir geschilderten Fall so: "C:\Program Files (x86)\Valve\Steam"
Ich habe den Pfad von dir übernommen und passend gekürzt. Dafür, dass er stimmt, bist du natürlich selber verantwortlich. Den setzt du mitsamt dieser Sorte Anführungszeichen anstelle des im Skript vorgegebenen Pfades (D:\Games\Steam) ein. Alles andere in der Zeile lässt du unverändert. Der einzusetzende Bereich fängt mit dem ersten Anführungszeichen an und endet mit dem zweiten (jeweils inklusive).

Die beiden, relativ simplen, Batch-Skripte sahen (zum Zeitpunkt, als ich sie hier vorgefunden habe) vertrauenswürdig aus. Trotzdem kann ich für ihre Funktion keine Gewähr übernehmen. Ob sie erwartungsgemäß funktionieren, hängt neben der korrekten Verwendung und Abwesenheit von Kopierfehlern natürlich (mindestens) von der Steam-Software ab.

Grobe Funktionsweise, wobei eine Datei, die den Browser startet oder zum Browser selbst gehört (von hier aus nicht unterscheidbar), als "Browser" bezeichnet wird:
- Das Skript verwendet den bereits bekannten Workaround, weswegen es darauf angewiesen ist, dass diese "minigameslist" grundsätzlich noch aufrufbar ist und funktioniert.
- Es unterdrückt den Browser, indem es nach dem Start der steam.exe in 5-Sekunden-Intervallen prüft, ob der Prozess des Browsers läuft und im Erfolgsfall die Schleife verlässt, die ausführbare Datei des Browsers umbenennt (gegen erneutes Starten) und den Prozess des Browsers abschießt.
- Ein trotzdem unter dem Originalnamen gefundenes Exemplar wird ggf. gelöscht. Ich kann nur spekulieren, warum dieses Löschen erfolgt. Vielleicht könnte Steam eine fehlende (da umbenannte) Datei erneut anlegen (oder zu unpassendem Zeitpunkt ein Update unterjubeln), sodass eine Blockade entstehen könnte, die so aufgelöst wird. Vielleicht hat es mit Beheben von Blockaden aufgrund vorangegangenen Scheiterns zu tun.
- Beim nächsten Durchlauf muss natürlich die umbenannte ausführbare Datei des Browsers zu ihrem Originalnamen umbenannt werden, was jeweils vor dem Starten von Steam erfolgt. Um den Originalzustand zurückzuerhalten, benötigt man vermutlich einen Durchlauf des zweiten Skriptes, da die ausführbare Datei des Browsers sonst umbenannt bleiben würde.
- Das Umbenennen und das Löschen betrifft jeweils in gleicher Weise auch zwei weitere ausführbare Dateien, auf deren Funktion man wohl über ihre Namen schließen kann (Fehlerberichterstattung/Telemetrie).
- Anscheinend macht die Steam-Software nicht, was sie soll, wenn der Browser am Anfang nicht zu finden oder nicht startbar ist, weswegen das einmalige Starten zugelassen wird. Im späteren Verlauf scheint es zu genügen, wenn der Browser nicht zu finden ist, weswegen die zugehörige ausführbare Datei vor dem Abschießen umbenannt wird und ein evtl. ersetztes Exemplar gelöscht wird, sodass nicht weiter geprüft werden muss, ob der Browser läuft.

Je nach Berechtigungen auf Dateisystemebene kann es erforderlich sein, das Skript mit Administratorberechtigungen auszuführen, z.B. falls Steam in einem der vordefinierten Programme-Ordner installiert ist (wie bei dem von dir gezeigten Pfad anzunehmen). Damit diese erhöhten Rechte nicht an die steam.exe vererbt werden, wird sie per runas /trustlevel:0x20000 explizit mit Berechtigungen von normalen Benutzern gestartet.

Ich kann die Skripte nicht für dich ausprobieren, da ich kein Steam installiert habe, und ich habe keinen Bock, sie mit Dummys auszuprobieren. Ob der mit dem Skript unternommene Versuch beim aktuellen Steam noch das Erwünschte bewirkt, weiß ich leider nicht. Das müsstest du wohl selber ausprobieren. So oder so gilt: Alles auf eigene Gefahr und Irrtümer vorbehalten!

Es ist vorsichtshalber mit Nebeneffekten zu rechnen, z.B. indem Steam immer wieder (erfolglos) versuchen könnte, den Browser zu starten oder mit einem fehlenden Browser zu kommunizieren, was eine leicht erhöhte CPU-Last verursachen könnte. In dem Fall müsste man abwägen, was weniger stört, mehr RAM-Belegung durch den Browser oder mehr CPU-Last. Ob es zu solchen oder anderen Nebeneffekten in störendem Ausmaß kommt, ist spekulativ, da es von der konkreten Ausgestaltung der Software abhängt.

Inwiefern Nachstartversuche bezüglich des Browsers unternommen werden, kann ich hier nicht überprüfen. Es wäre auch denkbar, dass sie nur zu bestimmten Zwecken erfolgen. Zudem ist denkbar bzw. teils erwartbar, dass die verbleibende Umbenennung den Zweck, Nebenzweck oder Nebeneffekt hat, bei anderweitig getriggerten Starts von Steam (am Skript vorbei, z.B. bei einem Autostart) ein Starten zu verhinden.

Es wäre (für dich) interessant zu wissen, ob man anstelle des Browsers einen Dummy unterschieben kann und welche Anforderungen an diesen gestellt wären. Aber ohne Steam kann ich das nicht alleine herausfinden.

[foobar]

Ja, .cmd-Dateien und .bat-Dateien sind meines Wissens quasi das Gleiche - ohne Gewähr.

.cmd und .bat als Dateinamenserweiterung bewirken jeweils dasselbe

Es gibt schon Unterschiede.

Ursprünglich war BAT mal für die 16-bittige COMMAND.COM des alten MS-DOS gedacht. Dieser Befehlsinterpreter wurde dann irgendwann auf neueren Windosen vom 32-bittigen CMD.EXE abgelöst, der dann auch die neue Erweiterung CMD mitbrachte. Die Idee war, dass BAT die Abwärtskompatibilität zur alten COMMAND.COM wahrt, während CMD sich darum nicht kümmern muss und die Kompatibilität opfern kann.

Ein Unterschied ist beispielsweise, dass sich bei BAT die Variable ERRORLEVEL nur ändert, wenn tatsächlich ein Fehler auftritt. Hingegen wird die Variable bei CMD mit jedem erfolgreich ausgeführten Befehl (auch internen wie SET, APPEND oder ASSOC) wieder zurück gesetzt. Man muss evtl. Fehler also sofort abfragen, sonst verliert man die Information.

Hier mal ein einfacher Test (Laufwerk K: existiert bei mir nicht, der Befehl erzeugt also einen Fehler):

Spoiler:(zum lesen bitte Text markieren)

[Bild: batcmd.png]

Ein und die selbe Datei liefert unterschiedliche Ergebnisse, je nachdem, ob man sie als CMD oder BAT ausführt (Umgebung: Windows 10 22H2).

Es gibt AFAIK noch ein paar andere Unterschiede, aber die sind noch esoterischer. In den meisten Fällen machen CMD und BAT das selbe. Aber in manchen Situationen kann man auch auf die Fresse fliegen.

[jabu]

Es gibt schon Unterschiede. [...]

Ah, danke, stimmt.
Diese unheilige Allianz aus Altlasten und meinem Siebgedächtnis.
Ich sollte mir lieber ein ruhiges Plätzchen suchen. [Bild: Troll_Chiller05.gif]

Da war mal was mit ERRORLEVEL, dass man es vorsichtshalber sofort prüfen und sich nicht auf Rücksetzen verlassen soll. So weit kann ich mich erinnern, aber die Information, unter welchen Umständen das nötig ist, ist bei mir schon verblasst...

Da %ERRORLEVEL% und if ERRORLEVEL n nicht dasselbe ist, habe ich mal beides probiert und das zusammen mit so einer Schleife, wie sie in dem Skript, für das sich honx interessiert, verwendet wird, wobei ich foo.exe nach einigen Sekunden manuell gestartet habe:

@echo off
:search
tasklist|find "foo.exe"
echo %%ERRORLEVEL%% ist set to %ERRORLEVEL%
if ERRORLEVEL 1 (echo ERRORLEVEL is at least 1) else echo ERRORLEVEL is 0
if %ERRORLEVEL% == 0 goto :found
TIMEOUT /T 2 1>nul
goto :search

:found
echo Found
taskkill /f /im foo.exe
pause

Ausgabe:

ERRORLEVEL is at least 1
%ERRORLEVEL% ist set to 1
ERRORLEVEL is at least 1
%ERRORLEVEL% ist set to 1
ERRORLEVEL is at least 1
foo.exe                      13204 Console                    1         4.556 K
%ERRORLEVEL% ist set to 0
ERRORLEVEL is 0
Found
ERFOLGREICH: Der Prozess "foo.exe" mit PID 13204 wurde beendet.
Drücken Sie eine beliebige Taste . . .

Das beobachtete Verhalten ist hierbei bei .bat und .cmd gleich (PID und Speicher ändern sich zufällig, was nichts zur Sache tut).
Es war zwar zu vermuten, aber ich wollte doch lieber gucken, ob die Variablen bei jedem Durchlauf aktualisiert werden.
Ich weiß, FOR ist ein anderer Fall, wo man aufpassen muss, was man macht. Ob EnableDelayedExpansion verwendet wird, spielt bei Variablen rein etc.
Manchmal verdeckt die nächste Ebene lediglich, was unten drunter liegt (neue Variable mit gleichem Namen angelegt).
Der Kram bleibt eklig.

[honx]

das hat mich nun doch eher verunsichert, nun wage ich es noch weniger, besagte scripte auszuprobieren...

[jabu]

das hat mich nun doch eher verunsichert, nun wage ich es noch weniger, besagte scripte auszuprobieren...

Für Supervorsichtige ist das nicht gemacht, da erstens Fehler während der Ausführung nicht abgefangen werden und zweitens nicht ersichtlich ist, wie genau Updates erfolgen. Dadurch könnten u.U. inkonsistente Zustände entstehen.

Ich glaube jedoch kaum, dass diese "steamwebhelper.exe" oder diese Errorreporter-Dingens sooo kritisch sind, dass ein Fixen ernsthafte Schwierigkeiten bereiten würde. Bis es so weit kommt, müsste wohl noch weiteres Pech hinzukommen.

Zur Vorbeugung würde ich gelegentlich das Skript für den normalen Modus verwenden und es darauf anlegen, dass Updates in dem Modus erfolgen, falls möglich und vielleicht nach Updates jeweils Steam (ohne Spiele) sichern, idealerweise mitsamt Einstellungen, damit alles zusammenpasst. Vermutlich wäre ich aber zu faul für alles zusammen.

Man könnte das Skript etwas verbessern. Aber auch das würde nicht alle Risiken beseitigen. Ich wäre zu faul dazu, überhaupt noch etwas zu verbessern, bei Hobby-Spielkram, der sich notfalls leicht fixen ließe und von dem nichts Wichtiges abhängt. Aber das wäre meine persönliche Entscheidung, die sich nicht unbedingt übertragen lässt.

Ich komme doch aus Stenkelfeld, siehe z.B.: https://www.youtube.com/watch?v=vAF3bfO94FQ
Legendär: https://www.youtube.com/watch?v=hgT43hx1QGY
Da ist man schon etwas abgehärtet.

[honx]

...und es darauf anlegen, dass Updates in dem Modus erfolgen, falls möglich

das ist leider deswegen unmöglich, denn bei steam merkt man gar nichts von bevorstehenden updates, bis es zu spät ist und bei einem start von steam plötzlich zuerst der updater läuft, bevor steam startet.

[jabu]

das ist leider deswegen unmöglich, denn bei steam merkt man gar nichts von bevorstehenden updates, bis es zu spät ist und bei einem start von steam plötzlich zuerst der updater läuft, bevor steam startet.

Mal auf die Schnelle durchspielen (wie ich darauf gekommen war), ohne Gewähr:

Nach mindestens einmaliger Benutzung des Skriptes mit unterdrücktem Browser sind, falls vorher alles geklappt hat, umbenannt:
- steamwebhelper.exe (zu steamwebhelper.exe2)
- steamerrorreporter.exe (zu steamerrorreporter.exe2)
- steamerrorreporter64.exe (zu steamerrorreporter64.exe2)
1. Am Anfang des Skriptes werden sie zu ihren Originalnamen zurückbenannt und sind daher verfügbar.
2. steam.exe wird gestartet und läuft.
3. steamwebhelper.exe wird durch steam.exe gestartet und vom Skript beendet.

Danach eine Fallunterscheidung (ohne Berücksichtigung von (seltenen) Glitches):

4a) Falls bis vor dem nächsten Umbenennen ein Update eingespielt wurde (vor dem Starten von steamwebhelper.exe wäre theoretisch Zeit dazu vorhanden), passt wegen kompletter Verfügbarkeit unter den Originalnamen alles zusammen. Dieses Umbenennen ist erfolgreich, weil unter den Zielnamen nichts vorhanden ist. Da es erfolgreich ist, ist unter den Originalnamen nichts vorhanden, sodass das Zurückbenennen beim nächsten Durchgang ebenfalls erfolgreich ist. Das Update ist komplett -> keine Beanstandung

4b) Falls nach dem nächsten Umbenennen das Update eingespielt wird (und davor nicht), wurden zuvor die alten Dateien umbenannt. Es gibt jetzt parallel dazu unter den Originalnamen die geupdateten Versionen. Das passt so weit noch zusammen. Beim nächsten Durchgang scheitert jedoch das Zurückbenennen der alten Dateien, weil die neuen im Weg sind. Die neuen werden benutzt, so weit, so gut. Das Umbenennen dieser neuen Dateien scheitert jedoch, da die alten (umbenannten) im Weg sind. Da die neuen noch da sind, werden sie im nächsten Schritt gelöscht. Der nächste Start beginnt also mit dem (nun erfolgreichen) Zurückbenennen der alten. Damit sind die Updates bezüglich der drei ausführbaren Dateien zurückabgewickelt, wogegen die Kernkomponenten von Steam durchaus auf einem neuen, geupdateten Stand sein können. Das muss nicht unbedingt zusammenpassen. -> Inkonsistenzpotential

Auch eine externe Triggerung sollte sich wie 4b) verhalten.

Fall 4b) sollte nicht eintreten, falls steamwebhelper.exe nur (indirekt) über dieses Skript gestartet wird, Updates an sich vorher ablaufen und steamwebhelper.exe immer nur einmal am Anfang gestartet wird, da der zugehörige Prozess vor dem Umbenennen abgeschossen wird.
Bei der Schleife ist Zufall dabei, wieviel vom 5-Sekunden-Zeitfenster konsumiert ist, bevor steamwebhelper.exe abgeschossen wird, daher folgende potentielle Zufälligkeiten bzw. Unzuverlässigkeiten:
- Falls steamwebhelper.exe zum Updaten benötigt wird, könnte das mögliche sehr frühe Beenden Updates u.U. und je nach Restzeit, unterdrücken.
- Falls steamwebhelper.exe für das Login benötigt wird, könnte das mögliche sehr frühe Beenden das Login, je nach Restzeit, (manchmal) unterdrücken.
--> Man sollte sich doch mal entscheiden, wieviel Zeit steamwebhelper.exe vor dem Abschießen bekommen sollte (z.B. eine Mindestzeit oder gar keine oder...) und das Skript dementsprechnd auslegen!

Vage optimistische Vermutung (keine Ahnung...):
steamwebhelper.exe ist (mehr oder minder indirekt) auch für Logins und Herunterladen von Updates zuständig, nicht aber für das Anstoßen der Installation eines Updates an sich, sodass Updates zum Fall 4a) passen.

Ausblick:
- Steam sollte beobachtet werden, um Zuständigkeiten, Abhängigkeiten und Zeitstruktur herauszufinden.
- Das Skript sollte damit anfangen, dass laufende Instanzen beendet werden.
- Es sollten, wo es nötig ist, Verzögerungszeiten ordentlich ausgeklügelt werden.
- Das einfache Umbenennen ist vermutlich zu schlicht und könnte einer blockadefreien Lösung (z.B. ähnlich "swap") weichen.
- Es sollten Erfolgskontrollen und, darauf aufbauend, Fallunterscheidungen eingebaut werden.
- Falls sinnvoll und vom Aufwand her vertretbar, könnte Rollback-Fähigkeit eingebaut werden.
- Eventuell atomare Operationen ermöglichen, evtl. bis hin zur Vermeidung von Glitches.
- Auf gewöhnliche Fehler sollte (sinnvoll) reagiert werden.

Das ginge mir persönlich aber etwas zu weit, da mir Steam nicht wichtig ist, Steam hier nicht installiert ist und ich immerhin 16 GB RAM zur Verfügung habe.

[jabu]

In einem Anfall von Wahnsinn habe ich mir das näher angeguckt (musste dazu Steam installieren, Skripte und Weiteres schreiben und mir ein Wochenende versauen, grrr...).

In folgenden zwei Absätzen ein stark verkürzter Auszug aus gewonnenen Erkenntnissen:

Schaffen von Voraussetzungen:

• Robuste Skripte mit ordentlicher Fehlerbehandlung, zusätzlichen Sicherheiten und aussagekräftigen Meldungen erstellen -> klappt.
• Prüfung bezüglich der Softwareintegrität des Browsers umgehen, um die störende automatische Reparatur nur noch selten erdulden zu müssen -> klappt.
• Herstellen von Integrität, sodass in den allermeisten Fällen bei der Software insgesamt alles zueinander passt -> klappt.
• Wo es ausnahmsweise nicht klappt (wegen Eigenlebens der Software), hilft die automatische Reparatur, die man sonst nicht haben will -> kann man mit leben.
• Durch die bisher unvermeidbaren "Fehler" (speziell aus der Sicht der steam.exe), lässt diese zu viele Error-Dumps und zu große Fehler-Logs anlegen -> bereits reduziert, darf verbessert werden.
• Die Fehlerberichterstattungs-Executables sollte man (zusätzlich zu den Maßnahmen der Skripte) per gpedit.msc (Win Prof erforderlich) abschalten.
• Das Übermitteln von Fehlerberichten (an Valve) sollte man gleich nach der Installation in den Softwareeinstellungen abschalten. Das verhindert aber nicht, dass eine Spam-Welle an Dumps und Logs entsteht (s.o.).
• Auf letzterem Gebiet wären weitere Maßnahmen erforderlich, um die Sache wenigstens einigermaßen wasserdicht und stubenrein zu machen -> nicht schwierig, aber zeitraubend und lästig.

Der nervige Kern der Sache:

• Der echte Browser muss zunächst kurz laufen, damit die steam.exe nicht lange auf Antwort wartet (um dann irgendwann trotzdem fortzufahren). Wegen dieses lästigen Wartens ist hier ein Trick mit Verbieten per Gruppenrichtlinie zwar nutzbar, aber führt zu nervig langen Wartezeiten, bis die steam.exe trotz Scheiterns endlich fortfährt. Die CPU-Last steigt beim Trick mit der Gruppenrichtlinie bei mir wegen intervallweiser Startversuche phasenweise auf ca. 2 % an, natürlich bei erhöhtem I/O (was man nicht will).
• Dummys, die man ab einem günstigen Zeitpunkt anstelle des Browsers unterjubelt, liefern der steam.exe nicht die Antwort, die sie braucht, wodurch sie in einen (anscheinend in einer Loop schnell rotierenden) Wartezustand versetzt wird, der bei mir durchweg um 4 % CPU-Last erzeugt. Das ist viel zu viel, wenn man bedenkt, dass sich das auf alle Cores zusammen bezieht. Ein einzelner Core ist davon zu hoch ausgelastet.
• Wenn die ausführbare Datei (ab einem günstigen Zeitpunkt) fehlt (wie in den bekannten Skripten), dann wartet die steam.exe nicht, sondern versucht in Intervallen die Starts erneut, und zwar innerhalb eines Intervalls zigmal. Das erzeugt bei mir eine CPU-Last von rund 2 % innerhalb dieser Phasen, natürlich bei erhöhtem I/O (was man nicht will).
• Wenn die ausführbare Datei (ab einem günstigen Zeitpunkt) durch einen extrem schlanken Dummy (ohne C-Laufzeit, ohne Lesen aus dem Environment, ohne Importtabelle, Rücksprung direkt vom Einsprungpunkt) ersetzt wird und dieser Dummy sich also sofort beendet, dann wartet die steam.exe nicht, sondern versucht in Intervallen die Starts erneut, und zwar innerhalb eines Intervalls zigmal (s.o.). Dieser Fall erzeugt bei mir eine CPU-Last von weniger als 1 % innerhalb dieser Phasen, natürlich bei erhöhtem I/O (was man nicht will).

Die Intervalle, von denen hier die Rede ist, werden endlos wiederholt. Die steam.exe gibt leider niemals auf. Innerhalb eines jeden solchen Intervalls erfolgen die zig Startversuche. Dann gibt es eine Pause von einigen Sekunden, wonach sich das Prozedere wiederholt. Ein weiterlaufender Dummy ist noch ungünstiger, da das "Warten" (sie könnte evtl. noch etwas anderes versuchen) der steam.exe eine andauernde und noch höhere CPU-Last erzeugt.

Die letzte Lösung, also das Unterjubeln eines superschlanken Dummys, ist die bisher beste Lösung bei mir. Eine optimale konnte ich nicht finden, da mir der Aufwand langsam zu groß wurde. Man müsste (sehr aufwändig) herausfinden, welche Information die steam.exe zufriedenstellt (und wie diese übermittelt werden muss), damit sie ihre beknackte Loop beendet, sodass der Dummy (ebenso wie das Original) einfach weiterlaufen kann, ohne dass die steam.exe sich (CPU-intensiv) im Kreis dreht. Ich wüsste zwar Ansätze zum Untersuchen (Messaging-Hooks, Trampolines per Detours-Lib etc.), aber für die doch ziemlich großen Mühen fehlt mir die Motivation. Vielleicht geht es sogar einfacher, aber auch einfache Lösungen wollen gesucht und gefunden werden. Die Stunden vor dem, was nachher so einfach aussieht, sind das Problem. Wie gut man da mit einem Debugger weiterkommt, weiß ich nicht. Ich traue denen zumindest zu, dass sie es erheblich erschwert haben könnten. Falls nicht, ist das in einer dermaßen fetten und komplexen Software (mit vielen Threads) schon ohne Schikanen nicht gerade bequem.

Zum Vergleich:
Der Browser (CEF) verursacht noch weniger CPU-Last als die durch die steam.exe phasenweise erfolgenden Aufrufe eines extrem schlanken Dummys. Damit gewinnt normalerweise das Original.

Mein persönliches Fazit Nr. 1:
RAM ist i.d.R. viel billiger, als diese Stunden zu verbraten. Ein Spiel ggf. per GOG neu zu kaufen, ist ebenfalls billiger.
Das mag zwar nicht auf einen reinen Nutzer einer fertigen Lösung zutreffen, aber sobald diese nicht mehr funktioniert, stellt sich das Problem von Aufwand erneut. Dieses Hinterherjagen kann in der Summe doch ganz schön aufwendig werden, zumal man auch einiges durchlesen und verstehen muss.

Mein persönliches Fazit Nr. 2:
Schlechten Ideen sollte man nicht (noch mehr) gute Lebenszeit hinterherwerfen.

Mein persönliches Fazit Nr. 3:
Valve nutzt opportunistische Herangehensweisen, um leicht und schnell immer reicher zu werden. Warum sollte ich Valve dabei helfen, indem ich für die kostenlose Arbeit leiste und damit Valves verdiente Kehrseite einer Medaille beseitige? Damit würde ich doch anderen, die es sich mit dem Geldeinsammeln (von "verdienen" zu sprechen, widerstrebt mir, da das für unprivilegierte Leute viel höhere Anstrengungen erfordert) nicht so leicht machen, schaden.

Aus den Fazits hat sich ergeben, dass ich den Kram deinstalliert habe und nicht supporten werde. Wer es trotzdem möchte, hat jetzt erste Hinweise (schon zu viel...).

Weiteres:
- Allgemein halte ich nichts von DRM (z.B. die Macht über von mir rechtmäßig erworbene Spiele vom Funktionieren unnützer Software und von fremden Servern anzuvertrauen).
- Ich halte nichts vom Einklinken von Steam ins System, sobald Steam läuft (Verwendet Methoden, die Hooks vom Ergebnis her zumindest ähneln, zwar eher mild eingesetzt, nervt aber trotzdem).
- Die Nutzung des CEFs habe ich bei anderen Firmen schon schlimmer gesehen (kleiner Punkt, der an Valve geht). Ob es noch besser/schlanker ginge? Jepp. Zu Not kann man der steam.exe für den CEF-Browser Parameter mitgeben, spart einiges an RAM. Mehr oder minder aktuelle Tipps dazu gibt es im Web. Deren Funktionieren kann sich natürlich ändern.

[honx]

Mein persönliches Fazit Nr. 1:
RAM ist i.d.R. viel billiger, als diese Stunden zu verbraten. Ein Spiel ggf. per GOG neu zu kaufen, ist ebenfalls billiger.
Das mag zwar nicht auf einen reinen Nutzer einer fertigen Lösung zutreffen, aber sobald diese nicht mehr funktioniert, stellt sich das Problem von Aufwand erneut. Dieses Hinterherjagen kann in der Summe doch ganz schön aufwendig werden, zumal man auch einiges durchlesen und verstehen muss.

das problem mit dem ram ist: ich hab 2021 schonmal versucht, zumindest ram aufzurüsten (2gb gingen noch, auf insgesamt 8gb). das problem war damals, ich war schlicht ZU SPÄT dran mit der idee, denn bereits 2021 gabs keinen kompatiblen ram mehr für meine 14 jahre alte krücke... fazit: ram aufrüsten ist nicht. ich muss wohl oder übel mit den 6gb klar kommen...

ein neukauf bei gog würde auch nur dann funktionieren, wenn ein spiel bei gog verfügbar wäre.
die meisten spiele sind aber drm verseucht und somit steam-only, eben nicht bei gog verfügbar.
z.b. ein mir persönlich wichtiges spiel: euro truck simulator 2, ist nur bei steam verfügbar.

- Allgemein halte ich nichts von DRM (z.B. die Macht über von mir rechtmäßig erworbene Spiele vom Funktionieren unnützer Software und von fremden Servern anzuvertrauen).
- Ich halte nichts von diesem tiefen Einklinken von Steam ins System, sobald Steam läuft

voll und ganz deiner meinung. ich hasse drm und steam ist der einzige drm-bullshit, den ich installiert habe. um den ganzen anderen bullshit wie origin, epic, paradox und wie diese drm-malware von anderen firmen heissen mag, mach ich nen weiten bogen. steam hab ich tatsächlich nur, weil man das 2004 mit installieren musste, um half life 2 zocken zu können und damals wusste man es eben nicht besser... tatsächlich hab ich 2019 zuletzt bei steam etwas gekauft.

- Die Nutzung des CEFs habe ich bei anderen Firmen schon schlimmer gesehen (kleiner Punkt, der an Valve geht). Ob es noch besser/schlanker ginge? Jepp. Zu Not kann man der steam.exe für den CEF-Browser Parameter mitgeben, spart einiges an RAM. Mehr oder minder aktuelle Tipps dazu gibt es im Web. Deren Funktionieren kann sich natürlich ändern.

bzgl. nutzung des cef hab ich gelesen, dass davon eindinglich ABGERATEN wird, da dadurch der steam browser extrem unsicher und zum einfallstor für malware (driveby downloads) wird, denn tatsächlich wird dabei alles (browser, community, whatever, ...) in einen einzigen prozess gepackt...

[jabu]

das problem mit dem ram ist: ich hab 2021 schonmal versucht, zumindest ram aufzurüsten (2gb gingen noch, auf insgesamt 8gb). das problem war damals, ich war schlicht ZU SPÄT dran mit der idee, denn bereits 2021 gabs keinen kompatiblen ram mehr für meine 14 jahre alte krücke... fazit: ram aufrüsten ist nicht. ich muss wohl oder übel mit den 6gb klar kommen...

Was ist denn schon drin und läuft? Ich rate mal: 3 Riegel stinknormaler DDR2-RAM? Ich habe vorhin mehrere Bezugsquellen gefunden, welche sich nicht nur in Deutschland nutzen ließen. Vielleicht ist es aktuell nicht mehr so schlecht.

ein neukauf bei gog würde auch nur dann funktionieren, wenn ein spiel bei gog verfügbar wäre.
die meisten spiele sind aber drm verseucht und somit steam-only, eben nicht bei gog verfügbar.
z.b. ein mir persönlich wichtiges spiel: euro truck simulator 2, ist nur bei steam verfügbar.

Verstehe.

bzgl. nutzung des cef hab ich gelesen, dass davon eindinglich ABGERATEN wird, da dadurch der steam browser extrem unsicher und zum einfallstor für malware (driveby downloads) wird, denn tatsächlich wird dabei alles (browser, community, whatever, ...) in einen einzigen prozess gepackt...

Jepp, da ist was dran.

In dieser Sammlung sind schon Kandidaten für Minderung von Sicherheit mit drin (gerade diejenigen, die am meisten bringen, kann man sich selber denken...):
-dev -console -nofriendsui -no-dwrite -nointro -nobigpicture -nofasthtml -nocrashmonitor -noshaders -no-shared-textures -disablehighdpi -cef-single-process -cef-in-process-gpu -single_core -cef-disable-d3d11 -cef-disable-sandbox -disable-winh264 -cef-force-32bit -no-cef-sandbox -vrdisable -cef-disable-breakpad

[Homerclon]

Valve hat nun auch ein Datum für das Supportende von Steam für Win7 und Win8(.1) angekündigt.
Im Januar 2024 ist es soweit, dann wird auf eine Chromium-Version für den integrierten Browser gewechselt, welche Win7 und Win8(.1) nicht mehr unterstützt. Offiziell endet die Unterstützung am 1.Januar 2024, ob das Update direkt am 1.1. ausgespielt wird, wird man sehen müssen.
Das Update der Chromium-Version ist aber nur der erste Schritt, es sollen in weiteren Updates auch auf Funktionen und Sicherheitsupdates zurückgegriffen werden, die von Windows erst ab Win10 unterstützt werden.

In der Steam-Statistik liegt die Windows 7 Nutzung auch bei nur noch knapp über 1,5%.