Windows – Erklärung eines Laien für „alles ist eine Datei“ – was unterscheidet sich von Windows?

Wie wirkt sich hier die „Alles ist eine Datei“-Philosophie aus?

Ich werde das erläutern, indem ich meine drei obigen Punkte im Detail erläutere.

Lange Antwort, Teil 1:Laufwerke vs. Gerätedateien

Angenommen, Ihr CF-Kartenleser wird als E: angezeigt unter Windows und /dev/sdc unter Linux. Welchen praktischen Unterschied macht es?

Es ist nicht nur ein kleiner Syntaxunterschied.

Unter Linux kann ich dd if=/dev/zero of=/dev/sdc sagen um den Inhalt von /dev/sdc zu überschreiben mit Nullen.

Denken Sie für eine Sekunde darüber nach, was das bedeutet. Hier habe ich ein normales Userspace-Programm (dd(1) ), die ich gebeten habe, Daten von einem virtuellen Gerät (/dev/zero) einzulesen ) und schreibe das Ausgelesene auf ein echtes physisches Gerät (/dev/sdc ) über das einheitliche Unix-Dateisystem. dd weiß nicht, dass es von speziellen Geräten liest und auf diese schreibt. Es funktioniert genauso gut mit normalen Dateien oder mit einer Mischung aus Geräten und Dateien, wie wir weiter unten sehen werden.

Es gibt keine einfache Möglichkeit, E: auf Null zu setzen Laufwerk unter Windows, da Windows zwischen Dateien und Laufwerken unterscheidet, sodass Sie nicht dieselben Befehle verwenden können, um sie zu bearbeiten. Das Beste, was Sie erreichen können, ist eine Festplattenformatierung ohne die Option "Schnellformatierung", die die meisten auf Null setzt des Laufwerksinhalts, schreibt dann aber ein neues Dateisystem darüber. Was, wenn ich nicht will ein neues Dateisystem? Was ist, wenn ich wirklich möchte, dass die Festplatte nur mit Nullen gefüllt wird?

Seien wir großzügig und sagen, dass wir wirklich ein frisches neues Dateisystem auf E: wollen . Um dies in einem Programm unter Windows zu tun, muss ich eine spezielle Formatierungs-API aufrufen.⁴ Unter Linux müssen Sie kein Programm schreiben, um auf die Funktion „Festplatte formatieren“ des Betriebssystems zuzugreifen. Sie führen einfach das entsprechende User-Space-Programm für den Dateisystemtyp aus, den Sie erstellen möchten:mkfs.ext4 , mkfs.xfs , oder was hast du. Diese Programme schreiben ein Dateisystem in eine beliebige Datei oder /dev Knoten, den Sie passieren.

Weil mkfs type-Programme auf Unixy-Systemen arbeiten mit Dateien, ohne künstliche Unterscheidungen zwischen Geräten und normalen Dateien zu treffen, das bedeutet, dass ich ein ext4-Dateisystem in einer normalen Datei auf meiner Linux-Box erstellen kann:

$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs

Dadurch wird im aktuellen Verzeichnis buchstäblich ein 1-MiB-Disk-Image mit dem Namen myfs erstellt . Ich kann es dann mounten, als wäre es jedes andere externe Dateisystem:

$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint

Jetzt habe ich ein ext4-Disk-Image mit einer Datei namens my-passwd-entry darin, die den /etc/passwd meines Benutzers enthält Eintrag.

Wenn ich möchte, kann ich dieses Bild auf meine CF-Karte brennen:

$ sudo dd if=myfs of=/dev/sdc1

Oder ich kann dieses Disk-Image packen, es Ihnen per Post zusenden und Sie es auf ein Ihres Medium schreiben lassen Auswahl, z. B. USB-Speicherstick:

$ gzip myfs
$ echo "Here's the disk image I promised to send you." | 
  mutt -a myfs.gz -s "Password file disk image" [email protected]

All dies ist unter Linux⁵ möglich, weil es keine künstliche Unterscheidung zwischen Dateien, Dateisystemen und Geräten gibt. Viele Dinge auf Unix-Systemen sind Dateien oder werden über das Dateisystem aufgerufen, sodass sie aussehen Dateien oder auf andere Weise ausreichend dateiähnlich aussehen, sodass sie als solche behandelt werden können.

