FR2699702A1 - Systèmes de commande de micro-ordinateurs pour des communications interprogrammes et des méthodes de planification. - Google Patents

Abstract

L'invention concerne un micro-ordinateur du type compatible IBM utilisant un système d'exploitation MSDOS. Il comporte un système qui offre la possibilité à une pluralité de programmes d'application d'échanger des informations entre eux et avec un programme KERNEL, le programme KERNEL pouvant lancer des applications en fonction du contenu de ses tampons de messages, ce qui améliore l'environnement MSDOS sans engendrer les conflits habituellement observés dans le cas des systèmes de communication interprogrammes.

Description

i

La présente invention concerne des micro-ordinateurs et plus précisément, des systèmes de commande de micro-ordina-

teurs qui confèrent à des programmes d'application la capacité de communiquer les uns avec les autres, de se5 commander les uns les autres et de partager les systèmes de communication par l'intermédiaire d'un pilote commun tout en fournissant une interface uniforme à l'utilisateur. Les ordinateurs personnels à base de microprocesseurs de la famille Intel 8 x 86, également connus sous le nom d'IBM

PC ou de PC compatibles IBM, constituent la norme prédomi-

nante dans le domaine des calculateurs personnels La popularité durable de cette norme est principalement due au coût relativement bas du matériel associé à la disponibilité d'un grand nombre de logiciels d'application écrits pour fonctionner avec un Système d'Exploitation à Disques (DOS) connu sous le nom de MSDOS, qui est vendu par la Société Microsoft Corporation Le système MSDOS, comme tous les systèmes d'exploitation, offre un environnement prédéterminé pour la mise en oeuvre de programmes d'application Bien que le terme MSDOS désigne littéralement le logiciel vendu par la Microsoft Corporation, on considère souvent qu'il incorpore le système d'entrées/sorties de base (Basic Input-Output System, BIOS) contenu dans la mémoire morte présente dans tous les Pc compatibles IBM Dans ce qui suit, le terme MSDOS

sera utilisé pour désigner le système d'exploitation classi-

que, incluant le BIOS, d'un ordinateur personnel compatible IBM se conformant d'une manière générale au protocole MSDOS (version 3 0 ou ultérieure) Les spécialistes de ce domaine connaissent la structure et le mode de fonctionnement du MSDOS, mais pour d'autres informations générales, on se

référera à la description détaillée du système MSDOS fournie

dans la Publication intitulée "Advanded MSDOS" par Raymond

Duncan, Microsoft Press, Copyright 1988.

BRÈVE INITIATION AU MSDOS

Le MSDOS est constitué d'un ensemble de program-

mes qui fournissent ensemble une interface d'exploitation au moyen de laquelle un utilisateur peut interroger et commander le fonctionnement du PC Au démarrage du MSDOS, celui-ci exécute tout d'abord un processus d'initialisation, puis appelle 1 'interpréteur de commandes (COMMAND COM) Ce5 programme accepte, et agit sur, des commandes fournies par l'utilisateur par l'intermédiaire du clavier A ce niveau, les commandes sont en fait des noms de fichiers qui contien- nent un programme exécutable correspondant C'est ainsi que, si l'utilisateur entre la commande "DIR", le programme10 interpréteur de commandes recherche le fichier "DIR COM'", charge le programme DIR en mémoire s'il n'y réside pas déjà, et passe la main au programme "DI Rectory" Le programme DIR est exécuté et fait en sorte que le contenu du répertoire courant soit imprimé sur le dispositif d'affichage de l'utilisateur Le programme DIR s'achève en repassant la main à l'interpréteur de commandes MSDOS qui reste alors en

attente de la commande suivante de l'utilisateur L'utilisa-

teur peut ainsi évoquer l'exécution de toute commande MSDOS ou de tout programme d'application en fournissant le nom du programme Le programme ainsi appelé peut lui-même appeler des routines de gestion du DOS de bas niveau pour communiquer

avec les diverses ressources d'Entrées/Sorties.

La description qui précède couvre assez bien l'étendue

relativement primitive du système MSDOS lorsqu'il a été introduit la première fois sur 1 'IBM PC Modèle XT La mémoire

et les ressources de calcul limitées du modèle XT interdi-

saient un grand nombre de possibilités des gros ordinateurs connus et des systèmes d'exploitation de mini-ordinateurs tels qu'UNIX Alors qu'UNIX fournissait un environnement multi-utilisateur, multitâche très puissant, MSDOS était limité à un seul utilisateur, n'exécutait qu'une seule tâche avec au maximum 600 ko de mémoire vive Plus précisément, MSDOS offre aux programmes d'application un accès illimité à des dispositifs d'entrées-sorties tels que des ports de

communications asynchrones Les limitations mentionnées ci-

dessus sont intrinsèques au système MSDOS et ne peuvent être directement résolues à l'intérieur du système MSDOS sans en compromettre la compatibilité Bien que des exemples probants de communication interprogramme et de planification dynamique des tâches soient bien connus dans d'autres systèmes d'ex-5 ploitation, cette possibilité souhaitable n'était donc pas disponible sur les ordinateurs personnels utilisant le système MSDOS. Bien que MSDOS soit facilement extensible, par exemple par incorporation de nouveaux programmes de commande qui ajoutent de nouvelles caractéristiques ou des caractéristi- ques modifiées au système d'exploitation, les techniques de l'art antérieur ne conduisent pas à un environnement d'ex- ploitation dans lequel un certain nombre de programmes d'application distincts peuvent être appelés par une seule15 commande de l'utilisateur pour accomplir de façon efficace et en coopération une tâche complexe Bien que des exemples d'une telle possibilité abondent dans d'autres systèmes d'exploitation plus puissants, la méthode généralement utilisée dans le cas de MSDOS consiste à écrire un programme monolithique unique correspondant à la complexité de la tâche On pense que cela résulte du fait que les solutions apportées par l'art antérieur aux problèmes de la communica- tion interprogramme et à la planification dynamique sous MSDOS étaient soit incomplètes, soit trop complexes Le25 problème sous-jacent est que pour qu'un programme de commande accomplisse efficacement des tâches de communication et de planification, il doit résider en mémoire vive, o il entre en conflit avec les programmes d'application pour se partager les faibles ressources de la mémoire Ce conflit persiste même lorsque la vitesse et la capacité des mémoires vives des

ordinateurs PC augmente.

Pour mieux comprendre l'impact de la méthode de commande de la présente invention sur l'environnement DOS, on pense qu'il est utile de décrire certaines des limitations imposées par le DOS aux logiciels qu'il contrôle Dans toute

cette description, l'intérêt présenté par l'environnement du

programme de commande de la présente invention ressortira plus clairement. Le système d'exploitation appelé DOS a été écrit à l'origine pour fonctionner dans un environnement matériel assuré par le microprocesseur INTEL 8088 Dans cet environne- ment, on disposait au maximum de 1 Mo de mémoire vive adressable Celle-ci était divisée en deux régions par le DOS L'espace mémoire inférieur comprend 640 ko de mémoire de programme C'est dans cette zone que les programmes sont10 chargés et s'exécutent La limitation que cela impose est que, si un programme exige une mémoire supérieure à cette quantité, il ne dispose pas de mémoire supplémentaire dans laquelle il peut s'étendre De plus, il est à noter que l'espace de 640 ko doit être occupé par le programme DOS en laissant l'espace restant pour les applications, les pilotes de périphériques et d'autres logiciels systèmes Cela peut conduire au fait que l'on ne dispose pas de suffisamment

d'espace mémoire pour exécuter l'application.

L'espace mémoire supérieur est constitué des 384 ko restants, qui sont utilisés pour les microprogrammes résidant

sur toutes les cartes pour PC installées dans les emplace-

ments pour cartes d'extension La RAM vidéo est également adressée dans cet espace Cet espace n'a jamais eu pour but

d'être utilisé pour les programmes d'application.

Une amélioration ultérieure a permis de disposer de davantage de mémoire par utilisation d'une mémoire dite mémoire d'extension Cette méthode place un tampon de 64 ko dans l'espace supérieur de 384 ko La mémoire éventuellement présente dans l'ordinateur au-delà de l'espace de 1 Moctet initial est transférée dans ce tampon par utilisation de registres internes Cette mémoire est utilisable pour les données des programmes, mais ne résout toujours pas les limitations imposées à la mémoire servant au code exécutable

de l'application.

Lors de l'introduction des processeurs 80286 et des processeurs plus récents, une autre méthode de topographie de la mémoire a été introduite Celle-ci utilise les nouvelles

