News CPU-Boost: Windows 11 beschleunigt jetzt auch den Start von Apps

[Weyoun]

Es gab keine künstliche Bremse, Microsoft hat einen Haufen Müll zusammengeschustert und fordert nun ab dem ersten Zentimeter 100% Vollgas, damit ihre Fußfesseln dem Nutzer nicht mehr so stark auffallen im Vergleich zu allen anderen Betriebssystemen.

Unfähigkeit ist auch eine Art von Bremse...

 

[waldi2005]

Jetzt noch die Verzögerung bei den Autostart-Programmen rausnehmen und vielleicht dauert es dann nach dem Hochfahren bei einem System mit 16C/32T nicht mehr 5 Minuten, bis alle Programme sich geöffnet haben

Lässt sich in der Registry einstellen unter: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Serialize

 

[SSD960]

Aber die Bleigewichte werden doch nicht entfernt, die CPU wird "nur" gezwungen maximalen Boost anzulegen, um das Blei schneller in Gang zu bringen.

Wie du schon geschrieben hast nur ein Workaround. An der eigentlichen Lösung wird nicht gearbeitet. Neulich habe ich auf einem T14s mit 8 GB RAM Windows 11 installiert. Sofort wieder durch CachyOS ersetzt. Dann war die Performance ok.

 

[Insebtion]

Ich schmunzle weiter über Windows Updates

 

[Piktogramm]

Die Verzögerung gibt es deshalb, weil es wenig Sinn ergibt Programme zu starten, wenn noch nicht einmal alle Dienste von Windows bereits lauffähig sind. Alles gleichzeitig starten zu lassen, macht zwar bei einer SSD nicht mehr so viel aus, aber was willst du mit einem Tool was Daten aus dem Netz holen möchte, wenn das eigentliche Netzwerk noch nicht gestartet ist?
[...]

Also man könnte ja so einen fancy init-System bauen, bei dem man Dienste, Services etc. als Unit anlegt, in denen definiert ist, ob/wann sie zu starten sind, welche Abhängigkeiten vorher gestartet sein müssen. So bisschen Graphentheorie um das Aufzulösen und ab geht der Lennart. Müssten halt jemand fragen, der sich damit auskennt.
Ich Schlage den Namen "SystemW" vor!

Slogan zur Einführung: "SystemW statt wait!"

 

[xexex]

Also man könnte ja so einen fancy init-System bauen, bei dem man Dienste, Services etc. als Unit anlegt, in denen definiert ist, ob/wann sie zu starten sind, welche Abhängigkeiten vorher gestartet sein müssen.

Den gibt es unter Windows seit es Windows NT gibt, ungefähr seit der Zeit als überhaupt die ersten Linux Zeilen geschrieben wurden und vermutlich nicht einmal Init.d existierte. Er war sogar zeitweise so intelligent, dass es zum schnelleren Systemboot auf HDDs, Cache Dateien anlegte und jeden einzelnen Boot analysierte.

Es wäre mir aber neu dass unter Linux, KDE Startprogramme über den Systemstartdienst gestartet werden, wieso sollte man das unter Windows erwarten? Wenn eine Software eine laufende grafische UI benötigt, dann kann sie nun mal erst dann ausgeführt werden, wenn diese geladen ist.

Ich kann an dieser Stelle natürlich nur für mich sprechen, aber mein altes Windows mit einigen Tools im Autostart, hat mehr als hervorragende Startzeiten. Wenn es bei einem anders aussehen sollte, ist es kaum ein Problem des OS, sondern der Software und der Konfiguration.

 

[Kkndzocker]

Ich hätte gerne noch schnelleren Boot ohne aktiviertem Schnellstart und noch schnellere Updates.
Warum muss ich mit 9800X3D und NVMe immer noch so lange auf Windows warten?

Bei mir ist gefühlt nach 60 Sekunden auf dem Desktop alles da. 🤷‍♂️

Bin bei 32Sek bis zum Desktop mit schlechterer Hardware. (Ryzen 7 5700X SSD EVO 500GB)

 

[t3chn0]

Ich merke exakt 0,0 Unterschied zu vorher.

 

[Land_Kind]

Das Ergebnis ist das gleiche: Während des Training hat man die "Bremse" eingebaut und zurück im Tal ist man dann plötzlich "Superman", so wie man jetzt plötzlich nach dem Lösen der künstlichen Bremse "Super-Windows" zu haben scheint.

