Cette page reprend les textes en français du site IsaacOS jusqu'à début avril 2006.

Elle n'est plus mise jour.

Présentation succincte du projet Isaac

Le projet Isaac / Lisaac est issu de la thèse de Benoit Sonntag au sein de l'équipe Design du Loria. Ce projet constitue les premières étapes de la conception d'une nouvelle architecture de système d'exploitation, entièrement basée sur la technologie objet à base de prototype.

Les systèmes d'exploitation actuellement utilisés (Microsoft Windows, Linux,...) sont architecturalement vieux de 30 ans : leur structure a été pensé dans les années 1965 et 1970 lors de la conception de Multics puis d'Unix. Les concepts les plus récents implémentés en leur sein datent des années 1980 (threads, drivers). Ces systèmes sont conçus et écrit à l'aide de langages impératifs, principalement le C.

L'intégration de logiciels pensé et écris en langage objet n'était alors possible qu'à haut niveau et l'objet n'est souvent qu'une vue de l'esprit destinée à simplifier la vie du développeur.

ISAAC est le premier OS réellement opérationnel, intégralement objet, intégrant des mécanismes architecturaux radicalement nouveaux.

De la même manière que le C a été conçu pour l'écriture d'UNIX, l'écriture de ce système a nécessité la conception d'un nouveau langage : le Lisaac. Ce langage novateur intègre la technologie des objets à prototypes, alternatif à la technologie des objets à classe. Ce langage est intégralement objet, tout élément en étant un à part entière, toute méthode(fonction) étant vivante dès l'écriture : plus de classe abstraite à instancier. La puissance de cette technologie permet à un objet de changer dynamiquement de parent en pleine exécution, permettant ainsi une flexibilité jamais égalée.

Ce langage extrêmement expressif, permet de diminuer fortement les coûts et temps de développement. Pour preuve, le code de l'OS Isaac, interface graphique comprise, avoisine les 30 000 lignes, contre 130 000 pour un noyau GNU/Linux réduit à sa plus simple expression ; sa palette d'utilisation couvre tous les besoins puisqu'il est à la fois bas, moyen et haut niveau.

Son compilateur puissant utilise des techniques originales de compilation pour la suppression de la liaison dynamique, des optimisations de prédiction de type et de spécialisation de code.

Un nouvel algorithme d'analyse de contexte, adapté à la technologie objet, rend le code cible d'une efficacité encore inégalée pour ce type de langage (voir Benchs ).

Ce système d'exploitation ouvre des perspectives impensables jusqu'à peu : Logiciels autogénéré à la demande de l'utilisateur par assemblage d'objets, portabilité totale des logiciels par ajout/supression/modifications légère d'objets, système d'exploitation intelligent, génération de drivers semi automatique, etc....

Presentation

file size date description
project_st_overview.zip 3.4 Mo 05/2004 Présentation générale (diaporama)
project_overview.zip 2.3 Mo 05/2004 Présentation générale (diaporama)
pres_these.zip 2.7 Mo 11/2003 Présentation de la thèse (diaporama)
fiche.pdf 66 Ko 07/2003 Fiche descriptive du projet (1 page)
sujet.pdf 44 Ko 09/1999 Sujet de Thèse de Benoit Sonntag

Présentation d'IsaacOS

ISAAC : L'objet au coeur du système d'exploitation

Identity card
concept Object prototype based.
language Lisaac and assembler (for boot loader and hardware ports)
platforms Intel x86, Strong ARM (Intel), Dragon Ball (Motorola), ST230, Linux and Windows
features Graphic user interface
Vectorial GDI
True type font support
Bitmap and Postcript viewer
MPEG-1 and MPEG-2 viewer
Games (tetris, 4online)

L'évolution des technologies et du matériel nous amène à revoir la conception du noyau des systèmes d'exploitation actuels. Nous pensons que l'introduction de concepts objets de haut niveau au coeur même des systèmes d'exploitation simplifie et optimise l'utilisation des divers composants physiques d'un ordinateur. Ce type de démarche apporte un réel progrès aussi bien dans l'adaptation dynamique du système, que dans la simplification et le pouvoir expressif du code.

Évolution 
      des sytèmes d'exploitations vers plus de flexibilité
screen Isaac Isaac est un système d'exploitation composé uniquement de prototypes interconnectés dynamiquement. Chaque prototype est un macro-objet fonctionnant directement sur le processeur. Isaac n'est pas un interfaçage d'objets avec les concepts de systèmes d'exploitation actuels. Le système Isaac est une homogénéité parfaite où seul l'objet règne en maître. Pas de fichier, pas de processus , pas de segment de mémoire sans revêtir une forme d' objet unique.

Modularité

Chargement dynamique des objets

Flexibilité

Modification des objets durant l'exécution

Expressivité

Héritage multiple et dynamique en natif, même après compilation
macro
computer

Légéreté

Moins de 500 Ko de mémoire vive (avec interface graphique).

Adaptabilité

Portage facilité par le découpage en objets
Actuellement fonctionnel sur Intel x86, Motorola DragonBall (Palm), Intel ARM : le compilateur génère du C, seule une centaine de ligne en assembleur sont à réécrire.