possibilités d'adressage de la mémoire de ces nouveaux processeurs (jusqu'à 16 Moctets) en tant que mémoire étendue. Ici encore, la mémoire est utilisable pour le stockage des5 données des programmes, mais non pas pour celui des program- mes eux-mêmes.

Avec ces nouvelles méthodes de topographie de la mémoire, on est toujours limité à l'espace programme de 640 ko Par conséquent, les additions apportées aux logiciels du10 niveau système doivent occuper aussi peu de mémoire que possible De plus, avec les processeurs les plus récents ( 80286 et ultérieurs), il est possible de déplacer certains pilotes de périphériques et d'autres programmes systèmes dans la région supérieure de 384 ko On notera cependant que ces logiciels doivent être relogeables de façon à fonctionner convenablement indépendamment de l'endroit o ils sont placés

en mémoire.

Une caractéristique puissante de l'environnement DOS

est le concept de programme résidant après exécution (Termi-

nate and Stay Resident, TSR) Il s'agit d'un programme qui,

lorsqu'il est lancé, s'initialise (en se rattachant générale-

ment à une interruption) et renvoie le contrôle au DOS A partir de ce stade, lorsque son interruption est générée, le TSR se "réveille" et exécute la fonction requise Un exemple courant de ce type de programme est le logiciel populaire Sidekick fourni par la Société Borland Corporation Ce

logiciel se rattache à l'interruption du clavier du PC.

Chaque fois qu'une touche est enfoncée, le programme "se

réveille" et propose une multitude de fonctions à l'utilisa-

teur, telles qu'un calendrier, un bloc-notes, etc Si la touche enfoncée n'est pas une "touche sensible" de Sidekic, celui-ci transmet simplement la touche enfoncée au DOS en vue

de son traitement ultérieur.

Le DOS fournit un mécanisme de fichier de commandes au moyen duquel un utilisateur peut créer un fichier ASCII contenant des lignes de commandes DOS quelconques Les programmes d'application, les commandes DOS et toute autre action pouvant être lancée à partir de la ligne de commande DOS peuvent également être lancés à partir d'un fichier de commandes A titre d'exemple, la tâche consistant à mettre 5 directement à zéro les fichiers d'un système DOS, peut être automatisée par création d'un fichier de commandes qui contient la séquence nécessaire de commandes telle qu'elle serait introduite sur la ligne de commande DOS Chaque fois

que ce fichier de commandes est exécuté, la série de comman-

des qu'il contient sera exécutée comme si elles avaient été entrées manuellement sur la ligne de commande DOS En réalité, le logiciel de traitement des fichiers de commandes DOS analyse le fichier de commande et exécute momentanément le COMMAND COM pour exécuter ces commandes Un problème lié

au traitement des fichiers de commande est que l'environne-

ment du programme père (dans ce cas, le processeur des fichiers de commandes) n'est pas transféré au processus fils (c'est-à-dire à l'action générée par l'entrée se trouvant dans le fichier de commandes) C'est pourquoi les fichiers de commandes ne peuvent pas se comporter de façon adéquate et d'une manière aussi intègre que le permet l'environnement du programme de commande de la présente invention En outre, comme les lignes de commande sont codées de façon fixe dans le fichier de commandes, elles ne peuvent être modifiées dynamiquement en réponse à des modifications provenant d'ordres extérieurs Les fichiers de commandes peuvent exploiter des codes d'erreurs rudimentaires produits par les programmes lorsque ceux-ci s'achèvent, mais si la ligne de commande permettant de traiter ce code n'est pas déjà présente dans le fichier de commandes, l'erreur ne peut être traitée. Une autre partie du système d'exploitation MSDOS est constituée par les "pilotes de périphériques" Celle-ci permet une indépendance du logiciel d'application vis-à-vis des périphériques L'accès aux périphériques s'effectue par l'intermédiaire du pilote de périphérique, simplement comme pour un fichier On ouvre le périphérique, on le lit, on y

écrit, puis on le ferme lorsqu'il n'est plus nécessaire que l'application accède aux périphériques.

La présente invention a pour but de fournir un micro-

ordinateur comportant un système de commande dont l'effet technique est de fonctionner en coopération avec le système MSDOS pour assurer des communications interprogramme ayant un

temps de réponse garanti permettant à des directives com-

plexes fournies par l'utilisateur d'être exécutées efficace-

ment par une multiplicité de programmes d'application interagissant mutuellement, et a en outre pour but de faire en sorte que cette possibilité puisse être étendue à un

traitement pour lequel le temps est plus déterminant, c'est-

à-dire commandé par les événements ou en temps réel, et pour lequel l'ordinateur personnel à système MSDOS n'était

généralement pas approprié jusqu'à présent.

Un autre but de la présente invention est de fournir un système de commande qui permet une planification dynamique ayant pour effet que les programmes d'application qu'il

commande sont capables de modifier le déroulement de l'exécu-

tion. Un autre but de l'invention est de fournir un degré de contrôle amélioré et une spécificité de l'environnement d'exploitation sous lequel des programmes d'application

subordonnés sont exécutés.

Un autre but de l'invention est de fournir un système de commande qui puisse être étendu facilement, de façon modulaire En d'autres termes, l'environnement du système de commande est une architecture "ouverte" au moyen de laquelle d'autres logiciels (niveau système et/ou application) ont pleinement accès aux éléments essentiels ou à des "points d'accueil" Cela a pour résultat que des améliorations

peuvent être ultérieurement apportées au logiciel en entraî-

nant peu ou pas de modifications du système existant.

La présente invention a également pour but de permettre à des ordinateurs de fonctionner sans entrer en conflit avec le système MSDOS ou tout autre programme d'application

compatible avec le système MSDOS.

L'invention a également pour but d'atteindre les objectifs mentionnés ci-dessus sans introduire de nouvelles limitations au fonctionnement efficace de programmes d'appli- cations subordonnés tout en rendant maximal l'espace de mémoire vive disponible pour ces programmes par utilisation

d'un protocole de commande très compact et efficace.

Un but supplémentaire de l'invention est de fournir un nouvel environnement logiciel dans lequel le logiciel résident, y compris la totalité des tampons, est entièrement écrit en langage assembleur 8086 et ne nécessite qu'une quantité minime d'espace mémoire (par exemple environ 24 koctets de l'espace de 640 koctets) De plus, le logiciel de la présente invention peut être chargé dans l'espace mémoire supérieur de 384 koctets, ce qui réduit encore davantage la

totalité de la mémoire exigée dans l'espace de 640 koctets.

L'invention concerne un micro-ordinateur comportant un moyen de commande qui étend efficacement les capacités du système d'exploitation MSDOS de manière à ce qu'il comprenne les communications interprogramme et la planification dynamique Il se compose de deux programmes, le programme HOLDER et le programme KERNEL, qui sont installés en tant que programmes résidents pendant l'initialisation du système et deviennent donc des extensions du système d'exploitation MSDOS se conformant aux règles du MSDOS qui s'appliquent à de telles extensions La figure 1 est une représentation schématique illustrant la relation entre le moyen de commande et le système d'exploitation MSDOS, et les programmes30 d'exploitation qui s'exécutent sous le système d'exploitation étendu.

Le programme HOLDER est analogue à un bureau de poste.

Il commande les processus de réception, de stockage et de délivrance du "courrier", c'est-à-dire les communications interprogramme Les programmes d'application peuvent appeler le programme HOLDER pour envoyer du courrier, déterminer si du courrier leur a été adressé ou recevoir du courrier Le programme HOLDER contient deux mémoires tampon (soutes à courrier) qui ont des structures identiques et utilisent le même protocole de commande Cependant, elles conduisent à un5 résultat différent Le tampon public constitue la soute à courrier qui sert aux communications interprogrammes Un

programme d'application A peut appeler le programme d'appli- cation HOLDER pour envoyer un message au programme d'applica- tion B Lorsque le programme d'application A s'achève, et si10 le programme d'application B est exécuté ultérieurement, le programme d'application B peut appeler le programme d'appli-

cation HOLDER pour recevoir le message envoyé par le pro- gramme d'application A Le destinataire du message est désigné par les variables indiquant le type de données, qui15 sont constituées par un entier non signé de 16 bits formant l'en-tête de chaque message stocké dans le tampon public,

celui-ci pouvant donc traiter 65536 destinataires distincts.

Pour autant, le programme d'application A n'a aucun moyen de

s'assurer que le programme d'application B a déjà eu l'occa-

sion de recevoir son message Cela ne pose pas de problème si les deux programmes font partie d'un script prédéfini qui