Das Windows-Konzept des Dateisystems ist ein Sammelsurium; es unterscheidet zwischen Verzeichnissen, Laufwerken und Netzwerkressourcen. Es gibt drei verschiedene Syntaxen, die alle in Windows miteinander vermischt sind:das Unix-ähnliche ..FOOBAR Pfadsystem, Laufwerksbuchstaben wie C: und UNC-Pfade wie \SERVERPATHFILE.TXT . Dies liegt daran, dass es sich um eine Ansammlung von Ideen aus Unix, CP/M, MS-DOS und LAN Manager handelt und nicht um ein einziges kohärentes Design. Aus diesem Grund gibt es so viele illegale Zeichen in Windows-Dateinamen.

Unix hat ein einheitliches Dateisystem, bei dem auf alles über ein einziges gemeinsames Schema zugegriffen wird. Für ein Programm, das auf einem Linux-Rechner läuft, gibt es keinen funktionalen Unterschied zwischen /etc/passwd , /media/CF_CARD/etc/passwd , und /mnt/server/etc/passwd . Lokale Dateien, externe Medien und Netzwerkfreigaben werden alle gleich behandelt.⁶

Windows kann ähnliche Ziele erreichen wie mein obiges Disk-Image-Beispiel, aber Sie müssen spezielle Programme verwenden, die von ungewöhnlich talentierten Programmierern geschrieben wurden. Aus diesem Grund gibt es unter Windows so viele Programme vom Typ „virtuelle DVD“. Das Fehlen einer zentralen Betriebssystemfunktion hat einen künstlichen Markt für Programme geschaffen, um die Lücke zu füllen, was bedeutet, dass Sie einen Haufen Leute haben, die darum konkurrieren, das beste virtuelle DVD-ähnliche Programm zu erstellen. Wir brauchen solche Programme auf *ix-Systemen nicht, weil wir einfach ein ISO-Disk-Image mit einem Loop-Gerät mounten können.

Gleiches gilt für andere Tools wie Disk-Wipe-Programme, die wir auf Unix-Systemen ebenfalls nicht benötigen. Möchten Sie den Inhalt Ihrer CF-Karte unwiederbringlich verschlüsselt statt nur auf Null gesetzt? Okay, benutze /dev/random als Datenquelle statt /dev/zero :

$ sudo dd if=/dev/random of=/dev/sdc

Unter Linux erfinden wir solche Räder nicht immer wieder neu, weil die Kernfunktionen des Betriebssystems nicht nur gut genug funktionieren, sie funktionieren so gut, dass sie allgegenwärtig verwendet werden. Ein typisches Schema zum Booten einer Linux-Box beinhaltet ein virtuelles Disk-Image, um nur ein Beispiel zu nennen, das mit Techniken wie den oben gezeigten erstellt wurde.⁷

Ich denke, es ist nur fair darauf hinzuweisen, dass wir den netcat nicht hätten, wenn Unix TCP/IP I/O von Anfang an in das Dateisystem integriert hätte vs socat vs. Ncat vs nc Durcheinander, dessen Ursache dieselbe Designschwäche war, die zur Verbreitung des Disk-Imaging- und Löschwerkzeugs unter Windows geführt hat:das Fehlen einer akzeptablen Betriebssystemeinrichtung.

Lange Antwort, Teil 2:Pipes als virtuelle Dateien

Trotz seiner Wurzeln in DOS hatte Windows nie eine reiche Befehlszeilentradition.

Das soll nicht heißen, dass Windows keine hat eine Befehlszeile, oder dass viele Befehlszeilenprogramme fehlen. Windows hat heutzutage sogar eine sehr leistungsfähige Befehlsshell, passenderweise PowerShell genannt.

