Hello! J'ai une question, pourquoi Windows utilise pleins de petits fichiers au démarrage, car c'est la, la source de ralentissement, car on sait bien que les disques durs, même SDD n'aiment pas le transfère de petit fichier...
Donc pourquoi pas créer un/quelques gros fichier(s) ou moins de fichiers mais qui rassemble plusieurs fichiers ensemble?
Je suis moi même un petit dev, je pense savoir pourquoi on le fait pas, car ça serait un gros bordel pour y trouver ce qu'on veut...
Mais je suis sûr qu'il y a une solution pour que dans le gros fichier, on s'y retrouve plus facilement pour développer tranquillement.
Vous n'y avez pas réfléchi? (Je m'adresse peut être surtout au dev).
 
J'espère que vous aviez compris ce que je voulais dire ^^
 
Bonne soirée!

Donc plein d'accès à de petits fichiers, ou plein d'accès à un gros fichier contenant les mêmes données concaténées.

Ca finira pareil.

J'étais dev à l'époque du Z80 et du 68000, mais ce qui valait en terme de logique reste valide même avec des systèmes obèses en terme de Ghz et de To.

PS: ce n'est pas un problème hardware

quelque part, n'est ce pas le role de la base de registre ? une base de donnée structuré pour contenir les données de tout les programmes, pour remplacer tout les fichiers .ini, voir même tout les fichiers qu'on stockerait dans un "/etc"

Le mec qui a conçu la base de registre, devait être un geek des années 70 sous LSD et embauché par Microsoft pour Win95 :-)

Ensuite, il est difficile de mettre en // des OS dont l'esprit de base dans le fonctionnement est différent (du moins aux origines)

Avoir des fichiers de conf en texte, pour une gestion c'est chronophage, mais au moins si cela plante (l'appli) ce n'est pas tout le système qui plante
Idem pour un autre OS qui stockait dans "Devs" tout ce qui se rapportait à la config

D'un point de vue efficacité/stabilité, le rôle de ce qui se rapporte au registre devrait se cantonner à un rôle de couche basse (proche du matériel et du système)
et il ne devrait donc pas dépendre des couches hautes (softwares/drivers), car la contrepartie est une instabilité à plus ou moins long terme

Edit : Accessoirement, si je me souviens bien windows "traite" (lit et/ou écrit) environ 1200 fichiers au démarrage

Windows est censé fonctionner aussi bien sur des petites machines que des grosses machines , le fait de concaténer bouffe un plus sur le CPU et sur la RAM, je suppose fait pour un nivellement vers le bas et pour garder une certaine compatibilité avec les applications plus anciennes...
 
On utilise ce principe pour les jeux (comme avec Zlib pour GTA5 par exemple).
 
Il me semble aussi que le démarrage rapide de Windows 10 fonctionne sur le principe d'un "fichier image" qui regroupe donc plein de petit fichiers

la BDR est la clef de voute des GPO, donc Active Directory, donc aujourd'hui Azure.
je trouve que pour un gars sous LSD, il s'en ai pas mal tiré.

Du point de vue d'un Amigaiste, la BDR c'est une sorte d'enfer : sur Amiga (certes dérivé lointain d'UNIX), chaque application s'installait dans son répertoire, POINT. S'il y avait des bibliothèques partagées, on trouvait la référence dans "Libraries" ; et si le programme avait besoin de la version 4.56 de la library mais qu'on en était à la 5.0, pas grave, les fonctions de la library restaient compatibles (= on n'avait pas X versions de la même library avec référencement pour chaque programme "pour pas se tromper de version" comme avec Windows). Ou alors s'il y avait changement de paramètres, on avait les nouvelles fonctions, mais on gardait les anciennes pour les programmes anciens également etc.

Mais bon, on ne peut pas comparer un système de 1985 avec un Windows du XXIe siècle.

 
Pareil du point de vue d'un MAChiste (ou MAChiniste   ) (pas moi!)
et je parle de 2019!

mvouiiiiiiiii mais le Mac actuel n'est à mon sens ni plus ni moins qu'une surcouche graphique sur du Linux avec de l'Intel, du Nvidia et du SATA (je parle pas de l'heure glorieuse du Mac en Motorola 680x0, ou PowerPC ensuite, en SCSI etc)
 
   
 
mais nous digressons  

 
Je n'osais le dire :-) sans compter les autres OS de l'époque (QNX, BeOS, ...)
 
Tu avais aussi ce genre d'architecture sous QNX, OS véritablement multitâches avec un temps de réponse des interruptions de 0.55 µsec (sur un Pentium III)  ce qui était à comparer avec  Windows NT 4.0 et d'autres systèmes à temps partagé,  dont le temps de réponse était de 10 ms environ
 
Avec un boot sur disquette 1.44Mo, on avait un OS "à la windows" (pour l'aspect graphique) et les outils de base
 
 
https://youtu.be/K_VlI6IBEJ0
 
Ensuite il y a eu le live CD nettement plus complet
 
 

 
Si si on peut :-)  si on imagine les différents OS de l'époque (et/ou architecture) et comment ils auraient évolué, si le marketing de Microsoft n'avait pas été aussi efficace :-)
 
Ce qui est amusant c'est de voir la jungle que c'était à l'époque.. Cela bouillonnait de tous les côtés. Un petit aperçu à travers le processeur, ce qui était  et ce qui aurait pu se passer (couvre les années 1981 à 1993)  http://www.gamopat.com/2016/11/fic [...] ative.html

Yep. Ma remarque était ironique/désabusée

Entièrement d'accord sans grande surprise.

L'amiga s'est retrouvé bloqué par l'impasse Motorola au niveau CPU (j'ai fini avec 68060 mais voilà quoi )

Quant aux tentatives actuelles de revival de L'amigaOS je dois dire que je n'ai pas suivi depuis des années.

Comme toujours ça n'est pas l'excellence du code qui joue mais le côté marketeux (Gates) ou gourou (Jobs) qui emporté la mise.

Mais veux pas pourrir le topic : y'a plein de fichiers parce que c'est comme ça