Ashram de Swâmi Petaramesh

Je ne mets pas de timeline, je n'ai pas les dates précises en tête, mais en gros, voilà l'histoire du truc.

1981 : Naissance au monde de l'IBM PC. Quand je pense que nombre de mes lecteurs n'étaient sans doute pas nés !

1984 : C'est le temps qu'il a fallu à ce machin pour traverser l'Atlantique et arriver jusqu'à la SSII où je programme des ordinateurs sérieux pour gagner ma modeste croûte (des IBM 23, avec 64 Ko de RAM, sans déconner...). A l'époque, on regarde le PC en se moquant et en se demandant à quoi peut bien servir ce jouet.

Mais venons-en aux choses sérieuses. Le BIOS. Et ces choses qui ont fait des misères à Agnès.

Le BIOS de l'IBM PC est simple et non réglable. Il n'y a rien à régler par logiciel avant le démarrage de la machine. Les ressources matérielles utilisées par les (rares et chères) cartes d'extension, essentiellement adresse I/O et ligne IRQ, se règlent en positionnant des cavaliers sur chaque carte.

Le PC tourne sous MS-DOS de Microsoft, mais pourra par la suite tourner sous d'autres variantes de DOS, notamment l'excellent DR-DOS de Digital Research.

Apparaîssent le PC-XT (8088) et le PC-AT (80286) et, avec eux, les premiers disques durs en interface ST-506 si mes souvenirs sont bons. Pour pouvoir gérer le disque dur, le PC a besoin de connaître la géométrie du disque (nombre de têtes de lectures, de cylindres et de secteurs par cylindre). Le BIOS a besoin de connaître ces valeurs. Il devient réglable en bootant avec une disquette contenant un programme de diagnostic spécifique : le programme de setup. Les valeurs réglées pour le BIOS sont sauvegardées dans une mémoire CMOS alimentée par une petite pile. A cet époque, grâce à la pile montée en standard, apparaît également l'horloge permanente (auparavant, le PC demandait la date et l'heure à chaque démarrage...).

Rapidement, les PC-XT et AT clones et compatibles apportent un programme de setup du BIOS installé dans une ROM : Il n'est plus nécessaire d'utiliser une disquette de diagnostic spéciale (que l'on n'a jamais sous la main quand on en a besoin...) pour régler le BIOS. Une touche particulière, généralement [Suppr], pressée lors du démarrage de la machine, permet de lancer le programme de setup du BIOS depuis sa ROM. C'est un progrès.

Apparaîssent successivement le processeur Intel 80386 (32 bits), puis diverses versions de Windows jusqu'à Windows 3.11, qui ne changent pas fondamentalement grand-chose (du point de vue qui nous intéresse). Le bus du PC passe en 16 bits à travers divers tâtonnements, essais, bides commerciaux, erreurs : (PS/2 architecture MCA, EISA, VLB, puis enfin PCI, plus tard encore AGP...). Puis arrive Windows 95.

Le PC, à ce moment, peut tourner sous foule de systèmes d'exploitation différents : MS-DOS, DR-DOS, autres DOS, DOS + Windows 3.x, Windows 95, et même, même, Linux. La part du lion en termes d'OS revient rapidement à Windows 95. Le PC s'est démocratisé et devient une plate-forme de jeux vendue en grande surface. Un tas de gusses ignorants et non qualifiés branchent des accessoires dessus.

Le BIOS devient Plug'n Play, "Brancher et jouer", que beaucoup cependant appellent "Plug'n Pray" (Brancher et prier).^[1]

Ce nouveau système a été développé conjointement avec Windows 95, et permet au système d'exploitation à la fois de demander au BIOS l'état des ressources matérielles de la machine et de leurs réglages, et également de modifier ces réglages selon son bon plaisir. Pour la première fois, le système d'exploitation peut modifier les réglages du matériel, ce qui pouvait jusque là être réalisé uniquement par le programme de setup, ou en déplaçant physiquement des cavaliers sur les cartes.
Progressivement alors, les cavaliers disparaîssent des cartes, toutes les options deviennent réglables de manière logicielle dans le setup du BIOS, et peuvent être ensuite modifiées par le système d'exploitation en cours de fonctionnement.