Uniformité

Modèle uniforme des objets reposant directement sur le matériel.

Rapidité

Code compilé des prototypes réellement efficace.
test
security

Sécurité

4 niveaux de privilège hardware.

Stabilité

Utilisation de la programmation par contrat.
Ecrit à 100 % en langage de haut niveau.

Carte d'idendité de Lisaac

Lisaac: The power of simplicity at work for operating systems

Identity card
concept small prototype-based programming language
The ideas in Lisaac are mostly inspired by Smalltalk (all values are objects), Self (prototype-based) and Eiffel (design by contract)
platforms all platforms (host/target specific for GCC)
features pure object language
very fast (like C code)
dynamic and multiple inheritance
dynamic definition slot
static typing (invariant)
genericity type
auto-cast type system
programming by contract
interrupt manager
include C code facilities
Emacs

La réalisation du système d'exploitation Isaac nous a conduit à concevoir un nouveau langage de programmation: Lisaac. Ce langage à base de prototypes s'inpire fortement du langage Self. En plus des atouts de Self, Lisaac intègre des mécanismes de protection des communications ainsi que d'autres outils relatifs à la conception de systèmes d'exploitation. L'utilisation de prototypes et en particulier l'héritage dynamique sont très bien adaptés à la conception de système d'exploitation. Les premiers tests d'exécution de nos objets compilés montrent qu'il est possible d'obtenir des performances comparables à des programmes C avec des programmes dans un langage de haut niveau à base de prototypes . Ainsi, notre langage est le fruit d'une expérience dans la mise en place d'un système d'exploitation à base d'objets dynamiques; ses possibilités sont un subtil mélange de Self, d'Eiffel et dans une moindre mesure du langage C. Il hérite de la sémantique de Self et une certaine forme de typage statique d'Eiffel. Pour sa part, l'implantation est particulièrement originale sur de nombreux points. Un langage de ce type sous la forme compilé est une grande première dans le domaine. Son originalité ne s'arrête pas là, le fait que les objets restent objets après compilation permet de conserver toute son expressivité.

Classe Versus Prototype

Objet à classe contre Objet à prototype

Ouverture sur les possibilités offertes par le projet IsaacOS

L'informatique est soumise comme d'autres disciplines à des limitations technologique qui sous-tend pour beaucoup son évolution. Celle-ci touche une discipline fondamentale dans ce domaine: le génie logiciel.

D'un côté on possède des langages dit de "haut niveau" permettant de développer rapidement sans trop se soucier des particularitées structurelles de l'ordinateur et de l'autre les langages de "bas niveau" qui ont la particularité d'être rapide mais oblige le développeur à comprendre et gérer assez finement son code en fonction des particularitées de la machine cible.

On peut ainsi appliquer la célèbre maxime "On ne peut avoir le beurre et l'argent du beurre" ou appliqué à notre contexte, on ne peut disposer d'un langage de "haut niveau" avec les performances d'un langage bas niveau. On ne peut donc imaginer d'écrire un système d'exploitation avec un langage de haut niveau sans subir des performances catastrophiques aisi que l'impossibilité de porter ce SE sur une architecture embarquée.

C'est cette problématique que se propose de résoudre, entre autre, le projet IsaacOS grâce à son langage Lisaac.

Lisaac est un langage objet moderne dans lequel on trouve tous les outils de haut niveau qu'on est en droit d'attendre dans des langages de ce type : Collection, table de hashage, chaînes de caractères évoluée et outillée, librairie numérique complète, etc...

En tant que langage objet à prototype, Lisaac innove en offrant une gestion des objets plus souple avec la disparition des classes et la possibilité de changer dynamiquement de parent à l'exécution.

Mais Lisaac est aussi doté de mécanismes de gestion du système qui en fait un langage permettant d'écrire des drivers et des systèmes d'exploitations (gestion mémoire, interruptions, masque de bit, etc...)

Grâce à un algorithme de supression de la liaison dynamique, le compilateur produit du code aussi rapide que du C.

IsaacOS est la première application démontrant les larges possibilités offertes par le compilateur. Ce système est entièrement constitué d'objets dialoguant entre eux, très léger (500 Ko avec inerface graphique), il ouvre la voie à des SE ou la notion de processus s'efface devant celui d'espaces applicatif, une application n'étant qu'un rassemblement opportun d'objets distinct.

Pourquoi un nouveau Système d'exploitation ?

Les systèmes d'exploitation actuellement disponibles sur le marché sont tous basés sur des études, des machines, et des besoins datant de plus d'une vingtaine d'années. En effet, que ce soit Solaris de SUN, Linux ou Windows de Microsoft, leur architecture interne est peu différente et s'appuie sur les fondements d'Unix. Notre approche se veut différente et particulièrement en rupture avec cette architecture pour faciliter l'évolution du système lui-même, et par conséquent de la couche applicative s'y rattachant.

