Windows 10, c'est un code source de plus de 0,5 To, plus d'un demi-million de dossiers et 4 millions de fichiers,
Il est essentiellement écrit en C

Le , par Bill Fassinou

126PARTAGES

14  0 
Le système d’exploitation (OS pour Operating System) est un ensemble d’applications (de logiciels) qui permettent d’utiliser les ressources physiques (le matériel) de l’ordinateur. Il permet également d’utiliser d’autres logiciels en correspondance avec l’usage que l’on fait de l’ordinateur. Il en existe plusieurs aujourd’hui comme Linux et ses multiples distributions, Chrome OS, Android, iOS, Mac OS et bien sûr le plus utilisé dans le monde, Windows. Cependant, si vous en utilisez un, vous êtes-vous déjà demandé comment il est construit ? Dans le cas de Windows 10, Axel Rietschin, ingénieur noyau chez Microsoft, a essayé de répondre à la question en apportant quelques explications sur ce que contient le système.

Si le langage de programmation le plus utilisé pour la programmation système reste encore le C, le système d’exploitation Windows 10 de Microsoft ne fait pas exception à la règle. D’après les explications de Rietschin, Windows 10 lui-même est écrit en grande partie avec le langage C et contient à quelques endroits du code C++ et C#, un langage de la firme. Cela s’explique par le fait que Windows suit la même base de code que ses prédécesseurs Windows 2000, XP, NT, Vista, 7 et Windows 8.x, où chaque génération a connu une refactorisation importante pour ajouter de nouvelles fonctionnalités, une performance améliorée, un support matériel et plus de sécurité tout en maintenant un très haut niveau de compatibilité ascendante, a-t-il notifié.


Ainsi, la grande majorité du noyau (ntoskrnl.exe) et la plupart de ce qui fonctionne en mode noyau c’est-à-dire les fichiers système, de réseau, de pilotes, etc., sont écrits avec le langage de programmation C avec d'infimes portions de code en C++. Néanmoins, au fur et à mesure que vous progressez dans la pile en mode utilisateur et en développements plus récents, vous trouverez un peu moins de C et un peu plus de C++. Il informe que vous pourrez retrouver des copies du code du noyau de Windows sur GitHub et constater par vous-même cet état de choses. Cependant, il ajoute que ce code est en grande partie incomplet, mais devrait fournir cependant des informations significatives sur ce qu’il sous-entend.

Pour information, le ntoskrnl.exe est une forme courte du noyau du système d'exploitation Windows NT (New Technology). C'est l'un des fichiers les plus importants qui permettent à l'utilisateur de démarrer le système d'exploitation à partir de son emplacement. C'est un fichier qui fournit le noyau et les couches exécutives aux Windows NT. En dehors de cela, le fichier est utilisé pour diverses tâches jugées importantes pour les utilisateurs. Cela comprend la virtualisation matérielle, la gestion des processus et de la mémoire et le gestionnaire de cache.

En effet, dit-il, ce n’est pas la chose la plus remarquable à souligner dans Windows 10. Il estime que ce que la plupart des gens ne remarquent pas, c’est la taille importante de Windows 10. « C’est un projet gigantesque aux proportions véritablement épiques », a-t-il affirmé. L’ingénieur de Microsoft nous informe que l'arborescence complète du code source (le code de test et tout ce qui constitue le code source Windows 10) a une taille de plus d'un demi-téraoctet. Pour aller plus loin, il explique que cela regroupe plus d’un demi-million de dossiers contenant le code de chaque composant, plus de 4 millions de fichiers, ainsi que des d’outils et des kits de développement associés.

Selon lui, il vous faudra environ un an pour explorer l'arborescence complète de tous les dossiers. Maintenant, dit-il, si vous voulez voir à l’intérieur des fichiers et essayer de comprendre quel fichier faire quoi, à ce stade, il vous faudra une vie entière pour y arriver. « Je pense qu'on peut affirmer qu'une seule personne ne peut pas lire tous les jours le code ajouté à Windows, et encore moins lire ce qui a été écrit au cours des trente dernières années ! », a-t-il déclaré dans son billet.

Ensuite, Axel Rietschin a essayé d'expliquer le rôle qu’a joué le langage de programmation C# dans toute cette architecture. D’après ses dires, la bibliothèque .NET BCL et les autres bibliothèques et frameworks gérés livrés dans la boîte sont généralement écrites en C#, mais elles ne représentent que de minuscules gouttes dans une mer géante de codes écrits en C avec quelques îles de codes écrits en C++. Ils proviennent également d’une autre division (DevDiv, la division du développeur) et leur code ne fait pas partie de l’arborescence source de Windows.

