._ut schrieb:
Die Möglichkeiten von NTFS sind mir durchaus bekannt. Nur werden sie von Windows überhaupt nicht genutzt. Genau davon handelt mein Statement.
Denn das OS nutzt nicht die Möglichkeiten des FS. Unter Windows kann man NTFS nur wie FAT nutzen, denn die API ist auf FAT ausgerichtet und seitdem nicht mehr modernisiert worden.
Das möchte ich lediglich in der Hinsicht anfechten, dass es seit NTFS möglich ist, Dateien und Ordner mit einem Mausklick zu verschlüsseln - 2000/XP nutzen diese NTFS-Möglichkeit durchaus.
Ansonsten geb ich dir Recht, dass das Dateisystem (welches ja auch keine Neuentwicklung, sondern lediglich auf FAT erweitert wurde) garantiert noch mehr könnte, als das was MS in die API integriert hat.
Zur Stabilität (Treiberseitig):
Das was Microsoft eigentlich mit der NT-Reihe vermeiden wollte (die Unterbindung der direkten Hardware-Kontrolle seitens eines Programmes) und durch immer mehr Treiber-Einbindung auszugleichen versucht, ist leider (wie ich heute in Datenverarbeitung gelernt hab
) insofern auch wieder riskant, weil schon kleine Programmierfehler in Treibern, das System abwürgen können.
Ein Beispiel:
Das Treibermodell von Windows beinhaltet so genannte Windows-IO-Funktionen oder auch Handles genannt. Um ein Gerät zu aktivien / zu öffnen ist der Befehl CreateFile() (auf C++ Basis) nötig. Sind alle Operationen gemacht worden, ist es unbedingt erforderlich das Gerät wieder mit CloseHandle() zu schließen.
Wird dies nicht gemacht (was halt ein schlecht programmierter Treiber wäre), wird der Treiber nicht wieder freigegeben und bleibt im Arbeitsspeicher geladen. Schreibt nun ein anderes Programm in diesen Speicherbereich hinein, stürzt der Treiber ab (aufgrund der falschen Befehle) und dann kommt... Bingo! Der blaue Bildschirm
Ein anderes Problem der Treiberarchitektur von Windows ist zum Beispiel der Parameter NIL (=nichts). Dieser wird festgelegt, um das Verhalten des Programms beim Öffnen des Treibers zu bestimmen. Er bewirkt, dass das Programm solange pausiert wird, bis die Geräteaktion (z.B. das Kopieren von Daten auf einen USB-Stick) abgeschlossen ist. Dies kann ebenfalls zu Programmabstürzen führen, wenn die Datenübertragung einmal fehlerhaft ist. Da das Programm schließlich noch "pausiert" ist, hat es keine Möglichkeit einzugreifen.
Man sieht also, dass es durchaus möglich ist, mit nur einem unüberlegten Parameter das System lahmzulegen - Microsoft weiß das natürlich und hat anstatt wieder die gesamte Treiber-API zu ändern, einfach die Treiber Zertifizierung erfunden - sprich: Entwickler sendet Treiber an MS, Treiber wird auf eben solche Probleme geprüft. Wenn Treiber okay, kriegt Entwickler Treiber mit Windows-Zertifikat wieder.
Das nur mal ein wenig von der Treiber-Seite