Évolution des systèmes de fichiers
Avant que les ordinateurs ne soient développés pour fonctionner sur des systèmes d’exploitation sur disque, chaque ordinateur était conçu pour exécuter une seule application propriétaire, qui avait le contrôle complet et exclusif de l’ensemble de la machine. L’application écrivait ses données persistantes directement sur un disque, ou un tambour, en envoyant des commandes directement au contrôleur de disque. L’application était responsable de la gestion des emplacements absolus des données sur le disque, en s’assurant qu’elle ne remplace pas les données déjà existantes. Étant donné qu’une seule application était en cours d’exécution sur l’ordinateur à tout moment, cette tâche n’était pas trop difficile.
L’avènement de systèmes informatiques capables d’exécuter plusieurs applications nécessitait un mécanisme pour s’assurer que les applications n’écrivaient pas sur les données des autres. Les développeurs d’applications ont résolu ce problème en adoptant une norme unique pour distinguer les secteurs de disque utilisés de ceux qui étaient libres en les marquant en conséquence. Avec le temps, ces normes se sont coalisées pour devenir un système d’exploitation sur disque, qui fournissait différents services aux applications, y compris un système de fichiers pour la gestion du stockage persistant. Avec l’avènement d’un système de fichiers, les applications n’ont plus à traiter directement avec le support de stockage physique. Au lieu de cela, ils ont simplement demandé au système de fichiers d’écrire des blocs de données sur le disque et de laisser le système de fichiers se soucier de la façon de procéder. En outre, le système de fichiers permettait aux applications de créer des hiérarchies de données via une abstraction appelée répertoire. Un répertoire peut contenir non seulement des fichiers, mais aussi d’autres répertoires, qui à leur tour peuvent contenir leurs propres fichiers et répertoires, et ainsi de suite.
Le système de fichiers fournissait un seul niveau d’indirection entre les applications et le disque, et le résultat était que chaque application voyait un fichier comme un seul flux contigu d’octets sur le disque, même si le système de fichiers stockait en fait le fichier dans des secteurs discontiguants. L’indirection a libéré les applications de l’obligation de suivre la position absolue des données sur un périphérique de stockage.
Aujourd’hui, pratiquement toutes les API système pour l’entrée et la sortie de fichier fournissent des applications permettant d’écrire des informations dans un fichier plat. Les applications voient ce fichier comme un seul flux d’octets qui peut augmenter autant que nécessaire jusqu’à ce que le disque soit plein. Pendant longtemps, ces API ont suffi aux applications pour stocker leurs informations persistantes. Les applications ont apporté d’importantes innovations dans la façon de traiter un seul flux d’informations pour fournir des fonctionnalités telles que des sauvegardes incrémentielles « rapides ».
Toutefois, dans un monde d’objets de composant, le stockage de données dans un seul fichier plat n’est plus efficace. Tout comme les systèmes de fichiers sont nés de la nécessité pour plusieurs applications de partager le même support de stockage, les objets de composant nécessitent maintenant un système qui leur permet de partager le stockage dans le cadre conceptuel d’un seul fichier. Même s’il est possible de stocker les objets distincts à l’aide du stockage de fichiers plats conventionnels, si l’un des objets augmente en taille ou si vous ajoutez simplement un autre objet, il devient nécessaire de charger le fichier entier en mémoire, d’insérer le nouvel objet, puis d’enregistrer le fichier entier. Ce processus peut prendre beaucoup de temps.
La solution fournie par COM consiste à implémenter un deuxième niveau d’indirection : un système de fichiers dans un fichier. Le stockage de fichiers plats nécessite qu’une grande séquence contiguë d’octets sur le disque soit manipulée via un handle de fichier unique avec un pointeur de recherche unique. En revanche, le stockage structuré COM définit comment traiter une entité de système de fichiers unique comme une collection structurée de deux types d’objets ( stockages et flux ) qui agissent comme des répertoires et des fichiers.