Windows - Explication d'un profane pour "tout est un fichier" - qu'est-ce qui diffère de Windows ?

Je sais que "Tout est un fichier" signifie que même les périphériques ont leur nom de fichier et leur chemin dans les systèmes Unix et de type Unix, et que cela permet d'utiliser des outils communs sur une variété de ressources, quelle que soit leur nature. Mais je ne peux pas comparer cela à Windows, le seul autre système d'exploitation avec lequel j'ai travaillé. J'ai lu quelques articles sur le concept, mais je pense qu'ils sont quelque peu difficiles à comprendre pour les non-développeurs. L'explication d'un profane est ce dont les gens ont besoin !

Par exemple, lorsque je veux copier un fichier sur une carte CF qui est attachée à un lecteur de carte, j'utiliserai quelque chose comme

zcat name_of_file > /dev/sdb

Sous Windows, je pense que le lecteur de carte apparaîtra comme un pilote, et nous ferons quelque chose de similaire, je pense. Alors, comment la philosophie "Tout est un fichier" fait-elle une différence ici ?

Réponse acceptée :

"Tout est un fichier" est un peu désinvolte. "Tout apparaît quelque part dans le système de fichiers" est plus proche de la vérité, et même alors, c'est plus un idéal qu'une loi de conception de système.

Par exemple, les sockets de domaine Unix ne sont pas des fichiers, mais ils apparaissent dans le système de fichiers. Vous pouvez ls -l un socket de domaine pour afficher ses attributs, modifier son contrôle d'accès via chmod , et sur certains systèmes de type Unix (par exemple macOS mais pas Linux), vous pouvez même cat données vers/depuis un.

Mais, même si les sockets réseau TCP/IP ordinaires sont créés et manipulés avec les mêmes appels système de sockets BSD que les sockets de domaine Unix, les sockets TCP/IP ne le font pas apparaissent dans le système de fichiers,¹ même s'il n'y a pas de raison particulièrement valable pour que cela soit vrai.

Un autre exemple d'objets non-fichiers apparaissant dans le système de fichiers est le /proc de Linux système de fichiers. Cette fonctionnalité expose une grande quantité de détails sur le fonctionnement du noyau à l'espace utilisateur, principalement sous forme de fichiers texte virtuels. Beaucoup de /proc les entrées sont en lecture seule, mais beaucoup de /proc est également accessible en écriture, vous pouvez donc modifier la façon dont le système s'exécute à l'aide de n'importe quel programme capable de modifier un fichier. Hélas, là encore nous avons une non-idéalité :les Unix de type BSD tournent généralement sans /proc , et les Unix System V exposent beaucoup moins via /proc que Linux.

Je ne peux pas comparer cela à MS Windows

Tout d'abord, une grande partie du sentiment que vous pouvez trouver en ligne et dans les livres sur Unix étant tout au sujet des E/S de fichiers et Windows étant «cassé» à cet égard est obsolète. Windows NT a résolu beaucoup de problèmes.

Les versions modernes de Windows ont un système d'E/S unifié, tout comme Unix, vous pouvez donc lire les données réseau à partir d'un socket TCP/IP via ReadFile() plutôt que l'API spécifique à Windows Sockets WSARecv() , si tu veux. Ceci est exactement parallèle à Unix Way, où vous pouvez lire à partir d'un socket réseau avec soit le générique read(2) Appel système Unix ou recv(2) spécifique aux sockets appeler.²

Néanmoins, Windows ne parvient toujours pas à amener ce concept au même niveau qu'Unix, même ici en 2021. De nombreux domaines de l'architecture Windows ne sont pas accessibles via le système de fichiers ou ne peuvent pas être considérés comme des fichiers. Quelques exemples :

1. Chauffeurs.

Le sous-système de pilotes de Windows est facilement aussi riche et puissant que celui d'Unix, mais pour écrire des programmes pour manipuler les pilotes, vous devez généralement utiliser le kit de pilotes Windows, ce qui signifie écrire du code C ou .NET.

Sur les systèmes d'exploitation de type Unix, vous pouvez faire beaucoup de choses sur les pilotes à partir de la ligne de commande. Vous avez presque certainement déjà fait cela, ne serait-ce qu'en redirigeant la sortie indésirable vers /dev/null .³

2. Communication inter-programmes.

