- Unter Windows 7 und Windows Server 2008 R2 konnte bei Verwendung eines einfarbigen Desktophintergrunds während der Anmeldung der Welcome-Bildschirm bis zu 30 Sekunden sichtbar bleiben; Ursache war ein fehlendes Bereitschaftssignal
- Das Anmeldesystem wechselt erst vom Welcome-Bildschirm weg, wenn Taskleiste, Systemdienst-Komponenten, Desktopfenster, Anzeige des Hintergrundbilds usw. alle Bereitschaft melden oder 30 Sekunden vergangen sind
- Der Code für das Hintergrundbild rief
Report(WallpaperReady)nur dann auf, wenn ein Bitmap-Hintergrund vorhanden war; bei einem einfarbigen Hintergrund ohne Bitmap wurde die Wartebedingung daher bis zum Ende ausgeschöpft - Auch die Gruppenrichtlinie „Desktopsymbole ausblenden“ konnte nach demselben Muster dazu führen, dass der Aufruf von
Report(DesktopIconsReady)in einer Bedingung steckte und die Meldung über bereite Symbole ausblieb - Die eigentliche Anmeldung wurde dadurch nicht immer um 30 Sekunden verlängert; unabhängig davon, ob der Vorbereitungsvorgang ursprünglich nach 5 oder 25 Sekunden fertig gewesen wäre, blieb der Welcome-Bildschirm bis zum Timeout von 30 Sekunden sichtbar
Warum der Welcome-Bildschirm bei einfarbigem Hintergrund lange sichtbar blieb
- Nach Abschluss der Anmeldeauthentifizierung richtet Windows die Desktopumgebung des Benutzers ein
- Erstellen der Taskleiste
- Laden und Initialisieren mehrerer für Systemdienste zuständiger Komponenten
- Erstellen des Desktopfensters und Anzeigen der Symbole
- Laden des Hintergrundbilds im Fenster für den Desktophintergrund und Zeichnen auf dem Bildschirm
- Das Anmeldesystem wartet, bis jede Komponente meldet, dass sie bereit ist
- Wenn alle Komponenten Bereitschaft gemeldet haben, wird vom Welcome-Bildschirm gewechselt
- Oder nach Ablauf von 30 Sekunden wird vom Welcome-Bildschirm gewechselt
- Das Problem mit dem einfarbigen Hintergrund entstand, weil die Meldung über die Bereitschaft des Hintergrundbilds innerhalb des Bitmap-Ladecodes lag
- Wenn ein Bitmap-Hintergrund definiert ist, wird die Datei gesucht, in den Speicher geladen, auf den Bildschirm gezeichnet und anschließend
Report(WallpaperReady)aufgerufen - Wenn es wie bei einem einfarbigen Hintergrund keine Bitmap gibt, wird dieser Codepfad nicht ausgeführt, sodass keine
WallpaperReady-Meldung erfolgt - Das Anmeldesystem wartet auf eine Meldung, die nie kommt, und erreicht schließlich die 30-Sekunden-Grenze
- Wenn ein Bitmap-Hintergrund definiert ist, wird die Datei gesucht, in den Speicher geladen, auf den Bildschirm gezeichnet und anschließend
Fehlendes Bereitschaftssignal wiederholte sich auch bei Gruppenrichtlinien
- In dem zugehörigen Supportdokument heißt es, dass es auch bei aktivierter Gruppenrichtlinie „Desktopsymbole ausblenden“ zu einer Verzögerung von 30 Sekunden kommen kann
- Gruppenrichtlinien werden häufig nachträglich auf bestehenden Code aufgesetzt und daher leicht in Bedingungen wie „ausführen, wenn die Richtlinie es erlaubt“ eingeschlossen
- Der ursprüngliche Initialisierungscode für Desktopsymbole bindet an den Desktopordner, zählt die Symbole auf, fügt sie dem Bildschirm hinzu und ruft anschließend
Report(DesktopIconsReady)auf - Wenn beim Hinzufügen der Unterstützung für Gruppenrichtlinien dieser gesamte Block in eine Richtlinienbedingung verschoben wird, wird bei aktivierter Richtlinie zum Ausblenden der Symbole auch die Bereitschaftsmeldung nicht ausgeführt
- Der ursprüngliche Initialisierungscode für Desktopsymbole bindet an den Desktopordner, zählt die Symbole auf, fügt sie dem Bildschirm hinzu und ruft anschließend
- Dieses Verhalten bedeutet nicht, dass der Anmeldevorgang selbst zusätzliche 30 Sekunden dauert
- Je nach Systemleistung können ursprünglich alle Bereitschaftsmeldungen nach 5 Sekunden oder auch nach 25 Sekunden abgeschlossen sein
- Im Fehlerfall bleibt der Welcome-Bildschirm unabhängig von der tatsächlichen Vorbereitungszeit bis zum 30-Sekunden-Timeout sichtbar
- Dem Zeitstempel des Dokuments zufolge wurde dieses Problem im November 2009 behoben, einige Monate nach der Veröffentlichung von Windows 7 im Juli 2009
- Ein Grund, Bitmap-Hintergründe zu vermeiden, war früher, dass in Umgebungen mit 4 MB oder 8 MB Arbeitsspeicher allein das Hintergrundbild mit etwa 0,75 MB ins Gewicht fiel
1 Kommentare
Meinungen auf Hacker News
Als jemand, der einfarbige Hintergründe bevorzugt, überrascht es mich immer wieder, wie eine so einfache Vorliebe oft in seltsame Kaninchenlöcher führt.
Im aktuellen macOS bekommt man beim Versuch, einen benutzerdefinierten einfarbigen Hintergrund einzustellen, nur einen grell weißen Bildschirm: https://discussions.apple.com/thread/256029958?sortBy=rank
GNOME hat die gesamte UI zum Einstellen einfarbiger Hintergründe entfernt, aber technisch ist es noch möglich, wenn man mehrere Konfigurationsschlüssel manuell ändert; diese Schlüssel scheinen sich zudem von Version zu Version willkürlich zu ändern: https://www.tc3.dev/posts/2021-09-04-gnome-3-solid-color-bac...
Am Ende wirkt es wie eine halb beibehaltene Funktion für eine kleine Minderheit von Nutzern; besser wäre es, sie entweder richtig zu unterstützen oder sauber zu entfernen. Ich möchte einfach RGB-Werte eingeben, aber in diesem Zustand erscheint mir ein gut gepflegtes Wallpaper-System besser als eine instabile Logik für Hintergrundfarben.
wallpaper type: plain colorauswählen und die Farbe über eine Farbauswahl festlegen.Es zeigt auch den Bildschirm an, auf den es angewendet wird, und es gibt eine boolesche Option, um es auf alle Bildschirme gleichzeitig anzuwenden.
Auf modernen Telefondisplays ist das auch in Sachen Stromverbrauch sinnvoll und sieht ordentlich aus, aber etwas, das eine Standardoption oder ein Ein-Tap-Schalter in den Einstellungen sein sollte, wurde zu einer lästigen Aufgabe aus Misstrauen, Suchen und Resignation.
In früherem OS X funktionierte das über 20 Jahre lang problemlos, daher scheint es mit der Neuschreibung der System Preferences zusammenzuhängen.
Weil Desktop-Verknüpfungen über Generationen hinweg missbraucht wurden, ist das Anzeigen des Desktops zu verschwendetem Bildschirmplatz geworden, und selbst wenn man aufpasst, wird er am Ende zu einer unordentlichen Ödnis. Unter Windows gilt das besonders; ich habe mich einfach daran gewöhnt, den Desktop für gar nichts zu verwenden und auf mehreren Monitoren immer Fenster offen zu haben.
Nachdem ich die Windows-Welt 25 Jahre lang gemieden hatte und in den letzten Jahren in Unternehmensumgebungen zurückgekehrt bin, sehe ich dieses Muster ständig in Microsoft-Tools.
Wegen eines Sicherheitsproblems lädt Teams nicht, aber in Benachrichtigungen erscheint der vollständige Inhalt von Nachrichten; oder in der Cloud-Version von Word tippt man ein paar Wörter ein oder fügt ein ganzes Dokument ein, und erst danach läuft die Sicherheitsprüfung hinterher und verlangt, ein Sensitivity-Label zu setzen.
Das wirkt wie ein Zeichen dafür, dass Microsofts Softwarearchitektur für Web-Apps sehr schlecht ist, und die Desktop-Apps scheinen keine Ausnahme zu sein.
Danach kam die Berechtigungsanfrage; wenn man sie ablehnte, verschwand die Vorschau.
Bei offensichtlichen Use Cases funktionieren sie sehr gut, aber sobald man auf einen nicht abgedeckten Grenzfall trifft, stößt man sofort auf seltsame Probleme. Da Microsoft-Entwickler nicht den Ruf haben, schwach zu sein, könnte es an der Unternehmenskultur oder Arbeitsweise liegen; bei einer riesigen Nutzerbasis können 80 % geschäftlich sogar optimal sein. Trotzdem meidet man als externer Entwickler Microsoft-Produkte möglichst.
Laptops, die vor fünf Jahren perfekt schlafen konnten, sind jetzt 24-Stunden-Zombies, bei denen CPU, Lüfter und Festplatte weiterlaufen.
Ich bin sicher, dass eine ähnlich dumme Änderung wie die im Artikel eine funktionierende Funktion zerstört hat und dass niemand sie behebt, weil sie den neuesten Hirngespinsten im Weg stehen könnte, bei denen ein zehn Jahre alter Laptop selbst im Schlaf KI laufen lässt, um auf Basis mitgehörter Inhalte Werbung vorzuschlagen.
Das hängt mit einer Praxis zusammen, die ungefähr damals begonnen haben dürfte: Splash Screens werden nur für eine bestimmte Zeit angezeigt, danach zeigt man die Benutzerumgebung, bevor die Software vollständig gestartet ist.
Ich vermute, sowohl Betriebssysteme als auch Apps taten das, um den Eindruck zu vermeiden, „die App braucht zu lange“. Jetzt muss man raten, ob die Software wirklich geladen ist, bevor man sie benutzt.
Erst danach sieht man einen nicht reagierenden UI-Thread, der stumpf darauf wartet, dass die gesamte darunterliegende Software geladen ist.
Man hält einen halb kaputten, aber irgendwie nutzbaren Desktop für besser als eine Situation, in der man ewig in einem Ladebildschirm festhängt und in ein anderes OS booten muss, um das Problem zu beheben.
Wenn man etwas tut, zeigt die UI ein Lade-/Fortschrittsrad, aber tatsächlich dauert es endlos; beim Start einer Webseite sieht man einen leeren Bildschirm mit Platzhalterbalken oder unscharfen Farbbildern. Und das soll sogenanntes responsives Design sein.
Manchmal ist es für Nutzer besser, wenn das System optimistisch behandelt, dass es tatsächlich geladen wurde.
Ich habe gelernt, fast überall die Standardeinstellungen zu verwenden.
Anpassungen zu pflegen ist so mühsam, dass es am einfachsten ist, sich gar nicht darum zu kümmern. Die Ausnahme sind etwa 50 Zeilen VS-Code-Einstellungen, die in irgendeine mysteriöse Datei synchronisiert werden – vermutlich auf GitHub-Servern, aber an keinem Ort, den ich sehen kann.
Auf meinem privaten Rechner nutze ich stow, auf Remote-Maschinen kopiere ich sie per Copy-and-paste. Mir gefällt, dass diese Tools so stabil sind, dass sie auch beim Wechsel auf Debian stable weiterhin funktionieren.
Selbst wenn ich ein Backup von Sublime Text von vor ein paar Jahren direkt wiederherstelle, funktionieren meine Benutzereinstellungen immer noch.
Als regelmäßige Erinnerung: nix ist tatsächlich gut.
Man kann sagen: „Es gibt einen Bug, und mit
nixos-rebuild build-vm --flake "github:user/repo#test-vm" && ./result/bin/run-*-vmbekommt ihr eine Repro-VM.“ Auch der Code, der diese VM erstellt, ist kein sicherheitstechnischer Albtraum aus binären Blobs, sondern ein gewöhnlicher, für alle lesbarer nix-Ausdruck; und das Ausrollen auf eine neue Maschine ist mit einem einzigen Befehl erledigt.Wenn man versteht, was die Defaults tun, ist es oft mühsamer, jede Option unter der Sonne anzufassen.
Der Ausdruck „Comfort Food“ ist witzig. Seit ich von AIX zu Linux gewechselt bin, nutze ich immer noch den motif window manager mit einem steelblue4-Desktop und einem wheat-Hintergrund für xterm.
Das waren die Defaults, denen ich 1989 an der Uni zum ersten Mal begegnet bin, und ich habe seitdem nichts Besseres gesehen. Von Dingen wie GNOME oder KDE wird mir übel.
Ein angeflanschter
if()-Wrapper, dessen Geltungsbereich etwas zu weit gefasst wurde, ist ein klassisches Beispiel.Nostalgie ist eine starke Droge.
Nicht sarkastisch gemeint; ich bin ehrlich neugierig, ob HiDPI unter motif tatsächlich funktioniert.
Vor sehr langer Zeit, als ich Windows hobbymäßig nutzte, habe ich den Wert eines bestimmten Windows-Registry-Schlüssels bearbeitet und
explorer.exedurchcmd.exeersetzt.Dadurch startete Windows nicht
explorer.exe, um einen Desktop mit Hintergrundbild und Icons anzuzeigen, sondern es entstand eine Umgebung, in der auf einem einfarbigen Hintergrund jedes Fenster als Microsoft-cmd.exe-Shell erschien, ähnlich wie bei einem UNIX-Window-Manager. Es waren die klassischen schwarzen Windows-Kästen mit blauer Titelleiste und dünnem grauen Rahmen, und über die Eingabeaufforderung konnte man Apps wietaskmgr.exeausC:\windows\system32starten.Für mich fühlte sich das viel schneller und robuster an als die Nutzung von
explorer.exe, und es war definitiv leichtgewichtiger. Später sah ich in einem Foto in einem Artikel von Arthur Whitney eine Szene, in der auf dem Windows-Desktop nur ein einzigescmd.exe-Fenster geöffnet war; ich will damit nichts andeuten, aber es ist mir immer im Gedächtnis geblieben.Kürzlich habe ich das auch in der Microsoft-Dokumentation gesehen: https://learn.microsoft.com/en-us/windows/configuration/shel...
Ich erinnere mich, dass es auch für IoT oder Embedded günstige/kostenlose Windows-Versionen gab, die ohne
explorernur mit cmd liefen.So etwas fällt in die Kategorie dessen, was ich systemische Bugs oder „Typ-Bugs“ nenne.
Wenn man der Login-Komponente ein Token übergeben und den Destruktor des Tokens automatisch den Abschluss des Prozesses hätte markieren lassen, wäre dieser Bug kaum schreibbar gewesen.
Stattdessen hat man es zur Laufzeit zu „die Komponenten müssen sich daran erinnern“ gemacht, wodurch die Codestruktur selbst den Bug zulässt.
Vor ein paar Jahren gab es bei Facebook einen ähnlichen Bug: Die Benachrichtigungsanzahl zeigte an, dass es Benachrichtigungen gebe, aber beim Anklicken war nichts da. Der Pfad zur Aktualisierung der Anzahl und der Pfad zum Einfügen in die Liste waren unterschiedlich und liefen auseinander; als man beides von demselben Systemteil verwalten ließ, verschwand dieser Bug dauerhaft.
Ich habe immer angenommen, dass das an schlechtem Caching liegt.
Ein bisschen meta, aber ich habe inzwischen angefangen, mich auf Raymond-Chen-Artikel mit Titeln im Stil von „Why did happen with“ zu freuen.
Sie sind immer interessant.
Es ist der einzige Blog, der meine seit der Kindheit gepflegten Computer-Aberglauben rund um Windows aufgelöst hat.
Dieser Code erinnert mich sehr an viele meiner liebsten Kubernetes-Bugs.
if (request.authenticationData) { ok := validate(etc); if (!ok) { return authenticationFailure; } }Dasselbe Meme zieht sich also über Jahrzehnte hinweg.
Wenn jede Funktion, die eine bestimmte Berechtigung braucht, diese Berechtigung als Argument annimmt, etwa
void doFoo(PermissionToDoFoo permission, ...){...}, und Aufrufe nur über einen Pfad möglich sind, der aus den Authentifizierungsdaten die Berechtigung gewinnt,dann wird es unmöglich, den ungültigen Zustand auszudrücken, Foo ohne Berechtigung auszuführen.
Wurde es standardmäßig als authentifiziert behandelt, wenn
authenticationDatafehlte?Ein wenig abseits des Themas, aber ich mochte die Windows-Spotlight-Hintergründe auf dem Anmeldebildschirm, die automatisch aktualisiert werden, wirklich sehr.
Deshalb habe ich auch ein Skript genutzt, das sie mit dem Desktop-Hintergrund synchronisiert. Unter meinem Windows 10 blieb das jedoch ohne ersichtlichen Grund stehen, also schrieb ich stattdessen ein Skript, das das Bing Image of the Day herunterlädt: https://blog.est.im/2025/stdout-03