Es gibt jedoch Folgewirkungen dieses Fehlens einer Befehlszeilentradition. Sie erhalten Tools wie DISKPART Dies ist in der Windows-Welt fast unbekannt, da die meisten Leute die Festplattenpartitionierung und dergleichen über das Computer Management MMC-Snap-In vornehmen. Wenn Sie dann die Erstellung von Partitionen skripten müssen, finden Sie diesen DISKPART wurde nicht wirklich dafür gemacht, von einem anderen Programm angetrieben zu werden. Ja, Sie können eine Reihe von Befehlen in eine Skriptdatei schreiben und diese über DISKPART /S scriptfile ausführen , aber es geht um alles oder nichts. Was Sie wirklich in einer solchen Situation möchte, ist eher so etwas wie GNU parted , das einzelne Befehle wie parted /dev/sdb mklabel gpt akzeptiert . Dadurch kann Ihr Skript die Fehlerbehandlung Schritt für Schritt durchführen.

Was hat das alles mit „alles ist eine Datei“ zu tun? Ganz einfach:Pipes machen Befehlszeilen-Programm-I/O zu einer Art „Dateien“. Pipes sind unidirektionale Streams und haben keinen wahlfreien Zugriff wie eine normale Festplattendatei, aber in vielen Fällen ist der Unterschied ohne Bedeutung. Wichtig ist, dass Sie zwei unabhängig voneinander entwickelte Programme anhängen und über einfachen Text kommunizieren lassen können. In diesem Sinne können zwei beliebige Programme, die nach dem Unix-Prinzip entwickelt wurden, miteinander kommunizieren.

In den Fällen, in denen Sie wirklich eine Datei benötigen, ist es einfach, die Programmausgabe in eine Datei umzuwandeln:

$ some-program --some --args > myfile
$ vi myfile

Aber warum die Ausgabe in eine temporäre Datei schreiben, wenn Ihnen die „Alles ist eine Datei“-Philosophie einen besseren Weg bietet? Wenn Sie nur die Ausgabe dieses Befehls in ein vi einlesen möchten Editorpuffer, vi kann das direkt für Sie erledigen. Aus dem vi „normalen“ Modus, sagen Sie:

:r !some-program --some --args

Dadurch wird die Ausgabe dieses Programms an der aktuellen Cursorposition in den Puffer des aktiven Editors eingefügt. Unter der Haube vi verwendet Pipes, um die Ausgabe des Programms mit einem Teil des Codes zu verbinden, der dieselben Betriebssystemaufrufe verwendet, die er stattdessen zum Lesen aus einer Datei verwenden würde. Ich wäre nicht überrascht, wenn die beiden Fälle von :r – also mit und ohne ! — beide verwendeten dieselbe generische Datenleseschleife in allen gängigen Implementierungen von vi . Mir fällt kein guter Grund ein, es nicht zu tun.

Dies ist keine neuere Funktion von vi , entweder; es geht eindeutig auf das alte ed(1) zurück Texteditor.⁸

Diese mächtige Idee taucht immer wieder in Unix auf.

Erinnern Sie sich als zweites Beispiel an mein mutt E-Mail-Befehl oben. Der einzige Grund, warum ich das als zwei separate Befehle schreiben musste, war, dass ich wollte, dass die temporäre Datei *.gz heißt , damit der E-Mail-Anhang korrekt benannt wird. Wenn mir der Dateiname egal wäre, hätte ich die Prozessersetzung verwenden können, um das Erstellen der temporären Datei zu vermeiden:

$ echo "Here's the disk image I promised to send you." | 
  mutt -a <(gzip -c myfs) -s "Password file disk image" [email protected]

Das vermeidet das Temporäre, indem die Ausgabe von gzip -c umgedreht wird in ein FIFO (das dateiähnlich ist) oder ein /dev/fd Objekt (das dateiartig ist). (Bash wählt die Methode basierend auf den Fähigkeiten des Systems aus, da /dev/fd ist nicht überall verfügbar.)

Für noch eine dritte Möglichkeit, wie diese mächtige Idee in Unix erscheint, betrachten Sie gdb auf Linux-Systemen. Dies ist der Debugger, der für jede in C und C++ geschriebene Software verwendet wird. Programmierer, die von anderen Systemen zu Unix kommen, sehen sich gdb an und meckern fast immer darüber:"Igitt, es ist so primitiv!" Dann machen sie sich auf die Suche nach einem GUI-Debugger, finden einen von mehreren, die es gibt, und setzen ihre Arbeit glücklich fort … oft merken sie nicht, dass die GUI nur gdb ausführt darunter und bietet oben eine hübsche Schale. Auf den meisten Unix-Systemen gibt es keine konkurrierenden Low-Level-Debugger, da Programme auf dieser Ebene nicht konkurrieren müssen. Alles, was wir brauchen, ist ein gutes Low-Level-Tool, auf dem wir alle unsere High-Level-Tools aufbauen können, wenn dieses Low-Level-Tool einfach über Pipes kommuniziert.