Enfin, selon lui, si vous regardez un « Live DVD » Windows 10 et que vous cherchez à savoir quels langages de programmation ont été utilisés pour créer tout ce qui se trouve sur ce disque, « je suppose que 98 % de ce contenu serait en C et C++, le C obtenant la part du lion », a-t-il conclu. Ainsi, l’on pourrait être amené à dire que tous les systèmes d’exploitation Windows sont construits avec des technologies identiques ou presque identiques. Le noyau est principalement écrit en C et les routines en C++ et en C# de haut niveau.

Source : Quora

Et vous ?

Qu'en pensez-vous ?

Voir aussi

Il n'y a rien de mieux que le langage de programmation C pour le développement de systèmes d'exploitation d'après Linus Torvalds

Windows 10 ne devrait jamais redémarrer votre PC sans votre permission, Microsoft devrait vous redonner le contrôle de votre appareil, selon une étude

Vous pouvez maintenant exécuter Windows 10 sur le Raspberry Pi 3, Grâce au programme d'installation WoA pour Microsoft

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de redcurve
Membre confirmé https://www.developpez.com
Le 15/04/2019 à 10:49
Citation Envoyé par esperanto Voir le message
Ce n'est hélas pas un gage de qualité: avec toutes ces lignes de code Windows 10 est incapable de fonctionner sans toute sa lourde interface graphique, non client-serveur (alors qu'un fonctionnement en ligne de commandes peut être justifié dans certains cas: ressources réduites, machine uniquement serveur...)
Et puis je suis sûr qu'il y a là dedans plein de choses qui n'ont rien à faire dans un OS, genre des bouts de feu Internet Explorer datant de l'époque où Microsoft voulait que tout soit dans l'OS

On pourrait le croire mais même pas: par exemple je ne compte plus le nombre d'écrans bleus trouvés sur des simples afficheurs dans les aéroports ou sur un distributeur bancaire par exemple.
Eh oui, bien qu'il ne soit pas du tout conçu pour l'embarqué, Windows trouve toujours le moyen de se glisser là où on ne l'attend pas...

Et pourtant on pourrait le faire, si au lieu de refaire le système entièrement on partait d'un linux personnalisé: ça économiserait tout ce qui fait vraiment partie de l'OS, à savoir le noyau et les parties les plus proches de la machine.
Les 3/4 du temps les machines type distributeur utilisent des softs moisie et je suis très loin de la vérité quand au drivers qui font tourner ça je préfère ne simple pas en parler. En lisant les messages d'erreurs tu te rendras compte qu'ils s'agit quasi exclusivement de plantage de pilote spécifiquement conçu par le fabricant des machines en question.

Concernant l'interface de Windows, il faut bien comprendre qu'il ne s'agit qu'un d'un sous système qui peut être désactivé, Windows tout entier n'est lui même qu'un sous système d'ailleurs. Il n'y strictement aucun restriction si tu veux fournir une interface en ligne de commande, toutes les apis pour cela existent et sont documentés by the way.

Concernant les bouts de truc qui traînent pour faire simple les 99% du temps le code en question n'existe simplement plus il s'agit de hook. Ceci explique pourquoi les applications GDI continuent de fonctionner alors que l'intégralité du code a été supprimé, pareil pour la partie réseau l'intégralité du code de la pile réseau historique a été supprimé y'a 10 ans, ou encore l'ensemble du système de pilote a été remplacé etc. Il faut bien comprendre que le sous système Windows ne possède pas de Gui, la Gui de ce que tu appel Windows est dans le sous système GUI...

Donc quand tu lances une appli graphique le sous système Windows va fournir les informations adéquat au sous système Gui qui affiche ce que tu vois à l'écran. De même, quand tu lances une application console dans le sous système Windows elle n'est pas exécutée par ce que tu appel Windows mais par le sous système Console etc.

Ceci explique pourquoi tu peux piloter n'importe quelle application graphique Windows en ligne de commande, ça sert pas à grand chose mais tu peux.

En fait, il ne reste plus grand chose du système historique. Le gros challenge dont on voit le bout du tunnel est la suppression totale de Win32, l'API principale est en cours de mise en boite (PAL comme WSL). Ce faisant à terme (dans le courant de l'année), Windows tel que tu te l'imagine aura simplement cessé d'exister.

On voit arriver ce qui est la suite logique de la refonte du système le fait de pouvoir faire tourner des applications Gui linux directement sans VM, ça marche bien.