Ich sehe das schlicht als Ausgleich für jemanden, der nicht wie ich in den Bergen wohnt.

 

[mae]

Dynamische Taktsteuerung und dynamisches Verteilen von Zeitslots auf Prozessoren machen alle Betriebssysteme. Das was die Neuigkeit bei Windows ist, noch vorm Prozessstart den höchsten (boost) Energiezustand des Prozessors einzustellen macht Linux als Kernel, keine mir bekannte Dirstribution, Android so.

Der Satz ist unklar formuliert. aber ich nehme an, Du meinst, dass Linux das nicht so macht.

Mein Eindruck ist, dass das System unter Linux inzwischen nicht mehr leicht vom Benutzer zu beeinflussen ist (zumindest muss man da deutlich von der Default-Konfiguration weg). Na jedenfalls scheint der Takt erst raufzugehen, wenn tatsaechlich was auf der CPU laeuft. Das geht dann recht schnell, aber jedenfalls nicht schon im vorhinein (wobei m.E. die paar ms, bis das hochtaktet, fuer den Benutzer nicht wirklich spuerbar sein sollten).

Beispiel: Core Ultra 225:

#default-Einstellungen unter Debian 13
root@arrowlake:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver|uniq
intel_pstate
root@arrowlake:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor|uniq
powersave
#wobei mein Eindruck ist, dass sich intel_pstate wenig vom scaling_governor sagen laesst.
#Mal ein sehr kurzes Programm gestaertet:
root@arrowlake:~# perf stat true
              0.59 msec task-clock                       #    0.373 CPUs utilized             
...
                53      page-faults                      #   89.573 K/sec                     
            866562      cpu_atom/cycles/                 #    1.465 GHz                       
     <not counted>      cpu_core/cycles/                                                        (0.00%)
       0.001585812 seconds time elapsed

       0.001637000 seconds user
       0.000000000 seconds sys
# Also das Programm wurde auf einem E-Core gestartet und der Durchschnittstakt in der kurzen Zeit war gering.
# Wobei die Wahl des E-Cores wohl von Linux kam und nicht von intel_pstate.
# Als naechstes ein etwas laengeres Programm:
root@arrowlake:~# perf stat gforth -e ": foo 10000000 0 do loop ; foo bye"
            18.01 msec task-clock                       #    0.952 CPUs utilized             
                 0      context-switches                 #    0.000 /sec                      
                 0      cpu-migrations                   #    0.000 /sec                      
               323      page-faults                      #   17.930 K/sec                     
          77209616      cpu_atom/cycles/                 #    4.286 GHz                       
     <not counted>      cpu_core/cycles/                                                        (0.00%)
       0.018914351 seconds time elapsed

       0.018931000 seconds user
       0.000000000 seconds sys
# Noch immer nur auf dem E-Core, aber im Durschnitt schon nahe am Maximaltakt (4.4GHz), das Hochtakten ging also schnell

# Noch laenger (eine 0 mehr in der Schleife):
root@arrowlake:~# perf stat gforth -e ": foo 100000000 0 do loop ; foo bye"

 Performance counter stats for 'gforth -e : foo 100000000 0 do loop ; foo bye':

            145.70 msec task-clock                       #    0.993 CPUs utilized             
                 1      context-switches                 #    6.863 /sec                      
                 1      cpu-migrations                   #    6.863 /sec                      
               325      page-faults                      #    2.231 K/sec                     
         618731934      cpu_atom/cycles/                 #    4.247 GHz                         (50.79%)
         693341896      cpu_core/cycles/                 #    4.759 GHz                         (49.21%)
       0.146715130 seconds time elapsed

       0.146704000 seconds user
       0.000000000 seconds sys
# Da wurde dann nach vielleicht 80ms gemerkt, dass das Programm doch laenger laeuft,
# auf den P-Core umgeschaltet, und der dann auch relativ zuegig auf seinen Maximaltakt (4.9GHz) gebracht.