Das bedeutet, dass wir jetzt eine dokumentierte Debugger-Schnittstelle haben, die einen Drop-in-Ersatz von gdb ermöglichen würde , aber leider der Hauptkonkurrent von gdb nicht den reibungsarmen Weg eingeschlagen.

Trotzdem ist es zumindest möglich dass einige zukünftige gdb Der Ersatz würde einfach durch Klonen seiner Befehlszeilenschnittstelle transparent eingefügt. Um dasselbe auf einer Windows-Box zu erreichen, hätten die Entwickler des austauschbaren Tools eine Art formelles Plugin oder eine Automatisierungs-API definieren müssen. Das bedeutet, dass es außer bei den beliebtesten Programmen nicht vorkommt, da es eine Menge Arbeit ist, sowohl eine normale Befehlszeilen-Benutzeroberfläche als auch eine vollständige Programmier-API zu erstellen.

Diese Magie geschieht durch die Anmut der allgegenwärtigen textbasierten IPC.

Obwohl der Windows-Kernel über anonyme Pipes im Unix-Stil verfügt, ist es selten, dass normale Benutzerprogramme sie für IPC außerhalb einer Befehlsshell verwenden, da Windows diese Tradition vermisst, alle Kerndienste zuerst in einer Befehlszeilenversion zu erstellen und dann die GUI darauf aufzubauen oben drauf separat. Dies führt dazu, dass einige Dinge ohne die GUI nicht möglich sind, was einer der Gründe dafür ist, dass es im Vergleich zu Linux so viele Remote-Desktop-Systeme für Windows gibt:Windows ist ohne die GUI sehr schwer zu bedienen.

Im Gegensatz dazu ist es üblich, Unix-, BSD-, OS X- und Linux-Boxen über SSH fernzusteuern. Und wie geht das, fragen Sie? SSH verbindet einen Netzwerk-Socket (der dateiähnlich ist) mit einem Pseudo-TTY unter /dev/pty* (was dateiartig ist). Jetzt ist Ihr entferntes System mit Ihrem lokalen über eine Verbindung verbunden, die so nahtlos zum Unix-Weg passt, dass Sie bei Bedarf Daten durch die SSH-Verbindung leiten können.

Bekommst du jetzt eine Vorstellung davon, wie mächtig dieses Konzept ist?

Ein geleiteter Textstrom ist aus der Perspektive eines Programms nicht von einer Datei zu unterscheiden, außer dass er unidirektional ist. Ein Programm liest aus einer Pipe genauso, wie es aus einer Datei liest:über einen Dateideskriptor. FDs sind absolut Kern von Unix; die Tatsache, dass Dateien und Pipes auf beiden dieselbe Abstraktion für I/O verwenden, sollte Ihnen etwas sagen.⁹

Die Windows-Welt, der diese Tradition der einfachen Textkommunikation fehlt, begnügt sich mit schwergewichtigen OOP-Schnittstellen über COM oder .NET. Wenn Sie ein solches Programm automatisieren müssen, müssen Sie auch ein COM- oder .NET-Programm schreiben. Das ist um einiges schwieriger als das Einrichten einer Pipe auf einer Unix-Box.

Windows-Programme, denen diese komplizierten Programmier-APIs fehlen, können nur über verarmte Schnittstellen wie die Zwischenablage oder Datei/Speichern gefolgt von Datei/Öffnen kommunizieren.

Lange Antwort, Teil 3:Die Registrierung vs. Konfigurationsdateien

Der praktische Unterschied zwischen der Windows-Registrierung und der Unix-Art der Systemkonfiguration veranschaulicht auch die Vorteile der „Alles ist eine Datei“-Philosophie.