Dans plusieurs domaines de l'informatique moderne, comme l'ergonomie, la communication inter-applications, ou la répartition de la charge, nous commençons à entrevoir certaines limites liées essentiellement, à notre avis, au système d'exploitation. Nous pensons que les systèmes d'exploitation manquent d'expressivité et de dialogue avec la couche applicative de manière significative, rendant ainsi certains services impossibles à imaginer actuellement. Nous pouvons citer comme exemple: une gestion entièrement automatique de la mémoire, un multi-tâche implicite, la fusion des fonctionnalités de différentes composantes logicielles.

Le système ne doit plus se contenter de gérer le matériel, mais il doit s'impliquer d'avantage dans la gestion même des applications. Dans cette partie, nous montrons ce qu'est à notre avis le système d'exploitation idéal. A chaque élément de réflexion, nous apporterons petit à petit les concepts de notre système pour atteindre nos objectifs.

Flexibilité, modularité et évolutivité: un système à la carte

Aujourd'hui, les systèmes d'exploitation sont évolutifs au niveau des périphériques par le biais de drivers installables au coeur du système. L'idée est séduisante, mais elle reste un cas relativement isolé de flexibilité dans son ensemble. En effet, le noyau du système, le système de fichier et parfois même l'environnement utilisateur reste encore figé sans évolution, ni flexibilité possibles. La mise en place de drivers reste une opération fastidieuse et instable pour bien des systèmes. L'opération nécessite encore trop souvent le redémarrage complet de l'ordinateur. Et l'écriture de ces drivers reste complexe pour atteindre une stabilité prenant en compte l'ensemble des paramètres du système.

Un système d'exploitation entièrement en drivers apporte une flexibilité encore inégalée. Un système où la modularité règne en maître et où l'identité du système se décrit par son ensemble et non pas par un noyau rigide.

Réutilisabilité des fonctionnalités : un système coopératif

A notre avis, un des nombreux volets d'un système d'exploitation d'un genre nouveau porte sur la réutilisabilité du code déjà présent dans le système complet (système d'exploitation + application). Aujourd'hui, nous pouvons constater certains efforts qui vont dans ce sens comme les DLL (Dynamic Link Library (Microsoft)), OLE/COM (Component Object Model (Microsoft)) ou les librairies dynamiques de Linux (.SO : Shared Object file) permettent à plusieurs applications d'utiliser les mêmes librairies de fonctions durant l'exécution. Cette approche pragmatique reste largement insuffisante. Dans notre approche, l'ensemble du système devient collectivement une librairie accessible et offrant des services logistiques ou physiques à l'ensemble des applications. Bien évidemment, notre idée est d'étendre notre démarche au niveau applicatif et de permettre ainsi qu'une application devienne elle-même réutilisable par une autre. Ainsi, les fonctionnalités de chacun sont partagées par tous.

Lorsque l'on parle de réutilisabilité, on parle très souvent de concepts objets. Là encore, notre système idéal s'accaparerait les vertus de l'objet pour accroître la réutilisabilité. Ici, nous pouvons nous placer au niveau de Corba. Mais, les objectifs de cet outil ne sont pas les mêmes. Tout d'abord, Corba n'est pas prévu pour de la programmation système. En revanche, il est plus adapté à la prise en compte d'exécution à distance d'objet. Mais la lourdeur que celà impose ne permet pas son utilisation de manière intensive au sein d'un unique système. En effet, nous envisageons nos drivers comme des objets pouvant hériter, redéfinir, compléter ou spécifier d'autres objets. L'idée d'objets dynamiques vient du mariage entre le côté dynamique des drivers et de la flexibilité d'expressivité et de réutilisabilité des concepts objets.

Un système d'exploitation tirant pleinement partie de la notion d'héritage est à notre avis un grand pas en avant en terme de coût de développement et de clarté du système. Toutefois, il est vrai que l'évolution va dans ce sens, avec une approche plus simple, l'approche par délégation qui est déjà présente dans les systèmes traditionnels.

Robustesse et stabilité : un système fiable

Dans notre approche, la stabilité du système n'est pas un réel problème. Au contraire, la division du noyau et du système tout entier en une multitude de parties permet d'obtenir une meilleure stabilité globale. En effet, à l'image de la nature, si un élément de notre corps est defectueux, le reste de l'être reste heureusement opérationnel. Evidemment, certains objets restent indispensables pour le bon fonctionnement du système. Mais nous pouvons d'ores et déjà présager une flexibilité étonnante. A titre d'exemple, en cas d'absence de drivers scheduler dans Isaac, l'ensemble du système reste fonctionnel en mono-tâche ! Cela montre bien la puissance d'un tel système par rapport aux difficultés d'instabilité que l'on peut rencontrer dans les systèmes conventionnels.

A l'image du problème de la stabilité, la cohérence et la compatibilité entre deux systèmes Isaac possédant des drivers différents peuvent susciter une inquiétude. Plusieurs solutions sont à envisager. La première passe par l'unicité des interfaces des drivers offrant les mêmes fonctionnalités. En cas d'absence de drivers nécessaires à une quelconque compatibilité, le système se doit d'approcher au mieux la demande avec les outils dont il dispose.