Les programmes Windows ne communiquent pas facilement entre eux.

Les programmes de ligne de commande Unix communiquent facilement via des flux de texte et des canaux. Les programmes GUI sont souvent construits au-dessus des programmes de ligne de commande ou exportent une interface de commande textuelle, de sorte que les mêmes mécanismes de communication simples basés sur du texte fonctionnent également avec les programmes GUI.

3. Le registre.

Unix n'a pas d'équivalent direct du registre Windows. Les mêmes informations sont dispersées dans le système de fichiers, la plupart dans /etc , /proc et /sys .

Si vous ne voyez pas que les pilotes, les canaux et la réponse d'Unix au registre Windows ont quelque chose à voir avec "tout est un fichier", lisez la suite.

En quoi la philosophie "Tout est un fichier" fait-elle une différence ici ?

Je vais expliquer cela en développant mes trois points ci-dessus, en détail.

Réponse longue, partie 1 :Disques et fichiers de périphérique

Supposons que votre lecteur de carte CF s'affiche sous la forme E: sous Windows et /dev/sdc sous Linux. Quelle différence pratique cela fait-il ?

Ce n'est pas seulement une différence de syntaxe mineure.

Sous Linux, je peux dire dd if=/dev/zero of=/dev/sdc pour écraser le contenu de /dev/sdc avec des zéros.

Réfléchissez à ce que cela signifie une seconde. Ici, j'ai un programme d'espace utilisateur normal (dd(1) ) que j'ai demandé de lire des données à partir d'un périphérique virtuel (/dev/zero ) et écrivez ce qu'il lit sur un périphérique physique réel (/dev/sdc ) via le système de fichiers Unix unifié. dd ne sait pas qu'il lit et écrit sur des appareils spéciaux. Cela fonctionnera aussi bien sur des fichiers normaux, ou sur une combinaison d'appareils et de fichiers, comme nous le verrons ci-dessous.

Il n'y a pas de moyen facile de mettre à zéro le E: lecteur sous Windows, car Windows fait une distinction entre les fichiers et les lecteurs, vous ne pouvez donc pas utiliser les mêmes commandes pour les manipuler. Le plus proche que vous pouvez obtenir est de faire un formatage de disque sans l'option de formatage rapide, qui met à zéro le plus du contenu du lecteur, mais écrit ensuite un nouveau système de fichiers par-dessus. Et si je ne veux pas un nouveau système de fichiers ? Et si je veux vraiment que le disque ne soit rempli que de zéros ?

Soyons généreux et disons que nous voulons vraiment un nouveau système de fichiers sur E: . Pour ce faire dans un programme sous Windows, je dois appeler une API de formatage spéciale.⁴ Sous Linux, vous n'avez pas besoin d'écrire un programme pour accéder à la fonctionnalité "formater le disque" du système d'exploitation. Il vous suffit d'exécuter le programme d'espace utilisateur approprié pour le type de système de fichiers que vous souhaitez créer :mkfs.ext4 , mkfs.xfs , ou ce que vous avez. Ces programmes écriront un système de fichiers sur n'importe quel fichier ou /dev nœud que vous passez.

Parce que mkfs les programmes de type sur les systèmes Unixy fonctionnent sur des fichiers sans faire de distinctions artificielles entre les périphériques et les fichiers normaux, cela signifie que je peux créer un système de fichiers ext4 à l'intérieur d'un fichier normal sur ma machine Linux :

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

Cela crée littéralement une image disque de 1 Mio dans le répertoire courant, appelée myfs . Je peux ensuite le monter comme s'il s'agissait de n'importe quel autre système de fichiers externe :

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

Maintenant, j'ai une image disque ext4 avec un fichier appelé my-passwd-entry dedans qui contient le /etc/passwd de mon utilisateur entrée.

Si je veux, je peux graver cette image sur ma carte CF :

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

Ou, je peux emballer cette image disque, vous l'envoyer par courrier et vous laisser l'écrire sur un support de votre choix, comme une clé USB :

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

Tout cela est possible sur Linux⁵ car il n'y a pas de distinction artificielle entre les fichiers, les systèmes de fichiers et les périphériques. Beaucoup de choses sur les systèmes Unix soit sont fichiers, ou sont accessibles via le système de fichiers afin qu'ils ressemblent fichiers, ou d'une autre manière ressemblent suffisamment à des fichiers pour pouvoir être traités comme tels.