Auf Unix-Systemen kann ich mir die Systemkonfigurationsinformationen von der Befehlszeile aus ansehen, indem ich einfach die Dateien untersuche. Ich kann das Systemverhalten ändern, indem ich dieselben Dateien ändere. Größtenteils sind diese Konfigurationsdateien nur einfache Textdateien, was bedeutet, dass ich jedes Tool unter Unix verwenden kann, um sie zu manipulieren, das mit einfachen Textdateien arbeiten kann.

Das Erstellen von Skripten für die Registrierung ist unter Windows nicht annähernd so einfach.

Die einfachste Methode besteht darin, Ihre Änderungen über die Registrierungseditor-GUI auf einem Computer vorzunehmen und diese Änderungen dann mit regedit blind auf andere Computer anzuwenden über *.reg Dateien. Das ist nicht wirklich „Scripting“, da es Ihnen nichts Bedingtes tun lässt:Es geht um alles oder nichts.

Wenn Ihre Registrierungsänderungen ein gewisses Maß an Logik erfordern, besteht die nächsteinfachste Option darin, PowerShell zu lernen, was im Grunde dem Erlernen der .NET-Systemprogrammierung gleichkommt. Es wäre, als ob Unix nur Perl hätte und Sie alles ad hoc erledigen müssten Systemverwaltung durch sie. Nun, ich bin ein Perl-Fan, aber nicht jeder ist es. Mit Unix können Sie jedes beliebige Tool verwenden, solange es reine Textdateien bearbeiten kann.

Fußnoten:

1. Plan 9 hat diesen Entwurfsfehler behoben und Netzwerk-I/O über /net offengelegt virtuelles Dateisystem.

Bash hat eine Funktion namens /dev/tcp die Netzwerk-I/O über reguläre Dateisystemfunktionen ermöglicht. Da es sich um eine Bash-Funktion handelt, eher um eine Kernel-Funktion, ist sie außerhalb von Bash oder auf Systemen, die Bash überhaupt nicht verwenden, nicht sichtbar. Dies zeigt als Gegenbeispiel, warum es so eine gute Idee ist, alle Datenressourcen über das Dateisystem sichtbar zu machen.

2. Mit „modernem Windows“ meine ich Windows NT und alle seine direkten Nachkommen, einschließlich Windows 2000, alle Versionen von Windows Server und alle Desktop-orientierten Versionen von Windows ab XP. Ich verwende den Begriff, um die DOS-basierten Versionen von Windows auszuschließen, nämlich Windows 95 und seine direkten Nachkommen, Windows 98 und Windows ME, sowie ihre 16-Bit-Vorgänger.

Sie können den Unterschied am Fehlen eines einheitlichen E/A-Systems in diesen letzteren Betriebssystemen erkennen. Sie können keinen TCP/IP-Socket an ReadFile() übergeben unter Windows 95; Sie können Sockets nur an die Windows Sockets-APIs übergeben. Weitere Informationen zu diesem Thema finden Sie in Andrew Schulmans wegweisendem Artikel Windows 95:What It’s Not.

3. Machen Sie keinen Fehler, /dev/null ist ein echtes Kernel-Gerät auf Unix-Typ-Systemen, nicht nur ein Dateiname mit Sonderfällen, wie es das oberflächlich gleichwertige NUL ist unter Windows.

Obwohl Windows versucht, Sie daran zu hindern, einen NUL zu erstellen Datei, ist es möglich, diesen Schutz mit bloßem Trick zu umgehen, indem die Windows-Logik zum Analysieren von Dateinamen getäuscht wird. Wenn Sie versuchen, mit cmd.exe auf diese Datei zuzugreifen oder Explorer, Windows weigert sich, es zu öffnen, aber Sie können über Cygwin darauf schreiben, da es Dateien mit ähnlichen Methoden wie das Beispielprogramm öffnet, und Sie können es mit ähnlichen Tricks löschen.

Im Gegensatz dazu lässt Unix Sie gerne rm /dev/null , solange Sie Schreibzugriff auf /dev haben , und Sie können an ihrer Stelle eine neue Datei neu erstellen, alles ohne Tricks, da dieser dev-Knoten nur eine weitere Datei ist. Während dieser Dev-Knoten fehlt, existiert das Null-Gerät des Kernels immer noch; Es ist nur unzugänglich, bis Sie den dev-Knoten über mknod neu erstellen .

