La lecture du rapport technique peut donner le sentiment que la technique mise en oeuvre pour obtenir des performances temps réel de Windows 3.1 ressort plus d’un bricolage informatique que d’un algorithme mûrement réfléchi. En fait, il n’en est rien. Je pense honnêtement pouvoir affirmer, qu’avec la configuration choisie, la méthode choisie a été la bonne; l’application parfaitement opérationnelle en est la meilleure preuve. Toutefois, il me faut reconnaître qu’il ne peut en aucun cas s’agir de la méthode à retenir dans la perspective d’une application spatiale. En effet, n’oublions pas que nous nous étions fixé l’objectif de réaliser une maquette destinée à prouver la faisabilité du dispositif optique. Aujourd’hui mais surtout demain, les besoins sont tout autres: la notion de test laisse place à celle de réalisation.
La prochaine étape, nous l’avons vu lors de la présentation du projet MUST, consiste à réaliser une maquette grandeur nature équipée de plusieurs télescopes : 2 puis 3, et finalement 5. Ceci implique, vis à vis du traitement informatique, l’exécution en parallèle de 2 à 5 fois l’algorithme de cophasage. Bien sûr, il n’est pas question de réaliser un multiplexage des algorithmes en employant la technique utilisée pour le transfert de l’image du signal DS. En effet, non seulement cela nuirait aux performances du système mais surtout la complexité du programme et de sa maintenance serait multipliée d’autant. C’est pourquoi nous avons choisi l’option du portage vers un système préemptif.
Un système d’exploitation multitâche préemptif est un système d’exploitation capable d’exécuter simultanément des processus indépendants et non coopérants. En d’autres termes, c’est lui qui répartit la CPU entre les différentes entités d’exécution selon des niveaux de priorités définissables. Donc, contrairement à la situation dans laquelle je me trouvais jusqu’alors, un tel système me permettra de réaliser la procédure de cophasage sans me préoccuper du partage ni des ressources, ni du temps machine; exactement comme si l’ordinateur était totalement dédié à ce processus. Les avantages sont immédiats. Le code gagne en simplicité donc en clarté. De plus il n’est pas plus compliqué d’en lancer plusieurs qu’un seul à la fois. Enfin, les performances ne sont plus limitées à la résolution du timer, mais bien aux performances de la machine utilisée.
La raison pour laquelle cette option de programmation et de configuration logicielle n’a pas été choisie dès la première année est simple: les drivers des cartes dont nous avons besoin n’existe pas encore et donc a fortiori n’existait pas à l’époque. Cet obstacle de poids doit pourtant trouver une solution; elle consiste à réécrire les librairies pour l’environnement choisi. Reste à choisir la plate-forme répondant aux critères précédemment évoqués.
Afin de garder une certaine homogénéité avec l’actif, il a été décidé de choisir un système parmi ceux proposés par Microsoft comme étant les alternatives préemptives à Windows 3.1: Windows 95 et Windows NT 3.5. Bénéficiant d’un accord de partenariat et étant abonné au Microsoft Developer Network, nous avons réussi à obtenir une version beta de Windows 95 qui, rappelons-le, ne sortira pas avant le second semestre 95. Après une longue étude des différences de performances aussi bien éprouvées par la pratique que par la consultation de la documentation accompagnant leur SDK respectif, j’ai donné ma préférence pour Windows NT 3.5. Ce système de par son architecture interne constitue une solide base de scheduling contrairement à Windows 95 qui, de par ses objectifs de système destinés essentiellement à la Bureautique, reste assez peu fiable.