Le concept de système de fichiers de Windows est un méli-mélo; il fait des distinctions entre les répertoires, les lecteurs et les ressources réseau. Il existe trois syntaxes différentes, toutes mélangées dans Windows :le ..FOOBAR de type Unix système de chemin, lettres de lecteur comme C: , et les chemins UNC tels que \SERVERPATHFILE.TXT . C'est parce qu'il s'agit d'une accumulation d'idées d'Unix, CP/M, MS-DOS et LAN Manager, plutôt qu'une seule conception cohérente. C'est pourquoi il y a tant de caractères illégaux dans les noms de fichiers Windows.

Unix a un système de fichiers unifié, avec tout accessible par un schéma commun unique. Pour un programme exécuté sur une machine Linux, il n'y a pas de différence fonctionnelle entre /etc/passwd , /media/CF_CARD/etc/passwd , et /mnt/server/etc/passwd . Les fichiers locaux, les supports externes et les partages réseau sont tous traités de la même manière.⁶

Windows peut atteindre des objectifs similaires à mon exemple d'image disque ci-dessus, mais vous devez utiliser des programmes spéciaux écrits par des programmeurs exceptionnellement talentueux. C'est pourquoi il existe tant de programmes de type « DVD virtuel » sous Windows. L'absence d'une fonctionnalité de base du système d'exploitation a créé un marché artificiel pour les programmes destinés à combler le vide, ce qui signifie que vous avez un groupe de personnes en compétition pour créer le meilleur programme de type DVD virtuel. Nous n'avons pas besoin de tels programmes sur les systèmes *ix, car nous pouvons simplement monter une image disque ISO à l'aide d'un périphérique en boucle.

En relation:Comment empêcher RealVNC de mettre à l'échelle l'affichage en fonction de l'option de mise à l'échelle de Windows ?

Il en va de même pour d'autres outils comme les programmes d'effacement de disque, dont nous n'avons pas non plus besoin sur les systèmes Unix. Vous voulez que le contenu de votre carte CF soit irrémédiablement brouillé au lieu d'être simplement mis à zéro ? OK, utilisez /dev/random comme source de données au lieu de /dev/zero :

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

Sous Linux, nous ne continuons pas à réinventer de telles roues, car non seulement les fonctionnalités de base du système d'exploitation fonctionnent assez bien, mais elles fonctionnent si bien qu'elles sont utilisées de manière omniprésente. Un schéma typique pour démarrer une machine Linux implique une image de disque virtuel, pour un seul exemple, créée à l'aide de techniques comme celles que je montre ci-dessus.⁷

Je pense qu'il est juste de souligner que si Unix avait intégré les E/S TCP/IP dans le système de fichiers depuis le début, nous n'aurions pas le netcat contre socat contre Ncat vs nc désordre, dont la cause était la même faiblesse de conception qui a conduit à la prolifération des outils d'imagerie et d'effacement de disque sous Windows :l'absence d'une installation de système d'exploitation acceptable.

Réponse longue, partie 2 :Pipes en tant que fichiers virtuels

Malgré ses racines dans DOS, Windows n'a jamais eu une riche tradition de ligne de commande.

Cela ne veut pas dire que Windows n'a pas une ligne de commande, ou qu'il manque de nombreux programmes en ligne de commande. Windows a même un shell de commande très puissant ces jours-ci, appelé à juste titre PowerShell.

Pourtant, il y a des répercussions sur ce manque de tradition de ligne de commande. Vous obtenez des outils comme DISKPART ce qui est presque inconnu dans le monde Windows, car la plupart des gens partitionnent les disques et autres via le composant logiciel enfichable Computer Management MMC. Ensuite, lorsque vous avez besoin de créer un script pour la création de partitions, vous constatez que DISKPART n'était pas vraiment fait pour être piloté par un autre programme. Oui, vous pouvez écrire une série de commandes dans un fichier de script et l'exécuter via DISKPART /S scriptfile , mais c'est tout ou rien. Ce que vous vraiment vouloir dans une telle situation ressemble plus à GNU parted , qui acceptera des commandes simples comme parted /dev/sdb mklabel gpt . Cela permet à votre script de gérer les erreurs étape par étape.