Sie können sogar an anderer Stelle zusätzliche Null-Geräte-Entwicklungsknoten erstellen:Es spielt keine Rolle, ob Sie sie /home/grandma/Recycle Bin nennen , solange es sich um einen dev-Knoten für das Nullgerät handelt, funktioniert es genauso wie /dev/null .

4. Eigentlich sind es zwei High-Level-APIs zum „Festplattenformatieren“ in Windows:SHFormatDrive() und Win32_Volume.Format() .

Es gibt zwei für ein sehr … na ja … Windows Art Grund. Das erste fordert den Windows Explorer auf, sein normales Dialogfeld „Datenträger formatieren“ anzuzeigen, was bedeutet, dass es auf jeder modernen Version von Windows funktioniert, aber nur, während ein Benutzer interaktiv angemeldet ist. Das andere können Sie im Hintergrund ohne Benutzereingabe aufrufen. aber es wurde bis Windows Server 2003 nicht zu Windows hinzugefügt. Richtig, das Kernverhalten des Betriebssystems war bis 2003 hinter einer GUI verborgen, in einer Welt, in der Unix mkfs auslieferte ab Tag 1.

Meine Kopie von Unix V5 von 1974 enthält /etc/mkfs , eine ausführbare 4136-Byte-PDP-11-Datei mit statischer Verknüpfung. (Unix hat bis Ende der 1980er Jahre keine dynamische Verknüpfung erhalten, also ist es nicht so, als gäbe es irgendwo anders eine große Bibliothek, die die ganze eigentliche Arbeit erledigt.) Sein Quellcode – im V5-Systemabbild als /usr/source/s2/mkfs.c — ist ein vollständig eigenständiges C-Programm mit 457 Zeilen. Es gibt nicht einmal #include Aussagen!

Das bedeutet, dass Sie nicht nur untersuchen können, was mkfs ist auf hohem Niveau tut, können Sie damit experimentieren, indem Sie dasselbe Tool-Set verwenden, mit dem Unix erstellt wurde, genau wie Sie Ken Thompson vor vier Jahrzehnten sind. Versuchen Sie das mit Windows. Am nächsten kommen Sie heute, wenn Sie den DOS-Quellcode herunterladen, der erstmals 2014 veröffentlicht wurde , die Sie finden, entspricht nur einem Haufen Montagequellen. Es wird nur mit veralteten Tools erstellt, die Sie wahrscheinlich nicht zur Hand haben werden, und am Ende erhalten Sie Ihre ganz eigene Kopie von DOS 2.0, einem Betriebssystem, das weit weniger leistungsfähig ist als Unix V5 von 1974, obwohl es fast ein Jahrzehnt später veröffentlicht wurde.

(Warum über Unix V5 sprechen? Weil es das früheste noch verfügbare vollständige Unix-System ist. Frühere Versionen sind anscheinend mit der Zeit verloren gegangen. Es gab ein Projekt, das ein Unix der V1/V2-Ära zusammensetzte, aber es scheint mkfs , trotz der Existenz der oben verlinkten V1-Handbuchseite, die beweist, dass sie irgendwann irgendwo existiert haben muss. Entweder konnten diejenigen, die dieses Projekt zusammengestellt haben, keine vorhandene Kopie von mkfs finden einzubeziehen, oder ich bin schlecht darin, Dateien ohne find(1) zu finden , die es in diesem System ebenfalls nicht gibt. :) )

Jetzt denken Sie vielleicht:„Kann ich nicht einfach format.com anrufen? ? Ist das unter Windows nicht dasselbe wie der Aufruf von mkfs unter Unix?“ Leider nein, es ist aus einer Reihe von Gründen nicht dasselbe:

- First, `format.com` wasn't designed to be scripted. It prompts you to "press ENTER when ready", which means you need to send an Enter key to its input, or it'll just hang.

