Version imprimable
Bonjour à tous, il me semble avoir lu que en mode protégé il fallait des drivers pour utiliser les périphériques alors qu'ils n'étaient pas nécessaires en mode réel : déjà est-ce que cela est vrai ? Ensuite est-ce que quelqu'un peut m'éclairer un petit peu s'il vous plaît
Bonjour et bienvenue,
En fait non : techniquement, les périphériques eux-mêmes vont être exploités de la même façon, au travers des ports I/O et/ou de zones de mémoire mappées dans le plan adressable.
Par contre, en mode réel, par définition, il n'y a aucune restriction d'accès à ces ports ou à ces zones. Rien ne peut empêcher un programme d'y accéder directement.
De plus, le seul système d'exploitation grand public et tous usages qui ait réellement exploité le mode réel sur PC est D.O.S. Ce système était par nature mono-utilisateur et mono-tâche. Cependant, il était très répandu et et il était naturel pour pratiquement tout le monde de travailler avec, comme aujourd'hui le gens le font sous Windows (Linux ou *BSD pour les initiés). Si bien qu'il était tout-à-fait sûr de manipuler directement les ressources de son PC, qui étaient d'ailleurs relativement limitées dans les premiers temps. Par exemple, on pouvait facilement inhiber les interruptions IRQ lorsque le temps d'exécution était un facteur critique. Tout cela pour dire, donc, qu'on pouvait à la fois directement accéder aux ports I/O du matériel et le faire sans risquer d'interférer avec le système ou les autres programmes.
Évidemment, le système proposait quand même des pilotes et des points d'entrée officiels pour commander les principaux périphériques surtout quand ils étaient installés en standard dans un PC, comme un port parallèle ou un port série. Seulement, ceux-là mêmes étaient tellement rudimentaires qu'il était souvent plus simple — et également beaucoup plus amusant — pour le programmeur d'y accéder directement plutôt qu'utiliser une routine sur laquelle il n'avait aucun contrôle, qui n'était pas spécialement optimisée, et qui introduisait une dépendance dans son programme.
Avec l'arrivée du mode protégé et, concomitamment, des systèmes d'exploitation s'appuyant dessus, par définition, ton programme ne peut plus écrire en dehors de la zone mémoire qui lui a été allouée ni écrire directement dans les ports d'entrée/sortie. L'idée étant d'empêcher un programme malveillant ou défaillant d'aller mettre le souk dans le reste du système ainsi que gérer le partage de ressource entre les différents logiciels. Exemple, le clavier : tant que tu es tout seul, pas de problème. Par contre, dès lors que deux programmes sont à l'écoute, s'ils lisent simultanément le clavier, chacun d'eux risque de récupérer une touche sur deux ! C'est bien sûr totalement inacceptable. Il faut donc un système superviseur qui soit donc en charge de récupérer d'un côté tout ce qui provient du clavier et, de l'autre côté, de présenter tout cela sous une forme unifiée au système d'exploitation qui, lui, va les mettre à disposition de tous les programmes qui en feront la demande.
En résumé : c'est à la fois l'interdiction d'accès direct aux périphérique et la mise en place d'un système multitâche qui impose aujourd'hui aux logiciels de passer par de la programmation système, et donc des pilotes.
Par contre, il n'y a rien d'impossible techniquement. Linux, par exemple, permet aux programmes de demander le droit d'accès à certains port d'entrées-sorties, via les appels ioperm() et iopl(). Libre au système (et à son administrateur par l'entremise de la configuration qu'il lui applique) de refuser ces droits. Mais s'il les accorde, le programme en langage machine gagne à nouveau la possibilité d'aller exploiter lui-même ces ports. Après, au niveau de la gestion du micro-processeur, soit le système laisse une exception se déclencher à chaque fois, la rattrape et honore la commande, soit il fait passer le segment du processus dans un niveau de privilège où il est permis d'accéder aux ports.
Merci beaucoup pour cette réponse très claire ! (Et rapide !)
Ainsi qu'une bonne année 2013 à tous