Néanmoins, la mise en place d'une compatibilité par ajout de drivers ou d'objet dynamique reste une solution simple et naturelle qui je pense, n'est pas un frein à notre démarche.

Aussi, il est nécessaire de s'interroger sur la protection des différents objets du système. A l'image des systèmes conventionnels, il existe une hiérarchie au sein de nos objets. Certains objets sont indispensables pour le bon fonctionnement et la robustesse du système. Il faut donc leur garantir une bonne protection par rapport aux autres. L'intégrité de leurs données doit passer par une protection hardware de leurs zones de travail. Aussi, les deux niveaux de privilège (Le premier niveau appelé kernel) est composé du noyau système et de ces drivers. Le second niveau appelé user renferme l'ensemble des applications en cours d'utilisation, dans les systèmes actuels nous paraissent insuffisants.

Aujourd'hui, un système d'exploitation peut se bloquer par l'utilisation d'un mauvais drivers. Le driver étant de même niveau de privilège que le noyau, aucune protection fiable n'est possible. Un modèle comprenant 4 niveaux de privilège est souhaitable, comme le suggère le système. Multics et les manuels de référence des processeurs Intel. Nous pouvons ainsi mieux protéger les objets indispensables au fonctionnement du système. Car, plus nous divisons l'ensemble du système (système d'exploitation et applications) dans des espaces indépendants et protégés entre eux, plus nous évitons un crash complet du système.

Evidemment, le système idéal devrait garantir une protection hardware pour chaque objet. Mais les contraintes matérielles et le coût en terme de performance d'exécution ne nous le permettent pas encore.

Lisibilité, transparence et simplicité : un système ouvert

L'évolution n'est intéressante que dans sa simplicité. Il est nécessaire de pouvoir installer ou désinstaller un driver de manière plus intuitive qu'actuellement.Ainsi dans Isaac, l'installation d'un nouvel élément se réduit à une simple copie de fichier dans le répertoire approprié. Après copie de ce fichier , le système prend en compte automatiquement le nouvel élément. La désinstallation se matérialise par la suppression de ce fichier. Les fichiers sont considérés comme des éléments toujours vivants et actifs au sein du système.

Aussi, les systèmes actuels sont devenus conséquents. Aujourd'hui, une abondance de fichiers obscurs "non parlants" rangés dans une multitude de répertoires ne permet pas à l'utilisateur (même expérimenté) de manipuler ou de comprendre leur intérêt et leur utilité au sein du système. Dans le monde Isaac, l'ensemble des fichiers est représenté comme des objets. Un objet sous sa forme exécutable posséde une interface lisible à tous permettant de comprendre son utilité au sein du système. Nous entendons par interface, une liste de fonctionnalités par description des prototypes de l'objet comparable à un fichier .h du langage C. Ces prototypes devront être agrémentés de commentaires aidant ainsi sa réutilisabilité par un programmeur extérieur. Dans le cas où le fichier n'est pas un objet de type Isaac (une image ou un texte), le système effectura automatiquement un lien vers un objet Isaac capable d'extraire une interface virtuelle du fichier. Cette interface pourra avoir différents niveaux d'interprétation. Par exemple pour un fichier d'animation, le niveau d'interprétation le plus abstrait est l'affichage de l'animation. Puis nous pouvons imaginer le découpage de l'animation en image et son. L'interprétation de ce fichier la plus concrète réside en l'affichage de ses octets avec les attributs du fichier (Lecture/écriture, dates, taille,...)

Pour un système d'une meilleure lisibilité, le choix des répertoires doit refléter exactement le chemin d'accès via l'interface utilisateur. Là encore une totale fusion entre la représentation de l'arborescence des fichiers et de son accessibilité via l'interface utilisateur est souhaitable. Les menus contextuels présents dans le système BeOS vont dans ce sens, nous pensons que cette meilleure transparence pour l'utilisateur entre la réalité et son interface permet une compréhension plus approfondie et plus simple du système. Nous étendons ce concept jusqu'au menu des applications. Par exemple, les objets capables d'ouvrir des fichiers document seront rangés dans le répertoire ouvrir du répertoire fichier qui correspondra directement au menu fichier de l'application. De ce fait, l'ajout d'un objet permettant d'ouvrir un nouveau format de fichier provoque automatiquement sa prise en compte et son accès via le menu fichier. De plus, une remarque importante doit être faite sur le nombre réel d'applications que possèdera ce système. Par son fonctionnement, il y aura très peu de réelles applications disjointes proprement dites. En effet, tous les objets traitant le même domaine sont regroupés dans une seule application. Par conséquent, nous ne parlons pas réellement d'applications, mais plutot de domaine applicatif.

A première vue, nous aurions un nombre très restreint de domaines:

Chaque domaine forme une application unique composée de l'union d'objets pouvant apporter des fonctionnalités liées au domaine applicatif.

Diviser pour règner: un système qui construit ses applications

Notre système et les applications elles-mêmes réagissent comme des librairies pour d'autres applications. Un exécutable Isaac est une multitude de fonctions accessibles à tous (ou presque) permettant ainsi des échanges de fonctionnalités comparables à des environnements et des techniques que l'on trouve dans le multi-agents. Une application est un assemblage d'objets liés à un domaine applicatif. Par simple copie de fichier objet dans un répertoire lié à un domaine d'application, l'utilisateur voit son application adopter de nouvelle fonctionnalité.

Comme les objets se partagent mutuellement leurs fonctionnalités, nous pouvons envisager qu'un seul objet feuille est utile pour toutes les applications à sortie graphique:

Par exemple, quel graphiste n'a pas rêvé de manipuler en même temps sur une même feuille du dessin vectoriel et du dessin bitmap ?! Aujourd'hui, le professionnel de l'image travaille avec un logiciel de traitement photo et un logiciel de traitement vectoriel. Aucun logiciel n'est capable de coordonner les deux mondes correctement. Dans ce domaine, toutes les tentatives se sont soldées par un échec: par manque de professionnalisme des fonctionnalités du produit ou par la lourdeur catastrophique du logiciel L'exemple le plus frappant est le logiciel Expression de Macromédia actuellement abandonné et racheté par la firme Corel...

Actuellement, les lourdes applications sont effectivement découpées en différentes parties. Mais, la conception actuelle ne facilite pas ce découpage et nous sommes bien forcé de constater que les temps de chargement restent conséquents pour ce type de logiciel. Ici, le découpage en objet est inhérent au concept du système, par conséquent, plusieurs atouts vont dans le sens de mes propos. Tout d'abord, la conception objet d'une application permet un meilleur partage du code via l'héritage (surtout dans le concept d'objet à base de prototype). Mais aussi, l'encapsulation du code en différents objets permet une meilleure ségrégation des différentes parties du logiciel. Par conséquent, le chargement de ces parties peut être réalisé par nécessité. Ainsi, le système ne conserve en mémoire que ce que l'utilisateur lui impose. Segmenter les fonctionnalités tout en les rendant compatibles entre elles est le secret d'un bon travail en concert sans être obligé d'exécuter une "usine à gaz"!