fait en sorte que les deux programmes sont appelés séquen-

tiellement Cependant, il serait souhaitable de permettre au programme d'application A de provoquer l'exécution du programme d'application B, ce qui permettrait d'exécuter une tâche complexe au moyen d'un jeu de programmes d'application

interactifs sans rendre le script illisible Cette possibili-

té, connue sous le nom de planification dynamique, peut être

assurée par la soute à courrier du programme HOLDER, c'est-à-

dire par le tampon privé qui est réservé à un type particu-

lier de courrier.

Le tampon privé contient les procédures d'exécution requises pour accomplir une tâche complexe Un programme d'application peut envoyer un ou plusieurs messages au tampon privé, chaque message identifiant un programme devant être

exécuté pour créer en fait un plan d'ensemble détaillé.

Lorsqu'un programme d'application est appelé pour jouer son rôle dans le plan d'ensemble détaillé, il peut communiquer, par l'intermédiaire du programme HOLDER, pour prendre connaissance du plan d'ensemble dont il fait partie et peut5 également modifier ce plan Ces modifications comprennent l'addition de ce nouveau programme d'application au plan d' ensemble, 1 'élimination de programmes d'application du plan d'ensemble et la modification de l'ordre d'exécution Il peut également déclencher sa propre réexécution ultérieure par

addition de son propre nom de programme au plan d'ensemble.

Bien que les programmes d'application mentionnés ci-

dessus ne fassent pas partie de la présente invention, il est clair qu'ils peuvent être écrits pour se conformer au protocole de communication interprogramme de la présente invention afin d'exploiter cette possibilité Cependant, la

description ci-dessus n'exclut pas la possibilité d'inclure

dans le déroulement de l'exécution du plan d'ensemble détaillé tout programme compatible MSDOS, même s'il n'est pas

écrit dans ce but.

Il doit exister au moins un programme d'application capable d'invoquer le système de commande de la présente

invention En général, cela s'effectue au moyen d'un pro-

gramme à menus répondant aux directives de l'utilisateur, car les commandes fondamentales exécutées par un ordinateur

personnel sont en général réalisées par un opérateur humain.

Les programmes du commerce, tels que le logiciel Windows vendu par la Société Microsoft Corporation et Deskview vendu

par la Quarterdeck Corporation, sont des exemples de program-

mes utilisant des menus et qui présentent un menu de tâches que l'utilisateur peut choisir Les entrées fournies par les utilisateurs sont interprétées par le programme à menus qui déclenche l'exécution du ou des programmes respectif(s) Le terme de "programme à MENU" est utilisé ici pour désigner un programme faisant appel au système de commande de la présente invention en réponse à une entrée quelconque de l'ordinateur,

y compris, bien que cela ne soit pas exclusif, des périphéri-

il ques d'entrée utilisés par les opérateurs, tels que les

claviers et les souris Le programme MENU communique avec le programme de commande en deux étapes En premier lieu, le programme MENU appelle le programme HOLDER pour stocker la5 séquence d'exécution requise dans le tampon privé Dans le cas le plus simple, il s'agirait là du nom d'un seul pro-

gramme d'application à exécuter, mais il pourrait s'agir d'une séquence d'au plus 32 programmes, la limitation étant uniquement imposée par la capacité mémoire du tampon privé.10 Le programme MENU peut également utiliser le tampon public du programme HOLDER pour envoyer des messages à certains programmes d'application qui comprennent la file d'exécution pour modifier leur comportement lorsqu'ils s'exécutent De plus, chaque application a la possibilité de modifier les15 tampons public et privé du programme HOLDER pour modifier dynamiquement le déroulement des actions effectuées après les ordres donnés par l'application Le programme MENU n'est en fait qu'une application parmi d'autres constituant un processus fils déclenché par le programme KERNEL Toute application exploitant l'environnement peut remplir des

fonctions identiques.

On se rappellera du fait que l'interaction avec le programme HOLDER établit simplement un plan d'ensemble détaillé pour l'exécution L'exécution proprement dite est déclenchée lorsque le programme MENU passe le contrôle au programme KERNEL Bien que le programme KERNEL apparaisse comme un autre programme d'application au MSDOS, il semble faire partie du système d'exploitation étendu pour les programmes d'application qu'il commande Le programme KERNEL fonctionne comme un répartiteur Lorsqu'il prend le contrôle, il lit le tampon privé pour déterminer le programme suivant à appeler Chaque fois que le programme KERNEL trouve une entrée dans le tampon privé, il élimine cette entrée et lance le programme correspondant Le programme ainsi lancé est subordonné au programme KERNEL en ce sens que le programme lancé est le fils du programme père "KERNEL" héritant de l'environnement du KERNEL et repassant la main au programme KERNEL lorsqu'il s'achève Lors de la reprise de contrôle, cette action est répétée jusqu'à ce que la file d'exécution se soit achevée, c'est-à-dire lorsque le tampon privé est vide, le contrôle étant alors repassé au programme MENU. Alors que les programmes d'application qui font partie de la file d'exécution peuvent modifier cette file d'exécution, le programme KERNEL est contraint de se conformer à la file d'exécution sans la modifier.10 Il est préférable que l'ensemble du traitement soit déclenché par un premier appel au programme KERNEL qui trouve le tampon privé vide et appelle par conséquent le programme MENU Comme le programme KERNEL est maintenant le "père" du programme MENU, le contrôle est passé au programme KERNEL

chaque fois que le programme MENU se termine normalement.

Lorsque le programme KERNEL a achevé la file d'exécution en répondant à tous ses messages contenus dans le tampon privé, un programme par défaut (en général le programme MENU) est lancé dans l'attente d'un nouvel événement qui mettra de

nouveau en jeu le programme de commande.

En résumé, le programme d'application MENU peut utiliser le système de commande de la présente invention pour faire en sorte qu'une multiplicité d'autres programmes d'application fonctionnent d'une manière prédéterminée bien

que non entièrement décrite dans un fichier de commandes.