- Then, if you want anything more than a success/failure status code, you have to open its standard output for reading, which is [far more complicated on Windows than it has to be](http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499%28v=vs.85%29.aspx). (On Unix, everything in that linked article can be accomplished with a simple [`popen(3)`](http://linux.die.net/man/3/popen) call.)

- Having gone through all this complication, the output of `format.com` is harder to parse for computer programs than the output of `mkfs`, being intended primarily for human consumption.

- If you trace what `format.com` does, you find that it does a bunch of complicated calls to [`DeviceIoControl()`](http://msdn.microsoft.com/en-us/library/windows/desktop/aa363216%28v=vs.85%29.aspx), `ufat.dll`, and such. It is not simply opening a device file and writing a new filesystem onto that device. This is the sort of design you get from [a company that employs 126000 people](https://news.microsoft.com/facts-about-microsoft/#EmploymentInfo), and needs to *keep* employing them.

5. Wenn ich über Loop-Geräte spreche, spreche ich nur von Linux und nicht von Unix im Allgemeinen, da Loop-Geräte nicht zwischen Unix-Systemen portierbar sind. Es gibt ähnliche Mechanismen in OS X, BSD usw., aber die Syntax variiert etwas.

6. Damals, als Festplatten die Größe von Waschmaschinen hatten und mehr kosteten als das Luxusauto des Abteilungsleiters, teilten sich große Computerlabors im Vergleich zu modernen Computerumgebungen einen größeren Anteil ihres gemeinsamen Festplattenspeichers. Die Möglichkeit, eine entfernte Festplatte transparent in das lokale Dateisystem einzufügen, machte solche verteilten Systeme viel einfacher zu verwenden. Hier erhalten wir /usr/share , zum Beispiel.

Im Gegensatz zu Windows, wo eine Remote-Festplatte normalerweise entweder einem Laufwerksbuchstaben zugeordnet ist oder über einen UNC-Pfad zugegriffen werden muss, anstatt transparent in das lokale Dateisystem integriert zu werden. Laufwerksbuchstaben bieten Ihnen nur wenige Möglichkeiten für den symbolischen Ausdruck; macht P: Verweisen Sie auf den „öffentlichen“ Bereich auf BigServer oder auf das Verzeichnis „packages“ auf dem Software-Spiegelserver? UNC-Pfade bedeuten, dass Sie sich merken müssen, auf welchem ​​Server sich Ihre Remote-Dateien befinden, was in einer großen Organisation mit Hunderten oder Tausenden von Dateiservern schwierig wird.

Windows erhielt keine symbolischen Links bis Windows Vista, das 2007 veröffentlicht wurde und symbolische NTFS-Links einführte. Die symbolischen Links von Windows sind etwas leistungsfähiger als die symbolischen Links von Unix – eine Funktion von Unix seit 1977 –, da sie auch auf eine entfernte Dateifreigabe verweisen können, nicht nur auf einen lokalen Pfad. Unix hat das anders gemacht, über NFS im Jahr 1984, das auf der bereits vorhandenen Mount-Point-Funktion von Unix aufbaut, die es von Anfang an hatte.

Also, je nachdem, wie man es betrachtet, lag Windows ungefähr 2 oder 3 Jahrzehnte hinter Unix zurück.

Selbst dann sind symbolische Links aus mehreren Gründen kein normaler Bestandteil der Erfahrung eines Windows-Benutzers.

Erstens können Sie sie nur mit dem Rückwärts-Befehlszeilenprogramm MKLINK erstellen . Sie können sie nicht im Windows Explorer erstellen, während die Unix-Äquivalente zum Windows Explorer dies normalerweise tun lassen Sie Symlinks erstellen.

Zweitens hindert die standardmäßige Windows-Konfiguration normale Benutzer daran, symbolische Links zu erstellen, was erfordert, dass Sie entweder die Befehlsshell als Administrator ausführen oder dem Benutzer die Erlaubnis geben, sie über einen obskuren Pfad in einem Tool zu erstellen, das Ihr durchschnittlicher Benutzer noch nie gesehen hat, geschweige denn weiß wie benutzt man. (Und im Gegensatz zu den meisten Problemen mit Administratorrechten in Windows hilft UAC in diesem Fall nicht.)

7. Linux-Boxen verwenden nicht immer ein virtuelles Festplatten-Image in der Startsequenz. Es gibt verschiedene Möglichkeiten, dies zu tun.

8. man ed

9. Netzwerk-Socket-Deskriptoren sind übrigens auch FDs darunter.