Qu'est-ce que tout cela a à voir avec « tout est un fichier » ? Facile :les tuyaux transforment les E/S du programme en ligne de commande en "fichiers", en quelque sorte. Les tubes sont des flux unidirectionnels, et non un accès aléatoire comme un fichier disque normal, mais dans de nombreux cas, la différence est sans conséquence. L'important est que vous puissiez joindre deux programmes développés indépendamment et les faire communiquer via un texte simple. En ce sens, deux programmes conçus avec la méthode Unix à l'esprit peuvent communiquer.

Dans les cas où vous avez vraiment besoin d'un fichier, il est facile de transformer la sortie du programme en fichier :

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

Mais pourquoi écrire la sortie dans un fichier temporaire alors que la philosophie « tout est un fichier » vous donne un meilleur moyen ? Si tout ce que vous voulez faire est de lire la sortie de cette commande dans un vi tampon de l'éditeur, vi peut le faire pour vous directement. Depuis le vi mode "normal", dites :

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

Cela insère la sortie de ce programme dans le tampon de l'éditeur actif à la position actuelle du curseur. Sous le capot, vi utilise des canaux pour connecter la sortie du programme à un morceau de code qui utilise les mêmes appels de système d'exploitation qu'il utiliserait pour lire à partir d'un fichier à la place. Je ne serais pas surpris si les deux cas de :r — c'est-à-dire avec et sans le ! - les deux utilisaient la même boucle de lecture de données générique dans toutes les implémentations courantes de vi . Je ne vois pas de bonne raison de ne pas le faire.

Ce n'est pas une fonctionnalité récente de vi , Soit; il remonte clairement à l'ancien ed(1) éditeur de texte.⁸

Cette idée puissante revient sans cesse sous Unix.

Pour un deuxième exemple de cela, rappelez-vous mon mutt commande par e-mail ci-dessus. La seule raison pour laquelle j'ai dû écrire cela en deux commandes distinctes est que je voulais que le fichier temporaire s'appelle *.gz , afin que la pièce jointe soit correctement nommée. Si je ne me souciais pas du nom du fichier, j'aurais pu utiliser la substitution de processus pour éviter de créer le fichier temporaire :

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