Les modifications effectuées par le système d'exploitation, toutefois, ne sont pas mémorisées, et ne survivent pas à un reboot.^[2]

Certains fournisseurs commencent à livrer, en plus du programme de setup en ROM, une version plus "conviviale" tournant sous Windows. Il n'est, cependant, généralement pas nécessaire de l'utiliser, la version en ROM faisant la même chose.

Seuls certains portables peuvent poser des problèmes particuliers, parce que le matériel qui les compose est "exotique" et très spécifique, notamment dans ses fonctions, nouvelles à l'époque, de gestion et économie d'énergie, changement à la volée de vitesse du processeur, mise en veille et reprise, etc. Ces fonctions très avancées ne sont généralement disponibles qu'en utilisant les pilotes spécifiques à Windows développées pour ce modèle précis de machine et une version précise de Windows (et rien d'autre) par le constructeur du portable.

Les systèmes d'exploitation alternatifs (Linux) ont donc des difficultés à accéder à ces fonctions non-standard - et généralement non documentées par le constructeur et hautement variables d'une machine à une autre.

Ces saloperies de portables conduisent rapidement l'industrie à se rendre compte que la norme Plug'n play ne suffit pas à répondre à l'ensemble des besoins de "communication" entre l'O.S. et la configuration matérielle^[3], et que l'O.S. a besoin de davantage de contrôle.

Arrive alors la nouvelle norme ACPI (Advanced Configuration and Power Interface)^[4] qui donne beaucoup plus de latitude à l'O.S. pour contrôler le matériel.

Et c'est là que, dans certains cas, les utilisateurs de systèmes d'exploitation alternatifs, se retrouvent bités : Certains constructeurs de matériels ne se donnent désormais même plus la peine d'intégrer le contrôle de tous les périphériques dans le setup du BIOS. Notamment en ce qui concerne leur activation/désactivation. Ils laissent cette tâche aux fonctions ACPI du système d'exploitation (Windows), à travers les pilotes (Windows seulement...) fournis par le fabricant de l'ordinateur.

Et voilà comment on peut se retrouver incapable d'activer ou de désactiver tel ou tel périphérique autrement qu'en passant par le panneau de contrôle de Windows. Par rapport à la situation Plug'n Play précédente, quelque chose de dramatique a changé : Avec l'ACPI, désormais, le système d'exploitation peut modifier les réglages du BIOS, et ces modifications de réglage sont conservées y compris à travers un reboot ou une mise sous tension. Windows a désormais directement accès au setup^[5], et, parfois, le programme de setup lui-même, en ROM hors Windows est désormais incomplet, c'est-à-dire qu'il ne contient plus^[6] que le réglage d'éléments très basiques (ordre de boot des périphériques, mot de passe...), laissant l'activation ou la désactivation de tel ou tel périphérique, et l'affectation des ressources, au système d'exploitation via l'ACPI et les pilotes spécifiquement développés pour Windows par le constructeur du matériel.

Ce qui éclaire la situation où une personne, qui a modifié un réglage système via Windows, découvre à son grand dam qu'elle a foutu la m... dans les réglages de son système même lorsqu'elle n'utilise pas Windows.

Et qui nous montre que, même si l'on ne veut plus jamais utiliser Windows, il y a des machines modernes sur lesquelles ont est contraint et forcé de le conserver... seulement pour servir de programmes de setup. Plusieurs centaines de Méga-octets sur disque pour un programme de setup. Ca fait beaucoup, la vache. Sans compter la licence Windows payée à l'achat de la machine, bien sûr...

(Et sans même parler des disques tatoués etc, car c'est encore une autre histoire...)

BITTER (bi-té) v. a. Prendre le tour de bitte, c'est-à-dire faire faire à la chaîne un ou plusieurs tours pour qu'elle résiste mieux à l'effort à subir quand elle retient le navire.
- Nouveau Larousse Illustré (vers 1900)