#Mal sehen, was mit der performance governor macht:
root@arrowlake:~# for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance >$i; done
root@arrowlake:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor|uniq
performance
root@arrowlake:~# perf stat true

 Performance counter stats for 'true':

              0.27 msec task-clock                       #    0.338 CPUs utilized             
           1172299      cpu_atom/cycles/                 #    4.296 GHz                       
     <not counted>      cpu_core/cycles/                                                        (0.00%)
       0.000808000 seconds time elapsed

       0.000833000 seconds user
       0.000000000 seconds sys
# scheint zwar keinen Einfluss auf die Wahl des Cores zu haben, aber darauf, wie schnell hochgetaktet wird. 
# Deutlich unter 1ms ist wirklich schnell
# Das Umschalten auf den P-Core erfolgt aber immer noch nach aehnlich langer Zeit:
root@arrowlake:~# perf stat gforth -e ": foo 100000000 0 do loop ; foo bye"

 Performance counter stats for 'gforth -e : foo 100000000 0 do loop ; foo bye':

            141.02 msec task-clock                       #    0.995 CPUs utilized             
                 1      context-switches                 #    7.091 /sec                      
                 1      cpu-migrations                   #    7.091 /sec                      
               319      page-faults                      #    2.262 K/sec                     
         619090602      cpu_atom/cycles/                 #    4.390 GHz                         (49.20%)
         689196651      cpu_core/cycles/                 #    4.887 GHz                         (50.80%)
       0.141766375 seconds time elapsed

       0.137697000 seconds user
       0.004049000 seconds sys

Und das ganze mit einem Ryzen 8700G unter Debian 12:

root@smaug:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver|uniq
acpi-cpufreq
root@smaug:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor|uniq
schedutil
# Das ganze cpufreq-scaling-System weiss nicht so wirklich, dass der mehr als 4200MHz kann:
root@smaug:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies|uniq
4200000 2200000 1600000
root@smaug:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq|uniq
4200000
# Hoehere Takte kommen also von der Firmware
# Mal sehen, wie schnell er hochtaktet:
root@smaug:~# perf stat true

 Performance counter stats for 'true':

              0.31 msec task-clock                       #    0.324 CPUs utilized             
            837921      cycles                           #    2.731 GHz                       
       0.000945784 seconds time elapsed

       0.001024000 seconds user
       0.000000000 seconds sys
#geht's schneller mit dem performance-governor?
root@smaug:~# for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance >$i; done
root@smaug:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor|uniq
performance
root@smaug:~# perf stat true

 Performance counter stats for 'true':

              0.29 msec task-clock                       #    0.328 CPUs utilized             
            842617      cycles                           #    2.912 GHz                       
       0.000882960 seconds time elapsed

       0.000951000 seconds user
       0.000000000 seconds sys
# nicht wirklich, scheint also praktisch nur von der firmware gesteuert zu sein

Naja, jedenfalls wird der Takt nicht von vornherein hinaufgesetzt, aber da das eh innerhalb von Millisekunden geht, spielt das auch keine grosse Rolle. Die Wahl des E-Cores auf dem Intel-Prozessor ist aber interessant, insbesondere da der nach meinen Messungen nicht verbrauchseffizienter ist.

 

[Melvyn]

Aber Hauptsache was mit Linux im Windows Thread gepostet.

Nee, weiß ich nicht.
Aber wie darunter geschrieben, ich hab bis Ende 2022 selbst hauptsächlich Windows genutzt und auch seitdem auf Arbeit und anderen Gelegenheiten.

Und Win10+11 sind verglichen mit sowohl Linux, ja, aber eben auch Win8.1 deutlich langsamer im Starten. Mein Arbeitsrechner hat brauchbare HW und dennoch: Erst 30s nach Login ist alles optisch fertig, aber im Hintergrund rödelt es gern weitere 1-2 Minuten.

 

[updater14]

Ist doch identisch zum RAM.
Ich habe das schon mit Vista nicht verstanden, warum soll das Betriebssystem die vorhandenen Ressourcen nicht auch benutzen?
Was hilft es mir, wenn die CPU im Schlummermodus verbleibt, der RAM in großen Teilen brach liegt, aber alles irgendwie vor sich hin schleppt.

Natürlich ist es gut, wenn das Betriebssystem so wenig wie möglich und so viel wie nötig nutzt, aber es weiß doch was zu Verfügung steht und wenn das Ressourcenmanagement passt, dann ist doch alles in Butter.

 

[Salamimander]

