Die „Format-Dialog“-Funktion von Windows NT
(twitter.com/davepl1968)- Ende 1994 portierte Microsoft große Teile des Windows95-Benutzeroberflächencodes auf Windows NT; wegen der Unterschiede zwischen NT und Windows95 war für das Formatieren von Datenträgern eine eigene UI erforderlich
- Die Formatierungsoptionen wie Dateisystem, Bezeichnung, Clustergröße, Komprimierung und Verschlüsselung wurden zunächst auf Papier festgehalten und dann mit dem VC++ 2.0 Resource Editor als vertikale Auswahlliste aufgebaut
- Der temporäre Dialog, der nur bis zu einer besseren UI verwendet werden sollte, existiert rund 30 Jahre später noch immer in fast derselben Form
- Bei demselben Arbeitsprozess führte eine willkürliche Entscheidung über den zulässigen Bereich von cluster slack zur 32-GB-Beschränkung beim Formatieren von FAT-Volumes
- Da auch eine provisorisch eingecheckte Implementierung zu langfristigem Produktverhalten und Einschränkungen werden kann, sollte man beim Einbau „temporärer“ Lösungen vorsichtig sein
Der Windows-NT-Format-Dialog, an einem Donnerstagmorgen gebaut
- Ende 1994 portierte Microsoft einen großen Teil des Benutzeroberflächencodes von Windows95 auf Windows NT
- Die Format-Funktion war ein Bereich, in dem wegen der großen Unterschiede zwischen NT und Windows95 eine separate benutzerdefinierte UI nötig war
- Die Auswahlpunkte für die Datenträgerformatierung wurden zunächst auf Papier zusammengestellt
- Dateisystem
- Bezeichnung
- Clustergröße
- Komprimierung
- Verschlüsselung
- Anschließend wurden die Optionen mit VC++ 2.0 und dem Resource Editor in einer vertikal gestapelten Form angeordnet, die der benötigten Reihenfolge möglichst nahekam
- Diese UI war weniger als ausgereiftes Design gedacht, sondern als temporäre Implementierung, bis eine bessere UI kommen würde
Langfristige Folgen einer temporären Implementierung
- Rund 30 Jahre später existiert dieser Dialog noch immer in der Form, in der er an jenem Donnerstagmorgen erstellt wurde
- Auch die 32-GB-Beschränkung beim Formatieren von FAT-Volumes geht auf eine willkürliche Entscheidung aus derselben Zeit zurück
- Damals musste entschieden werden, wie viel cluster slack noch akzeptabel war
- Diese Entscheidung führte zur Größenbeschränkung beim Formatieren von FAT-Volumes
- Ein „temporärer“ Check-in kann sich entgegen der ursprünglichen Absicht zu langfristigem Produktverhalten und festen Einschränkungen verfestigen
1 Kommentare
Meinungen auf Hacker News
Im Quellcode von Windows NT4 ließ sich bestätigen, dass er am 13. Februar 1995 erstmals Teile des Codes für den Formatierungsdialog geschrieben hat; die Angabe Ende 1994 bis Anfang 1995 stimmt also im Großen und Ganzen
Allerdings unterstützte NT4 FAT32 nicht, und FAT-Volumes erlaubten auch 64K-Cluster, sodass bis zu 4 GB möglich waren – größer als bei vielen damaligen Systemen. Beim FAT-Format von NT4 gab es keine Cluster-Prüfung oder Optionen; die Clustergröße wurde anhand der Volume-Größe festgelegt
Außerdem lag die 32-GB-Grenze für FAT32-Volumes nicht im Dialog, sondern in der internen Formatierungsfunktion. Unter Windows 2000 kann man zwar versuchen, ein Laufwerk mit mehr als 32 GB als FAT32 zu formatieren, aber am Ende der Formatierung schlägt es wegen eines hartkodierten Limits fehl. Das gilt genauso für das Kommandozeilenprogramm format.com, das dieselbe Funktion verwendet
Ich weiß nicht, warum er seinen eigenen Anteil immer übertreibt. Auch beim Zip-Ordner-Code, den Microsoft von Info-Zip lizenziert hatte, glaubten manche Leute, er habe ihn geschrieben, nur weil er bei der Integration daran gearbeitet hatte. Inzwischen scheint er wohl Influencer werden zu wollen, und Übertreibungen gehören offenbar dazu
Ob FAT32 Ende 1994 bereits in Entwicklung war, weiß ich nicht, aber weder Windows NT 4 noch die frühen Versionen von Windows 95 enthielten es. Als es in Windows 95 OSR2 eingeführt wurde, akzeptierte der format-Befehl problemlos Partitionen bis 128 GiB; Windows 95 ist allerdings nicht NT
Die tatsächliche Ursache scheint die interne Formatierungsfunktion von Windows 2000 gewesen zu sein. GUI, format-Befehl und diskpart können alle keine Dateisysteme über 32 GiB erstellen. Warum das so war, obwohl es damals bereits Laufwerke dieser Größe gab, ist unklar. Wenn man etwas wie mkdosfs unter Linux verwendet, akzeptiert der VFAT-Treiber von Windows 2000+ auch 2-TiB-Volumes, und man kann Windows 2000 sogar auf solchen großen Volumes installieren
Ehrlich gesagt sah er aus, als sei er durch ein Obfuskierungs-Tool gelaufen, und ich dachte, der ursprüngliche Autor habe ihn absichtlich so gestaltet, um Änderungen oder Verbesserungen durch Microsoft zu erschweren. Von diesem Code habe ich immer noch Albträume
Woher kam dann die Corvette: https://www.tomshardware.com/software/windows/dev-shows-off-...
Dieser Code scheint auch in einigen XP-Versionen noch vorhanden gewesen zu sein: https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b...
Bei der ZIP-Unterstützung ist der Quellcode der Zip-Ordner selbst schwer zu finden. Stattdessen gibt es Codeauszüge von einer anderen Firma, Schlumberger Technology Corp.: https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b... Wenn man dem Kommentar glaubt, wurde der Code 1996 hinzugefügt
Dave Plummer ist wirklich ein toller Typ. Mir gefällt, wie nüchtern er darüber schreibt, an einem der meistgenutzten Kernel der Geschichte gearbeitet zu haben
Er hat unter anderem den Task-Manager für Windows, die Portierung von Space Cadet Pinball auf Windows NT, Zip-Datei-Unterstützung für Windows und HyperCache[4] für Amiga entwickelt und soll außerdem sechs Patente im Bereich Software Engineering erhalten haben
https://en.wikipedia.org/wiki/Dave_Plummer
Zeigt eine häufige Falle sehr gut. Wenn man ein Problem mit einem Workaround „löst“, rutscht die Priorität für eine bessere Lösung unter die aller noch ungelösten Probleme.
Von solchen ungelösten Problemen gibt es immer genug, sodass niemand mehr zurückkommt, um sich den Workaround noch einmal anzusehen.
Ich weiß nicht mehr, wo ich das gehört habe, aber ich benutze es in der Firma oft, um dafür zu argumentieren, keinen Workaround herauszugeben, sondern es von Anfang an richtig zu bauen.
Aus der Aussage „Ich habe alle auswählbaren Optionen rund um das Formatieren von Datenträgern auf Papier notiert, etwa Dateisystem, Label, Clustergröße, Komprimierung, Verschlüsselung usw.“ folgt für mich nicht so recht die Schlussfolgerung „Es war eine provisorische UI, die nur halten sollte, bis eine elegante UI kommt“.
Wenn alle nötigen Optionen in einer einfachen Oberfläche angezeigt werden, was sollte dann in eine „elegantere“ Oberfläche noch hinein?
Dieser Dialog existiert nicht nur immer noch, er hat auch Tools wie das HP USB Disk Storage Format Tool beeinflusst. Das habe ich immer benutzt, um die 32-GB-FAT32-Grenze zu umgehen: https://www.majorgeeks.com/files/details/hp_usb_disk_storage...
So wie es jetzt ist, ist es perfekt; ich hoffe, sie ersetzen es nicht durch eine „elegante UI“.
Als Ersatz für den Format-Dialog gefällt mir die neue UI ziemlich gut. Nur der Teil, der die Disk-Manager-Funktionen ersetzt, ist etwas schwach, weil eine grafische Darstellung des Datenträger-Layouts fehlt.
Standardansicht: https://i.imgur.com/56yZ8gZ.png
Abschnitt der erweiterten Ansicht: https://i.imgur.com/fKb3R8c.png
Vorhandene Partition formatieren: https://i.imgur.com/DmbX3FQ.png
Es ist nicht perfekt, behält aber im Großen und Ganzen dasselbe Layout bei, passt es an das OS-Theme an und fügt ein paar Optionen hinzu, die im alten Disk Manager über mehrseitige Assistenten liefen. Es gibt auch kleine Verbesserungen wie „format“ statt „start“, was direkter ist, und „cancel“ statt „close“, was besser passt. Natürlich werden manche es wohl als Weltuntergang betrachten, dass es 33 % breiter geworden ist.
Allerdings ist es fragwürdig, dass man die Größe neuer Partitionen weiterhin in MB eingeben muss. Zwar werden lokalisierte Zahlentrennzeichen eingefügt, aber da die Zahlen künftig noch größer werden, ist es schon etwas seltsam, dass man sich mit Millionen von MB befassen muss.
Ich glaube nicht, dass es provisorische und dauerhafte Lösungen als getrennte Kategorien gibt, sondern eher schlechte Lösungen und gute Lösungen. Eine gute Lösung bleibt bestehen, weil sie gut genug ist, selbst wenn sie schnell implementiert wurde.
Auch eine schlechte Lösung kann bestehen bleiben, wenn sie eine Zeit lang die einzige oder praktikable Option ist, und alles Spätere muss dann abwärtskompatibel dazu sein.
Ich habe bei einer der größten und ältesten Banken Europas gearbeitet, und die Produktionsumgebung war oft voll von solchen Workarounds.
Meist waren das wiederum provisorische Lösungen, um schnell größere Probleme zu beheben, die durch frühere provisorische Fixes entstanden waren.
Vorsicht vor „gut genug“ wirkenden Workarounds. Die zentrale Logging-Komponente unserer Firma wurde von einem Praktikanten geschrieben und enthält POC im Namen.
Auch das Datenformat sah aus, als hätte es ein Praktikant entworfen; als es allen richtig auffiel, waren bereits so viele Daten geschrieben worden, dass Budget und Aufwand für eine Korrektur größer waren als das Problem selbst.
Ich tröste mich damit, dass man nicht immer alles perfekt machen kann, sondern Prioritäten auf das Wichtigste setzen und weniger Wichtiges bis zu einem gewissen Grad durchgehen lassen muss.
Wie das alte Sprichwort sagt: Nichts ist so dauerhaft wie ein Workaround.