Cette possibilité ressortira plus clairement d'une analogie avec une équipe de football Le quart arrière, comme le programme d'application MENU, a pour rôle de transmettre au reste de son équipe (autres programmes d'application) les instructions devant être effectuées pour un jeu donné La mêlée et l'appel effectués sur la ligne de lancé en mêlée permettent au quart arrière de communiquer un plan détaillé dans lequel chaque joueur a un rôle spécifié Certains joueurs reçoivent une instruction particulière, également appelée option de jeu Lorsque le ballon est lancé, chaque

joueur exécute sa partie du plan en y apportant les adapta-

tions nécessaires, en réponse à l'action d'autres joueurs (l'analogie pourrait être développée pour prendre en compte l'équipe adverse qui serait analogue à l'environnement

d'exploitation dynamique de programmes d'application qui5 modifie de façon conditionnelle le comportement des pro- grammes).

L'équipe de football est un modèle parallèle dans

lequel des joueurs communiquent et interagissent simultané-

ment Dans l'environnement MSDOS, seul un programme peut être actif à un instant donné et ce programme ne connaît pas en lui-même les programmes qui le précédent ou le suivent La planification dynamique et la possibilité de communication interprogramme du présent programme de commande permet à un ensemble de programmes d'application d'acquérir cette connaissance et de se comporter comme s'ils fonctionnaient simultanément sans que cela ne consomme le temps système

relativement important associé à une exploitation multitâche.

Cela conduit à un programme très compact qui peut être entièrement résident en mémoire vive permettant d'obtenir de faibles temps de réponse tout en laissant suffisamment

d'espace en mémoire vive pour les programmes d'application.

La mémoire requise tant pour le système de commande que pour le pilote de communications est le suivant: Code HOLDER 4,6 Ko Tampon privé l Tampon public 1 Code KERNEL 7,4 Code du pilote COM 2 Tampon COM 16 4 Ko x 4 ( 2 ports comportant chacun un tampon IN de 4 Ko et un tampon OUT de 4 Ko) Mémoire totale 32 Ko Dans l'environnement du programme de commande de la présente invention, le KERNEL ouvre les deux ports de

communications par l'intermédiaire du pilote de périphérique.

Les pointeurs de fichiers obtenus sont alors placés dans le tampon public HOLDER TSR Une application quelconque accède ensuite aux ports RS-232 par l'intermédiaire des pointeurs de fichiers se trouvant dans le tampon HOLDER TSR L'application a seulement pour fonction de lire et d'écrire sur les ports RS-232 Comme le programme KERNEL est le seul à ouvrir ou fermer les ports, diverses applications sont capables de partager les circuits RS-232 A titre d'exemple, une applica- tion peut commencer un transfert de données et lancer une10 autre application devant se poursuivre Comme les tampons se trouvant dans le pilote de périphériques sont suffisamment

grands pour contenir généralement deux secondes de données à un débit de 19200 bauds, chaque application dispose d'un temps amplement suffisant pour en lancer une autre sans15 perdre de données. Le programme HOLDER de la présente invention est un programme de type

résident après exécution (TSR) Il se rattache à une interruption inutilisée de manière à ne se "réveiller" que lorsque son interruption est produite spécifiquement par une application ou par le programme de commande KERNEL Le fonctionnement de HOLDER est ainsi entièrement transparent pour l'utilisateur En outre, tous les détails techniques concernant le programme de commande sont entièrement transparents pour l'utilisateur En ce qui concerne l'utilisateur, le programme de commande de la présente invention n'est qu'un simple programme à menus parmi d'autres alors qu'il effectue en fait en coulisses un grand

nombre d'opérations diverses.

Le système de commande de la présente invention est entièrement compatible avec MSDOS Il fonctionne avec MSDOS en transférant toutes les commandes non reconnaissables à MSDOS pour que ce dernier les traite, en se servant d'une interruption inutilisée pour résider après exécution et en fournissant des pilotes de périphériques écrits en stricte conformité avec les directives de Microsoft En outre, l'environnement du programme de commande ne cherche pas à reproduire les fonctionnalités du système MSDOS Il tente au contraire d'améliorer MSDOS en assurant les fonctions qui ne sont pas déjà assurées par MSDOS, et cela sans occuper un grand volume de mémoire dans l'espace réservé aux programmes.5 Le code source, écrit en langage Turbo- Assembleur de Borland, est fourni en annexe A. L'invention sera décrite plus en détail ci-après, en référence aux dessins annexés sur lesquels: La figure 1 est un schéma fonctionnel illustrant l'organisation du Système d'Exploitation mettant en oeuvre le programme de commande de la présente invention et ses relations avec le système MSDOS et les programmes d'applica- tion non résidents; les figures 2 (a) et 2 (b), qui composent la figure 2, représentent un organigramme illustrant le programme KERNEL de la présente invention; les figures 3 (a) et 3 (b), qui composent la figure 3, représentent un organigramme illustrant la séquence suivie par un programme d'application particulier conçu pour exploiter les communications interprogrammes permises par le programme de commande de la présente invention; la figure 4 est un organigramme illustrant la séquence d' exécution et les communications interprogrammes permises aux programmes d'application qui exploitent le programme de commande de la présente invention; la figure 5 est un organigramme du programme HOLDER faisant partie de l'ensemble du programme de commande de la présente invention; la figure 6 est un organigramme général représentant l'interprétation de fonctions contenues dans le tampon public et demandées par utilisation d'un identificateur stocké; les figures 7 A-7 E sont des organigrammes plus détaillés illustrant les diverses options disponibles selon les

résultats de l'interprétation des fonctions, par l'intermé-

diaire du tampon public, qui peuvent être envisagées grâce au programme HOLDER; et

la figure 8 est un organigramme illustrant le programme CHRON.

L'initialisation d'un ordinateur PC met en jeu l'ins- tallation de la partie résidente du système MSDOS en mémoire vive Lorsque cette opération est achevée, le programme HOLDER est également installé en tant que programme de type TSR L'adresse de départ du programme HOLDER est stockée à l'adresse 63 h de la table des vecteurs d'interruption Cela permet au programme HOLDER d'être appelé par exécution de10 l'interruption programmable 63 h Le programme KERNEL est

ensuite installé Il ne nécessite pas de vecteur d'interrup-

tion étant donné qu'il est appelé par utilisation d'une procédure MSDOS normale servant à l'appel de programmes d'application Le système de commande est maintenant résident

et prêt à assurer la gestion des commandes et des communica-

tions pour les programmes d'application.

Le programme KERNEL est un programme de supervision qui fonctionne en association avec les programmes MENU et HOLDER pour lancer un programme ou une séquence de programmes, en réponse à un ordre de l'utilisateur, tout en maintenant un contrôle continu de l'environnement d'exploitation Bien qu'il soit possible à un programme d'application de prendre le contrôle de l'environnement d'exploitation, contrairement

au but que se fixe l'invention, le programme KERNEL n'aban-

donne pas le contrôle qu'il exerce Pour faciliter la compréhension de l'invention, on peut considérer que le programme d'application est un "fils" du programme KERNEL "père", "héritant" de l'environnement d'exploitation MSDOS du

père en plus d'extensions éventuelles apportées à l'environ-

nement d'exploitation et placées dans le tampon public La figure 2 représente un schéma fonctionnel du fonctionnement

du programme KERNEL Le programme KERNEL est le seul pro-

gramme à lancer sur la ligne de commande MSDOS Toute application exécutée sous le contrôle du programme de

commande est lancée par le KERNEL en tant que processus fils.

Celui-ci inclut le programme MENU Le programme HOLDER, en tant que programme résident après exécution, est généralement exécuté au démarrage du système à partir du fichier AUTO EXEC BAT, bien qu'il puisse être lancé à partir de la ligne de commande du DOS Le programme HOLDER doit être5 installé avant que le programme de la présente invention ne soit lancé Le programme KERNEL commence au point d'entrée , après avoir été appelé par le programme MENU ou avoir été directement lancé au niveau des commandes MSDOS A l'étape 12, l'état du système est testé pour déterminer si c'est la première fois que le programme a été appelé Dans l'affirma- tive, l'étape 14 est exécutée Pour ouvrir le pilote de

périphériques de communications, le programme de la Demande- resse émet simplement une requête "D'OUVERTURE DE FICHIER" destinée au système DOS qui renvoie un pointeur de fichier15 que le programme KERNEL stocke ensuite dans le tampon public HOLDER Cela est effectué pour chaque port de communication.

Ce pilote fonctionne d'une manière très semblable aux pilotes MSDOS CO Ml et COM 2 pour établir les paramètres de communica- tion essentiels Le MSDOS renvoie le pointeur de fichier20 pour chaque port trouvé dans l'ordinateur hôte Un pointeur de fichier est un entier à 16 bits qui associe un nom au fichier ou au port de communication Il est fourni par le système MSDOS lorsqu'une requête est émise pour ouvrir un

fichier ou un port de communication et les requêtes ultérieu-

res fournies au système MSDOS pour le traitement d'un fichier doivent inclure le pointeur de fichier Comme indiqué au bloc 14, le programme KERNEL stocke chaque pointeur de fichier en même temps qu'un identificateur spécifié de façon unique dans le tampon public associé au programme HOLDER Comme les pointeurs de fichiers de communication restent constants et accessibles à tous les programmes d'application lancés par le programme KERNEL, plusieurs applications sont alors capables d'utiliser un pointeur de fichier commun pour partager ainsi un port de communication considéré Cela illustre les

possibilités générales de la présente invention qui permet-

tent au système d'exploitation de reprendre le contrôle dans les cas o le MSDOS a cédé une trop grande partie du contrôle qu'il exerce et qui permettent de disposer d'un environnement d'exploitation global plus puissant pour les programmes d'application.5 Si le programme KERNEL a déjà été appelé, la ramifica- tion 13 est choisie et l'exécution passe à l'opération représentée par le bloc 20 Si le programme KERNEL a été appelé depuis le niveau des commandes MSDOS et qu'un nouveau nom de programme d'application par défaut a été entré en tant10 qu'option donnée sur la ligne de commande, cette situation est détectée par le bloc de décision 16 et le bloc 18 a pour fonction d'enregistrer le nouveau nom de programme et de l'écrire à la place du nom de programme d'application par défaut du programme MENU Si la condition précitée ne s'est pas produite, la ramification 13 est choisie et l'exécution passe directement à l'opération exécutée par le bloc 20 Dans ce bloc, le programme HOLDER est appelé par l'intermédiaire de l'interruption 63 h, avec un code de requête permettant d'obtenir des données du tampon privé Le programme HOLDER renvoie l'identité de l'éventuel programme ou de l'éventuelle commande suivante devant être exécutée en même temps que l'identificateur associé On rappellera le fait que les

identificateurs sont prédéfinis pour fournir une classifica-

tion du type d'action à exécuter Si aucune action n'est renvoyée, le contrôle passe au bloc 24 en déclenchant le lancement du programme d'application par défaut Le programme MENU est lancé sauf si le nom par défaut a été modifié du

fait de l'exécution de l'opération désignée par le bloc 18.

Si un ordre d'action est renvoyé, un test est effectué au bloc 26 pour déterminer si la valeur de l'identificateur associé à l'action déterminée par l'opération effectuée au bloc 20 correspond à une action effectuée S'il indique que

l'action est le nom d'un programme d'application, l'opéra-

tion du bloc 28 déclenche ce programme d'application en tant que processus "fils" par l'intermédiaire d'un appel MSDOS Si l'identificateur a une valeur de 2 et si l'action est reconnue comme étant l'une des commandes internes du KERNEL contenues dans le Tableau 1, l'étape 34 exécute alors la

commande interne et reboucle vers l'opération du bloc 20.

Dans le cas contraire, la commande est présumée être une commande MSDOS et est transférée au système MSDOS en vue de

son exécution.

TABLEAU 1

Commandes Internes du Programme KERNEL Commande Signification home Retour au répertoire de départ du programme de commande reset Effacer tous les tampons TSR du programme HOLDER help Imprimer la liste des commandes shell Passer dans le mode d'exécution du programme de commande

dos Passer du mode de program-

me de commande à l'environ-

nement MSDOS exit Sortir du mode d'exécution du programme de commande et revenir au programme fils (ou si le programme fils produit la commande, quitter le KERNEL et

revenir au MSDOS).