@updater14 RAM verbraucht aber nicht mehr Strom wenn er genutzt wird. Und ALLE anderen OS machen es besser. Wirklich ausnahmslos … selbst die alten aus dem Hause MS…

 

[Biertrinker]

Verzeihung, aber den Artikel finde ich sehr lückenhaft. Ihr redet davon nachsehen zu können ob das Feature bereits aktiviert ist er nennt sogar das Programm mittels dessen sich nachschauen lässt. Erwähnt aber überhaupt nicht wo genau man nachschauen muss.

Dann nehmt ihr Bezug auf testergebnisse eurer Kollegen, sprecht aber Artikel überhaupt nicht an die maßnahmen etwas bringen obwohl die testergebnisse vorliegen.

Insgesamt einer der schwächeren Artikel hier. Schade

 

[bart1983]

So kann man es natürlich auch machen, einfach Ressourcen auf ein Problem werfen, ohne das Problem (deng anzen Bloat) zu lösen.

Erstmal die CPU hochtakten für den Taschenrechner - wäre es nicht so traurig, dann könnte man fast darüber lachen

Selbst beim Calc? Lol. Habe mal das in Linux mit KCalc nachgespielt: Ist sofort da & der CPU-Takt blieb bei 1,4Ghz und belegt 22MB RAM

.


Was zum Teufel muss man für den Taschenrechner bitte boosten? Hat MS da etwa auch noch einen KI-Assistenten reincodiert?

 

[Piktogramm]

Den gibt es unter Windows seit es Windows NT gibt, ungefähr seit der Zeit als überhaupt die ersten Linux Zeilen geschrieben wurden und vermutlich nicht einmal Init.d existierte. Er war sogar zeitweise so intelligent, dass es zum schnelleren Systemboot auf HDDs, Cache Dateien anlegte und jeden einzelnen Boot analysierte.

Es wäre mir aber neu dass unter Linux, KDE Startprogramme über den Systemstartdienst gestartet werden, wieso sollte man das unter Windows erwarten? Wenn eine Software eine laufende grafische UI benötigt, dann kann sie nun mal erst dann ausgeführt werden, wenn diese geladen ist.

Ähh, ich hatte die Diskussion so verstanden, dass dass es um die Delayed auto-start services die bei Windows auch zum "init-System" bzw. dem Service Control Manager gehören.
Und bei aller Liebe, solche Delays sind einfach üble Hacks und sprechen nicht für eine saubere Auflösung der Abhängigkeiten.

Windows Autostarts aus dem Autostartordner bzw. unter Linux DEs ~/.config/autostart sollten bei beiden OS nicht vom init-System bearbeitet werden, sondern von der DE/Session Management.
Da du von der Abhänigkeit wie Netzwerk geschrieben hattest, dachte ich auch ans Autostarts im Konext der laufenden Usersession, denn die lösen solche Abhängigkeit zum Netzwerkstack doch garnicht auf?!

Ich kann an dieser Stelle natürlich nur für mich sprechen, aber mein altes Windows mit einigen Tools im Autostart, hat mehr als hervorragende Startzeiten. Wenn es bei einem anders aussehen sollte, ist es kaum ein Problem des OS, sondern der Software und der Konfiguration.
[BILD]

Dicker Hardwareknüppel hilft
Im großen und ganzen ist der technische Unterbau von Windows nicht schlecht[1]. Da gehe ich mit, der ganze grundlegende Kram funktioniert, ist für die meisten Belange ausreichend schnell und effizient. Bei einigen guten Lösungen war Microsoft auch durchaus früh dabei, die Weiterentwicklung ist aber gefühlt unterlassen worden und es gab eher mal Hacks wie den Beschriebenen.

[1] außer NT-Paths..

Der Satz ist unklar formuliert. aber ich nehme an, Du meinst, dass Linux das nicht so macht.

Ja.

Mein Eindruck ist, dass das System unter Linux inzwischen nicht mehr leicht vom Benutzer zu beeinflussen ist (zumindest muss man da deutlich von der Default-Konfiguration weg). Na jedenfalls scheint der Takt erst raufzugehen, wenn tatsaechlich was auf der CPU laeuft. Das geht dann recht schnell, aber jedenfalls nicht schon im vorhinein (wobei m.E. die paar ms, bis das hochtaktet, fuer den Benutzer nicht wirklich spuerbar sein sollten).