Cela évite le temporaire en transformant la sortie de gzip -c dans un FIFO (qui ressemble à un fichier) ou un /dev/fd objet (qui ressemble à un fichier). (Bash choisit la méthode en fonction des capacités du système, puisque /dev/fd n'est pas disponible partout.)

Pour encore une troisième façon cette idée puissante apparaît dans Unix, considérez gdb sur les systèmes Linux. C'est le débogueur utilisé pour tout logiciel écrit en C et C++. Les programmeurs venant d'autres systèmes sous Unix regardent gdb et presque invariablement se plaindre à ce sujet, "Beurk, c'est tellement primitif!" Ensuite, ils partent à la recherche d'un débogueur d'interface graphique, en trouvent un parmi plusieurs qui existent et continuent joyeusement leur travail… souvent sans se rendre compte que l'interface graphique exécute simplement gdb en dessous, offrant une jolie coquille sur le dessus. Il n'y a pas de débogueurs de bas niveau concurrents sur la plupart des systèmes Unix car il n'est pas nécessaire que les programmes soient en concurrence à ce niveau. Tout ce dont nous avons besoin est un bon outil de bas niveau sur lequel nous pouvons tous baser nos outils de haut niveau, si cet outil de bas niveau communique facilement via des tuyaux.

Cela signifie que nous avons maintenant une interface de débogage documentée qui permettrait le remplacement direct de gdb , mais malheureusement, le principal concurrent de gdb n'a pas emprunté la voie à faible friction.

Pourtant, c'est au moins possible que certains futurs gdb replacement tomberait de manière transparente simplement en clonant son interface de ligne de commande. Pour obtenir la même chose sur une boîte Windows, les créateurs de l'outil remplaçable auraient dû définir une sorte de plug-in formel ou d'API d'automatisation. Cela signifie que cela n'arrive pas, sauf pour les programmes les plus populaires, car il faut beaucoup de travail pour créer à la fois une interface utilisateur de ligne de commande normale et une API de programmation complète.

Cette magie opère grâce à la CIP textuelle omniprésente.

Bien que le noyau de Windows ait des canaux anonymes de style Unix, il est rare de voir des programmes utilisateur normaux les utiliser pour IPC en dehors d'un shell de commande, car Windows n'a pas cette tradition de créer d'abord tous les services de base dans une version en ligne de commande, puis de construire l'interface graphique sur dessus séparément. Cela conduit à ne pas pouvoir faire certaines choses sans l'interface graphique, ce qui est l'une des raisons pour lesquelles il existe tant de systèmes de bureau à distance pour Windows, par rapport à Linux :Windows est très difficile à utiliser sans l'interface graphique.

En revanche, il est courant d'administrer à distance des boîtiers Unix, BSD, OS X et Linux via SSH. Et comment ça marche, demandez-vous? SSH connecte un socket réseau (qui ressemble à un fichier) à un pseudo tty à /dev/pty* (qui ressemble à un fichier). Maintenant, votre système distant est connecté à votre système local via une connexion qui correspond si parfaitement à la méthode Unix que vous pouvez acheminer les données via la connexion SSH, si nécessaire.

Avez-vous une idée de la puissance de ce concept ?

Un flux de texte canalisé est indiscernable d'un fichier du point de vue d'un programme, sauf qu'il est unidirectionnel. Un programme lit à partir d'un tube de la même manière qu'il lit à partir d'un fichier :via un descripteur de fichier. Les FD sont absolument essentiels à Unix ; le fait que les fichiers et les canaux utilisent la même abstraction pour les E/S sur les deux devrait vous dire quelque chose.⁹

Le monde Windows, dépourvu de cette tradition de communications textuelles simples, se contente d'interfaces POO lourdes via COM ou .NET. Si vous avez besoin d'automatiser un tel programme, vous devez également écrire un programme COM ou .NET. C'est un peu plus difficile que de configurer un tube sur une machine Unix.

Les programmes Windows dépourvus de ces API de programmation compliquées ne peuvent communiquer que via des interfaces appauvries comme le presse-papiers ou Fichier/Enregistrer suivi de Fichier/Ouvrir.

Réponse longue, partie 3 :Le registre et les fichiers de configuration

La différence pratique entre le registre Windows et la méthode Unix de configuration du système illustre également les avantages de la philosophie « tout est un fichier ».

Connexes :Empêcher le point d'accès Wi-Fi de Windows 10 de s'éteindre automatiquement sur 1809 ?

Sur les systèmes de type Unix, je peux consulter les informations de configuration du système à partir de la ligne de commande simplement en examinant les fichiers. Je peux changer le comportement du système en modifiant ces mêmes fichiers. Pour la plupart, ces fichiers de configuration ne sont que des fichiers de texte brut, ce qui signifie que je peux utiliser n'importe quel outil sur Unix pour les manipuler qui peut fonctionner avec des fichiers de texte brut.

Scripter le registre n'est pas aussi simple sous Windows.

La méthode la plus simple consiste à apporter vos modifications via l'interface graphique de l'éditeur de registre sur une machine, puis à appliquer aveuglément ces modifications à d'autres machines avec regedit via *.reg des dossiers. Ce n'est pas vraiment du "script", puisqu'il ne vous laisse rien faire de manière conditionnelle :c'est tout ou rien.

Si vos modifications de registre nécessitent une certaine quantité de logique, la prochaine option la plus simple consiste à apprendre PowerShell, ce qui revient essentiellement à apprendre la programmation système .NET. Ce serait comme si Unix n'avait que Perl, et que vous deviez faire tout ad hoc l'administration du système à travers elle. Maintenant, je suis un fan de Perl, mais tout le monde ne l'est pas. Unix vous permet d'utiliser n'importe quel outil que vous aimez, tant qu'il peut manipuler des fichiers en texte brut.

Notes de bas de page :

1. Le plan 9 a corrigé cette erreur de conception, exposant les E/S réseau via /net système de fichiers virtuel.

Bash a une fonctionnalité appelée /dev/tcp qui permet les E/S réseau via les fonctions régulières du système de fichiers. Puisqu'il s'agit d'une fonctionnalité de Bash, plutôt d'une fonctionnalité du noyau, elle n'est pas visible en dehors de Bash ou sur des systèmes qui n'utilisent pas du tout Bash. Cela montre, par contre-exemple, pourquoi c'est une si bonne idée de rendre toutes les ressources de données visibles via le système de fichiers.

2. Par « Windows moderne », j'entends Windows NT et tous ses descendants directs, qui incluent Windows 2000, toutes les versions de Windows Server et toutes les versions de Windows orientées bureau à partir de XP. J'utilise le terme pour exclure les versions DOS de Windows, à savoir Windows 95 et ses descendants directs, Windows 98 et Windows ME, ainsi que leurs prédécesseurs 16 bits.

Vous pouvez voir la distinction par l'absence d'un système d'E/S unifié dans ces derniers systèmes d'exploitation. Vous ne pouvez pas passer un socket TCP/IP à ReadFile() sous Windows 95 ; vous ne pouvez transmettre des sockets qu'aux API Windows Sockets. Consultez l'article phare d'Andrew Schulman, Windows 95 :What It's Not, pour approfondir ce sujet.

3. Ne vous y trompez pas, /dev/null est un véritable périphérique du noyau sur les systèmes de type Unix, pas seulement un nom de fichier à casse spéciale, comme l'est le NUL superficiellement équivalent sous Windows.

Bien que Windows essaie de vous empêcher de créer un NUL fichier, il est possible de contourner cette protection avec une simple ruse, en trompant la logique d'analyse du nom de fichier de Windows. Si vous essayez d'accéder à ce fichier avec cmd.exe ou Explorer, Windows refusera de l'ouvrir, mais vous pouvez y écrire via Cygwin, car il ouvre les fichiers en utilisant des méthodes similaires au programme d'exemple, et vous pouvez le supprimer via une astuce similaire.

En revanche, Unix vous laissera volontiers rm /dev/null , tant que vous avez un accès en écriture à /dev , et vous permet de recréer un nouveau fichier à sa place, le tout sans artifice, car ce nœud de développement n'est qu'un autre fichier. Tant que ce nœud de développement est manquant, le périphérique nul du noyau existe toujours ; il est juste inaccessible jusqu'à ce que vous recréiez le nœud de développement via mknod .

Vous pouvez même créer des nœuds de développement de périphérique nuls supplémentaires ailleurs :peu importe si vous l'appelez /home/grandma/Recycle Bin , tant qu'il s'agit d'un nœud de développement pour le périphérique nul, il fonctionnera exactement de la même manière que /dev/null .

4. Il y en a en fait deux API de "formatage de disque" de haut niveau dans Windows :SHFormatDrive() et Win32_Volume.Format() .

Il y en a deux pour un très… eh bien… Windows sorte de raison. Le premier demande à l'Explorateur Windows d'afficher sa boîte de dialogue normale "Formater le disque", ce qui signifie qu'il fonctionne sur n'importe quelle version moderne de Windows, mais uniquement lorsqu'un utilisateur est connecté de manière interactive. L'autre que vous pouvez appeler en arrière-plan sans intervention de l'utilisateur, mais il n'a pas été ajouté à Windows avant Windows Server 2003. C'est vrai, le comportement du système d'exploitation principal était caché derrière une interface graphique jusqu'en 2003, dans un monde où Unix fournissait mkfs dès le premier jour.

Ma copie d'Unix V5 de 1974 inclut /etc/mkfs , un exécutable PDP-11 de 4136 octets lié statiquement. (Unix n'a pas obtenu de liaison dynamique avant la fin des années 1980, ce n'est donc pas comme s'il y avait une grande bibliothèque ailleurs qui faisait tout le vrai travail.) Son code source — inclus dans l'image système V5 sous la forme /usr/source/s2/mkfs.c — est un programme C de 457 lignes entièrement autonome. Il n'y a même pas de #include déclarations !

