Pour résumer, et essayer de faire simple (et neutre: pas question de dire que c’est plus mieux, ou plus moins bien…):
Actuellement, n’importe quel programme a accès à toute la mémoire de l’Amiga. Quand un programme dit: « je veux avoir accès à tant de mémoire », le système lui dit: « ok, voila, on t’as réservé ta mémoire, ici: [adresse de sa zone1] »
Il est fort possible qu’un deuxième programme dise aussi: « ok, moi je voudrai aussi avoir tant de mémoire ». Là imaginons que le système lui dise « ok », et lui donne l’adresse juste après la zone mémoire réservée par le 1er programme. On se retrouve avec:
[…mémoire….][zone mémoire réservée par le programme 1][zone mémoire réservée par le programme 2][…fin mémoire…]
Maintenant, qu’est-ce qui se passe si le programme 1 est buggé, et « dépasse » de sa zone ? Bein il va tout simplement écraser une partie de la zone mémoire du programme 2. Résultat: le programme 2 se retrouve, sans le savoir, avec des données complètement aléatoires dans sa mémoire réservée. Donc il a de grandes chances de crasher.
Maintenant imaginez que le programme 2 c’est une librairie importante du système d’exploitation. Et que le programme 1 est un petit programme x. Ce qui se passe (dans le pire des cas biensur), c’est que le petit bug du programme x va entraîner un crash de la librairie, donc un blocage possible de tout le système.
Tous les AmigaOS fonctionnent en gros de cette manière: n’importe quel programme peut accéder à n’importe quelle zone mémoire (les puristes me diront que MorphOS protège certaines zones mémoires, mais bon: ca reste limité…).
Maintenant, avec un système avec protection mémoire, ce qui se passe, c’est que quand un programme 1 demande un peu de mémoire, le système lui dit « ok, voila, c’est à l’adresse 1 ». Le programme 2 fait de même. Le système lui dit « ok, voila, c’est à l’adresse 2 ». Maintenant, si on tombe dans le même cas, à savoir que le méchant programme 1 dépasse de son tableau, c’est là qu’intervient la protection mémoire. Le système va interdire le programme de sortir de sa zone. Alors: ca n’empêchera pas évidemment le programme 1 de planter parce qu’il est buggé (personne n’a dit que c’était le cas). Mais on est sur que le programme 2 aura sa zone mémoire intacte, et ne crashera donc pas à cause du bug du programme x.
Voila en gros ce qu’apporte la protection mémoire. C’est en réalité beaucoup plus complexe que ca. Mais mon but est juste d’en montrer le principe, et ce que ca peut apporter. Pas de d’en détailler le fonctionnement.
Et, pour info, tous les Unix (que ce soit Linux, Unix, MacOSX,…), et Windows (depuis NT) fonctionnent de cette manière. Si vous avez déjà vu un « segfault » sur un Unix, il y a de grandes chances que ce soit un problème de ce genre en fait. De même, si vous êtes tombés sur l’erreur Windows « Le programme va être arrêté, erreur: la zone mémoire 0x1155454 ne peut être written », c’est aussi la même chose.
Voili, voila.
J’espère que ca t’éclairera. Et à toi de voir si au final c’est mieux, ou moins bien… Moi j’ai mon avis.
@+,
Léo.
—
PS: et pour expliquer le resource_tracking, un autre principe que l’on retrouve dans les systèmes modernes… Si on reprend le cas précédent. Et qu’on imagine que le programme 1 a alloué beaucoup de mémoire, alloué des canaux audio, et ouvert 3 fenêtres. S’il crash, et bein ca mémoire reste « allouée », sa fenêtre ouverte, et ses canaux audios alloués. Maintenant, sur un système avec « resource_tracking », le système garde une trace de toutes les resources allouées par un programme x. Ce qui fait que si un programme x crash, le système peut le « tuer » proprement, et libérer toutes les resources que celui ci avait alloué, fermer les fenêtres qu’il avait ouvertes,…
Admin 
Admin 