Ist halt P-State. An sich geben die Govonor der CPU Paramater vor und die CPU kümmert sich in Sachen Zustandsverwaltung großartig selber. Wobei aktuelle CPUs da unter <5ms um auf Last zu reagieren können.
https://chipsandcheese.com/p/addendum-clock-ramp-on-adl-zen-4-m1-and-more

Und vom Nutzer beeinflussbar ist doch an der Stelle viel, du könntest selbst den Treiber fürs Scaling umstellen: https://wiki.archlinux.org/title/CPU_frequency_scaling#Scaling_drivers

Ist halt sinnig, wieso sollte auf so schnelle Zustandsanpassung an Last verzichten?

[Intel, verhält sich sauber und schnell]

Die Einstellungen schränken bei meinem AlderLakeN hauptsächlich die Powertargets ein. Oder hat es das zumindest, ich kann es gerade nicht reproduzieren.

Und das ganze mit einem Ryzen 8700G unter Debian 12:

root@smaug:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver|uniq
acpi-cpufreq
[...]

Naja, jedenfalls wird der Takt nicht von vornherein hinaufgesetzt, aber da das eh innerhalb von Millisekunden geht, spielt das auch keine grosse Rolle. Die Wahl des E-Cores auf dem Intel-Prozessor ist aber interessant, insbesondere da der nach meinen Messungen nicht verbrauchseffizienter ist.

Der scaling driver ist auffällig. Eigentlich sollte bei AMD da als Standard AMD-pstate-epp genutzt werden.


Was aber auch so ein Ding ist, die Taktfrequenzen sind bei modernen CPUs auch sehr schnell wieder im Keller. Wieso unter Windows da jetzt 1..3Sekunden Pauschalboost angesagt ist bemerkenswert.

Ergänzung (Gestern um 22:55)

Was zum Teufel muss man für den Taschenrechner bitte boosten? Hat MS da etwa auch noch einen KI-Assistenten reincodiert?

Verdachtsboost auf Anwendungsstart.

 

[areiland]

Jetzt noch die Verzögerung bei den Autostart-Programmen rausnehmen und vielleicht dauert es dann nach dem Hochfahren bei einem System mit 16C/32T nicht mehr 5 Minuten, bis alle Programme sich geöffnet haben

Dafür gibts eine einfache Lösung: Den Ruhezustand nutzen und die Programme nicht mehr schliessen. Hat bei mir immer saugut funktioniert und musste nur am Patchday wegen des fälligen Neustarts unterbrochen werden.

Selbst jetzt mit Linux nutze ich nur den Ruhezustand und starte nur gelegentlich mal neu.

Einfacher kann man solche Hemmnisse nämlich nicht ausmerzen.

 

[xexex]

Die Wahl des E-Cores auf dem Intel-Prozessor ist aber interessant, insbesondere da der nach meinen Messungen nicht verbrauchseffizienter ist.

Das ist nichts neues und ist von Intel so vorgesehen, um ständige Threadwanderung zu minimieren und damit Prozesse mit wenig Last nicht die wichtigen Prozesse stören. Seit Arrow Lake und seit man sich von dem HT Unsinn getrennt hat, ist das standardmäßige Scheduling simpel. Starte alles auf den effizienten Kernen und sobald der Prozess mehr Leistung benötigt, verschiebe ihn auf einen P-Kern, falls noch einer frei ist.

https://www.igorslab.de/evolution-o...rchitektur-effizienz-und-softwareintegration/

Ein System macht ständig zig Dinge im Hintergrund und jeder Taskswitch kostet viele Taktzeiten. Da ergibt es Sinn prinzipiell alles auf den vielen E-Kernen auszuführen und nur bei Bedarf oder wenn eine Applikation es anfordert, die P-Kerne zu nutzen.

Ergänzung (Gestern um 23:30)

Ähh, ich hatte die Diskussion so verstanden, dass dass es um die Delayed auto-start services die bei Windows auch zum "init-System" bzw. dem Service Control Manager gehören.

Es ging um diese Aussage.

Jetzt noch die Verzögerung bei den Autostart-Programmen rausnehmen und vielleicht dauert es dann nach dem Hochfahren bei einem System mit 16C/32T nicht mehr 5 Minuten, bis alle Programme sich geöffnet haben