Trucs supprimés y'a déjà 10 ans et remplacé:
- Pile réseau
=> Remplacé et coupé en deux

- Système graphique
=> Remplacé et déplacé
=> Suppression de GDI/GDI+ => Mise en place de hook
=> Remplacement du système de rendu 2D
=> Remplacement du rendu GDI par D3D
=> Extension du système de rendu 2D pour la du rendu du texte à l'écran

- Système console
=> Remplacé intégralement

- Système de pilote
=> Remplacé par UMDF/KMDF, un wrapper permet de l'utiliser avec COM même si lui ne l'utilise pas il s'agit juste un adapter. Le code de WDM n'existe plus à l'heure actuelle.
=> Déplacé en partie en user land

Ceci est une short list bien entendu.

De façon plus globale la quasi intégralité du système a été réécrit ... COM3 (aka .net framework) est entré en phase de maintenance longue. Je n'ai pas encore pu tester la build avec Win32 en boite, faut que je check ça la semaine prochaine.

D'ailleurs à la base l'intégralité du code de Windows faisait plus 1TO ceci comprenait bien entendu les sources, mais aussi les ressources images, son, trad, wmp etc. bref tout ce qui va dans la distribution pour grand publique. 50% de la distribution à juste disparu y'en a encore 15% qui a disparu avec W32.
7  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 18/04/2019 à 12:32
Citation Envoyé par esperanto Voir le message
Sauf que les programmes incorporés dans une distribution linux ne font pas partie du code source de la distribution, et sont maintenus par des équipes distinctes. Ces codes sont indépendants, interchangeables (tu peux prendre le source sur une Debian et le compiler sur une RedHat)
Certes, sur le CD tu trouveras les sources de chaque outil parce que c'est imposé par la GPL, mais si tu veux contribuer à l'un des projets, c'est le dépôt Git/Svn du dit projet et non celui de la distribution qui est concerné.
Si tu vas chercher les sources de la distribution elle-même, tu trouveras uniquement celles des programmes d'installation, qui eux sont spécifiques à chaque distribution.

Et pourtant, malgré ça, il reste une grande cohérence: par exemple tous les programmes écrits en C utiliseront la même libc, libm, et plein d'autres encore, là où sous Windows, on se retrouve le plus souvent avec des gros EXE où toutes les librairies sont statiques.
Ma remarque porte sur le fait d'avoir honte de cumuler des millions de lignes de code écrites en C depuis plus de 20 ans. Loin d'être une honte, c'est la fierté d'une équipe que de pouvoir pérenniser son travail et protéger l'investissement d'une société sur des décennies.

Après je comprends pas trop ta remarque. Chez MS aussi il y a tout un tas d'équipes qui sont chacune en charge de tout un tas de briques du projet - ça me parait évident non ? Le fait que ce soit centralisé dans un seul repo vs des centaines de repo, c'est juste de l'organisation, tu n'es pas obligé de tout récupérer et compiler en local pour modifier le code de notepad (voir la comunication de MS et Google sur comment et pourquoi ils centralisent tout dans un même repo) - ça me parait évident non ?

Et pour ta remarque sur les exe, c'est juste faux. S'il y a bien un OS qui offre un piètre portabilité binaire c'est bien Linux avec sa libc changeante justement (c'est pas pour rien que Docker est apparu sur cette plateforme). Et un OS ne peut pas fournir de libs statiques pour son API système. Tous les exe Win32 s'appuient sur de nombreuses dlls (kernel32, user32, etc...) dont les version modernes sont toujours compatibles avec des applis Win95 (25 ans!), et ces dlls sont partagées par toutes les applis du système, exactement comme ta libc. Et le fait d'utiliser la même libc ou crt dépend juste du fait d'utiliser le même compilo. Historiquement Windows fournissait aussi une "libc" (crt) au niveau système (msvcrt.dll) mais depuis pas mal de temps maintenant elle est traitée comme étant un composant non système parmi tant d'autres. Et à bien y réfléchir, on peut se demander si c'est une si bonne idée que ça d'avoir un couplage fort entre le runtime d'un compilateur donné dans une version donnée et l'API système d'un OS...

Citation Envoyé par chrtophe Voir le message
Tu te vois lire 500 Go de code source ? Je ne parle même pas de les comprendre, juste de les lire.
Remarque : 500Go ça inclut les artefacts et surtout le versionning, c'est à dire que c'est la taille complète du repo git. Il parle de 4 millions de fichiers (qui ne doivent pas tous être du source), à 10Ko en moyenne par fichier (sachant que le source est splitté en 2 : .h et .c), ça fait dans les 40 Go de "source". Fais un clone de WebKit ou Firefox avec leurs dépendances et regarde ce que ça donne... Et ce n'est pas juste le code de l'OS mais aussi celui des tests, SDK et outils.