Un exemple de partage consiste à déléguer à un objet le choix d'une couleur pour l'ensemble des applications graphiques. Cet objet aurait la capacité de travailler avec différents modes de représentation d'une couleur:

L'ensemble des applications graphiques se retrouve ainsi avec des fonctionnalités de choix de couleurs multiples sans aucun ajout de code. De plus, un avantage non négligeable pour l'utilisateur réside en l'unicité de la représentation de l'interface qui s'occupe du choix d'une couleur.

L'idée générale est que chaque objet dynamique s'attribue une tâche bien précise et suffisamment restreinte pour que le travail soit bien fait.

Cela est séduisant, mais elle soulève de nombreux problèmes, notamment en terme de communication, d'échange de données et d'ergonomie d'interface. Ici, le système Isaac apporte plusieurs mécanismes permettant la communication entre plusieurs objets qui ne se connaissent pas ou peu, sans pour autant avoir de solution miracle. Le système est entièrement réflexif: chaque objet est capable d'analyser les interfaces des autres objets présents dans le système. Cette réflexivité permet à tout objet de connaitre les fonctionnalités dont il dispose. Il peut ainsi utiliser un objet inconnu par envoi de message. Il peut le consulter ou éventuellement en hériter pour enrichir l'objet en question après analyse de celui-ci.

Un autre mécanisme est celui des journaux. Isaac voulant s'orienter de plus en plus vers un système intelligent et multi-agents, nous avons imaginé un mécanisme par abonnement à des journaux circulant dans le système. Chaque objet a la possibilité d'éditer un journal qui sera automatiquement distribué à l'ensemble des objets s'étant abonné à celui-ci. Aux évènements simples comme un clic de souris, jusqu'à des évènements plus complexes, des journaux sont édités pour informer les objets intéressés.

La dernière difficulté se situe au niveau de l'interface utilisateur. L'application étant émergente par assemblage d'objets, le programmeur ne définit pas ou que partiellement le "look" d'une application. En effet, chaque objet possède la lourde tâche de définir l'interface d'accès pour les fonctionnalités de l'objet. Mais c'est le système qui doit s'occuper lui-même d'agencer l'interface globale de l'application. Nous pouvons parler d'interface émergente. Elle doit varier, s'enrichir lorsqu'on  ajoute de nouveaux objets, mais cette variation ne doit pas déstabiliser l'utilisateur. Une fois encore, il n'existe pas de solution miracle. Nous avons effectué des études sur les interfaces des applications actuelles. Cette analyse nous a permis d'extraire deux axiomes de constructions interfaces qui, par analyse du contexte, permettent d'extrapoler, et d'inférer automatiquement toutes les variantes des interfaces présentes dans les applications actuelles.

En effet, avec ce que nous avons appelé les "groupes" et les "items", nous sommes capables de construire par inférence tous les éléments présents dans une application: menus déroulants, fenêtres de dialogue, boîtes à outils , listes, arbres, boutons, check list... Le programmeur définit simplement un "item" dans un "groupe" pour donner accès à une fonctionnalité de son objet par l'interface utilisateur. Par la suite , le système calcule le "look" de cet item selon le contexte où il se situe. Il peut parfaitement devenir un bouton, un élément d'un menu, un élément d'une liste, ou encore un raccourci en icône.