L'organigramme de la figure 3 illustre la séquence de

programme effectuée à l'intérieur d'un programme d'applica-

tion quelconque conçu pour exploiter les communications interprogrammes et les possibilités d'interaction offertes par la présente invention Le point d'entrée 50 est le début d'un programme quelconque de ce type lancé par des opérations effectuées par l'un quelconque des blocs 24 ou 28 de la figure 2 Les étapes 52 et 54 appellent le programme HOLDER par l'intermédiaire de l'interruption 63 h, au moyen d'un code de requête pour obtenir du tampon public des données placées dans celui-ci par un autre programme d'application Comme indiqué par le bloc 58, l'application effectue la fonction5 qui lui est assignée et, au bloc 60, un test est effectué pour déterminer si le programme d'application en cours doit demander l'exécution d'un autre programme d'application qui lui est lié Dans l'affirmative, l'étape 64 indique que le nom du programme d'application à exécuter, en même temps que10 son identificateur, est placé dans le tampon privé, par l'intermédiaire de l'interruption 63 h, en utilisant comme

code de requête le code "fournir données" De même, l'exécu-

tion des opérations et des tests représentés par les blocs 66, 68 et 72 de la figure 3 offrent l'option de placer des données dans le tampon public de façon qu'elles soient disponibles pour d'autres programmes d'application Le bloc 74 indique qu'une fin normale du programme est exécutée par appel de l'une quelconque des fonctions MSDOS réservées à cette action en déclenchant de nouveau le programme KERNEL au point A (bloc 10, figure 2) En résumé, l'exécution des opérations représentées par les opérations 52 et 54 fournit

des données d'entrée provenant d'autres programmes d'applica-

tion alors que les opérations 60 et 64 assurent une planifi-

cation dynamique et que les étapes 66, 68 et 72 fournissent des données de sortie à d'autres programmes d'application En variante, le programme KERNEL peut lancer une application qui n'est pas informée de la présence des programmes KERNEL ou HOLDER Dans ce cas, seules les opérations des blocs 58 et 74

sont exécutées.

L'exemple suivant, représenté dans la figure 4, illustre la versatilité autorisée par ces programmes Les lignes en tirets gras représentent la file d'exécution du programme alors que les lignes pleines et fines indiquent les

communications vers et en provenance des tampons respectifs.

Le programme KERNEL est tout d'abord appelé à partir du niveau des commandes MSDOS Comme tous les tampons HOLDER sont initialement vides, le programme d'application par défaut MENU est lancé L'utilisateur sélectionne une option du MENU devant être exécutée, celle-ci exigeant qu'un programme A recueille des données en provenance d'un emplace-5 ment spécifié par l'utilisateur, que des programmes B, C ou D traitent conditionnellement les données et qu'un programme E dissémine les données à la fin des programmes concernés Le programme MENU utilise l'identificateur de programme A pour transmettre un message au programme A, par l'intermédiaire du10 tampon public, qui informe le programme A de l'endroit o se trouvent les données de source Le programme MENU stocke également une action dans le tampon privé, en indiquant au programme A d'être lancé Le programme MENU s'achève en repassant la main au programme KERNEL qui, lorsqu'il trouve15 l'ordre d'action fourni par le programme MENU, déclenche le programme d'application A Le programme A reçoit le message du programme MENU, recueille la donnée et détermine que la donnée reçue nécessite un traitement par les programmes B et D, et non par le programme C, en faisant en sorte qu'il place des ordres d'actions dans le tampon privé et en indiquant au KERNEL de lancer les programmes B, D et E, dans cet ordre Le programme A envoie ensuite des messages aux programmes B et D en leur indiquant o trouver leurs données respectives puis se termine, en repassant la main au programme KERNEL De la même manière, les programmes B, D et E sont lancés, chaque

programme transférant si nécessaire des messages par l'inter-

médiaire du tampon public D'autres programmes d'application non représentés, peuvent être ajoutés de façon dynamique au plan pour permettre la gestion des exceptions, telles que

l'affichage des erreurs ou la récupération après erreur.

Lorsque le programme E se termine, le programme KERNEL, ne trouvant plus d'ordre d'action dans le tampon privé, lance de nouveau le programme MENU, et repasse la main à l'utilisateur

pour qu'il puisse effectuer d'autres choix par menus.

Les communications entre le programme d'application et le programme HOLDER, indiquées par les blocs 54 et 72 de la figure 3, utilisent la procédure d'appel de fonctions normales du MSDOS Divers registres de l'unité centrale sont chargés de données par l'application, selon la fonction

devant être exécutée L'application exécute ensuite l'inter-

ruption programmée 63 h pour appeler le programme HOLDER Le programme HOLDER effectue la fonction demandée en chargeant dans divers registres de l'unité centrale les informations

requises puis repasse le contrôle au programme d'application.

Un ensemble commun de fonctions, qui ne diffèrent que par la valeur particulière du code de requête, assure des services tant pour le tampon public que le tampon privé Il s'agit notamment de: getblock:

Obtient une donnée selon l'identificateur spéci-

fié.

getnext: Obtient la donnée suivante selon le dernier

identificateur spécifié.

putblock: Place une donnée et son identificateur dans un

emplacement de HOLDER.

clearblock: Efface le bloc de données obtenu en dernier Les

requêtes de lecture de données sont non destruc-

tives de sorte qu'un nombre quelconque de pro-

grammes peuvent si nécessaire y avoir accès.

status:

Obtient l'état de la dernière opération.

signature: (fournie dans un sous-programme de démarrage)

Détermine la signature du programme HOLDER EXE.

Cet appel est utilisé pour établir à la fois l'existence du programme TSR HOLDER EXE et son numéro de version Cet appel peut être fait par

le programme KERNEL central, lors du démarrage.

Une description détaillée de ces fonctions est fournie

ci-après:

FONCTIONS DU TAMPON PUBLIC:

__________________________

Fonction 1: obtenir les données stockées dans le tampon du programme HOLDER Registres à initialiser pour cet appel:

AH = 1

CX = nombre d'octets à extraire DL = code identificateur (O = sans type) ES:DI = adresse de destination On notera que la destination doit être suffisamment

grande pour contenir toutes les données demandées.

Configuration des registres au retour: CX = nombre d'octets effectivement transférés On notera que si CX = O, le tampon était vide et

qu'aucune donnée n'a été transférée.

Avant d'appeler cette fonction, il est prudent d'obte-

nir l'état courant du programme HOLDER pour s'assurer que la

donnée stockée est destinée au programme courant.

Fonction 2: placer des données dans le tampon du programme

HOLDER

Registres à initialiser pour cet appel:

AH = 2

CX = nombre d'octets à stocker DL = code identificateur (O = sans type) DS:SI = adresse source On notera que la valeur de CX doit être ≤ la taille du

tampon Si CX = 0, le tampon est effacé.

Configuration des registres au retour:

CX = nombre d'octets effectivement stockés.

La plupart du temps, la meilleure façon de stocker une donnée dans le tampon sera d'utiliser une structure C formelle Du point de vue du programme HOLDER, toute donnée envoyée n'est autre qu'un bloc d'octets que le programme HOLDER ne cherche pas à comprendre Le code identificateur doit être utilisé pour indiquer à un autre programme si la donnée stockée est intéressante ou non. Fonction 3: effacement du tampon interne du programme HOLDER5 Registres à initialiser pour cet appel:

AH = 3

Configuration des registres au retour: Aucun registre n'est configuré au retour Cet appel doit être effectué lorsque le programme

* appelant cherche à stocker une nouvelle donnée ou ne souhaite pas qu'un autre programme ait accès à la donnée stockée.

Fonction 4: obtention de l'état courant du programme HOLDER Registres à initialiser pour cet appel:15 AH = 4 On notera que ce sous- programme est réentrant et peut

être appelé de façon récursive.

Configuration des registres au retour: BX = taille du tampon interne (en octets) CX = nombre d'octets stockés à cet instant dans le tampon interne

DH = code d'erreur résultant de l'opération précé-

dente DL = code identificateur de la donnée stockée dans le tampon Cet appel doit être effectué après chaque opération pour s'assurer que l'opération demandée s'est exécutée normalement. Fonction 5: obtention du bloc suivant de données avant le même identificateur Registres à initialiser pour cet appel:

AH = 5

CX = nombre d'octets à extraire ES:DI = adresse de destination On notera que la destination doit être suffisamment

grande pour pouvoir contenir toutes les données demandées.

Configuration des registres au retour: CX = nombre d'octets effectivement transférés On notera que si CX = 0, le tampon était vide et qu'aucune donnée n'a été transférée. Fonction 100: obtention de la version et de la signature du programme HOLDER Registres à initialiser pour cet appel:

AH = 5

On notera que ce sous-programme est réentrant et peut

être appelé de façon récursive.

Configuration des registres au retour: CX = signature du programme TSR ( 6996) DH = numéro de version majeur du programme TSR DL = numéro de version mineur du TSR Exemple: version 1 2 DH = 1 et DL = 2 Cette opération doit être effectuée pour s'assurer que le code contenu dans le vecteur du programme HOLDER est bien

celui du programme HOLDER.

FONCTIONS DU TAMPON PRIVÉ:

_________________________

Fonction 101: obtention des données stockées dans le tampon du programme HOLDER Registres à initialiser pour cet appel:

AH = 101

CX = nombre d'octets à extraire ES:DI = adresse de destination, On notera que la destination doit être suffisamment

grande pour contenir toutes les données demandées.

Configuration des registres au retour: CX = nombre d'octets effectivement transférés On notera que si CX = 0, le tampon était vide et

qu'aucune donnée n'a été transférée.

Avant d'appeler cette fonction, il est prudent d'obte- nir l'état courant du programme HOLDER pour s'assurer que la

donnée stockée est destinée au programme courant.

Fonction 102: placer une donnée dans le tampon du programme HOLDER Registres à initialiser pour cet appel: AH = 102 CX = nombre d'octets à stocker DL = code identificateur (O = sans type) DS:SI = adresse de source On notera que la valeur contenue dans CX doit être

≤ la taille du tampon Si CX = 0, le tampon est effacé.

Configuration des registres au retour: CX = nombre d'octets effectivement stockés La plupart du temps, la meilleure façon de stocker des données dans le tampon consistera à utiliser une structure C formelle Du point de vue du programme HOLDER, toute donnée envoyée n'est autre qu'un bloc d'octets que le programme HOLDER ne cherche pas à comprendre Le code identificateur doit être utilisé pour indiquer à un autre programme si la

donnée stockée est intéressante ou non.

Fonction 103: effacer le tampon interne du programme HOLDER Registres à initialiser pour cet appel:

AH = 103

Configuration des registres au retour: Aucun registre n'est configuré au retour Cet appel doit être effectué lorsque le programme appelant cherche à stocker de nouvelles données ou ne souhaite pas qu'un autre programme ait accès aux données stockées. Fonction 104: obtention de l'état courant du programme HOLDER Registres à initialiser pour cet appel:

AH = 104

On notera que ce sous-programme est réentrant et peut

être appelé de façon récursive.

Configuration des registres au retour: BX = taille du tampon interne (en octets) CX = nombre d'octets actuellement stockés dans le tampon interne

DH = code d'erreur résultant de l'opération précé-

dente DL = code identificateur de la donnée stockée dans b tampon Cet appel doit être effectué après chaque opération pour s'assurer que l'opération demandée s'est exécutée -normalement. Fonction 105: obtention du bloc suivant de données avant le même identificateur Registres à initialiser pour cet appel:

AH = 105

CX = nombre d'octets à extraire ES:DI = adresse de destination On notera que la destination doit être suffisamment

grande pour pouvoir contenir toutes les données demandées.

Configuration des registres au retour: CX = nombre d'octets effectivement transférés On notera que si CX = 0, le tampon était vide et

qu'aucune donnée n'a été transférée.

Les erreurs suivantes peuvent être fournies lorsque l'état est renvoyé: 1 appel de fonction HOLDER invalide

2 pas de place dans le tampon pour d'au-

tres données 3 HOLDER occupé 201 erreur d'interruption système 202 l'identificateur demandé n'a pas été

trouvé.

La figure 5 représente un organigramme du programme HOLDER Le programme KERNEL ou un programme d'application peuvent l'un ou l'autre appeler le programme HOLDER par exécution de l'interruption programmée 63 h Au bloc 102, un5 test est effectué sur le registre AH pour déterminer l'action demandée par le programme appelant Si le code de la requête correspond à l'une des fonctions publiques déterminées par le bloc de décision 104, les opérations représentées par les blocs 106 et 108 sont alors exécutées Si le code de la requête correspond à l'une des fonctions privées déterminées par le bloc de décision 110, les opérations demandées par les

blocs 112 et 114 sont exécutées On se rappellera que les fonctions publiques, c'est-à-dire les opérations effectuées sur le tampon public, permettent des communications interpro-15 grammes alors que les fonctions privées gèrent la planifica-

tion dynamique Si le test effectué au bloc 116 détermine que le code de la requête est égal à 100, l'opération du bloc 118 est exécutée pour extraire la signature et la version du programme HOLDER Si le code de la requête est invalide, l'opération du bloc 120 est exécutée pour stocker un état de requête invalide Chaque trajet suivi par le programme a pour effet que l'information demandée par le programme appelant est chargée dans les registres de l'unité centrale spécifiés par la fonction de la commande HOLDER Le programme HOLDER se

termine par exécution d'un retour de l'instruction d'inter-

ruption au bloc 122 en rendant ainsi le contrôle au programme appelant. Plusieurs caractéristiques ont été intégrées au

programme HOLDER pour le rendre compact, efficace et versati-

le Pour chaque tampon, c'est-à-dire le tampon privé d'un kilo-octet et le tampon public d'un kilo-octet, une table d'emplacements est maintenue et contient l'identificateur et la taille de bloc de chaque emplacement La table des emplacements contient l'adresse du tampon correspondant à la fin des données plus un pour un emplacement donné Pour chaque table d'emplacements, le programme HOLDER maintient deux indices: l'indice de l'emplacement courant et l'indice de l'emplacement suivant La table des emplacements et ses indices sont initialisés de la manière suivante:

EMPLACEMENT 0 1 2 3 31

O 1024 1024 1024 1024

EMPLACEMENT COURANT = O EMPLACEMENT SUIVANT = O

Si le programme HOLDER reçoit par exemple une commande lui demandant de stocker 20 octets de données à l'emplacement suivant, les données sont introduites dans le tampon aux adresses O 19, l'indice de l'emplacement suivant est incrémenté, et la table des emplacements est mise à jour de la manière suivante:

EMPLACEMENT O 1 2 3 31

0 20 1024 1024 1024

EMPLACEMENT COURANT = O EMPLACEMENT SUIVANT = 1

Si le programme HOLDER reçoit par exemple ensuite une commande lui demandant de stocker 30 octets de données à l'emplacement suivant, ces données sont stockées dans le

tampon à partir de l'adresse 20 après le contenu de l'empla-

cement un de la table des emplacements, comme spécifié par la valeur de l'indice de l'emplacement suivant L'indice de l'emplacement courant et l'indice de l'emplacement suivant sont tous deux incrémentés et l'emplacement est mis à jour de la manière suivante:25 EMPLACEMENT O 1 2 3 31

0 20 50 1024 1024

EMPLACEMENT COURANT = 1 EMPLACEMENT SUIVANT = 2

Si le programme HOLDER reçoit une commande lui deman-

dant d'effacer les données se trouvant à l'emplacement

courant, le contenu de l'emplacement suivant moins l'emplace-