Citation Envoyé par AoCannaille Voir le message
même en considérant un facteur 10 pour chacune des estimations que j'ai faites, on arrive dans tous les cas à de l’inatteignable pour un humain (en particulier ici, les temps sont exprimés sans compter les repas, le repos... Sinon à 8h/jour, il faut tout multiplier par 3!)...
Je comprends pas ces remarques qui pour moi n'ont rien à voir avec Windows. J'ai envie de répondre : bienvenue dans le monde des gros projets !

Quel intérêt à lire un code pour le lire sans chercher à le comprendre ? Quel est le besoin de lire tout le code source d'un système par une seule personne ? Surtout quand ce système est le résultat de décennies de travail par des centaines ou milliers de personnes ? Il le dit dans son article : en quelques semaines, il se retrouve avec 60.000 commits de retard sur sa branche locale.

Peut être que vous ne le réalisez pas, mais des projets qui entrent dans cette catégorie (trop complexe pour pouvoir suivre ce qui se fait), il y en a beaucoup ! Surtout en C/C++ où un projet d'un million de LOC c'est juste pas un gros projet. Un gros projet ce sont de nombreuses équipes qui peuvent être distribuées dans plusieurs centres dans le monde. Et où chaque jour il y a plus de lignes de code écrites que ce qu'une seule personne peut lire. Et Microsoft n'est pas la seule société à entrer dans cette catégorie loin de là! Quand Google annonce avoir plus de 250 millions de LOC rien que pour son code C++ qui repose en totalité dans un même repository centralisé, pourquoi ne commentez-vous pas comme quoi c'est une honte blablabla ?

Les gros projets, c'est un monde où on travaille en équipe : il n'y a pas de place pour quelqu'un qui a besoin de se sentir tout puissant au centre du système. Il faut accepter humblement que l'individu, même excellent, ne peut pas faire grand chose tout seul car il sera toujours débordé. Alors on apprend à penser et agir différemment que lorsqu'on est le développeur star d'un petit projet insignifiant. Loin d'être une honte, c'est selon moi une fierté que de parvenir à s'intégrer et travailler dans un tel environnement. En tous cas c'est ainsi que je lis l'article de ce développeur de MS : il réalise tout ça, qu'il n'est qu'un petit élément parmi bien d'autres, et il partage juste sa fascination devant une telle chose.
6  0 
Avatar de CaptainDangeax
Membre éclairé https://www.developpez.com
Le 14/04/2019 à 23:08
Windows 10 n'est pas l'OS le plus utilisé au monde. Ou alors il faut préciser "sur ordinateur de bureau". L'OS le plus utilisé au monde, c'est Androïd et de fait, le noyau le plus utilisé au monde c'est Linux, qu'il soit GNU ou Androïd d'ailleurs.
11  6 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 15/04/2019 à 12:00
Citation Envoyé par esperanto Voir le message
Ce n'est hélas pas un gage de qualité: avec toutes ces lignes de code Windows 10 est incapable de fonctionner sans toute sa lourde interface graphique, non client-serveur (alors qu'un fonctionnement en ligne de commandes peut être justifié dans certains cas: ressources réduites, machine uniquement serveur...)
Et puis je suis sûr qu'il y a là dedans plein de choses qui n'ont rien à faire dans un OS, genre des bouts de feu Internet Explorer datant de l'époque où Microsoft voulait que tout soit dans l'OS
Tu devrais jeter un oeil à la déclinaison Server Core qui existe depuis plus de 10 ans:
https://en.wikipedia.org/wiki/Server_Core