Ganz abgesehen davon, dass es auf einem System auf einer SSD meist keine Minute dauert, hat es gute Gründe wieso Applikationen mit einer Verzögerung ausgeführt werden. Es ist bekanntlich schon lange nicht mehr so, dass sobald der Windows Bildschirm erscheint das System vollständig geladen ist. Technisch gesehen wartet Windows nicht einmal auf das Netzwerk, wenn es nicht an eine Domäne angebunden ist.

Würde man nun schnellstmöglich alles auf einmal starten wollen, wie es früher übrigens durchaus der Fall war, käme es wie früher zur lauter Fehlermeldungen und Software die nicht richtig funktioniert. Packe einen Browser mit zig Tabs in den Autostart und starte ihn bevor das Netzwerk aktiv ist, dann bekommst du einen Browser mit zig kaputten Tabs.

die Weiterentwicklung ist aber gefühlt unterlassen worden und es gab eher mal Hacks wie den Beschriebenen.

Diese "Hacks" sind oft direkt per Gruppenrichtlinien steuerbar, wie die parallele Ausführung von Autostartprogrammen oder ob ein System auf das Netzwerk warten soll oder nicht. Windows muss aber für eine breite Masse OOTB funktionieren und da nimmt man lieber 2-3 Sekunden Verzögerung in Kauf, über die sich niemand außerhalb irgendwelcher Foren beschwert, als laute kaputte Anwendungen die zu früh ausgeführt worden.

Es gibt mehr als ausreichend Werkzeuge um genau prüfen zu können wie lange was zum Start benötigt, einige davon sogar direkt installiert und andere verwendet Windows ständig selbst zur Optimierung. Selbst die Zeit die das System im UEFI verbringt wird von Microsoft protokolliert, man muss nur die Augen aufmachen und Probleme auch mal bei sich suchen.

 

[Piktogramm]

@xexex
Danke, ich habe gerade gelernt, dass in Windows bei den Autostarts aus der Usersession "Wait for idle State" zum Einsatz kommt.

Lustiger Gedanke, aber ich sehe da echt größere Wartezeiten bei Systemen mit (erzwung) mehreren Autostarteinträgen. Dann lieber Massenstarts mit geringer Priorisierung der entsprechenden Prozesse mit späterem Normalisieren der Prioritäten.

Was die Fehlermeldungen von früher angeht, also ich habe ja von Win95 bis Win11 alles mitgenommen inkl. NT 4.0 außer WinMe, aber Fehlermeldungen beim Autostart mit mangelnden Abhängigkeiten wären mir neu.

Wenn das Netzwerk nicht stehe, Software muss so oder so damit umgehen, dass externe Ressourcen nicht zur Verfügung stehen. Da ändert ein Autostartdelay nix.

 

[xexex]

Danke, ich habe gerade gelernt, dass in Windows bei den Autostarts aus der Usersession "Wait for idle State" zum Einsatz kommt.

Jupp... Erst dann ist ein System nun mal "Ready".

Wenn das Netzwerk nicht stehe, Software muss so oder so damit umgehen, dass externe Ressourcen nicht zur Verfügung stehen. Da ändert ein Autostartdelay nix.

Dein Ansatz ist ein Wunschdenken, an der Realität vorbei. Der Browser ist dabei der simpelste Beispiel, der wird einfach zig kaputte Tabs öffnen und es dabei belassen. Die Textanwendung wird ohne den Druckdienst völlig falsche Randeinstellungen konfigurieren und ein Spiel ohne gestartete "Spieldienste" egal welcher Art, ebenfalls in eine Fehlermeldung reinlaufen.

Die Lösung zu warten bis das System nach dem Boot in den Idle Zustand übergeht ist pragmatisch. Man hat aus Jahren an Beschwerden, gemeldeten Problemen und Software die von Optimalzustand ausgeht, schlichtweg gelernt.

Mit "deinem" Ansatz hätten wir vermutlich noch immer ein System, was nur eine Version einer Bibliothek im System zulässt und davor ausgeht die Applikationen müssten damit doch umgehen. Die Wahrheit war eben eine andere, weshalb heutzutage zig Bibliotheken in unterschiedlichsten Versionen das System praktisch "zumüllen", aber dafür nicht mehr eine neu installierte Anwendung, diverse anderen zerschießt.