FR 2840082 A1 20031128 FR 0206364 A 20020524 1 2840082 Procede d'echange d'informations entre svstemes d'exploitation cohabitant sur un meme ordinateur La presente invention concerne un procede d'echange d'informations entre des processus, taches, ou applications informatiques executees par des systemes d'exploitation differents cohabitant sur une meme machine informatique ou une meme plate-forma materielle. Dans de nombreux cas, il peut etre utile de faire cohabiter sur un meme ordinateur des applications informatiques provenant de sources ou d'epoques differentes, ou programmees en fonction d'un systeme d'exploitation different. Un systeme d'exploitation peut etre decrit comme une entite logicielle servant d'intermediaire entre des applications informatiques et les ressources materielles qu'elles utilisent. Le systeme d'exploitation est accessible depuis une application par un ensemble d'instructions, parfois appele >, qui fonctionnent selon un ensemble de regles definissant ['usage des ressources d'un ordinateur, les fonctionnalites accessibles a un operateur ou a un langage de programmation, et le mode d'utilisation de ces fonctionnalites. Un tel ordinateur peut etre constitue d'une seule machine independante, ou de plusieurs machines ou parties de machines cooperant ensemble pour constituer une plate-forma materielle globale, par exemple a travers une architecture distribuee regroupant plusieurs processeurs, ou plusieurs ordinateurs travaillant en cooperation et se partageant ou se repartissant entre eux certaines de leurs ressources. Par exemple, au fur et a mesure de ['evolution ou du renouvellement des materiels informatiques utilises pour une application informatique, les normes de fonctionnement des materiels disponibles changent, et en particulier a travers leurs systemes d'exploitation. Ceux-ci peuvent ainsi etre peu ou pas 2 2840082 compatibles entre plusieurs versions differentes, ou d'un modele d'ordinateur a l'autre. Lorsque certaines de ces applications existent et vent utilisees depuis un certain temps, ou par un certain nombre d'utilisateurs ou d'entreprises, il peut etre moins coOteux en temps comme en argent de conserver une application ancienne ou particulierement bien adaptee a un besoin. Certaines applications peuvent egalement n'etre disponibles que sous un certain systeme d'exploitation, alors que les besoins ou les materiels qu'elles gerent existent aupres d'ordinateurs qui utilisent un autre systeme 1 0 d'exploitation. 11 est done utile de pouvoir faire cohabiter une application executee par un certain systeme d'expioitation avec d'autres applications executees par un ou plusieurs autres systemes d'exploitations, et de les faire communiquer pour interagir entre elles lorsqu'elles traitent des donnees ou des objets logiciels 1 5 commune. Pour des besoins de standardisation des applications, de formation du personnel, ou de strategic commerciale, il est egalement utile de pouvoir disposer d'un meme systeme d'exploitation, qualifie de >, sur des machines de types differents. Plutot que de programmer une version specifique de ce systeme d'exploitation pour chacune de ces machines, il est alors connu d'en realiser une seule version qui soit capable d'etre executee par un autre systeme d'exploitation >, qui est lui-meme deja disponible pour ces differentes machines. On dire alors que ce systeme d'exploitation portable s'execute > du systeme d'exploitation de base de la machine. Par exemple, le systeme d'exploitation > de > (marques deposees) peut etre utilise sous la forme d'un environnement logiciel constituent une machine virtuelle, denommee > ou >, fonctionnant elle-meme sur toute machine materielle pourvue du systeme d'exploitation > de Microsoft (marques deposees). Ainsi, les 3 2840082 applications dbveloppees pour un ordinateur utilisant > de la societe Bull, peuvent etre utilisees sur toute machine sur laquelle existe une version de >. Pour eviter tout conflit entre ces differents systemes d'exploitation qui utilisent selon des regles differentes les ressources disponibles, chacun d'eux doit alors utiliser une partie differente de ces ressources, en particulier pour la memoire. La cohabitation de plusieurs programmes heterogenes, ctest a dire utilisant des systemes d'exploitation differents, occupera done au total plus de ressources que s'ils en partageaient une partie, pour les donnees qu'ils ont en 1 0 commun. De plus, les donnees ou objets logiciels devant etre communiques entre un programme et un autre, ou entre deux de leurs processus, doivent etre traites par un protocole de communication compatible avec les deux systemes, comme un echange de fichier. Un tel protocole d'echange de fichier peut etre par exemple par un protocole tel que FTP ( >), ainsi qu'illustre en figure 5. Or, pour etre compatible avec plusieurs systemes d'exploitation differents, de tels protocoles de communication passent par un certain nombre d'etapes intermediaires de complexites croissantes. Ces etapes vent realisees d'abord pour organiser dans un format commun les donnees a envoyees, puis pour decoder ce format et remettre ces donnees dans la forme adequate une fois re,cues. Ces differentes etapes correspondent par exemple aux differentes > teiles que definies par l'OSI. Dans le cas du protocole FTP, ces donnees pourront par exemple etre serialisees, puis codees selon le protocole TCP/IP, puis transmises selon le protocole FTP, avant d'etre decodees et memorisees par le processus destinataire. De telles etapes causent un ralentissement important dans les communications entre deux processus soumis a deux systemes d'exploitation differents, ainsi qu'une complexite source d'erreurs ou de risques, alors que les donnees vent memorisees dans la meme machine ou plate-forma materielle. 4 2840082 Par ailleurs, il est egalement tres important, pour la fiabilite comme pour la securite des applications, que le fonctionnement de l'un des systemes d'exploitation et de ses applications ne risque pas d'interferer dans le fonctionnement de l'autre. L'acces et l'utilisation, par chacun d'eux, des ressources de la plate-forma matbrielle doivent done etre organises d'une fa,con la plus etanche possible entre les deux environnements. Pour diminuer les problemes de maintenance ou de suivi des applications, il est egalement important que les fonctionnalites permettant la cohabitation impliquent le moins possible de modification, aussi bien dans les applications concernbes que dans les differents composants des systemes d'exploitation devant cohabiter et communiquer. Pour eviter de retarder l'un des processus lors d'un transfert de donnees entre deux processus heterogenes, il est egalement utile pour un processus emetteur de pouvoir mettre des donnbes a la disposition d'un autre processus selon une methode asynchrone, c'est a dire sans attendre que le destinataire soit pret ou disponible. La presente invention a done pour objet de pallier des inconvenients de l'art anterieur en proposant un procede permettant une grande rapidite de communication entre des processus clients fonctionnant dans des systemes d'exploitation non directement compatibles. La presente invention a egalement pour objet de pallier des inconvbnients de l'art anterieur en proposant un procede permettant une telle communication de fa,con asynchrone. La prbsente invention a egalement pour objet de pallier des inconvenients de l'a,rt anterieur en proposant un procede permettant d'assure une fiabilite et une securite du fonctionnement d'au moins un des systemes d'exploitation par rapport au comportement de processus clients non connus. La presente invention a egalement pour objet de pallier des inconvenients de l'art antebrieur en proposant un procedb permettant d'ajouter 2840082 un mecanisme de communication dans une architecture heterogene sans effectuer de modifications majeures sur ['ensemble des systemes d'exploitation existent. Ce but est atteint par un procede de communication entre au moins deux processus informatiques, dits processus clients, executes en meme temps dans un systeme informatique, dit plateforma materielle, comprenant un ou plusieurs processeurs et des moyens de memorisation dont au moins une partie constitue une zone de memoire adressable, utilisable comme memoire de travail, ces processus clients etant chacun executes au sein d'au moins deux systemes d'exploitation differents, gerant l'utilisation des ressources du systeme par leurs processus clients et n'etant pas directement compatibles entre eux, caracterise en ce que ces processus clients ecrivent ou lisent ou modifient des informations, cites donnees d'echange, dans au moins une partie commune, cite memoire d'echange, de la memoire adressable de la plate forme materielle. Selon une particularite, au moins un de ces processus clients ecrit ou lit ou modifie des donnees d'echange dans la memoire d'echange en accedant a un ou plusieurs emplacements de cette memoire d'echange par des donnees, ou adresses, representant de maniere constante et non ambigue la position de ces emplacements au sein d'au moins une partie de la memoire adressable de la plate-forma materielle. Selon une particularite, au moins un de ces processus clients effectue au moins une operation d'echange, par ecriture ou lecture ou modification de donnees d'echange dans la memoire d'echange sans tenir compte de lietat ou de la disponibilite de l'autre processus client ou du systeme d'exploitation de cet autre processus client. Selon une particularite, la gestion, realisee par au moins un systeme d'exploitation, de l'utilisation des ressources par un processus client comprend ['emission de donnees de commande, cites primitives, depuis ce meme systeme d'exploitation vers un environnement logiciel proprietaire gerant les 6 2840082 ressources de la plate-forma materielle pour le compte de ce systeme d'exploitation, le procede de communication comportant ['execution, geree dans cet environnement proprietaire, d'au moins un processus, dit moteur d'echange, recevant les demandes d'operations d'echange de la part d'au moins un processus client et gerant la realisation de ces operations d'echange par un processus execute au sein de ce meme environnement proprietaire. Selon une particularite, le processus moteur d'echange re,coit des demandes d'operations d'echange de la part des processus clients et les gere selon un procede comportant une repetition recursive continue des etapes suivantes: - attente, par le moteur d'echange, d'un evenement signale par un processus client, dit processus demandeur et representant une demande d'une operation d'echange; - reception, par le moteur d'echange en provenance du processus demandeur, de donnees (HslOpCell) representant ['operation d'echange demandee; - echange, entre le moteur d'echange et au moins un processus de ce logiciel proprietaire, d'informations representant ['operation d'echange demandee; - attente, par le moteur d'echange, d'un evenement representant la fin de traitement, par le logiciel proprietaire, de lioperation d'echange. Selon une particularite, les donnees d'echange vent structurees en un ou plusieurs objets logiciels, dits objets d'echange, memorises dans la memoire d'echange, ces objets d'echange comprenant un ou plusieurs semaphores dont la structure comporte au moins une donnee (COUNT) representant la valeur courante du semaphore, I'etat de ces semaphores pouvant etre lus ou testes par les processus clients et pouvant etre modifies a travers une ou plusieurs operations d'echange. 7 2840082 Selon une particularite, la modification d'un objet d'echange par un processus client, dit processus demandeur, se fait par une ou plusieurs operations d'echange comportant les etapes suivantes: - envoi, par le processus demandeur, d'au moins une instruction demandant la reservation d'un objet d'echange au seul usage audit processus demandeur; - envoi, par le processus demandeur, d'une ou plusieurs instructions demandant la modification audit objet d'echange; - envoi, par le processus demandeur, d'au moins une instruction demandant la remise a disposition audit objet d'echange a 1'ensemble des autres processus clients. Selon une particularite, le procede comporte au moins un processus gestionnaire interapplications, gere par le logiciel proprietaire, gerant la validite des demandes d'operations d'echange selon un procede comportant les etapes suivantes: - detection, par le processus gestionnaire interapplications, d'un evenement indiquant que les composants mettant en ceuvre le procede de communication vent disponibles; - envoi, par le processus gestionnaire interapplications a au moins un processus client apte a utiliser des donnees d'echange, d'informations indiquant que les composants mettant en oeuvre le procede de communication vent disponibles; - detection, par le processus gestionnaire interapplications, d'un evenement representant la fin de disponibilite des composants mettant en aeuvre le procede de communication; - envoi, par le processus gestionnaire interapplications a au moins un processus client apte a utiliser des donnees d'echange, que les composants mettant en osuvre le procede de communication ne doivent plus etre utilises. 8 2840082 Selon une particularite, au moins un systeme d'exploitation est un environnement logiciel compatible avec le systeme d'exploitation > de >, le systeme informatique comprenant au moins un environnement proprietaire > ou > de >, cet environnement proprietaire fonctionnant soit en tent qu'une machine virtuelle executee par un ou plusieurs systemes informatiques ou soit directement sur une plate-forma materielle adaptee a l'un de ces systemes d'exploitation. Selon une particularite, la machine virtuelle est executee par un systeme d'exploitation compatible avec > de la societe Microsoft. Selon une particularite, au moins un processus client est execute par l'un des systemes d'exploitation >, >, >, >, ou > ou > (marques deposees), ou dans l'une de leurs versions ou variantes. L'invention, avec ses caracteristiques et avantages, ressortira plus clairement a la lecture de la description faite en reference aux dessins annexes dans lesquels: - la figure 1 represente un schema symbolique de fonctionnement de ['invention dans un mode de realisation ou l'un des processus client est execute par un systeme d'exploitation proprietaire, lui-meme execute dans une machine virtuelle, elle-meme fonctionnant dans le systeme d'exploitation de l'autre processus client; - la figure 2 represente un schema de l'organisation des couches logicielles d'une plate-forma mettant en oeuvre ['invention, dans un mode de realisation ou la machine virtuelle est du type Diane utilisant un systeme d'exploitation du type >, et fonctionne dans une plate-forma materielle fonctionnant sous KWindows NT>>; - les figures 3a et 3b representent un organigramme presentant en parallele le fonctionnement: du processus proprietaire de la machine virtuelle, du processus moteur d'echange, et du 9 2840082 gestionnaire d'echange d'applications, respectivement dans les cas d ' activation d u mecan is me d 'echange et de desactivation d u mecanisme d'echange; la figure 4 represente un organigramme presentant en parallele le fonctionnement: d'un processus client de type >, du processus moteur d'echange, et du processus proprietaire de la machine virtuelle, dans un cas de demande d'une operation d'echange par le processus client >; - la figure 5 represente un schema symbolique de fonctionnement d'un systeme selon l'art anterieur, utilisant une communication par protocole FTP et TCP/IP. Avant d'aborder la description de ['invention, il est necessaire de preciser les notions suivantes. Au sein d'une plate-forma materielle, constituee diun ordinateur ou de plusieurs composants d'ordinateur fonctionnant comme un seul ordinateur, le terme > est ici employe pour designer un espace memoire fourni par des moyens de memorisation, lorsque les elements ou soul-ensemble de cet espace memoire vent accessibles directement par des donnees reperant leur position a l'interieur de cet espace memoire. Ces donnees d'adresse peuvent etre utilisees directement ou a travers des intermediaires constituent un adressage indirect, mais les elements designee par cette adresse conservent une position constante pendant une duree prolongee, de fa,con a ce qu'un programme ou tout autre agent ou objet logiciel puisse acceder a une partie de cet espace memoire sans se preoccuper du reste. Les adresses d'une zone de memoire affectee a un usage determine peuvent etre affectees a un espace de memoire physique adressable, pour une telle duree prolongee, cette operation pouvant alors etre appelee > en anglais. La rapidite d'acces a une partie d'un tel espace de memoire adressable est ainsi peu dependante de la quantite de memoire qu'il contient, 1 0 2840082 et de la nature des operations effectuees sur d'autres parties de cet espace memoire adressable. Dans la presente description, on designee par ['appellation > unitaire un enchanement d'instructions executees dans la continuite l'une de l'autre, en fonction des conditions definies par ces memes instructions. Cela correspond a ['element unitaire d'execution a l'interieur d'un programme ou application, et est en general designe en anglais sous le nom de >, qui evoque le > des instructions enchanees. Le terme >, > en anglais, est ici utilise pour designer un ou plusieurs > prevus pour fonctionner en partageant un meme espace memoire. Le terme > est ici utilise pour designer un ou plusieurs espaces de memoire adressable, structures et reserves pour etre utilisbs par les differents processus executes dans le cadre d'un meme systeme d'exploitation ou d'un meme environnement proprietaire. Cette memoire de travail comprend le plus souvent de la memoire cite memoire vive (ou RAM pour Random Access Memory) qui est tres rapide d'acces, mais peut egalement comporter des espaces memoires reserves de fac,on provisoire ou permanente sur des dispositifs de memoire de masse tels que des disques curs, moins rapides mais moins coOteux et non volatile. Dans le cadre d'un environnement logiciel comportant un logiciel proprietaire eVou un systeme d'exploitation, le terme > designe ici la survenue d'une action simple, mise en oeuvre (ou >) par un agent logiciel ou un processus. Une telle action est signalee en tent qu'action atomique, ou indivisible, et peut etre detectee par d'autres agents ou processus sans qu'ils soit necessaire de designer de destinataire. Un tel evenement peut etre identifie dans sa nature, par un nom ou un code d'identification, sans necessiter d'autres parametres. Qu'il soit repete une ou plusieurs fois, un evenement peut etre detecte par un processus, a l'interieur d'un environnement ou d'un groupe determine de processus ou cet evenement est >. 1 1 2840082 Chaque processus detectant un evenement peut alors decider s'il est concerne ou non, en fonction de la nature de cet evenement. Lorsqu'un processus ou un thread effectue une ou plusieurs operations portent sur un objet logiciel determine, il peut avoir besoin de s'assurer quieucun autre agent n'interviendra pendant ces operations. Par exemple pour realiser un ensemble indivisible d'operations. Un type de mecanisme logiciel connu est utilise dans ce but, appele verrou ou >. Un tel mecanisme est en general realise en modifiant de fa,con provisoire une certaine donnee, que tout agent devra consulter avant d'effectuer une action sur ['objet logiciel ainsi protege. Dans l'environnement >, un > (pour > en anglais) est un type de verrou prevu par le systeme d'exploitation. Dans un mode de realisation represente en figure 1, I'invention est utilisee pour mettre en communication deux processus clients executes chacun par un systeme d'exploitation different (21, respectivement 11). Ces deux systemes d'exploitation vent executes chacun sur une plate forme, ou machine, et gerent chacun i'utilisation des ressources vis a vis du processus client qui depend de lui. Dans ce mode de real isation, I'u n de ces systemes d 'exploitation est u n systeme d'exploitation (21) dit >, c'est a dire litteralement >. Selon les applications, il peut s'agir diun systeme d'exploitation specialement dedie a quelques machines materielles, specifiques ou simplement peu repandues. II peut s'agir egalement d'un systeme d'exploitation pour lequel il est necessaire de payer des droits lors de la commercialisation d'un logiciel se disant compatible ou adapte a cet environnement. A titre d'exemple dans la presente, I'invention sera decrite a travers un tel mode de realisation ou ce systeme proprietaire est le systeme >, developpe et maintenu par la societe aBULL>. 1 2 2840082 Dans un autre mode de realisation (non represente), un tel systeme d'exploitation peut etre utilise sur une plate-forma materielle specialement adaptee pour cela, ou sur une plate-forma materielle ellememe geree par un environ nement log iciel specifique a la plate-forma, d it log iciel proprietaire (K Firmware >> en anglais). Dans un tel cas, le systeme d'exploitation utilise les ressources de la plate-forma, pour le compte de son ou ses processus cilents, en envoyant des commandes au logiciel proprietaire sous la forme d'instructions, par exemple appelees > pour le systeme >. Dans le mode de realisation decrit ici, le systeme d'exploitation proprietaire (21) est utilise pour gerer les ressources d'une plate-forma qui est elle-meme logicielle et non materielle. Cette plate-forma logicielle, cite machine virtuelle (20), comprend alors un ensemble de logicieis incluant un logiciel proprietaire, le a Firmware CPU >>, I'ensemble de ces logiciels fonctionnant pour reproduire vis a vis du systeme d'exploitation proprietaire (21) le meme comportement qu'une machine materielle, et utilisant pour cela les memes primitives (210). Cette machine virtuelle (20) fonctionne elle-meme sur une plate-forma materielle (10) par l'intermediaire du systeme d'exploitation, dit systeme d'exploitation hote (11), de cette plate-forma materielle. Dans l'exemple utilisant aGCOS7>>, la machine virtuelle est un ensemble de logiciels appele > ou >, fonctionnant sur une plate-forma materielle sous >. Dans ce mode de realisation, le procede selon ['invention permet une communication entre d'une part un processus client (23), dit proprietaire, travaillant dans le systeme d'exploitation proprietaire (21) de la machine virtuelle (20), et d'autre part un processus client (13) dit ouvert, par exemple un processus de type aWindows NT>>, travaillant directement dans le systeme d'exploitation hote (11) de la plate-forma materielle (20), par exemple une plate-forma a architecture 64bits et dotee d'un ou plusieurs processeurs > de la societe INTEL (marques deposees). 1 3 2840082 Dans d'autres modes de realisation non representes ici, le procede selon ['invention peut etre utilise pour permettre une communication entre d'une part un processus client execute par un systeme d'exploitation proprietaire (par exemple ) fonctionnant directement sur une plate-forma materielle proprietaire (par exemple un ordinateur ), et d'autre part un processus client d'un monde ouvert (par exemple >) execute par un systeme d'exploitation fonctionnant dans une machine virtuelle ou un emulateur au sein de la plate-forma materielle proprietaire (le >). De meme, le procede selon ['invention peut etre utilise pour permettre une communication entre des processus clients fonctionnant sous d'autres systemes d'exploitation, par exemple de type UNIX. De meme, le procede selon ['invention peut etre utilise pour permettre une communication entre des processus clients executes par plus de deux systemes d'exploitation differents, fonctionnant sur la meme plate-forma 1 5 materielle. De meme, le procede selon ['invention peut egalement etre utilise pour permettre une communication entre processus clients executes par plusieurs systemes d'exploitation proprietaires. Ces systemes d'exploitation peuvent egalement fonctionner dans plusieurs machines virtuelles differentes reunies sur la meme plate-forma materielle. Dans un autre mode de realisation (non represente), ie moteur d'echange est execute dans ie logiciel proprietaire de la plate-forma materielle. Dans ce mode de realisation, le principe de fonctionnement de I'invention comprend l'utilisation d'un procede fonctionnant comme un mecanisme logiciel appele HSL (pour >, soit Liaison Haute Vitesse en anglais) dans l'exemple utilisant le systeme > comme systeme d'exploitation proprietaire. Plutot que de transmettre des donnees, telles que des valeurs ou etats, entre les deux processus clients (13, 23), ce mecanisme HSL permet a un de 1 4 2840082 ces processus clients d'ecrire directement dans la memoire de travail, a travers le bus memoire de la plate-forma, les donnees (24, 14) qui dolvent etre transmises a l'autre processus client, ou etre utilisees ou modifiees par lui. Dans la memoire d'echange (101), ces donnees vent alors memorisees en tent que donnees d'echange (15), et vent accessibles au meme endroit par l'un ou l'autre des processus clients (13, 23) heterogenes. Dans la memoire de travail de la plate-forma materielle (10), ce mecanisme HSL comprend en particulier l'utilisation commune aux deux processus clients (23, 13) d'une ou plusieurs zones de memoire, cite memoire partagee HSL ou memoire d'echange (101). L'utilisation de cette memoire d'echange est commune, ou partagee, au sens ou des memes zones ou adresses de memoire vent utilisees par plusieurs des processus clients communiquant selon le mecanisme HSL. Cette memoire d'echange (101) contient en particulier certaines donnees ou objets logiciels devant etre transmis d'un processus (13, 23) client a un autre, ou devant pouvoir etre utilises par plusieurs de ces processus clients. Ainsi, lorsqu'un processus client emetteur veut memoriser ou modifier un objet logiciel devant etre lu ou teste par un autre processus client destinataire, c'est a dire un objet d'echange faisant partie des donnees d'echange (15), il va memoriser cet objet d'echange dans la memoire d'echange (101). C'est alors ces memes donnees que le processus client destinataire va fire a l'endroit meme de cette memoire d'echange commune ou l'emetteur les aura memorisees. Le fait pour chaque processus client d'ecrire ou de fire directement cet objet d'echange dans une partie adressable de la memoire de travail lui permet d'effectuer cette operation avec une rapidite similaire a celle dont il dispose pour son propre fonctionnement a l'interieur de son systeme d'exploitation. 1 5 2840082 C'est a dire avec une rapidite proche de ['optimum des performances du systeme informatique mis en osuvre. Du fait que les objets d'echange vent memorises dans une partie commune de la memoire de la plate-forma materielle, chaque processus client peut modifier ou fire chacun de ces objets d'echange independamment des actions ou de l'etat des autres processus clients qui y ont acces, c'est a dire de fa,con asynchrone. Le fonctionnement de chaque processus client peut ainsietre programme avec une grande liberte vis a vis des elements exterieurs a ce processus. L'aspect asynchrone des transmissions de donnees permet egalement une grande rapidite de fonctionnement de chacun de ces processus clients, puisqu'il n'a pas besoin d'attendre ni de verifier la disponibilite de son correspondent lors d'une transmission d'objet d'echange. Ce mecanisme HSL comprend egalement l'utilisation d'un processus dit moteur d'echange (201), par exemple un processus unitaire (designe par le mot . Ce moteur d'echange (201) comprend un processus qui est execute en boucle tout au long de la duree d'activite ou de validite du mecanisme HSL. Ce moteur d'echange a en particulier pour role de centraliser les demandes d'acces a la memoire d'echange (101), et d'assurer ainsi une coherence et une unite des traitements. Cette unite de traitement permet en particulier d'assurer que cheque action d'un processus client dans la memoire d'echange se fasse d'une fa, con complete et indivisible, ou atomique, du point de vue des autres processus clients pouvant y acceder. Ce mecanisme HSL permet ainsi d'assurer une certaine fiabilite et securite dans l'utilisation de la memoire, en constituent une vole d'acces encadree et controlee par laquelle doivent passer toutes les actions de chaque 1 6 2840082 processus client voulant acceder a une partie de la memoire de travail impliquant d'autres processus ou programmes. Ces fiabilite et securite permettent en particulier de proteger des donnees ou programmes sensibles, en eux-meme ou pour ie fonctionnement du systeme, vis a vis d'actions a risque pouvant venir d'un processus client contenu dans un programme malveillant ou dont le fonctionnement n'est pas au point ou ne respecte pas correctement les regles correspondent a l'un des elements du systeme. Pour que ce mecanisme HSL fonctionne correctement, un certain l O nombre d'elements doivent etre en fonctionnement, valides et disponibles. L'activation et la validation de ce mecanisme peuvent etre commandees, depuis le systeme d'exploitation ou depuis un processus, par une commande d'activation. Lorsque la desactivation de ce mecanisme HSL est commandee, I'arret du mecanisme passe par une phase de fermeture ( > en anglais) pendant laquelle, les operations d'echange deja entamees vent menees a leur terme, sans qu'aucune nouvelle operation d'echange ne soit acceptee. En cours de fonctionnement, chaque processus client peut agir sur des donnees memorisees dans la memoire d'echange (101), par differentes operations, cites operations d'echange. Ces operations effectuent un certain nombre d'actions specifiques et codifiees, et peuvent etre mises en oeuvres a [ 'a id e d e pa ra metres reg la nt leu r com portement. Ces operations d'echange vent implementees dans chacun des diffbrents systemes d'exploitation (11, 21), de fa,con a etre accessibles au programmeur d'un processus client par l'utilisation au sein de son code programme d'une instruction specifique a chacune de ces operations d'echange. Ces instructions vent fournies au programmeur sous la forme d'une bibliotheque d' instructions adaptee au systeme d'exploitation dans lequel il travaille. 1 7 2840082 Dans ce mode de realisation, ainsi qu'illustre en figure2, pour un processus client (23) proprietaire sous >, ces operations seront implementees dans une bibliotheque (210) de primitives appelee LKU HSL. Pour un processus client sous >, ces instructions seront implementees en tent que des API ( >) accessibles dans une bibliotheque (110) de type DLL appelee DLL HSL. 11 est done ainsi possible au programmeur d'un programme fonctionnant sous l'un ou l'autre des systemes d'exploitation concernes d'adapter son programme pour qu'il soit capable d'utiliser le mecanisme HSL. Du fait de la codification des operations d'echanges et de leur disponibilite sous une forme accessible directement dans l'environnement de programmation, une telle adaptation est possible sans changer de langage de programmation, et avec une quantite limitee de modifications ou reecritures. La gestion de ['ensemble de ce mecanisme HSL comprend l'utilisation d'un processus (25) gestionnaire interapplication, appele HAM, pour l'anglais K HSL Application Manager >> dans l'exemple illustre ici. Ce gestionnaire interapplication (25) a en particulier pour role de coordonner l'utilisation du mecanisme HSL par les differentes applications ou processus clients concernes. II siagit en particulier de prevenir ces differentes applications de ['activation du mecanisme HSL, ou lorsque celui-ci va etre ferme, pour leur permettre de prendre leurs dispositions et reagir de fac,on adequate. Dans le mode de realisation decrit ici, la memoire d'echange est structuree en une suite d'objets logiciels, ou objets d'echange, ou objets HSL, presentant une ou plusieurs structures specifiques. Dans l'exemple decrit ici, les objets d'echange presentent des structures basees sur des objets logiciels tels que definis dans le systeme d'exploitation proprietaire >(21) . 1 8 2840082 Le systeme d'exploitation > utilise une memoire de travail repartie en portions denommees segments. Les differents segments de la memoire de travail vent repertories dans une structure logicielle comportant un certain nombre de tables numerotees, ces tables comprenant elles-memes un certain nombre d'entrees. Lors de ['attribution d'une zone de memoire a differents segments de la memoire de travail, ou de ces segments, chacune de ces entrees peut alors contenir l'adresse d'une zone de memoire qui est attribuee a un de ces segments. Dans la memoire de travail, un segment peut etre ainsi designe de fa,con non ambigue a travers une donnee cite descripteur de segment et notee SD, qui comporte les elements suivants: - STN (Segment Table Number): numero de la table contenant l'adresse du segment en question; - STE (Segment Table Entry): numero d'entree dans la table definie par STN, cette entree contenant l'adresse du segment en question da ns ia memo ire d e la plate-forma materiel le. Au sein du systeme d'exploitation > en tent qu'elements de son >. Ces semaphores peuvent etre testes par les processus fonctionnant sous >, et peuvent etre modifiees par eux en utilisant des operations specifiques definies elles aussi dans ce decor interieur. Ces semaphores comportent avant tout une donnee notee > servant de compteur, assortie d'une donnee notee > correspondent a sa valeur maximale autorisee dans une utilisation donnee. Un semaphore peut etre de type simple, note >, ou a message, note >. Un semaphore a message est un semaphore auquel est associe une donnee constituent un pointeur indiquant une zone de memoire ou peut etre memorise un message comprenant d'autres donnees (d'au plus 4 mots de g 2840082 4 octets, pour >). Ce message peut par exemple contenir une valeur a transmettre, ou l'adresse en memoire de donnees ou objets logiciels a transmettre. Un semaphore peut etre designe de fa,con non ambigue a travers le descripteur de segment (SD) designant le segment de memoire contenant ce semaphore, suivi d'une donnee notee a SRA >> (Segment Relative Address) indiquant la position relative du debut du semaphore dans le segment designe. Des operations de base utilisables pour agir sur un semaphore comportent en particulier la reservation et la liberation, ainsi que l'incrementation et la decrementation d'un semaphore, a travers des instructions specifiques au systeme >. Ces instructions vent codees par un code d'operation et comportent l'utilisation d'un registre memoire dit registre general pour transmettre un parametre designant le semaphore a 1 5 utiliser. La reservation et la liberation d'un semaphore vent realisees par des instructions notees respectivement > et >. La reservation d'un semaphore correspond a la demande d'attribution exclusive d'un semaphore au processus demandeur. Cette exclusivite permet en particulier de garantir que ce semaphore ne sera pas modifie par un autre processus pendant le temps ou le demandeur effectuera ses operations sur ce semaphore. La liberation d'un semaphore correspond a la remise du semaphore a la disposition du systeme d'exploitation et des autres processus voulant y acceder. L'incrementation et la decrementation diun semaphore vent realisees par des instructions notees respectivement > et >. Les semaphores peuvent etre utilises a de multiples taches au sein d'un ou plusieurs processus clients sous >, et ce type d'objets logiciels existe egalement dans d'autres systemes d'exploitation non cites ici. Des 2840082 semaphores peuvent etre utilises par exemple pour garder la trace diun nombre d'operations effectuees sur un objet logiciel par un ou plusieurs processus ne se connaissant pas directement. Ils peuvent etre utilises pour synchroniser plusieurs processus, par exemple en maintenant l'un d'eux en attente tent que le semaphore n'aura pas atteint une certaine valeur. II suffit alors de faire incrementer le semaphore par l'autre processus lorsqu'il est pret pour une synchronisation. Ils peuvent etre utilises pour gerer une file d'attente de taches ou d'objets a traiter. Dans le mode de realisation decrit ici, le procede selon ['invention comporte l'utilisation commune d'une memoire d'echange (101). Cette memoire d'echange est utilisee par des processus clients (13, 23) heterogenes, a travers des operations determinees portent sur des objets logiciels, ou objets d'echange, appartenant a cette memoire d'echange. Dans l'exemple decrit ici et utilisant un systeme > fonctionnant sur une plate-forma >, la memoire d'echange comprend des objets d'echange structures selon des formats specifiques au systeme aGCOS7>>. Ces objets d'echanges vent en particulier des segments de memoire au format >, ainsi que des semaphores de type >, avec ou sans messages. La memoire d'echange HSL est une partie de la memoire de travail du systeme >, par exemple au sein de la memoire vive ou RAM de la plate-forma materielle, affectee au mecanisme HSL. Cette affectation est faite par exemple lors du demarrage du systeme KGCOS7>>, par un processus note JOPD qui est celui execute en premier dans ce cast Cette memoire d'echange est reservee par ce processus JOPD et organisee en plusieurs groupes d'objets d'echange, ou >, qui regroupent des objets d'echanges des differents types disponibles pour les processus utilisant le mecanisme HSL. 21 2840082 Une partie de la memoire d'echange est constituee d'objets HSL de type semaphores, avec ou sans message, repartis en un ou plusieurs groupes appeles pools de semaphores (1011). Une autre partie de la memoire d'echange est constituee d'objets HSL comprenant essentiellement de l'espace memoire divise en segments, repartis en groupes appeles pools de segments (1012). Pour manipuler ces objets d'echange de type >, le procede selon ['invention comporte ['implementation de commandes et instructions supplementaires, ajoutees aux deux systemes d'exploitation concernes. II peut egalement stagir de commandes existantes, dont mode le de fonctionnement est adapte par des modifications de certains composants du logiciel proprietaire (firmware) ou du systeme d'exploitation auquel elles appartiennent. Ces commandes nouvelles ou modifiees comprennent d'une part des commandes de manipulation des objets d'echange dans la memoire d'echange (101), ces commandes fonctionnant de maniere similaire aux commandes existent dans le systeme > pour manipuler des objets de types similaires, en particulier les semaphores. Ces commandes nouvelles ou modifiees comprennent d'autre part des commandes de gestion du mecanisme HSL en lui-meme. Les commandes de gestion du mecanisme HSL vent implementees a l'interieur du logiciel proprietaire de la machine virtuelle, > ou Ces commandes vent lancees par un operateur, humain ou logiciel, a travers un jeu d'instructions internee faisant partie du > de la machine virtueile. Cette gestion interne du mecanisme HSL utilise en particulier une zone de memoire du systeme >, specifique au mecanisme HSL, notee >. Cette zone de memoire HSLControlArea (non 22 2840082 representee sur les figures) contient en particulier des informations concernant les objets du monde proprietaire, ou natif ( >), qui vent utilises par le mecanisme HSL. Les instructions suivantes permettent respectivement le demarrage et I'arret du mecanisme HSL: - HSLUP - HSLDOWN Les instructions suivantes permettent la manipulation d'objets d'echange de type semaphore depuis un processus client du monde >: - HSLGETSEM: permet la reservation, dans la memoire d'echange (101) (ou memoire-partagee HSL), d'un semaphore HSL, par un processus client en vue d'operations d'echange a venir; - HSLFREESEM: permet la liberation dans la memoire d'echange (101) (ou memoire partagee HSL), d'un semaphore HSL, par un processus client, apres operations d'echange; - V-OP: est ['operation inchangee du systeme , utilisable egalement pour incrementer un semaphore reserve dans la memoire HSL; - P-OP: est ['operation inchangee du systeme >, utilisable egalement pour decrementer un semaphore reserve dans la memoire HSL. Les memes operations peuvent etre effectuees sur un semaphore HSL depuis un processus client du monde >, a travers des outils logiciels de type API, ajoutees a l'environnement >. Dans leur programmation, ces API utilisent des instructions ajoutees au logiciel proprietaire de la machine virtuelle. Ces instructions vent programmees dans la machine virtuelle pour se comporter vis a vis des objets d'echange de la meme fa,con que les instructions HSL du systeme >. Ces instructions suivantes permettent alors la manipulation d'objets d'echange de type 23 2840082 semaphore depuis un processus client du monde >, et comprennent les instructions suivantes: - Sim-HSLGETSEM: instruction accessible par les API et reproduisant ou simulant le fonctionnement de ['instruction HSLGETSEM; - Sim-HSLFREEMEM: instruction accessible par les API et reproduisant ou simulant le fonctionnement de ['instruction HSLFREESEM; - SimHSLV-OP: instruction accessible par les API et reproduisant ou simulant le fonctionnement de ['instruction V-OP; - SimHSLP-OP: instruction accessible par les API et reproduisant ou simulant le fonctionnement de ['instruction P-OP. Au sein du systeme d'exploitation >, certaines primitives vent modifiees pour permettre le fonctionnement du mecanisme HSL, et certaines primitives vent ajoutees. Ces modifications comprennent en particulier les procedures ou macros suivantes: - H_VMM_HSL_INIT: nouvelle procedure ajoutee dans le noyau logiciel ( >) du systeme d'exploitation. Cette procedure realise une initialisation des elements du mecanisme HSL, par exemple en effectuant la declaration ou ltouverture de la table (102) de communication HSL et de la zone de controle proprietaire (103). Wile permet egalement le verrouillage des operations d'echange, en reservant pour cela le premier des semaphores (SN) au sein de la memoire d'echange (101). Wile prepare egalement, dans une structure logicielle notee >, les parametres qui seront utilises par ['instruction HSLUP pour activer le mecanisme HSL. - H_NIPS_EPRD: est une modification de la procedure > de >, permettant l'appel de la procedure H_VMM_HSL_INIT. 24 2840082 - $H_DCSBE et $H_TSTDECOR: vent des declaratives du systeme >, qui vent modifiees par l'ajout d'un bit specifiquement utilise par le mecanisme HSL, au sein d'un octet de capabilite (CAPB13). Cette modification de lioctet de capabilite permet de memoriser le fait que le systeme est apte a utiliser le mecanisme HSL. - H_SSMGET_HSL: nouvelle primitive du systeme >, utilisee par ['instruction HSLGETSEM pour reserver un semaphore dans la memoire d'echange. 1 0 - H_SSMFREE_HSL: nouvelle primitive du systeme >, utilisee par ['instruction HSLFREESEM pour liberer un semaphore reserve auparavant dans la memoire d'echange. - H_TASKM_IGHSL et H_TASKM_IFHSL: nouveaux points d'entree, ou syntaxes d'appel, des procedures H_TASKM_IGSM et H_TASKM_IFSM du systeme >. Ces points d'entree vent utilises pour la reservation et la liberation de semaphores, dans le cas ou ces semaphores vent des donnees d'echange utilisees par le mecanisme HSL. * - H_VMM_JTAB: modification de cette procedure, incluse dans le module logiciel > du systeme >, pour introduire la declaration d'objets iogiciels ( >) relatifs a la table de communication HSL. - H_VMM_IISDCR: modification de cette procedure, incluse dans le module logiciel > du systeme >, pour supprimer le controle > qui devient inutile et risquerait de causer des interactions nefastes dans la gestion des segments de memoire utilises par le mecanisme HSL. - $H_VMM_SICID: modification de cette primitive, incluse dans le module logiciel > du systeme >, pour introduire 2840082 I'identification (c SICID >>) de la nouvelle procedure H_VMM_HSL_I NIT. Les API utilisees par les processus client du monde > vent regroupees dans une ou plusieurs bibliotheques de liens dynamiques de type DLL, pour l'anglais >. Les API contenues dans ces bibliotheques vent directement accessibles par ces processus, des lors que les fichiers DLL contenant ces bibliotheques vent presents dans les repertoires contenant le systeme >. Cette accessibilite par simple copie d'un nouveau fichier, ou de quelques nouveaux fichiers, est un des elements qui permet une grande modularite et une facilite d'adaptation du systeme, lors de la mise en place du procede selon ['invention. Ces bibliotheques comprennent en particulier des API de gestion de la zone de communication, qui comprend la table de communication HSL (102) et la zone de controle (103), ou leur reflet dans le monde > : - La fonction CreateHSLI nterfaceArea cree l'espace de communication necessaire au mecanisme HSL (ciest a dire, entre autres, la table de communication, la zone de controle, la table des pointeurs et les pointeurs associes) ainsi que les evenements ( >) et verrous ( > pour >) commune. - La fonction OpenHSLlnterfaceArea ouvre cet espace de communication necessaire au mecanisme HSL. - La fonction CloseHSLlnterfaceArea ferme cet espace de communication necessaire au mecanisme HSL. - La fonction GetHSLlnterfaceAreaAddress retourne le pointeur sur l'espace de communication necessaire au mecanisme HSL, et fournit ainsi i'adresse permettant l'acces a cet espace de communication. 26 2840082 Les fonctions InComTable et OutComTable gerent le verrouillage de la table de controle. Ces bibliotheques comprennent egalement des API de manipulation des semaphores HSL du monde > par les processus du monde >: - La fonction GetSemaphoreHSL permet d'obtenir un semaphore HSL de type sans message (HSL_SEM_TYPE_SN) ou avec message (HSL_SEM_TYPE_SM). La demande de semaphore emane d'un process NT. Le thread CPU va devoir executer une instruction >, qui simule du cote NT ['instruction GETSEM native de >. - La fonction FreeSemaphoreHSL permet de liberer un semaphore HSL. La demande de liberation du semaphore emane d'un process NT. Le thread CPU va devoir executer une - La fonction POPonSemaphoreSN permet d'effectuer une operation de type P-OP sur un semaphore HSL sans message. Cette API envole une demande de P-OP vers le thread CpuHsl et attend sur l'evenement passe en parametre, d'etre reveille. - La fonction POpOnSemaphoreSM permet d'effectuer une operation de type P-OP, cote NT, sur un semaphore HSL avec message. Cette API envoie une demande de P-OP vers le thread CpuHsl et attend sur l'evenement passe en parametre, d'etre reveille. - La fonction VOpOnSemaphoreSN permet, cote NT, de faire une VOP sur un semaphore HSL sans message. Cette API envoie une demande de V-OP sur un semaphore HSL et attend sur l'evenement passe en parametre d'etre reveille quand I'operation est terminee. 27 2840082 La fonction VOpOnSemaphoreSM permet, cOte NT, de poster un message sur un semaphore HSL avec message. Cette API envoie une demande de V-OP sur un semaphore HSL et attend sur l'evenement passe en parametre d'etre reveille quand I'operation est terminee. - Ces bibliotheques comprennent egalement des API de gestion de la memoire d'echange (101), ou memoire HSL partagee entre les deux mondes, (affectation et liberation de segments de memoire reserves a ce mecanisme HSL): - la fonction MapReadHSLSegment donne ie pointeur sur une portion de memoire > aux applications NT utilisatrices de HSL (portion qui correspond a un petit segment de > soit 64 ko). Cette API est appelee par les processus NT pour les fonctions gerant les caracteristiques du mecanisme HSL relatives a ['allocation et liberation d'espace memoire. - la fonction MapWriteHSLSegment donne le pointeur sur une portion de memoire > aux applications NT utilisatrices de HSL (portion qui correspond a un petit segment de GCOS>> soit 64 ko). Cette API est appelee par les processus NT pour les fonctions gerant les caracteristiques du mecanisme HSL relatives a ['allocation et liberation d'espace memoire. - la fonction UnmapHSLSegment enleve la vue sur une portion de memoire > cote NT (portion qui correspondait a un segment de >). Ces bibliotheques comprennent egalement des API d'acces a la zone de commande du mecanisme HSL (ouverture et fermeture de l'acces a la table de communication HSL, dont un soul-ensemble est note >): 28 2840082 - la fonction mapHSLTable donne le pointeur sur chacun des 2 segments de la Table HSL gardes dans la HSLFirmwareArea. Cette API est appelee par HSL a l'initialisation cote NT. Wile rend les pointeurs NT sur les 2 segments de type 0 contenant la table de controle logiciel de HSL: a HslTable >>. - la fonction UnmapHSLTable enleve la vue sur les 2 segments de la HSL_Table, cote NT Cette API est appelee par HSL a la terminaison de HSL (suite a HSLDOWN). Wile detruit la visibilite des segments de la table de controle logiciel de HSL ( HslTable). Dans ce mode de realisation, ainsi que represente en figure 4, le moteur d'echange (201) est anime par un processus unitaire (a thread cpuhsl >>) execute au sein de la machine virtuelle (20), de fa,con a etre capable de detecter des evenements signales par aussi bien par un processus client (23) du monde proprietaire (21) que par un processus client (13) du monde ouvert (11), c'est a dire dans l'exemple l'environnement aWindows NT>>. L'execution de ce processus unitaire est commandee et parametree par des primitives ou instructions internee du systeme d'exploitation proprietaire (21), par exemple de type macros publiques, interagissant avec l'environnement logiciel proprietaire qui anime la machine virtuelle (20). Pour la mise en ceuvre du mecanisme HSL, certaines primitives du systeme KGCOS7>> vent modifiees et certaines primitives supplementaires vent ajoutees et implementees comme decrit plus haut. Ainsi qu'illustre en figure 4, I'interaction du processus realisant le moteur d'echange (201) avec les processus clients (13, 23) et avec le processus proprietaire, egalement appele a thread cpu >>, se fait en particulier a travers 29 2840082 - d'une part la signalisation d'evenements par un emetteur dans l'environnement logiciel du destinataire; - d'autre part la memorisation par l'emetteur, dans un emplacement connu du destinataire, de donnees ou parametres a transferer. Cette memorisation de parametres se fait en particulier dans des zones de memoire, notees > (102) et > (103), dont l'adresse est connue des processus qui ont besoin d'y acceder. La communication entre les processus (13, 23) clients et le moteur d'echange (201) utilise une zone memoire appelee table de communication HSL (102) (ou >). Cette table de communication HSL, situee dans la memoire de travail de la plate-forma materielle (10), comprend un tableau compose d'une pluralite d'emplacements de memoire, dits cellules operatoires et notes >, de structures identiques et reperees au sein de la table (102) par un index ou numero d'entree. Une fois le mecanisme HSL active, lorsqu'un processus client, par exemple un processus NT (13), c'est a dire fonctionnant sous >, veut demander une operation d'echange sur un objet logiciel de la memoire d'echange (101), ce processus client commence par definir en interne la nature et les parametres de cette operation d'echange. II va alors d'une part creer (etape p31) et preparer un evenement de reveil (e43), unique et nouveau, represente par exemple par un code incremental, et obtenir (p33) une cellule operatoire HSLOpCell libre dans la table de communication HSL (102), et y memoriser (p34) les references de ce nouvel evenement (e43) de reveil, ainsi que des donnees representant ['operation d'echange demandee et ses parametres. Pour eviter les operations incompletes ou d'autres interactions, cette memorisation dans HSLOpCell se 2840082 fait apres verrouillage (p32) de la table de communication HSL (102) a ['aide d'un verrou >. II va d'autre part memoriser (p35) dans une file d'attente de type FIFO ( qu'il a cree et memorise dans la cellule operatoire HSLOpCell. Entre deux operations et lorsque le mecanisme HSL est active, le moteur d'echange > (201) est en sommeil ou en boucle, en attente (p30) d'une nouvelle demande d'operation, par exemple une operation d'echange ou de desactivation. Lorsqu'il detecte un evenement EvRequestOpHsl (e41) signalant une nouvelle demande d'operation d'echange, le moteur d'echange extrait (p38) de la file d'attente HSL les references de ia cellule operatoire HSLOpCell contenant les donnees de cette demande. II lit alors les references de cette cellule operatoire et les memorise dans une zone memoire appelee zone de controle proprietaire HSL (103) (ou >). A partir de ces references, le moteur d'echange lit (p39) dans la table de communication HSL (102) le contenu de la cellule operatoire, et l'interprete pour determiner la nature et les parametres de ['operationd'echange demandee. Par sa communication avec le processus proprietaire (thread cpu) dans la machine virtuelle (firmware cpu de la machine >), il initialise les conditions necessaires a la realisation de cette operation d'echange. Dans 31 2840082 I'exemple, cette initialisation se fait par la modification (p40) d'un ou plusieurs bits determines, dits >, a l'interieur d'un registre, note >, dont la constitution ajuste le fonctionnement de la detection des evenements par le processus proprietaire > (202) ou processus cpu. Le moteur d'echange (201) se met (p41) alors en sommeil, en attente d'un evenement connu, note > (e42), lui signifiant que I'operation d'echange a ete traitee par le processus proprietaire (202). Lors d'une boucle survenant apres la modification (p40) du registre >, le processus proprietaire > (202) prend (p42) en compte le contenu de ce registre, ce qui le conduit done a realiser (p43) I'operation d'echange correspondante. La realisation (p43) de cette operation comprend en particulier la lecture, dans la zone proprietaire (HSLfirmwarearea) des references de la cellule operatoire. Dans cette cellule operatoire, le processus proprietaire peut alors fire la nature et les parametres de ['operation d'echange demandee, ainsi que les references de l'evenement de reveil correspondent a cette operation d'echange. En fonction du resultat de cette operation d'echange, le processus proprietaire ecrit (p44) dans une partie de la cellule operatoire HSLOpCell un code, dit code complementaire ou code condition et note >, representant ce resultat. II signale (p45) alors un evenement EvinternalHslCpu (e42), reveillant ainsi le moteur d'echange (201). Si les conditions le permettent, par exemple si ['operation d'echange est complete ou n'est pas une operation consideree (p46) comme bloquante, le processus proprietaire > signale (p47) alors l'evenement de reveil (e43) attendu par le processus client (13) a l'origine de la demande. Une fois reveille, le processus client (thread NT) peut alors fire dans la cellule operatoire le code complementaire CC representant le resultat de 32 2840082 I'operation d'echange qu'il avait demande. II va alors memoriser (p48) le resultat de cette operation dans ses parametres de fonctionnement internee pour pouvoir en tenir compte lors de la suite de son fonctionnement. Une fois ['operation d'echange acheve, le processus client peut alors liberer la (p50) cellule operatoire de la table de communication HSL (102) qui a ete utilisee pour cette operation d'echange. Pour eviter les operations incompletes ou d'autres interactions, cette liberation de la ceilule operatoire HSLOpCell se fait apres verrouillage (p49) de la table de communication HSL (102) a ['aide d'un verrou K Mutex >> du systeme d'exploitation On comprend que la presence du moteur d'echange permet aux processus clients de demander des operations d'echange sans avoir a intervenir a l'interieur du logiciel proprietaire (20), et en particulier sans acceder au registre >. II est done possible d'offrir a ces processus clients des operations d'echange leur permettant d'acceder directement a la memoire de travail de la machine virtuelle, par exemple >, sans leur permettre d'intervenir sur ces elements qui vent a la fois vitaux pour le fonctionnement de ['ensemble et peu proteges contre des erreurs de programmation. Ce moteur d'echange constitue done un processus tampon, gere par la machine virtuelle et donnant un acces limite depuis liexterieur, apportant done une bonne securite et fiabilite tout en permettant un acces rapide aux donnees communes de la memoire d'echange. Le gestionnaire interapplication (25) comprend en particulier un processus unitaire ( > en anglais) fonctionnant en boucle, et illustre en figures 3a et 3b. Au cours de son fonctionnement normal, ce processus unitaire, ou thread HAM, est en attente (p1) d'un ou plusieurs evenements, correspondent en particulier a une demande d'activation ou de fermeture du mecanisme HSL 33 2840082 au sein du systeme. Lorsqu'il detecte un de ces evenements, le thread HAM echange les informations correspondantes avec differentes applications, cites applications interop, utilisant des processus fonctionnant dans plusieurs systemes d'exploitation et utilisant le mecanisme HSL. A ['issue de ces echanges d'informations avec les applications interop, le thread HAM peut signaler un ou plusieurs evenements rendant compte de l'achevement de ces echanges et de leur resultat. Les elements du mecanisme HSL vent initialises ou prepares, pour etre mis a disposition des processus clients (13, 23), a travers l'utilisation d'une commande notee >. A reception (etape p9) de cette instruction HSLUP, un processus unitaire du logiciel proprietaire de la machine virtuelle, note thread CPU (202), commence par verifier l'etat de fonctionnement de ce mecanisme HSL. Pour cela, le thread CPU verifie (p10) dans la zone de controle proprietaire HSL, ou HSLFirmwareArea (103), la valeur d'une donnee notee HslValidity, et en deduit l'etat actuel du mecanisme HSL. Si cette donnee a une valeur differente de 0, le thread CPU termine ['instruction HSLUP en renvoyant (p11) un code complementaire, note > d'une valeur de 3, ce qui indique que le mecanisme HSL n'est pas inactif. Si le mecanisme HSL est inactif, le thread CPU (202) effectue (p12) les operations d'activation de ce mecanisme HSL et memorise cette activation en memorisant (p13) la valeur 1 dans le champ HslValidity de la HSLFirmwareArea (103). De fac,on a assurer la complete execution de cette activation, sans risquer d'interaction avec une autre instruction qui pourrait lui arriver en cours de traitement, le thread CPU realise cette modification (13) de HslValidity sous la protection d'un verrou logiciel appose sur la HSLFirmwareArea (103). Une fois cette activation effectuee (p12) et memorisee (p13), le thread CPU signale (p14) un evenement EvHslUp (e33) indiquant cette 34 2840082 activation, et termine ['instruction HSLUP en renvoyant (p15) un code complementaire (CC) d'une valeur de 0, correspondent a une execution correcte de ['instruction. Lorsque que le moteur d'echange (201), a travers le thread CpuHsl, detecte l'evenement EvHslUp (e33) ci-dessus, il signale (p16), ou emet, un evenement attente (p0) d'un evenement le concernant. Lorsque le HAM (25) detecte (p2) cet evenement EvHAMUp (e31), il demarre (p3) ou relance les diverges applications interop qui etaient en attente du mecanisme HSL, ou leur indique qu'elles peuvent maintenant l'utiliser. A reception (p17) d'une instruction > lui indiquant de fermer le mecanisme HSL, le thread CPU (202) commence par verifier l'etat de fonctionnement de ce mecanisme HSL. Pour cela, le thread CPU verifie (p18) dans la zone de controle proprietaire HSL, ou HSLFirmwareArea (103), la valeur de la donnee HslValidity, et en deduit ltetat actuel du mecanisme HSL. Si cette donnee HslValidity a une valeur de 0, le thread CPU (202) termine ['instruction HSLDOWN en renvoyant (p19) un code complementaire (CC) d'une valeur de 0, ce qui indique que le mecanisme HSL est deja inactif. Si cette donnee HslValidity a une valeur de 2, le thread CPU termine ['instruction HSLDOWN en renvoyant (p20) un code complementaire (CC) d'une valeur de 2, ce qui indique que le mecanisme HSL est deja en cours de fermeture. Si cette donnee HslValidity a une valeur de 1, le thread CPU enregistre cette demande de fermeture en memorisant (p21) la valeur2 dans le champ HslValidity de la HSLFirmwareArea(103). De fa,con a assurer la complete execution de cet enregistrement, sans risquer d'interaction avec une autre instruction qui pourrait lui arriver en cours de traitement, le thread CPU realise 2840082 cette modification de HslValidity sous la protection d'un verrou logiciel appose sur la HSLFirmwareArea (103). Une fois cette demande de fermeture memorisee, le thread CPU signale (p22) un evenement EvHslDown (e34) indiquant cette demande de fermeture, et termine ['instruction HSLDOWN en renvoyant (p23) un code complementaire (CC) d'une valeur de 1, indiquant que le mecanisme HSL etait actif et que la demande de fermeture a ete enregistree. Lorsque que le moteur d'echange (201), ou thread CpuHsl, detecte I'evenement EvHslDown (e34) ci-dessus, il signale (p24), ou emet, un evenement EvHAMDown (e32) indiquant au gestionnaire interapplications (25), ou HAM, que le mecanisme HSL va etre ferme. Lorsque le HAM (25) detecte (p3) cet evenement EvHAMDown (e34), il demande (p5) a toutes les applications interop utilisant le mecanisme HSL de terminer leurs operations d'echange HSL, et attend (p6) que toutes lui aient confirme cette terminaison. Lorsque toutes les applications interop ont cesse d'utiliser le mecanisme HSL, le HAM signale (p7) un evenement EvHslEnd (e35) indiquant au moteur d'echange (201) que le mecanisme HSL n'est plus utilise. Lorsqu'il detecte cet evenement EvHslEnd (e35), le moteur d'echange (201) enregistre la fermeture effective du mecanisme HSL en memorisant (p25) une valeur de 0 pour le champ HslValidity de la HSLFirmwareArea (103), puis se remet (p0) en attente d'un evenement le concernant. On comprend bien que la presence de ce gestionnaire interapplication (25), ou HSL Application Manager, permet de gerer l'utilisation du mecanisme HSL par toutes les applications qui vent concernees par un simple jeu d'evenements assurant une modularite du procede par rapport a la configuration du systeme. Ces evenements vent alors suffisamment specifiques 36 2840082 et exterieurs au mecanisme HSL et aux logiciels du systeme d'exploitation (21, 11) et de la machine virtuelle (20) ou materielle (10), pour que l'utilisation de ce mecanisme dans les differentes applications y soit simple a adapter. Du fait que les applications interop n'agissant pas directement sur les elements moteurs du mecanisme HSL, en particulier le moteur d'echange (201) la table de communication HSL (102) et la zone de controle proprietaire HSL (103), les applications externes aux systemes (11, 21) d'exploitation n'ont done que peu d'interactions avec les elements internee a ces systemes 1 0 d'exploitation. En cela, le procede selon ['invention permet done de minimiser les risques de perturbation ou de detournement du fonctionnement de ces systemes d'exploitation, et done de la machine, lors de iiacces d'applications (13, 23) clientes a des objets logiciels stockes directement dans la memoire de 1 5 travail. Dans le mode de realisation decrit ici, pour l'exemple d'un systeme d'exploitation proprietaire de type >, les zones de memoire utilisee pour coordonner le fonctionnement du mecanisme HSL peuvent presenter en particulier les structures decrites ci-apres. La table de communication entre les APls de Windows NT>> et le > presente une structure en tableau de 256 entrees ou enregistrements de structure identique, cites cellules d'operation et notees >. Cheque entree est codee sur 32 bits et comprend les champs de donnees suivants: 37 2840082 Numero de ['entree Status (FREEIBUSY/READIDELIVERED/WAITI NGIDONE) Operation simulee ( Get, Free, Pop ou Vop) Type ( SN ou SM) SID: STN-STESRA (identification du semaphore) ProcesslD Handle de ['event ( sur 64 bits) ( O dans le 2eme mot si ['architecture est une Intel a 32 bits) Report Maxcount Count MessageFirstWord MessageSecondWord MessageThirdWord MessageFourthWord Filler - Numero de ['entree: index ou position de lientree, c'est le numero qui est transmis au > (valeur comprise entre 1 et 256 bornes incluses) pour lui permettre de savoir ou se trouvent les parametres de ['operation d'echange demandee; - 0peration = nature de la demande, correspondent a une operation d'echange simulee et codifiee comme suit: GETSEM:01, FRESEM:04, POP:02 ou VOP:03; - Type: type de semaphore concerne, codifie comme suit: semaphore sans message (SN): type=1, ou avec message (SM): type=2; - STN-STE-SRA: adresse basee sur ['identification de segments, identifiant le semaphore (adresse du descripteur de semaphore >). Ce champ dans la table (HSLCommunicationTable) est un 38 2840082 parametre d'entree utilise lors de demandes d'operations de type P OP, VOP ou FRESEM; - >: code d'identification, au sein de >, de l'evenement sur lequel le processus client appelant ou demandeur veut etre reveille en fin de traitement. Si une operation de type P-OP est bloquante, c'est sur cet evenement que le processus client de type > restera en attente; - Maxcount et Count: ces champs, qui ne vent significatifs que sur une operation de type GETSEM, servent a initialiser le semaphore; - Statues: etat de ['entree. II s'agit d'un champ reserve a la gestion interne du mecanisme, et refletant l'etat d'avancement d'une demande d'operation d'echange. - MessageFirstWord a MessageFourthWord: 4 mots de memoire servant a transmettre les donnees constituent le message associe au semaphore concerne, dans le cas d'un semaphore a message (SM). La zone > est une structure incluse dans la zone de memoire attribuee au mecanisme HSL, et dont l'adresse est obtenue au sein d'un processus client de type >, par utilisation de I'API: > de la DLLHSLlnterfaces. Le mecanisme de gestion de la table de communication HSL (ou >) fait appel a une table intermediaire d'index assurant la fiabilite de la prise en compte dans un mode > (First In First Out) de toutes les entrees ou HslOpCell contenant une requete ou demande d'operation d'echange. La zone de controle proprietaire, utilisee par le thread Cpu HSL, ou >, presente une structure comprenant les champs de donnees suivants: 39 2840082 Validite Nombre de segments de pool de semaphores Adresse absolue > du 26me segment de pool de semaphores _ Adresse absolue > du 3em r segment de pool de semaphores Adresse absolue > du 46me segment de pool de semaphores STN-STE.0 du 1er segment de pool de semaphores STN-STE.0 du 26me segment de pool de semaphores STN-STE.0 du 3eme segment de pool de semaphores ou 0 STN-STE.0 du 4eme segment de pool de semaphores ou 0 Nombre de semaphores SN par segment de pool SRA du 1erSD de semaphore SN Nombre de semaphores SM par segment de pool SRA du 1erSD de semaphore SM N de segment pour prochaine allocation Filler La zone > comporte 15 mots de memoire correspondents aux STN-STE et a l'adresse absolue > de chaque segment du pool de semaphores alloue (ou 0). Ces elements vent suivis d'un mot de memoire donnant le nombre de segments de pools de semaphores (2); suivis de 2 mots de memoire donnant respectivement le nombre de semaphores SN et SM et 2 autres mots de memoire donnant les SRA des premiers semaphores SN et SM dans chaque segment du pool de semaphores; suivis de 2 mots de memoire donnant les adresses absolues de 2 segments de typeO de la table HSL A titre d'exemple, la zone (103) peut etre dimensionnee au maximum des besoins: on prendra 4 segments de pool de semaphores. Mais, en realite, le rnecanisme HSL n'a besoin le plus souvent que de 5000 entrees pour les semaphores SN et 256 pour ies semaphores SM. II ne faudra done 2840082 que 2 segments de pool de semaphores pour contenir tous les semaphores dont a besoin HSL. La valeur du champ Validite (ou HslValidity) peut prendre les valeurs suivantes: - valeur 0 quand le mecanisme HSL n'est pas operationnel; valeur 1 quand le mecanisme HSL est operationnel; - valeur 2 pour indiquer que l'arret du mecanisme HSL est en cours. Le numero de segment pour la prochaine allocation indique sous la forme d'un entier de O a 3 dans quel segment sera effectuee la prochaine demande d'allocation. 11 doit etre evident pour les personnel versees dans l'art que la presente invention permet des modes de realisation sous de nombreuses autres formes specifiques sans l'eloigner du domaine d'application de I'invention comme revendique. Par consequent, les presents modes de realisation doivent etre consideres a titre d'illustration, mais peuvent etre modifies dans le domaine defini par la portee des revendications jointes, et ['invention ne doit pas etre limitee aux details donnes ci-dessus. 4 1 2840082 REVENDICATIONS 1. Procede de communication entre au moins deux processus informatiques, dits processus clients (13, 23), executes en meme temps dans un systeme informatique, dit plate-forma materielle (10), comprenant un ou plusieurs processeurs et des moyens de memorisation dont au moins une partie constitue une zone de memoire adressable, utilisable comme memoire de travail, ces processus clients etant executes au sein de systemes d'exploitation (11, respectivement 21) differents, gerant l'utilisation des ressources du systeme par leurs processus clients et n'etant pas directement compatibles entre eux, caracterise en ce que ces processus clients ecrivent ou lisent ou modifient des informations, cites donnees d'echange (15), dans au moins une partie commune, cite memoire d'echange (101), de la memoire adressable de la plate-forma materielle. 2. Procede selon la revendication 1, caracterise en ce qu'au moins un de ces processus clients (13, 23) ecrit ou lit ou modifie des donnees (15) d'echange dans la memoire d'echange (10) en accedant a un ou plusieurs emplacements de cette memoire d'echange par des donnees, ou adresses, representant de maniere constante et non ambigue la position de ces emplacements au sein d 'au moins u ne partie de la memoire ad ressable de la plate-forma materielle. 3. Procede selon l'une des revendications 1 a 2, caracterise en ce qu'au moins un de ces processus clients (13, 23) effectue au moins une operation d'echange, par ecriture ou lecture ou modification de donnees (15) d'echange dans la memoire d'echange (101) sans tenir compte de l'etat ou de la disponibIiite de l'autre processus client (23, respectivement 13) ou du systeme d'exploitation de cet autre processus client. 4. Procede selon l'une des revendications 1 a 3, caracterise en ce que la gestion, realisee par au moins un systeme (21) d'exploitation, de l'utilisation 42 2840082 des ressources de l'utilisation des ressources par un processus client (23), comprend ['emission de donnees de commande, cites primitives, depuis ce meme systeme d'exploitation vers un environnement logiciel proprietaire (20) gerant les ressources de la plate-forma materielle pour le compte de ce systeme d'exploitation (21), le procede de communication comportant ['execution, geree par ce logiciel proprietaire (20), d'au moins un processus, dit moteur d'echange (201), recevant les demandes d'operations d'echange de la part d'au moins un processus client (13, 23) et gerant la realisation de ces operations d'echange par un processus execute au sein de ce meme logiciel proprietaire (20). 5. Procede selon la revendication 4, caracterise en ce que le processus moteur d'echange (201) recoit des demandes d'operations d'echange de la part des processus clients (13, 23) et les gere selon un procede comportant une repetition recursive continue des etapes suivantes: attente, par le moteur d'echange (201), d'un evenement (e41; figure 4) signale par un processus client (13), dit processus demandeur et representant une demande d'une operation d'echange; reception, par le moteur d'echange (201) en provenance du processus (13) demandeur, de donnees (HslOpCell) representant ['operation d'echange demandee; echange, entre le moteur d'echange (201) et au moins un processus de ce logiciel proprietaire (20), d'informations representant ['operation d'echange demandee; - attente, par le moteur d'echange (201), d'un evenement (e42) representant la fin de traitement, par le logiciel proprietaire (20), de lioperation d'echange. 43 2840082 6. Procede selon l'une des revendications 1 a 5, caracterise en ce que les donnees d'echange (15) vent structurees en un ou plusieurs objets logiciels, dits objets d'echange, memorises dans la memoire d'echange (101), ces objets d'echange comprenant un ou plusieurs semaphores dont la structure comporte au moins une donnee (COUNT) representant la valeur courante du semaphore, I'etat de ces semaphores pouvant etre lus ou testes par les processus clients (13, 23) et pouvant etre modifies a travers une ou plusieurs operations d'echange. 7. Procede selon la revendication 6, caracterise en ce que la modification d'un objet d'echange par un processus client (13, 23), dit processus demandeur, se fait par une ou plusieurs operations d'echange comportant les etapes suivantes: envoi, par le processus demandeur (13, 23), d'au moins une instruction demandant la reservation d'un objet d'echange au seul usage audit processus demandeur; envoi, par le processus demandeur, d'une ou plusieurs instructions demandant la modification audit objet d'echange; - envoi, par le processus demandeur, d'au moins une instruction demandant la remise a disposition audit objet d'echange a I'ensemble des autres processus clients. 8. Procede selon l'une des revendications 1 a 7, caracterise en ce qu'il comporte au moins un processus (25) gestionnaire interapplications, gere par le log iciel pro prieta i re (20), g erant la val id ite des d ema nd es d 'operations d'echange selon un procede comportant les etapes suivantes: - detection, par le processus (25) gestionnaire interapplications, d'un evenement (e31) indiquant que les composants mettant en ceuvre le procede de communication vent disponibles; 44 2840082 - envoi, par le processus (25) gestionnaire interapplications a au moins un processus (13, 23) client apte a utiliser des donnees (15) d'echange, d'informations indiquant que les composants mettant en cauvre le procede de communication vent disponibles; - detection, par le processus (25) gestionnaire interapplications, d'un evenement (e32) representant la fin de disponibilite des composants mettant en couvre le procede de communication; envoi, par le processus (25) gestionnaire interapplications a au moins un processus client (13, 23) apte a utiliser des donnees (15) d'echange, que les composants mettant en aeuvre le procede de communication ne dolvent plus etre utilises. 9. Procede selon l'une des revendications 1 a 8, caracterise en ce qu'au moins un systeme d'exploitation (21) est un environnement logiciel compatible avec le systeme d'exploitation de >, le systeme informatique comprenant au moins un environnement proprietaire > ou > de la societe BULL, cet environnement proprietaire fonctionnant soit en tent qu'une machine virtuelle (20) executee par un ou plusieurs systemes informatiques (10) ou soit directement sur une plate-forma materielle adaptee a l'un de ces systemes d'exploitation (21). 10. Procede selon l'une des revendications 1 a 9, caracterise en ce que la machine virtuelle (20) est executee par un systeme d'exploitation (11) compatible avec > de la societe Microsoft. 11. Procede selon l'une des revendications 1 a 10, caracterise en ce qu'au moins un processus client (13, 23) est execute par l'un des systemes d'exploitation >, aGCOS7>>, >, >, ou > ou