Cela signifie que vous pouvez non seulement examiner ce que mkfs fait à un niveau élevé, vous pouvez l'expérimenter en utilisant le même ensemble d'outils avec lequel Unix a été créé, tout comme vous êtes Ken Thompson, il y a quatre décennies. Essayez cela avec Windows. Le plus proche que vous puissiez trouver aujourd'hui est de télécharger le code source DOS, publié pour la première fois en 2014 , qui, selon vous, ne représente qu'une pile de sources d'assemblage. Il ne construira qu'avec des outils obsolètes que vous n'aurez probablement pas sous la main, et à la fin vous obtenez votre propre copie de DOS 2.0, un système d'exploitation beaucoup moins puissant que l'Unix V5 de 1974, malgré sa sortie près d'une décennie plus tard.

(Pourquoi parler d'Unix V5 ? Parce que c'est le premier système Unix complet encore disponible. Les versions antérieures sont apparemment perdues dans le temps. Il y avait un projet qui reconstituait un Unix de l'ère V1/V2, mais il semble qu'il manque mkfs , malgré l'existence de la page de manuel V1 liée ci-dessus prouvant qu'elle a dû exister quelque part, à un moment donné. Soit ceux qui ont mis en place ce projet n'ont pas pu trouver une copie existante de mkfs à inclure, ou je suis nul pour trouver des fichiers sans find(1) , qui n'existe pas non plus dans ce système. :) )

