Bonjour, 

Je voudrais savoir s'il est possible de lire un fichier sans la bibliothèque standard du C/C++ et sans autres bibliothèques. Merci.

Salut,

Donc sans C ou C++.

Oui c'est possible, avec ton shell ou autre.

Mais bon, si tu ne veux pas coder, dit le tous de suite :')

Je reformule, comment dans la bibliothèque standard C/C++ sont écrites les fonctions relatives à l'ouverture / écriture de fichiers ?

En utilisant les bibliothèques système.

Techniquement c'est possible dans la bibliothèque standard... Avec l'API système comme open(2) sous UNIX/Linux et OpenFile sur Windows.

Oui mais une bibliothèque.

Au bout d'un moment, autant utiliser ce qui est disponible.

Oui, re-inventer la roue est pratique pour apprendre un concept, mais il faut voir si les abstractions ne permettent justement pas de comprendre ce concept sans toute la theorie.

Ici, l'ouverture de fichier est quelque chose d'assez classique et banal, il n'y a pas enormement d'interet de creuser le fonctionnement interne, sauf pour des cas specifique comme la creation d'un formatage.

C'est à titre purement informatif. Comment peut on alors écrire sur le disque dur, en supposant qu'on connaît son model etc, comme si l'on voulait faire un petit OS ? Est-ce qu'on est obligé de passer par de l'assembleur ? Merci de vos réponses

C'est fonction de l'architecture hardware et logiciel du bidule.

Illustration avec Windows sur Architecture x86 :

Au démarrage, le boot loader utilise les fonctions du BIOS (stocké dans la "ROM" de la carte mère).

Le boot loader charge le Kernel qui charge lui-même les drivers des périphériques.

Un programme "User" utilise des bibliothèques, qui utilisent elles-même d'autres bibliothèques dont certaines sont celles de la partie User de l'OS.

Les bibliothèques systèmes utilisent d'autres bibliothèques systèmes, ainsi que des "appels systèmes" (passerelle entre la partie User et la partie Kernel de l'OS).

Le Kernel utilise les drivers Kernel (qui sont en "stack") pour faire le job.

L'assembleur n'est pas totalement indispensable mais les connaissances à avoir au niveau hardware sont telles que l'apprentissage d'un assembleur, c'est vraiment peanuts par rapport au travail à effectuer.

Si tu en es à savoir s'il faut apprendre un assembleur pour faire un OS qui ressemble à quelque chose, abandonnes tout de suite car c'est une tâche qui ce compte en années de développement pour une équipe de centaines de spécialistes.

Mais du coup les "logiciels" les plus proches de l'hardware, qui ne passent par aucun autre intermédiaire, ne peuvent pas être écrit en C/C++ non ? Je veux dire par là que parmi les bibliothèques utilisées, il y en a bien une qui au bout d'un moment n'utilise pas de bibliothèque, donc est-ce qu'elle peut communiquer avec l'hardware ou est-ce qu'on passe à un langage plus bas niveau ? 

Tu peux tout écrire en C. Linux est écrit en C par exemple.

Par contre, il faut faire de la programmation d'OS pour ce que tu veux.

Car sous un Windows ou un Linux, l'accès au disque ne se fait que par des requêtes à l'OS : l'OS t'interdira de faire autrement (et heureusement), c'est lui qui va gérer tout ce qui est bas niveau, il va être l'intermédiaire dont tu ne pourras pas te passer.

Donc pour faire autrement, il faut écrire son propre OS.

Je vais me renseigner sur la programmation des BIOS. Merci pour vos réponses

Mais c'est quoi ton objectif ?

On ne crée par un BIOS sur un coin de table.

Et franchement, le langage utilisé c'est vraiment très très accessoire.

A la limite, on se sert même pas d'un compilateur.

Mon objectif c'est juste d'apprendre un peu plus

Alors, si c'est apprendre "un peu plus", choisis un autre sujet d'apprentissage.

Avant, au début de l'ère des disques durs, on les contrôlait directement : on pilotait la tête sur un secteur manuellement, et quand on avait fini, il fallait penser à la remettre vers le moyeu, en gros on faisait tout à la main.

Il y a eu des disques abîmés voir foutus dans les cas ou l'alimentation a été coupée et la tête a atterri n'importe ou, voir est allée se cracher sur le moyeu ou sur les parois en cas d'envoi sur un secteur qui n'existe pas... Un débordement et paf !

Donc déjà, rapidement, il y a eu des contrôleurs sur les disques, autrement dit fini l'adressage manuel, une requête au disque dur et il se démerde. Qui plus est les disques durs se sont complexifié : il y a une cache dessus, il y a des algos d'optimisation de trajectoire des têtes si on doit donner plusieurs fichiers en même temps, et surtout, les disques contiennent plusieurs plateaux, plusieurs têtes et pour optimiser la vitesse, on preferea écrire un bout de chaque fichier sur tous les plateaux, plutôt que de les laisser sur un seul plateau.

On fera de la fragmentation. Avant même le système de fichiers NTFS ou FAT32, il y a déjà beaucoup d'optimisations opaques que chaque constructeur met en place pour de meilleures performances.

Leur seule contrainte est de répondre aux requêtes sur les fichiers. pour le reste on n'a pas de contrôle dessus.

Merci beaucoup Fvirtman pour tes explications !