Discussion :

[Bill Fassinou]

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 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

[CaptainDangeax]

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.

[23JFK]

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.

[esperanto]

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

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.

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 nos politiques sont persuadés qu'avec une poignée de milliards donné à quelques développeurs, ils auront dans 6 mos 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.

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.

[Jiji66]

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,

................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, ............ bla bla bla ....

...............Pour information, le ntoskrnl.exe est une forme courte du noyau du système d'exploitation Windows NT (nouvelle technologie pour désigner les systèmes d’exploitation de Windows XP à Windows 10)..................

Je retiens de tout ça que le "mammouth" n'est pas vraiment différent de ses prédécesseurs et que Microsoft sait bien vendre la même soupe en faisant croire que tout est nouveau.

[Aiekick]

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.

quand je lis ca je ne suis pas rassuré du tout... pour moi c'est aberrant

[redcurve]

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.

[Aurelien.Regat-Barrel]

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...).

[chrtophe]

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é.

[Invité]

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...

[goldbergg]

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.

[Aurelien.Regat-Barrel]

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...

[esperanto]

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.

[chrtophe]

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

Tu te vois lire 500 Go de code source ? Je ne parle même pas de les comprendre, juste de les lire.

[AoCannaille]

Tu te vois lire 500 Go de code source ? Je ne parle même pas de les comprendre, juste de les lire.

Juste quelques stats du coup:
Avec 4 millions de fichiers, en ouvrant tous les fichiers un par un pendant 1 seconde, on arrive à 46,3 jours.

EN considérant les 500Go comme "juste du texte" ( 1 Octet = 1char), façon roman on arrive à ce genre de données :

Un mot en français fait en moyenne 5 à 6 charactères en fonction du niveau de langue, mettons 5 pour simplifier, ça fait 100 Milliards de mots.
Un roman fait en moyenne 30k à 40k mots. Windows 10 fait donc ~2,9 Millions de Romans.
J'ai trouvé une vitesse de lecture entre 250 et 300 mots minutes. Soit environ 692 ans en lecture continue.

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!)...

[Aurelien.Regat-Barrel]

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...

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.

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.

[AoCannaille]

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 !

évidement, je mettais juste en évidence la taille du projet, juste pour se donner un peu le vertige. Mais ne soit ce n'est pas énorme. Je travaille actuellement sur un projet de cette envergure aussi et je me rend bien compte que sorti de mon composant précis de 1,2 Mloc, je comprend pas grand chose...
C'est d'ailleurs un gros problème dans la boite, chaque composant est énorme et interdépendant avec le reste du système (contrairement à notepad, calc etc. qui sont plus ou moins stand alone). Et très peu de personnes ont la vision complète du système et des interactions inter-composants. En général ce sont celles qui travaille sur le système depuis le début (20 ans) et le problème c'est que la majorité va pas tarder à partir à la retraite ^^'


Les gros projets, c'est très dur de rentrer dedans, mais c'est très gratifiant quand on commence à y apporter une vrai plue-value.

[Aurelien.Regat-Barrel]

C'est d'ailleurs un gros problème dans la boite [...] très peu de personnes ont la vision complète du système et des interactions inter-composants.

Tu mets le doigts sur la difficulté que tout le monde rencontre. Et ça va de paire avec la connaissance des fonctionnalités du produit quand il s'agit de vendre un logiciel tel que Photoshop par exemple : personne ne maîtrise l'ensemble des fonctionnalités disponibles...

Du coup j'ai une question pour toi (et ceux qui se sentent de participer) : selon toi, combien de lignes de code par an un développeur est en capacité d'assimiler ? Je veux dire par là, pour un projet d'1MLOC par exemple, il faudrait compter combien de temps avec combien de développeurs pour reprendre le contrôle total du projet où tout le monde est parti ?

[AoCannaille]

selon toi, combien de lignes de code par an un développeur est en capacité d'assimiler ? Je veux dire par là, pour un projet d'1MLOC par exemple, il faudrait compter combien de temps avec combien de développeurs pour reprendre le contrôle total du projet où tout le monde est parti ?

J'ai mis un peu moins d'un an pour être autonome sur ce composant , même si je n'en n'ai pas exploré tous les recoins et qu'on n'est jamais à l’abri d'une exception de design dans un coin.
Mais je suis souvent incapable de répondre à des questions techniques de tête sur telle ou telle partie du code, il faut toujours que je plonge dedans pour répondre pertinemment. Ce que n'ont pas besoin de faire des confrères qui sont là depuis plus longtemps.

Par contre, beaucoup de choses m'ont été expliquées ces confrères, évidement ce serait beaucoup plus long si je n'avais pas eu de formation continue et que j'aurais du me contenter des docs!

Mais ce composant a un bon design, avec une foultitude de comportement similaires. Quand je vois d'autres composants, ils ne sont pas aussi bien servis.

Je pense que la réponse dépend énormément de la qualité de conception voire même encore plus de son homogénéité. Avec une conception pourri mais identique partout dans le code, ça peut être plus rapide qu'avoir 30 patterns différents même s'ils sont chacun parfaitement adaptés à chaque situation...

[Invité]

Je pense que la réponse dépend énormément de la qualité de conception voire même encore plus de son homogénéité. Avec une conception pourri mais identique partout dans le code, ça peut être plus rapide qu'avoir 30 patterns différents même s'ils sont chacun parfaitement adaptés à chaque situation...

Et bien voilà, c'est exactement ce que je voulais dire dans mon message précédent : on nous balance des chiffres de façon superficielle en nous faisant croire que beaucoup = bien mais on n'a aucune vraie info technique intéressante. 500 Go de code C ? Whaou, trop fort ! MS a la plus grosse (base de code).
Bon perso, ce qui m'aurait impressionné ça aurait été que leur code se limite à 50 Mo de code F# écrit par 50 développeurs, mais bon...
Et sinon, vous vous rappelez de MULTICS, l'OS trop compliqué qui n'a jamais percé et a donné lieu à UNIX et son fameux principe KISS ?