Maintenant, vous pensez peut-être :"Je ne peux pas simplement appeler format.com ? N'est-ce pas la même chose sous Windows que d'appeler mkfs sous Unix ? Hélas, non, ce n'est pas la même chose, pour un tas de raisons :

- 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. Lorsque je parle de périphériques en boucle, je ne parle que de Linux plutôt que d'Unix en général car les périphériques en boucle ne sont pas portables entre les systèmes de type Unix. Il existe des mécanismes similaires dans OS X, BSD, etc., mais la syntaxe varie quelque peu.

6. À l'époque où les disques durs avaient la taille d'une machine à laver et coûtaient plus cher que la voiture de luxe du chef de service, les grands laboratoires informatiques partageaient une plus grande proportion de leur espace disque collectif par rapport aux environnements informatiques modernes. La possibilité de greffer de manière transparente un disque distant dans le système de fichiers local a rendu ces systèmes distribués beaucoup plus faciles à utiliser. C'est là que nous obtenons /usr/share , par exemple.

Contrairement à Windows, où un disque distant est généralement mappé à une lettre de lecteur ou doit être accessible via un chemin UNC, plutôt qu'intégré de manière transparente dans le système de fichiers local. Les lettres de lecteur vous offrent peu de choix pour l'expression symbolique; fait P: faire référence à l'espace "public" sur BigServer, ou au répertoire "packages" sur le serveur miroir du logiciel ? Les chemins UNC signifient que vous devez vous rappeler sur quel serveur se trouvent vos fichiers distants, ce qui devient difficile dans une grande organisation avec des centaines ou des milliers de serveurs de fichiers.

Windows n'a pas obtenu de liens symboliques avant Windows Vista, sorti en 2007, qui a introduit les liens symboliques NTFS. Les liens symboliques de Windows sont un peu plus puissants que les liens symboliques d'Unix - une fonctionnalité d'Unix depuis 1977 - en ce sens qu'ils peuvent également pointer vers un partage de fichiers distant, pas seulement vers un chemin local. Unix a fait cela différemment, via NFS en 1984, qui s'appuie sur la fonctionnalité de point de montage préexistante d'Unix, qu'il possède depuis le début.

Connexe :un XML sans LF veut le rendre joli en utilisant la commande sed dans le shell ?

Ainsi, selon la façon dont vous le voyez, Windows a suivi Unix d'environ 2 ou 3 décennies.

Même dans ce cas, les liens symboliques ne font pas partie intégrante de l'expérience d'un utilisateur Windows, pour plusieurs raisons.

Tout d'abord, vous ne pouvez les créer qu'avec le programme de ligne de commande arrière MKLINK . Vous ne pouvez pas les créer à partir de l'Explorateur Windows, alors que les équivalents Unix de l'Explorateur Windows le font généralement vous permet de créer des liens symboliques.

Deuxièmement, la configuration Windows par défaut empêche les utilisateurs normaux de créer des liens symboliques, ce qui nécessite que vous exécutiez le shell de commande en tant qu'administrateur ou que vous donniez à l'utilisateur la permission de les créer via un chemin obscur dans un outil que votre utilisateur moyen n'a même jamais vu, et encore moins sait comment utiliser. (Et contrairement à la plupart des problèmes de privilèges d'administrateur sous Windows, l'UAC n'est d'aucune utilité dans ce cas.)

7. Les machines Linux n'utilisent pas toujours une image de disque virtuel dans la séquence de démarrage. Il existe de nombreuses façons de le faire.

8. man ed

9. Soit dit en passant, les descripteurs de socket réseau sont également des FD en dessous.