De même Azure exécute des versions très allégées de Windows Server (Nano Server...).
4  0 
Avatar de SimonDecoline
Membre expert https://www.developpez.com
Le 15/04/2019 à 21:47
Merci pour l'article. C'est vraiment excellent : le gars fait son beau parce qu'il bosse sur un projet de 500 Go de code en C débuté il y a 20 ans et que personne n'est capable de comprendre entièrement... Pour moi c'est juste 4 raisons d'en avoir honte... Par contre, il ne dit rien sur l'architecture de code (monolithique, micro-noyau, hybride...), les systèmes de test, les preuves d'algorithmes pour les sections sensibles, les stratégies d'ordonnancement, etc...
5  1 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 16/04/2019 à 12:25
Citation Envoyé par SimonDecoline Voir le message
Merci pour l'article. C'est vraiment excellent : le gars fait son beau parce qu'il bosse sur un projet de 500 Go de code en C débuté il y a 20 ans et que personne n'est capable de comprendre entièrement... Pour moi c'est juste 4 raisons d'en avoir honte... Par contre, il ne dit rien sur l'architecture de code (monolithique, micro-noyau, hybride...), les systèmes de test, les preuves d'algorithmes pour les sections sensibles, les stratégies d'ordonnancement, etc...
Ah bon, et où est la honte exactement ? parce qu'avec tes propos y'a beaucoup de projets prestigieux dont on peut avoir honte, en premier lieu n'importe quelle distrib Linux au complet (avec toute sa couche GNU/Gnome etc...): codé en C, démarré il y a plus de 20 ans, trop gros pour être compris entièrement par une seule personne, des Go de code source...
3  0 
Avatar de esperanto
Membre éprouvé https://www.developpez.com
Le 16/04/2019 à 13:20
Citation Envoyé par Aurelien.Regat-Barrel Voir le message
Ah bon, et où est la honte exactement ? parce qu'avec tes propos y'a beaucoup de projets prestigieux dont on peut avoir honte, en premier lieu n'importe quelle distrib Linux au complet (avec toute sa couche GNU/Gnome etc...): codé en C, démarré il y a plus de 20 ans, trop gros pour être compris entièrement par une seule personne, des Go de code source...
Sauf que les programmes incorporés dans une distribution linux ne font pas partie du code source de la distribution, et sont maintenus par des équipes distinctes. Ces codes sont indépendants, interchangeables (tu peux prendre le source sur une Debian et le compiler sur une RedHat)
Certes, sur le CD tu trouveras les sources de chaque outil parce que c'est imposé par la GPL, mais si tu veux contribuer à l'un des projets, c'est le dépôt Git/Svn du dit projet et non celui de la distribution qui est concerné.
Si tu vas chercher les sources de la distribution elle-même, tu trouveras uniquement celles des programmes d'installation, qui eux sont spécifiques à chaque distribution.

Et pourtant, malgré ça, il reste une grande cohérence: par exemple tous les programmes écrits en C utiliseront la même libc, libm, et plein d'autres encore, là où sous Windows, on se retrouve le plus souvent avec des gros EXE où toutes les librairies sont statiques.
3  0 
Avatar de 23JFK
Membre expérimenté https://www.developpez.com
Le 15/04/2019 à 6:57
Et nos politiques sont persuadés qu'avec une poignée de milliards donné à quelques développeurs, ils auront dans 6 mois leur propre OS et en plus bien supérieur à ceux qui existe déjà... Disons qu'en faisant l'économie des fichiers d'entêtes, ça fait encore près de deux millions de fichiers à rédiger.
1  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 15/04/2019 à 19:23
Les versions Core ne sont dispo que sur les versions server. Dans la 2008, installer le mode core était irréversible. Et toutes les applications ne fonctionnent pas en mode Core.

A partir de 2012, la GUI était une couche activable/désactivable.

Avec 2016, tu as la notion de nano server, qui n'installe ni console ni gui, tout ce pilote à distance. Et la logique doit probablement de faire tourner plusieurs Nano servers en conteneurs je suppose, j'ai pas testé.
1  0 
Avatar de goldbergg
Membre actif https://www.developpez.com
Le 16/04/2019 à 9:42
Citation Envoyé par esperanto Voir le message

On pourrait le croire mais même pas: par exemple je ne compte plus le nombre d'écrans bleus trouvés sur des simples afficheurs dans les aéroports ou sur un distributeur bancaire par exemple.
Eh oui, bien qu'il ne soit pas du tout conçu pour l'embarqué, Windows trouve toujours le moyen de se glisser là où on ne l'attend pas...
Windows Embeded EST conçue pour faire de l'embarqué, de même que le plus récent Windows 10 IoT Core.
Et pour avoir conçue mes propre FFU sur ce dernier je peut t'affirmer que c'est très bien pensé et que sa fonctionne très bien.

Si il y a des écran bleu, la faute n'en revient pas forcement a Windows, mais sa peut aussi venir de mauvais pilote et/ou d'une mauvaise conception de l'image.

La famille Windows est bien plus large que ce que tu semble t'imaginer.
1  0 
Responsable bénévole de la rubrique Windows : chrtophe -

Partenaire : Hébergement Web