Ici, nous avons aussi pensé au côté international, car les items peuvent être traduits dynamiquement dans la langue de l'utilisateur. De plus, avec une telle abstraction de cette interface, il est facilement imaginable de construire une interface autre que graphique. Echange et description vocale des groupes et des items sont envisageables pour un utilisateur aveugle. Une adaptabilité de l'interface au périphérique disponible est indispensable pour imaginer un système d'exploitation universel. Un téléphone portable ne possède pas de souris et son clavier est restreint, l'interface doit donc s'adapter à celà. Nous pensons aussi à l'assistant personnel qui ne posséde pas de clavier mais juste un écran tactile.

Vers un système intelligent

Contrairement à la boîte noire "application" dans les systèmes actuels, nous disposons d'une vision très profonde de la sémantique d'un domaine d'application. Le système a accès à l'ensemble des composantes objets et de l'interface de chacune d'elles permettant ainsi l'analyse des échanges de données et services qui transitent entre chaque objet. Nous ajoutons en plus la réflexivité, qui permet à n'importe quel objet d'analyser les fonctionnalités d'un autre objet. Chaque groupe d'objets peut fonctionner en parallèle avec d'autres, changer son héritage ou modifier ses fonctionnalités durant son exécution (avec certaines limites qu'impose la compilation de nos objets).

D'ores et déjà, nous pouvons considérer nos objets comme des individus capables de communiquer et de demander des services à d'autres de manière comparable à une population dans les systèmes multi-agents. Sans encore bien savoir comment rester stable et cohérent, nous envisageons la possibilité que le système assemble, crée ou hérite de nouveaux objets, selon ses besoins, permettant ainsi d'obtenir des services encore non gérés par le système. Faut-il que l'utilisateur donne son but, comment et dans quelles proportions il canalise et maîtrise ce brassage d'objets? Le système doit trouver, si cela est possible, l'assemblage d'objets permettant de répondre à une demande. Notre réflexion est encore loin d'être suffisante pour prétendre répondre à ce type de questions. Néanmoins, de telles perspectives sont encourageantes et un système ouvert comme Isaac se dirige dans ce sens. Cette partie ne sera pas davantage développée, mais il me paraît interressant que le système puisse s'intercaler et analyser les échanges que les objets réalisent entre eux.

Compatibilité: vers un format de fichier unique

Les formats de fichier sont encore un frein pour certains utilisateurs inexpérimentés. La duplicité des formats dans certains domaines de l'informatique freine les échanges de documents directement d'un ordinateur à un autre. L'idéal serait évidemment un format unique de document pour n'importe quelle domaine applicatif. Il est malheureusement impensable de mettre véritablement cela en oeuvre. La trop grande variabilité des données à traiter est au cŒur du problème. Et puis, il ne faut pas freiner l'évolution en matière de compression de ces données provoquant inexorablement une multitude de formats de fichiers. Néanmoins avec l'architecture du fonctionnement applicatif d'Isaac, le format des documents produits par ces applications demande à être repensé pour tirer pleinement partie du coté modulaire du système. En effet, notre système a suffisamment de connaissance sur la sémantique des objets en cours d'utilisation pour en extraire une image mémoire minimale représentant un document composé de données variées. Cette image mémoire est en quelque sorte un fichier document standard pour Isaac. Il est important d'imaginer différents degrés de conservation et d'extraction de cette image mémoire dans un fichier. De façon graduelle, le système peut n'extraire que les liens de référence que nécessite le document ou bien encapsuler dans le fichier mémoire l'ensemble des objets et instances que nécessite l'ouverture de ce document.

Nous obtenons ainsi une forme de fichier plus ou moins coûteuse en terme de place sur le disque, plus ou moins riche en informations et évidemment plus ou moins portable. En cas d'absence d'un lien sur un ordinateur distant, l'ouverture du fichier provoque un message d'avertissement sans pour autant interdire l'ouverture partielle de ce fichier. De plus, il est facilement envisageable de produire un format standard par domaine d'application. Par exemple, l'objet feuille commun à l'ensemble des parties applicatif du domaine graphique est tout à fait en mesure d'effectuer une image de son contenu dans un fichier . La communication entre les différents outils graphiques et l'objet feuille passe forcément par un protocole commun. L'ordinateur distant ne devra que posséder un objet feuille pour visionner ce document sans obtenir la possibilité de le modifier.

En d'autres termes, un objet clé pour chaque domaine d'application peut servir de charnière pour la diffusion de documents.

Notre approche ressemble étroitement aux idées présentes dans le langage XML Extensible Markup Language: Langage Extensible de   balisage. En d'autres termes, nous pouvons exprimer notre démarche comme une généralisation des fichiers XML. Les fichers XML apportent une sémantique par balise à un document visuel simple. Notre idée est d'apporter une sémantique à n'importe quel fichier où les balises sont matérialisées par des envois de message aux objets du système.

Vers une répartition de la charge automatique: un système distribué

Le parallélisme reste une chose difficile à mettre en oeuvre dans un système d'exploitation moderne. Dans les systèmes actuels, nous pouvons constater trois formes de parallélisme utilisées. La première se situe au niveau du processeur, elle est directement liée à l'architecture de la machine et ne rentre pas en jeu dans la mise en place de nouveaux concepts en matière de système d'exploitation. Le second parallélisme est matérialisé par le biais de tâches, appelées processus, introduit par Unix La description des processus date en réalité du système d'exploitation Multics, mais je considère les systèmes Unix comme une implantation simplifié des concepts introduit par Multics. Elle permet d'exécuter plusieurs applications en même temps grâce à des procédés de préemption sur une machine monoprocesseur. La dernière forme de parallélisme, appelée thread ou encore processus léger, est très proche de la première. Elle permet de paralléliser l'exécution de morceaux de code au sein d'une même application .

Notre système possède un découpage de l'exécution en objet et une visibilité système de ce découpage. De manière simpliste, chaque objet pourrait fonctionner parallèlement à d'autres. Ce découpage implicite doit encore donner lieu à des études précises de faisabilité. Les problèmes directement liés à un fort parallélisme d'Isaac sont les inter-blocages entre objets. Plusieurs possibilités pour éviter ces inter-blocages sont à envisager.

Néanmoins, la solution actuelle est de regrouper les objets en ensembles indépendants et pouvant s'exécuter en parallèle. Cette étude fait l'objet de la partie.

Un parallélisme par l'exécution de certains objets sur une machine distante est aussi à envisager. Là encore, il serait nécessaire de réfléchir sur l'ordonnancement de l'exécution distante des objets. Est-il préférable de ramener l'objet distant en local, ou de le laisser s'interfacer avec le système à distance? Comment fonctionner avec des architectures variées alors que nos objets sont compilés pour des questions d'efficacité évidente?

Efficacité: un système rapide

Malgré les progrès des interprètes actuels, nous pensons qu'ils ne permettent pas de tirer pleinement partie de la puissance des processeurs. De plus, nous envisageons difficilement l'exécution de sections critiques du système comme les drivers de périphériques en code interprété. Tout notre système de communication, de protection et d'exécution de nos objets utilise au mieux directement les possibilités matérielles de la machine. L'ensemble de nos objets est donc compilé pour obtenir de bonnes performances à l'exécution. Le code restant portable d'une architecture à une autre via une simple recompilation, nous pensons que ce choix est des plus raisonnables.

Notre système peut prétendre à de bonnes performances pour les raisons suivantes

Avec un bon parallélisme de nos objets, même le noyau système peut être préempté et ainsi avoir une meilleure répartition globale de la charge. La communication par envoi de message est bien plus efficace qu'une communication par les traditionnelles interruptions. Le mécanisme d'héritage et de redéfinition permet d'éviter une certaine lourdeur au niveau des fonctions dite "relai" dans les API API: Application Protocol Interface . actuelles.

L'utilisation de langage de haut niveau facilite la mise en place des techniques de cache, d'aliasing et de table d'hash-coding où les gains en terme de temps d'exécution ne sont plus à démontrer.

Légèreté et adaptabilité: un système portable

Aussi, nous constatons aujourd'hui que les systèmes d'exploitation se partagent le parc informatique de manière bien précise. Aucun système d'exploitation n'est capable de fonctionner aussi bien sur votre téléphone portable que sur votre ordinateur de bureau. Là encore, la flexibilité du système fait défaut. Un OS moderne se doit de pouvoir s'adapter et faire corps avec les possibilités variées du matériel dont il dispose.

La division des services en objets et les mécanismes d'héritage nous permettent d'obtenir un système extrêmement compact. L'ensemble du système Isaac ne prend pas plus d'un méga-octet avec toutes les fonctionnalités d'un système actuel. Selon le matériel et les exigeances que l'on s'impose, le système peut être réduit à quelques kilo-octets par simple suppression d'objets. Ce gain de place est impressionnant et risque de l'être encore plus lors de la mise en oeuvre d'applications conséquentes.

Isaac est aujourd'hui capable de fonctionner et d'offrir les mêmes services sur un ordinateur de bureau que sur un assistant personnel. Sans grande difficulté et sans une réécriture systèmatique du code, le portage sur des architectures variées n'est pas un problème. Là encore, les vertus de l'objet y sont pour beaucoup.

Lorsque l'on regarde à la loupe le portage du système Linux sur d'autres architectures que le PC, on est forcé de constater des transformations massives du code C de certaines parties du noyau système. Il est vrai, qu'à la base, Linus Torvalds n'avait pas prévu le portage de Linux sur une autre architecture que le PC. Il y a donc peut-être un problème de conception datant des premières versions de ce système. En revanche, ce système est actuellement tellement porté sur d'autres architectures que la richesse du code déjà présent facilite grandement de nouveaux portages.

A titre d'exemple, sous Isaac, nous avons réalisé un portage entre le PC et une architecture particulièrement différente sur un assitant personnel. Les seules modifications du code se situent au niveau de la partie basse des drivers de périphérique que nous redéfinissons par héritage . Le drivers graphique ne diffère que d'une centaine de lignes entre les deux architectures.

L'uniformité des prototypes: un système élégant

La recherche d'uniformité est l'une des obsessions et des qualités de tout scientifique. L'abolition des cas particuliers pour en extraire le cas général et la définition la plus générique possible d'un problème amène la satisfaction de pérénité de notre recherche, mais aussi la solidité du modèle que l'on défend.

Pour cette raison, je me suis efforcé d'apporter un maximum de cohérence et d'uniformité dans l'ensemble du projet. Ici, le monde des prototypes s'étend du simple entier jusqu'aux structures les plus complexes du système. La création du langage Lisaac a permis de révéler sous une forme élégante la puissance des prototypes pour la programmation système. Une personne ne connaîssant pas l'informatique et ayant assimilé les mécanismes simples d'objet à prototypes peut comprendre l'ensemble du code en commençant par les conditionnels décrites par liaison dynamique, jusqu'au gestionnaire de mémoire entièrement écrit en Lisaac. Évidemment l'élégance d'un langage reste assez subjectif, comme la beauté d'une formule mathématiques. Mais je pense que la recherche faite avec passion et créativité se rapproche beaucoup de l'artiste qui cherche sans cesse à parfaire la beauté de son art.

Le nombre d'éléments externes au concept de prototypes (appelé aussi "briques de base") est particulièrement réduit dans notre projet. Mises à part certaines opérations arithmétiques et logiques comme la soustraction ou la multiplication, les autres opérations de bas niveau sont écrites en Lisaac. L'accès à l'assembleur est juste nécessaire pour l'écriture ou la lecture d'un port de périphérique ou pour des opérations très spécifiques comme l'invalidation des caches mémoire du processeur.

Comment atteindre le système idéal ?

Les concepts objets sont au coeur de notre problématique. Ils sont visiblement insuffisants pour réellement prétendre subvenir à l'ensemble de nos exigences. Néanmoins, ils apportent la réponse à de nombreuses attentes. Ils peuvent être considérés comme la meilleure base actuelle d'un tel projet. Mais je n'hésiterai pas à remettre en cause ce choix si le besoin s'en fait ressentir.

Isaac est actuellement unique pour avoir associé un modèle objet de haut niveau des applications jusqu'au noyau directement sur le matériel. Ses objets sont indépendants, compilés et communiquent entre eux. Ils héritent et se chargent durant l'exécution du système. J'ai choisi d'emprunter les idées des langages à base de prototypes car leur expressivité est actuellement encore inégalée et répond parfaitement à notre vision d'un système moderne .

Isaac s'inscrit parfaitement dans l'évolution informatique depuis sa création.

En effet, nous observons deux phénomènes d'évolution, l'un touchant les langages, l'autre les systèmes d'exploitation.

Pour réduire le nombre de lignes de code et gagner en clarté, les langages informatiques n'ont cessé de se structurer. De l'assembleur, nous avons vu la création de langage plus "évolué" comme le Fortran66. Le Fortran66 est assez proche du langage machine par son côté très linéaire du code. Mais il permet en quelques lignes d'effectuer un traitement complexe. Puis nous avons structuré le code linéaire en procédures et fonctions comme dans le langage C. L'utilisation de fonctions paramétriques permet une réduction et une généralisation du code. L'arrivée des concepts objets peut être vu comme un regroupement de procédures et fonctions en une entité appelé objet. L'héritage et les autres atouts des concepts objets sont encore là pour faciliter la réutilisabilité et la réduction du code. Je vois le découpage en objet comme une structuration macroscopique du code. Nous assistons donc à un phénomène de regroupement du code en entités de plus en plus grandes et abstraites pour permettre une vision plus macroscopique d'une application complexe.

Pour les systèmes d'exploitation, nous avons le phénomène inverse. Pour les mêmes raisons de réutilisabilité et de réduction du code, les systèmes n'ont cessé d'augmenter leur fragmentation. L'utilisation de librairies externes, l'insertion de drivers découpent le système en parties indépendantes et communicantes. On parle ici plus de flexibilité et de communication avec le système et les applications. Mais il est surprenant de constater que l'évolution des langages et des systèmes d'exploitation suivent une progression différente vers les mêmes objectifs. La jonction des deux disciplines au niveau conceptuel paraît souhaitable.

Le projet Isaac s'inscrit donc naturellement dans un prolongement de cette évolution par une fusion entre langage et système d'exploitation.

Nous avons eu besoin de construire le langage Lisaac permettant de matérialiser les mécanismes et possibilités d'Isaac. Puis nous avons effectué un prototype pour prouver qu'un système entièrement en objets dynamiques pouvait voir le jour.

Le projet Isaac est le début d'une solution complète d'un système d'exploitation à base de prototypes. Les problèmes ont été soulevés et traités dans leur ensemble. C'est pour celà que le projet est aussi complet et complexe.

Par son caractère novateur, il est difficile d'établir clairement les limites, les difficultés qu'il reste à résoudre et l'avancement global du projet.