ment courant est placé à l'emplacement courant et les données se trouvant dans le tampon sont déplacées pour traduire cette

modification Ce processus est réitéré pour chaque emplace-

ment suivant jusqu'à ce que le premier emplacement inutilisé soit rencontré, c'est-à-dire jusqu'à ce que le contenu de l'entrée de la tabledes emplacements soit égal à 1024 Ce procédé de gestion du tampon, connu dans la technique sous le nom de "récupération de place", permet d'ajuster en continu les frontières entre emplacements pour s'adapter à la taille des données de messages tout en permettant néanmoins au5 programme HOLDER d'identifier facilement le début et la fin d'un message par utilisation des indices d'emplacements et

des entrées de la table des emplacements. Cela permet l'utilisation de tampons relativement petits capables de jouer le rôle de boîte aux lettres vir-

tuelle de grande dimension Un éventuel emplacement peut utiliser une fraction quelconque d'un espace tampon total d'un kilo-octet et le contenu d'un emplacement quelconque peut soit être la donnée effective, soit être un vecteur qui identifie la position des données ailleurs dans la mémoire15 vive, soit être un pointeur sur un fichier qui identifie la position des données dans la mémoire à disques Il est préférable que l'identificateur soit utilisé pour déterminer par interprétation laquelle de ces conventions doit être appliquée au contenu d'un emplacement donné Le stockage direct des données dans cet emplacement offre la vitesse de réponse la plus élevée alors que le stockage des données sur disque permet d'effectuer des économies de mémoire vive plus intéressantes Par conséquent, chaque utilisateur de la fonction de boîte aux lettres publique, c'est-à-dire chaque

programme d'application, est capable d'équilibrer judicieuse-

ment les besoins en performances en imposant une plus grande charge de travail à l'espace du tampon public commun, ce qui permet de faire en sorte que l'espace tampon total soit relativement petit Les identificateurs constituent une forme d'adresses de boîte aux lettres qui simplifie le programme HOLDER, en le rendant à la fois rapide et compact Le rôle rempli par le programme HOLDER est analogue à celui d'un archiviste qui est capable de stocker et d'extraire des informations par utilisation d'un jeu de règles très limité et simple Le programme HOLDER est également rendu compact par utilisation de l'organisation en tampons et de la stratégie d'utilisation des tampons publics et privés en permettant ainsi le partage de certaines parties du code du programme. Les figures 6 et 7 A à 7 E représentent un organigramme plus détaillé des opérations représentées par les blocs 104

et 106 de la figure 5 Le logiciel représenté par l'organi-

gramme de la figure 6 interprète les fonctions spécifiques demandées en testant la valeur de l'identificateur transféré dans le registre DL puis en bifurquant vers les points d'entrée respectifs représentés par les blocs 142-150 et désignés respectivement Pub A à Pub E Les figures 7 A à 7 E correspondent chacune à l'un de ces points d'entrée Si une demande effectuée pour obtenir des données du tampon public A a été reçue, l'opération représentée par le bloc 160 (figure 7 A) est exécutée et analyse séquentiellement la table des emplacements publics pour trouver la première occurrence éventuelle d'un identificateur correspondant Si cette recherche échoue, le contrôle passe au bloc 164 pour stocker

cet état d'erreur Si l'identificateur est trouvé, l'opéra-

tion du bloc 166 est exécutée et accède à la table des

emplacements pour trouver la position de la donnée d'emplace-

ment dans le tampon public La donnée d'emplacement est ensuite transférée de sa position d'emplacement dans le tampon public à la position de destination spécifiée par le programme appelant, par l'intermédiaire des registres ES et DI Lorsque l'opération du bloc 168 est exécutée, elle stocke l'état d'un transfert de donnée réussi Si une demande pour stocker une donnée dans le tampon public a été reçue, l'opération 180 est exécutée (figure 7 B) et compare l'espace libre restant dans le tampon public au contenu du registre CX qui contient le nombre d'octets devant être stockés S'il reste suffisamment de place pour satisfaire à cette demande, l'étape 182 est exécutée et ajoute une nouvelle entrée à la table des emplacements, laquelle entrée est constituée de

l'identificateur et de la taille de l'emplacement, c'est-à-

dire du nombre d'octets devant être stockés Les opérations appelées par les blocs 184 et 186 utilisent les contenus des registres DS et SI pour localiser la source des données à stocker et le contenu de la table des emplacements pour localiser la destination des données dans le tampon public, et effectuer le transfert La table des emplacements et le tampon public contiennent alors les informations requises pour permettre à un autre programme d'application d'extraire

les données stockées par utilisation de la fonction d'obten-

tion des données précédemment décrite L'exécution de l'opération indiquée par le bloc 188 stocke l'état d'un

transfert de données réussi.

La figure 7 C représente les fonctions de "RÉCUPÉRATION DE PLACE" du Programme HOLDER Celles-ci permettent une

exploitation très efficace de petits tampons Une RÉCUPÉRA-

TION DE PLACE se produit lorsque cela est nécessaire sans intervention externe pour empêcher l'augmentation du volume

du tampon Si une demande effectuée pour effacer l'emplace-

ment courant du tampon public a été reçue, l'opération 200 (figure 7 C) est exécutée et copie le contenu de l'emplacement suivant à l'emplacement courant L'opération 202 met à jour la table des emplacements pour faire apparaître la nouvelle position dans le tampon public de la donnée d'emplacement suivante Les opérations effectuées par les blocs 200 et 202 sont ensuite réitérées jusqu'à ce que le test effectué par le bloc de décision 204 détermine que l'emplacement suivant est vide Dans l'affirmative, l'opération 206 efface l'espace tampon inutilisé alors que l'opération 208 conduit au chargement du nouvel état du tampon public dans la table des emplacements A ce stade, le tampon public a été ramené à30 l'état observé immédiatement avant que la donnée a été stockée à l'emplacement courant L'exécution de l'opération indiquée dans le bloc 210 stocke l'état d'une opération

d'effacement réussie.

Si un état de "requête d'obtention" a été reçu, l'opération du bloc 220 (figure 7 D) est exécutée et récupère l'état stocké pendant l'exécution des opérations 168, 188, 210 ou 236 pour le renvoyer au programme d'application Elle renvoie également la taille du tampon public, le nombre d'octets actuellement stockés dans le tampon public et l'identificateur stocké à l'emplacement courant Si une "requête d'obtention de données" du même type, c'est-à-dire ayant le même identificateur, provenant de l'emplacement suivant du tampon public, a été reçue, l'opération du bloc 230 est exécutée (figure 7 E) et provoque une recherche séquentielle dans la table des emplacements publics pour trouver l'éventuelle présence suivante d'un identificateur correspondant Si cette recherche échoue, comme cela peut être déterminé par le test identifié dans le bloc 232, l'opération du bloc 233 est exécutée pour stocker l'état d'erreur Dans le cas contraire, on accède à la table des

emplacements pour trouver la position de la donnée d'emplace- ment dans le tampon public (bloc 234) La donnée d'emplace-

ment est ensuite transférée de sa position d'emplacement dans le tampon public vers la position de destination spécifiée par le programme appelant par l'intermédiaire des registres20 ES et DI L'opération du bloc 236 stocke l'état d'un trans-

fert de données réussi.

Les fonctions du tampon privé correspondent en tous points aux fonctions du tampon public et n'en diffèrent que par le fait que les opérations sont effectuées sur le tampon25 privé Bien qu'il soit possible d'utiliser une organisation moins élaborée du tampon privé, qui satisferait de façon minimale aux exigences du programme KERNEL préféré, cela n'est pas préférable Quelle qu'en soit la simplicité, une gestion différente du tampon privé réduirait les possibilités30 de partage du code du programme HOLDER et par conséquent, en augmenterait la taille Il est en outre avantageux de conserver la souplesse de l'organisation du tampon public pour le tampon privé car elle offre une architecture plus ouverte qui permet au logiciel de la présente invention de conserver une compatibilité ascendante, tout en autorisant

l'adjonction de nouvelles fonctions non encore prévues.

La discussion qui suit porte tant sur un autre mode de réalisation de l'invention que sur une illustration de la souplesse de l'invention lorsqu'il s'agit d'y incorporer de nouvelles fonctionnalités sans modifier le programme de commande fondamental Le programme de type TSR CHRON ajoute la fonctionnalité d'une planification dynamique en ce qui

concerne la valeur de l'horloge temps réel de l'ordinateur.

La fonction du programme CHRON consiste à analyser périodi-

quement le tampon public pour y trouver des messages datés et, à l'instant désigné, pour interpréter ces messages et composer un message exécutable devant être ajouté à la file d'exécution contenue dans le tampon privé Tout programme d'application, y compris le programme MENU, peut placer un message daté dans le tampon public Ce message peut être une directive demandant une seule exécution d'un programme d'application à un instant ultérieur spécifié En variante,

le message peut demander l'exécution d'un programme d'appli-

cation N fois ou un nombre indéfini de fois, à un intervalle spécifié commençant à un instant ultérieur spécifié Les

messages datés sont distingués par la valeur de leur identi-

ficateur La figure 8 représente un organigramme du programme CHRON Le point d'entrée 250 indique que la table de vecteurs d'interruption est modifiée de telle façon que le programme

CHRON intercepte le vecteur d'interruption destiné à l'inter-

ruption de temporisation normale Cela provoque l'appel du programme CHRON, c'est-à-dire qu'il obtient un appel "d'éveil" 18,2 fois par seconde, c'est-à-dire lorsque l'interruption de temporisation normale serait appelée Bien qu'il soit également possible d'exécuter le sous- programme CHRON à des intervalles de 0,05 seconde, cela augmente la charge de traitement, et peut réduire le rendement Au contraire, l'opération représentée par le bloc 254 compte chaque appel d'éveil et ne passe le contrôle au bloc 256 que pour le nième appel d'éveil A titre d'exemple, si N = 1000, le contrôle passe à l'opération du bloc 256 toutes les 50 secondes Pour tous les appels d'éveil intermédiaires, le

contrôle est directement passé au gestionnaire des interrup-

tions de temporisation suivantes Au bloc 256, le programme HOLDER est appelé pour déterminer si l'emplacement suivant contient un message daté Dans la négative, l'opération du5 bloc 260 détermine alors s'il se trouve d'autres messages dans le tampon public en testant la valeur du registre CX.

On se rappellera que le registre aura été renvoyé avec une valeur nulle s'il ne se trouve pas d'autres données à analyser Dans ce cas, le contrôle est transféré au gestion-10 naire des interruptions de temporisation suivantes Dans le cas contraire, le programme reboucle vers le bloc 256 Si un message CHRON est trouvé, la date est testée pour déterminer s'il est alors temps d'exécuter le message Dans la négative, le programme reboucle conditionnellement vers l'opération 256 en passant par le bloc 264, de la manière décrite pour l'opération du bloc 260 Lorsqu'il est déterminé qu'il est maintenant temps d'exécuter un message, le contrôle passe au bloc 266, qui crée un message exécutable pour le programme KERNEL Plus précisément, le nom du programme d'application trouvé dans le message CHRON est ajouté au tampon privé afin

qu'il fasse maintenant partie de la file d'exécution.

Le message d'exécution peut en option contenir diverses formes de données de priorité qui peuvent être extraites du message CHRON Si la donnée de priorité est rendue accessible dans le tampon privé, tout programme d'application, au cours de son exécution, peut périodiquement examiner le tampon privé pour détecter l'instant o le programme CHRON a ajouté

un programme de priorité plus élevée à la file d'exécution.

Cela peut donner l'occasion à un programme de priorité inférieure de se terminer en permettant l'exécution d'un

programme de priorité plus élevée.

Les fonctions du tampon privé correspondent en tous points à celles du tampon public et n'en diffèrent que par le

fait que les opérations sont effectuées sur le tampon privé.

Bien qu'il soit possible d'utiliser une organisation moins élaborée du tampon privé, qui satisferait de façon minimale aux exigences du programme KERNEL préféré, cela n'est pas préférable Quelle qu'en soit la simplicité, une organisation différente du tampon privé réduirait les possibilités de partage du code du programme HOLDER et par conséquent, en5 augmenterait la taille Il est en outre avantageux de conserver la souplesse de l'organisation du tampon public

pour le tampon privé car elle offre une architecture plus ouverte qui permet au logiciel de la présente invention de conserver une compatiblité ascendante, tout en autorisant10 l'adjonction de nouvelles fonctions non encore prévues.

La présente invention a été décrite ci-dessus de façon très détaillée pour satisfaire à la réglementation des

brevets et pour fournir à l'homme de l'art les informations dont il a besoin pou appliquer ces nouveaux principes et pour15 élaborer et utiliser les éléments spécialisés nécessaires.

Cependant, il est clair que l'invention peut être mise en

oeuvre au moyen d'autres équipements et dispositifs particu-

liers différents et que diverses modifications, apportées tant aux détails concernant les équipements qu'aux modes opératoires, peuvent être envisagées tout en restant dans le

cadre de l'invention proprement dite.

Claims (3)

REVENDICATIONS

1 Micro-ordinateur du type compatible IBM

comportant une mémoire vive pour stocker un système d'exploi-

tation à disques de type MSDOS et une horloge temps réel pour générer des interruptions temps réel, ledit micro-ordinateur comportant un moyen de commande pour étendre et améliorer l'environnement d'exploitation des programmes d'application subordonnés, ledit moyen de commande étant caractérisé en ce qu'il comprend: (a) un premier tampon de capacité fixe résidant

dans ladite mémoire vive et stockant des messages interpro-

grammes; (b) un second tampon de capacité fixe résidant

dans ladite mémoire vive et stockant des données représenta-

tives d'une séquence d'exécution spécifiée de façon condi-

tionnelle; (c) un premier moyen commandant le transfert de données vers ledit, et en provenance dudit, premier tampon selon un premier protocole de commande prédéterminé, ledit premier moyen commandant en outre le transfert de données vers ledit, et en provenance dudit, second tampon selon un second protocole de commande prédéterminé; et (d) un second moyen commandant la séquence d'exécution d'un ensemble de programmes d'application subordonnés (fils) en fonction du contenu dudit second tampon, lesdits programmes d'application subordonnés ayant ainsi la possibilité de communiquer par l'intermédiaire dudit premier tampon. 2 Micro-ordinateur selon la revendication 1,

caractérisé en ce que ledit premier protocole de commande prédéterminé est sensiblement identique audit second proto-

cole de commande prédéterminé, ce qui permet de rendre minimal le code définissant ledit premier moyen. 3 Micro-ordinateur selon la revendication 2, caractérisé en ce que lesdits premier et second tampons comprennent chacun un ensemble d'emplacements, chaque emplacement ayant une taille variable permettant de s'adapter à des messages pouvant occuper une fraction quelconque de la capacité totale dudit premier tampon et aux données de la

séquence d'exécution qui peuvent occuper une fraction5 quelconque de la capacité totale dudit second tampon.

4 Micro-ordinateur selon la revendication 3, caractérisé en ce que lesdits messages interprogrammes comprennent un identificateur prédéfini servant à identifier le destinataire d'un message donné.10 5 Micro-ordinateur selon la revendication 1, caractérisé en ce que ledit second moyen commande en outre le fonctionnement des ports de communication série et stocke les pointeurs de fichiers associés auxdits ports de communication dans ledit premier tampon, ce qui permet de faire en sorte

que de multiples programmes d'application subordonnés (fils) peuvent partager un même port de communication série.

6 Micro-ordinateur selon la revendication 1, comportant en outre un troisième moyen sensible auxdites interruptions temps réel et à l'état de ladite horloge temps réel dudit micro-ordinateur pour stocker un message exécuta- ble dans ledit premier tampon tel qu'il est spécifié par un message daté placé dans ledit second tampon par l'un desdits programmes d'application subordonnés. 7 Procédé pour permettre des communications interprogrammes dans un micro-ordinateur de type compatible IBM comportant une mémoire vive pour le stockage d'un système d'exploitation à disques de type MSDOS, caractérisé en ce qu'il comprend les étapes consistant à: (a) prévoir un moyen de commande pour définir un premier et un second tampons, ayant chacun une capacité fixe et résidant dans ladite mémoire vive pour le stockage de messages interprogrammes et de données représentatives d'une séquence d'exécution spécifiée, respectivement; (b) inclure dans ledit moyen de commande un premier moyen pour commander le transfert de données vers ledit, et en provenance dudit, premier tampon selon un

premier protocole prédéterminé, ledit premier moyen comman-

dant en outre le transfert de données vers ledit, et en provenance dudit, second tampon selon un second protocole de commande prédéterminé; et5 (c) inclure dans ledit moyen de commande un second moyen pour commander la séquence d'exécution d'une

pluralité de programmes d'application distincts et subordon-

nés en fonction du contenu dudit second tampon, de telle façon que lesdits programmes d'application subordonnés puissent communiquer par l'intermédiaire dudit premier tampon.