FR 2792739 A1 20001027 FR 0000883 A 20000125 La description concerne d'une manière générale les systèmes informatiques et, d'une manière plus parti- culière, un procédé et un dispositif pour déterminer l'assignation de lettre d'unité d'une unité de CD-ROM lors de l'installation initiale d'un système informati- que. Lors de la mise en marche et de l'installation initiale d'un système informatique par un client, in- cluant une initialisation et une installation du système d'exploitation (par exemple, Windows 95 (marque déposée), Windows 98 (marque déposée), etc.), la lettre d'unité du CD-ROM n'est pas connue du système d'exploitation (O/S). Si d'autres dispositifs sont installés dans le système informatique, tels qu'une unité de disque dur à cartouche amovible ou unité ZIP (marque déposée), la lettre d'unité du CD-ROM changera, c'est-à-dire qu'elle sera différente de celle d'un système informatique ne comportant pas d'unité de disque dur à cartouche amovible. Un problème se pose dans un processus de fabrication d'ordinateurs fabriqués sur commande s'agissant des applications de conception des ordinateurs qui implémentent le chargement en usine des logiciels sur un système informatique cible fabriqué. Les applications de conception ont besoin de la lettre d'unité de l'unité de CD-ROM afin d'établir des liens entre applications basées sur CD et raccourcis et sélections de menu. En l'absence de liens corrects, le système informatique ne fonctionnera pas comme souhaité. Un procédé de la technique antérieure pour déter- miner la lettre d'unité d'une unité de CD-ROM consistait à rechercher toutes les lettres d'unité de disque dur dans un système informatique donné et à deviner ensuite que la lettre d'unité de CD-ROM serait la suivante dans une série de lettres d'unité de disque dur. Ce procédé particulier de détermination de l'assignation de lettres d'unité est leurré (donc échoue) si une unité de disque dur à cartouche amovible est ajoutée au système informa- tique cible. Un autre procédé inclut l'utilisation d'un pilote DOS pour assigner une lettre d'unité à l'unité de disque dur à cartouche amovible pendant l'amorçage initial du système informatique par un client. Dans un tel cas, pen- dant l'installation du système, la lettre d'unité de CD-ROM serait correctement assignée. Cependant, ce procé- dé particulier s'avère problématique en ceci que le pi- lote est fourni par un vendeur extérieur et que, de plus, le pilote risque fort de provoquer une sévère altération du disque sur des unités de disque de capacité supérieure à 8,4 gigaoctets. De plus, ce procédé ne fonctionne pas sous des environnements dans lesquels le système d'ex- ploitation est Windows NT (marque déposée) et Windows 98. Un autre procédé consisterait à coder matérielle- ment la lettre de l'unité de CD-ROM, de manière à ce que celle-ci soit située derrière les lettres d'unité suscep- tibles d'être normalement utilisées par les autres dispo- sitifs. Un tel procédé, cependant, n'est pas préférable du fait qu'il peut arriver que les connexions d'uni- tés-réseau nécessitent l'utilisation de la lettre d'unité codée matériellement. Dans un environnement dans lequel les produits sont fabriqués sur commande et personnalisés, les systè- mes informatiques fabriqués ont toujours la possibilité d'être différents des autres. Les systèmes informatiques peuvent différer tant par le matériel que par les logi- ciels pour répondre à une commande-client particulière. Par exemple, les applications logicielles peuvent être installées sur des systèmes informatiques fabriqués sur commande personnalisés durant la fabrication. Les appli- cations sont installées, d'une manière typique, à partir d'un CD-ROM. Les applications logicielles peuvent aussi avoir besoin d'accéder à un CD-ROM une fois qu'un client a reçu sa machine. Pour pouvoir fonctionner, les applica- tions ont besoin de savoir quelle est la lettre d'unité du CD-ROM. Lors de la fabrication de systèmes informatiques, par le passé, une lettre d'unité de CD-ROM était détermi- née, puis mémorisée jusqu'au moment o elle était deman- dée. Dans l'environnement de la fabrication sur commande personnalisée, un problème se pose lorsque la liste des périphériques que contient un système informatique donné et la liste des périphériques que reconnaît un système d'exploitation du système informatique diffèrent. Par exemple, une unité de disque dur à cartouche amovible peut être installée dans le système informatique, cepen- dant, le système d'exploitation ne la reconnaît pas. Au moment de l'installation d'applications logicielles dans l'environnement dans lequel les produits sont fabriqués sur commande et personnalisés, si le système d'exploita- tion (O/S) se voyait demander si oui ou non une unité de CD-ROM est présente sur le système, l'O/S répondrait qu'aucun CD-ROM n'est présent. Ceci tient au fait que, à cet instant du processus de fabrication, l'O/S ne connaît encore aucun CD-ROM. En d'autres termes, ce n'est pas là, en tout état de cause, que peut être déterminée quelle est la lettre d'unité d'une unité de CD-ROM. Celle-ci peut être déterminée en recourant à un procédé qui con- siste à compter l'unité de disque dur, le nombre de let- tres d'unité et à ajouter 1. Le nombre compté résultant est ensuite corrélé avec l'alphabet, la lettre correspon- dante étant prise comme la lettre de l'unité de CD-ROM. Du fait que les systèmes informatiques ont commencé à être fabriqués avec de multiples unités de CD-ROM, de multiples unités de disque dur à cartouche amovible, et analogues, l'hypothèse qui consiste à compter jusqu'à la dernière unité de disque dur et à ajouter 1 ne se traduit plus par la lettre d'unité de CD-ROM qui convient. Une autre manière possible de remédier au pro- blème ci-dessus consisterait à modifier chaque applica- tion logicielle chargée sur le système fabriqué sur com- mande personnalisé de manière à déterminer quelle est la lettre d'unité de CD-ROM du système informatique. Une telle modification serait exigée de chaque vendeur d'ap- plications. En variante, il serait possible de faire en sorte que la lettre d'unité de CD-ROM soit fixée à une désignation de lettre d'unité donnée et ne puisse être changée. De telles solutions ne conviennent pas à la fa- brication d'ordinateurs fabriqués sur commande personna- lisés en gros volume. Il serait, par conséquent, souhaitable de dispo- ser d'un procédé et d'un dispositif améliorés qui permet- tent de déterminer l'assignation de lettre d'unité d'une unité de CD-ROM, en particulier pour une utilisation du- rant un processus de fabrication de systèmes informati- ques fabriqués sur commande personnalisés. Selon un premier mode de réalisation, un système informatique inclut au moins un processeur, au moins une unité de support lisible par ordinateur, et des moyens codés en processus de fabrication, qui incluent des ins- tructions exécutables pour amener le processeur à déter- miner une désignation de lettre d'unité de la au moins une unité de support lisible par ordinateur. Le système informatique inclut en outre un système d'exploitation et un enregistrement descripteur de système, le système d'exploitation incluant un bureau adapté pour l'implémen- tation de raccourcis et de sélections de menu vers les applications logicielles basées sur l'unité de support lisible par ordinateur. La désignation de lettre d'unité de l'unité de support lisible par ordinateur est en outre une fonction du système d'exploitation et de l'enregis- trement descripteur de système. De plus, le code du pro- cessus de fabrication rend possible une détermination de la désignation de lettre de l'unité de support lisible par ordinateur par le processeur avant que le bureau du système d'exploitation ne soit entièrement initialisé, de manière à permettre en outre l'établissement de liens avec les applications logicielles basées sur l'unité de support lisible par ordinateur lors de l'établissement des raccourcis et des sélections de menu sur le bureau. Les modes de réalisation de la présente invention prévoient, d'une manière avantageuse, la fonctionnalité d'une bibliothèque de liens dynamiques pour déterminer les désignations de lettre d'unité sur la base du système d'exploitation, des composants installés, et de la ma- nière dont ces composants sont installés dans le système informatique cible. Les modes de réalisation de la présente invention permettent en outre, d'une manière avantageuse, de déter- miner des désignations de lettre d'unité de support lisi- ble par ordinateur pendant l'installation du système in- formatique cible en construisant une liste de types d'unités attendues qui inclut la liste de types d'unités telle qu'on la trouvera lorsque le bureau du système d'exploitation du système informatique cible sera entiè- rement initialisé. Les enseignements et les avantages de la présente invention qui précèdent, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description détaillée du meilleur mode d'implémentation de la présente inven- tion tel que décrit par la suite. Dans la description qui va suivre, on se reportera aux dessins annexés, sur les- quels: - la figure 1 représente un schéma fonctionnel d'un ordinateur destiné à implémenter un mode de réalisa- tion de la présente invention, - la figure 2 représente un ordinogramme du code source d'un module 'Get CDROM Drive Letter' conformément aux modes de réalisation de la présente invention, - la figure 3 représente un ordinogramme du code source d'un module 'Get Fake CDROM Drive Letter' confor- mément aux modes de réalisation de la présente invention, - la figure 4 représente un ordinogramme du code source d'un module 'Get Expected Drive Type List' confor- mément aux modes de réalisation de la présente invention, et - la figure 5 représente un ordinogramme du code source d'un module 'Get Drive Type' conformément aux mo- des de réalisation de la présente invention. En se reportant brièvement à la figure 1, un schéma fonctionnel d'un système informatique 10 est re- présenté, des caractéristiques inhérente à celui-ci étant configurées en réponse à la commande par un client du système informatique configuré, tel que décrit ici. Le système informatique 10 inclut une unité centrale de traitement (CPU) 12, des dispositifs d'entrée/sortie (E/S), tels qu'un affichage, un clavier, une souris, et des contrôleurs associés, désignés collectivement par la référence numérique 14, une unité de disque dur 16, et d'autres dispositifs de mémorisation, qui peuvent inclure une unité de disquette, une unité de CD-ROM, et analo- gues, désignés collectivement par la référence numérique 18, et divers autres sous-systèmes, tels qu'une carte d'interface réseau ("Network Interface Card" ou NIC), dé- signés collectivement par la référence numérique 20, tous interconnectés via un ou plusieurs bus, représentés col- lectivement sur la figure 1 par un bus 22. Lors de l'installation d'une application logi- cielle sur un système informatique fabriqué sur commande personnalisé et lorsque l'application logicielle a besoin de savoir quelle est la lettre de l'unité de CD-ROM, con- formément aux présents modes de réalisation, une partie noyau central' du code de fabrication est fournie. Le code de fabrication examine le système d'exploitation, examine la commande du client, examine de quelle manière le système d'exploitation est installé, examine de quelle manière l'unité de disque dur est formatée, recherche quel type de matériel est présent sur le système informa- tique et prend ensuite une décision éclairée, conformé- ment à un procédé prescrit, pour déterminer ce que sera la lettre de l'unité de CD-ROM. La détermination de let- tre d'unité de CD-ROM sera la même que celle assignée par le système d'exploitation lorsque le client obtient fina- lement son système informatique et l'amorce pour la pre- mière fois. Au moment de l'installation des applications logicielles pendant le processus de fabrication à la com- mande, certaines informations ne sont pas encore connues concernant le système informatique. Ceci tient au fait que, en réalité, on ne sait pas encore de quelle manière le système d'exploitation de l'ordinateur assignera les lettres d'unité dans le système informatique. Par exem- ple, le système d'exploitation Windows NT assigne les lettres d'unité différemment du système d'exploitation Windows 95. Une partie 'noyau central' du code de fabrication est intégrée à un programme d'installation d'applications logicielles qui s'exécute au cours d'une phase d'instal- lation du système d'exploitation durant un processus de fabrication. Lorsque le système informatique est tout d'abord monté pour un client, au cours de la phase d'ins- tallation du système d'exploitation pendant laquelle la partie 'noyau' du logiciel s'exécute, lorsque l'on ne sait rien des assignations de lettre d'unité, une appli- cation centrale de désignation de lettre d'unité de CD-ROM prescrite (appelée ici OS Drive) est prévue, laquelle s'exécute et construit une table indiquant o tout se trouve et, à partir de là, on sait o tout sera. Ensuite, lorsqu'une application a besoin de savoir o se trouve une unité de CD-ROM, elle le saura. Par ailleurs, s'il est nécessaire de savoir quelle est la lettre de l'unité de disque dur à cartouche amovible, cela se sau- ra. Grâce à ces modes de réalisation de la présente in- vention, les informations relatives aux lettres d'unité de n'importe quel système informatique donné peuvent fa- cilement s'obtenir. Les présents modes de réalisation in- cluent par conséquent un outil logiciel. Un système informatique est cassé ou rendu non fonctionnel lorsqu'une application s'exécutant sur ce- lui-ci ne peut trouver l'unité de CD-ROM du système in- formatique si nécessaire. Une unité de CD-ROM peut se voir demander par un client de réinstaller et/ou exécuter une application. Dans certains cas, si l'unité de CD-ROM n'est pas trouvée, une application peut fonctionner, mais cependant pas à 100 %. Une application de traitement de mots peut avoir besoin d'accéder à une unité de CD-ROM mais ne pas la trouver, par exemple, pour charger un jeu de documentation. Dans un tel cas, l'application de trai- tement de mots peut s'exécuter, cependant le jeu de docu- mentation ne sera pas disponible en ligne. Un utilisateur de système aurait à utiliser des manuels imprimés. Ceci illustre certains des types de problèmes que l'on peut rencontrer. Les présents modes de réalisation utilisent une combinaison d'une application de fabrication sur commande et d'un enregistrement descripteur du système ("System Descriptor Record" ou SDR). L'application de fabrication sur commande inclut des systèmes informatiques commandés personnalisés. L'enregistrement de description de système inclut un enregistrement ou fichier de données contenant des informations indiquant quels composants particuliers sont installés ou sont à installer sur le système infor- matique fabriqué sur commande d'un client. Autotool' est une application de l'environnement de fabrication de systèmes informatiques fabriqués sur commande qui utilise les modes d'implémentation de l'ou- til logiciel de la présente invention. L'outil logiciel de la présente invention utilise le SDR qui fournit les informations prescrites et, en outre, qui fournit des in- formations à l'application 'Autotool'. L'application 'Au- totool' est utilisée en association avec des aspects de l'installation logicielle lors de la fabrication d'un système informatique fabriqué sur commande personnalisé. C'est-à-dire que l'application 'Autotool' construit un ensemble de logiciels pour un système informatique fabri- qué sur commande pour un client donné en réponse à la commande du système informatique personnalisé particu- lier. Si une commande client inclut l'installation d'une unité de CD-ROM, alors, au cours du processus de fabrication, les présents modes d'implémentation seront utilisés. Le processus de fabrication de systèmes infor- matiques fabriqués sur commande inclut une installation logicielle par un programme d'installation de logiciels. Le logiciel qui doit être installé dans un système infor- matique fabriqué sur commande personnalisé pourrait être potentiellement différent pour chaque système informati- que fabriqué sur commande personnalisé fabriqué. Pour les systèmes informatiques fabriqués sur commande, fabriqués avec une unité de CD-ROM, les présents modes d'implémen- tation sont utilisés de manière à garantir une détermina- tion correcte de la désignation d'unité de CD-ROM. Au cours du processus de fabrication sur com- mande, 'ReadyWare' est un terme utilisé pour faire réfé- rence à des applications logicielles disponibles dans le commerce (par exemple, des applications logicielles du type traitement de mots, base de données, et tableur) qui sont installées sur un système informatique fabriqué sur commande, fabriqué en réponse à une commande-client par- ticulière. Pendant la fabrication d'un système informati- que fabriqué sur commande personnalisé, les applications logicielles 'ReadyWare' sont chargées sur le système in- formatique. Les applications logicielles sont installées comme composant installé a posteriori. L'installation lo- gicielle du processus de fabrication est entièrement au- tomatique, c'est-à-dire qu'elle se fait sans qu'un opéra- teur système n'ait à activer physiquement des commuta- teurs ou des touches pour insérer une désignation de let- tre d'unité de CD-ROM pendant une installation logi- cielle. Dans un environnement dans lequel sont fabriqués en gros volume des systèmes informatiques fabriqués sur commande personnalisés, systèmes dont le nombre est de plusieurs milliers par jour, une intervention manuelle ou physique pendant une installation logicielle est con- tre-productive et extrêmement onéreuse, et n'est par con- séquent pas préférée. Pendant le processus de fabrication de systèmes informatiques fabriqués sur commande personnalisés, les applications logicielles sont chargées sur un système in- formatique donné. 'Autotool' prend une image globale (c'est-à-dire, capture une image) de ce que représente une application logicielle particulière pour un système informatique, puis mémorise ces informations en vue d'une utilisation ultérieure. Les informations relatives à l'image capturée de l'application logicielle sont placées sur chaque système informatique fabriqué. Lorsque l'ap- plication 'Autotool' a capturé l'image de l'application logicielle, la lettre d'unité de CD-ROM peut avoir été "L" mais, sur un système informatique particulier fabri- qué, la lettre de l'unité de CD-ROM peut ne pas être "L". Un système informatique fabriqué peut même ne pas compor- ter d'unité de CD-ROM. Par exemple, un client peut ache- ter Microsoft Office, mais ne pas avoir commandé d'unité de CD-ROM. Le présent mode de réalisation déterminerait quelle serait la lettre d'unité de CD-ROM si une unité de CD-ROM était ajoutée au système informatique fabriqué sur commande personnalisé. Un client peut ajouter ultérieurement une unité de CD-ROM au système informatique et, en recourant à l'utilisation des présents modes de réalisa- tion, la désignation correcte de l'unité de CD-ROM est facilement déterminée. Les systèmes informatiques fabriqués sur commande personnalisés, en cours de fabrication, sont uniques et les applications logicielles ReadyWare sont uniques pour chaque système informatique fabriqué sur commande. Les présents modes de réalisation permettent d'obtenir que le matériel et les logiciels fonctionnent ensemble comme souhaité. Du fait que du matériel, des logiciels, des pilo- tes de dispositifs, et analogues, sont ajoutés aux systè- mes informatiques fabriqués sur commande, la désignation de lettre d'unité de CD-ROM change communément (c'est-à-dire, peut varier) pendant l'installation de lo- giciels sur un système informatique donné. La désignation de lettre d'unité de CD-ROM n'est pas une cible stable. Un scénario d'installation de logiciels peut commencer sans CD-ROM, avec un CD-ROM possédant une désignation de lettre d'unité incorrecte et se terminer avec un CD-ROM possédant éventuellement et finalement la bonne lettre d'unité. Malheureusement, lorsque les applications 'Rea- dyWare' sont en cours d'installation, le système d'ex- ploitation du système informatique cible se trouve dans l'une des diverses phases de l'installation logicielle. Le processus d'installation logicielle ne peut pas dépen- dre de ce que le système d'exploitation sait des éléments qui se trouvent dans le système informatique cible et de la manière dont ils y sont installés. Dans la réalité, le processus des présents modes de réalisation s'exécute et examine quel est le système d'exploitation (O/S), examine les composants de la commande-client (c'est-à-dire, ce qui est supposé se situer dans le système informatique), et détermine si oui ou non il existe une lettre d'unité de CD-ROM et, si, tel n'est pas le cas, ce qu'elle pour- rait alors être. Le présent mode de réalisation effectue ceci conformément aux applications logicielles 'Ready- Ware'. En outre, conformément au processus de fabrica- tion de systèmes informatiques fabriqués sur commande, FISH est un sigle d'un logiciel installé en usine pour du matériel. FISH inclut essentiellement les pilotes des dispositifs logiciels du matériel installé sur un système informatique cible donné. Si une unité de CD- ROM a été commandée de manière à être intégrée à un système infor- matique fabriqué sur commande personnalisé, alors les pi- lotes de dispositif de cette unité de CD-ROM sont instal- lés sur le système informatique pendant le processus de fabrication du système informatique fabriqué sur com- mande. Grâce aux applications logicielles 'ReadyWare', aucune carte imprimée ni matériel n'est généralement as- socié aux applications logicielles 'ReadyWare'. Avec FISH, un matériel est toujours associé aux pilotes de dispositif. Les applications logicielles 'ReadyWare', dans de nombreux cas, ont besoin de savoir ce qui arrive- ra éventuellement parallèlement à l'installation des pi- lotes de dispositif, c'est-à-dire les désignations de la lettre d'unité de CD-ROM ou de pilote de dispositif d'unité de disque dur à cartouche amovible et des dési- gnations de lettre d'unité de lettre d'unité, par exem- ple. Dans de nombreux cas, s'agissant de l'installation des applications logicielles 'ReadyWare', les pilotes de dispositif particuliers ne sont pas encore chargés dans le système informatique à ce stade du processus de fabri- cation, c'est-à-dire, les pilotes de dispositif ne sont pas encore physiquement présents. Les présents modes de réalisation discernent les désignations de lettre d'unité sur la base d'informations connues relatives au système informatique, comme décrit plus amplement ici. Pendant le processus d'installation logicielle, si un système d'exploitation fournit une désignation d'unité de CD-ROM, les présents modes de réalisation uti- lisent cette désignation de CD-ROM. Parallèlement, les présents modes de réalisation déterminent quelle est la désignation de lettre d'unité et o sera éventuellement la désignation de lettre d'unité. Si le système informa- tique a comme désignation de lettre d'unité de CD-ROM la lettre "E" et comporte aussi une unité de disque dur à cartouche amovible, la désignation de lettre d'unité de disque dur à cartouche amovible est insérée avant la dé- * signation de l'unité de CD-ROM, et la désignation de l'unité de CD-ROM est remplacée par une désignation de lettre d'unité suivante. Dans le présent exemple, l'unité de disque dur à cartouche amovible devient l'unité E: et l'unité de CD-ROM devient l'unité F:. Toutes les applica- tions logicielles installées qui connaissent l'unité de CD-ROM comme se trouvant sur l'unité E: ne fonctionneront plus du fait que la désignation de lettre E: pointe main- tenant sur l'unité de disque dur à cartouche amovible, ce qui fait que les applications logicielles installées ne peuvent plus trouver l'unité de CD-ROM. Les présents mo- des de réalisation surmontent cette situation. Lors de l'installation des applications logiciel- les 'ReadyWare', les applications s'assignent elles-mêmes une lettre d'unité. La lettre d'unité est fournie par les présents modes de réalisation, c'est-à-dire que le procé- dé du présent mode de réalisation informe les applica- tions logicielles de ce qu'est la lettre de l'unité de CD-ROM, du fait que la vraie lettre d'unité n'est pas vé- ritablement réelle à ce stade du processus de fabrica- tion. Lors de l'adjonction d'une unité de disque dur à cartouche amovible, la désignation de l'unité de CD-ROM est modifiée ou changée, par exemple comme décrit précé- demment. Les présents modes de réalisation fournissent un procédé pour déterminer ce que sera en dernier lieu la désignation de l'unité de CD-ROM. Les figures 2 à 5 re- présentent des ordinogrammes d'un code source, proposé à titre d'exemple, d'une bibliothèque de liens dynamiques (DLL) à utiliser dans la détermination d'une désignation de lettre d'unité de CD-ROM conformément aux présents mo- des de réalisation décrits plus amplement ci-après. Les ordinogrammes représentent le déroulement fonctionnel des implémentations logicielles dans une forme de bibliothè- que de liens dynamiques. Une forme de DLL permet de rem- placer aisément un module, sans avoir à recompiler tout le processus en usine. Par exemple, si un système infor- matique particulier inclut deux unités de CD-ROM, alors la DLL peut être modifiée afin de gérer l'adjonction de deux unités de CD-ROM et sait encore d'une manière con- sistante o sera la lettre de l'unité de CD-ROM. Les présents modes de réalisation sont actifs à l'intérieur d'un système informatique cible. Pendant l'installation du logiciel de fabrication sur un système informatique cible, les modes de réalisation dédiés à ladésignation de la lettre d'unité de CD-ROM (appelés ici OS Drive) de la présente description sont chargés sur le système cible de manière à être utilisés pendant que dure un processus d'installation logicielle 'ReadyWare' et FISH. Les modes de réalisation dédiés à la désignation de la lettre d'unité de CD-ROM peuvent être enlevés du sys- tème cible lorsqu'ils ont fini de remplir leur rôle. L'installation de logiciels sur le système infor- matique peut s'effectuer à la fois à l'usine et chez le client. Dans certains cas, certains logiciels peuvent être installés à l'usine et, dans d'autres cas, les logi- ciels ne le sont pas, suivant le système d'exploitation du système informatique cible. Pendant le démarrage ini- tial du système par un client, l'OS Drive de la présente description s'exécute. Il est à noter que, pendant un processus de fabrication de système informatique, l'ins- tallation logicielle comprend deux phases. Une première phase de l'installation logicielle se rapporte au charge- ment des logiciels. Le chargement des logiciels inclut le chargement des applications logicielles 'ReadyWare' com- mandées par le client, à l'usine, sur le système informa- tique. L'OS Drive est inclus dans le logiciel chargé sur le système informatique. Le système informatique peut ou peut ne pas être expédié au client à ce stade du proces- sus de fabrication. Lorsque le système informatique est mis en marche ou démarré pour la première fois, l'instal- lation du logiciel qui a été chargé s'effectue. En d'au- tres termes, la seconde phase de l'installation logi- cielle est la véritable installation du logiciel chargé. La mise en marche initiale et l'installation du système d'exploitation peuvent ou peuvent ne pas faire partie du processus de fabrication en usine. L'installation ini- tiale du système d'exploitation pourrait inclure le char- gement du logiciel O/S tel que reçu directement à partir du fabricant du logiciel O/S. C'est pendant l'installa- tion du logiciel chargé que le problème de la désignation d'une lettre d'unité de CD-ROM incorrecte apparaît. Le logiciel chargé ne fonctionnera pas comme prévu dans le cas d'une désignation de lettre d'unité de CD-ROM incor- recte, c'est-à-dire, non située à une désignation parti- culière. Après le chargement d'un logiciel et l'installa- tion de l'intégralité du logiciel chargé, le client peut alors souhaiter exécuter une partie de ce logiciel. Lors du chargement du logiciel sur le système informatique, il n'est pas nécessaire de savoir o se trouve l'unité de CD-ROM (c'est-à-dire, quelle est la désignation de la lettre d'unité). Lors de l'installation du logiciel char- gé, bien qu'une communication ne soit pas nécessaire avec l'unité de CDROM, il est nécessaire de savoir o sera l'unité de CD-ROM (c'est-à-dire, quelle sera la lettre de l'unité) lorsque le client désire lancer le logiciel. Lorsque les applications logicielles sont en cours d'ins- tallation, la lettre de l'unité de CD-ROM n'est pas con- nue. Les présents modes de réalisation, cependant, sont actifs pendant l'installation logicielle afin de détermi- ner quelle sera la désignation de lettre de l'unité de CD-ROM lorsqu'un client utilisera ensuite le logiciel. C'est-à-dire que les applications logicielles, bien que ne nécessitant aucune communication avec l'unité de CD-ROM pendant l'installation, peuvent exiger de communi- quer avec l'unité de CD-ROM durant l'utilisation. A ce stade du processus, l'unité de CD-ROM se voit assigner sa désignation de lettre d'unité via l'OS Drive. La désigna- tion d'une lettre d'unité de CD-ROM pourrait être réassi- gnée à un moment quelconque entre l'installation du logi- ciel et l'exécution du logiciel. La finalisation des dé- signations de lettre d'unité intervient quelque temps après l'installation du logiciel, mais avant l'exécution du logiciel par un client. Le système d'exploitation ins- tallé sur le système informatique effectue la finalisa- tion des assignations de lettre d'unité, conformément à un algorithme particulier du système d'exploitation. Par exemple, avec l'OS de Microsoft, les assignations de let- tre d'unité pour les unités de disquette incluent A: et B:. Les désignations de lettre d'unité C: et ainsi de suite sont réservées à toutes les unités de disque dur, quel que soit leur nombre, qui se trouvent dans le sys- tème informatique. Ensuite, les désignations de lettre d'unité sont assignées aux unités de disque dur amovi- bles. Ensuite, les désignations de lettre d'unité sont assignées aux unités de CD-ROM. Un système informatique peut inclure plus d'une unité de CD-ROM. Pendant la phase d'installation logicielle du processus de fabrication, le nombre d'unités de disquette et de disque dur et leurs désignations de lettre d'unité sont connus. Ceci tient au fait que le système d'exploi- tation a déjà assigné ces désignations de lettre d'unité. Les désignations de lettre des unités de disque dur amo- vibles et de l'unité de CD-ROM ne sont cependant pas con- nues pendant la phase d'installation logicielle. Grâce à une connaissance de la manière dont le système d'exploi- tation assignera éventuellement les désignations de let- tre d'unité des unités de disque dur amovibles et des unités de CD-ROM, en combinaison avec la commande du client, et, en outre, en relation avec ce que l'O/S sait du système informatique, un mécanisme est prévu de ma- nière à pré-assigner des désignations de lettre d'unité de disque dur à cartouche amovible et d'unité de CD-ROM, après l'obtention d'informations sur ce que seront éven- tuellement les désignations de lettre d'unité. Pendant l'utilisation par le client d'un système informatique, le logiciel qui est en cours d'exécution doit réellement sa- voir quelle est la désignation de lettre particulière de l'unité de disque dur amovible et/ou de l'unité de CD-ROM de manière à ce que le logiciel fonctionne comme prévu. Les présents modes de réalisation pourvoient aux désigna- tions de lettre d'unité des unités de disque dur amovi- bles et des unités de CD-ROM pendant une installation lo- gicielle. Le système informatique fonctionnera ainsi comme souhaité lorsque le logiciel s'exécutera. Pour une meilleure illustration, disons que l'O/S est chargé sur le système informatique et qu'un client se voir fournir une boîte de disques CD-ROM. Pour chaque ap- plication logicielle, le client se verrait demander d'in- sérer chaque CD dans l'unité, de cliquer sur "installer", puis d'attendre l'exécution du programme d'installation respectif. Ceci serait nécessaire pour chaque application logicielle, jusqu'à atteindre le nombre total des appli- cations logicielles commandées avec un système informati- que particulier de manière à installer toutes les appli- cations logicielles nécessaires pour obtenir que le sys- tème informatique corresponde à ce à qui il aurait éven- tuellement dû correspondre en sortie d'usine. Une fois au niveau du bureau du client, (par exemple, le bureau de Windows) toutes les informations relatives aux unités sont connues. Du point de vue de la chronologie du pro- cessus de fabrication, tout d'abord, il y a le charge- ment, puis le système informatique est mis sous tension pour un premier amorçage du système. Lorsque le système informatique tourne, exécutant son travail, les applica- tions logicielles sont installées. Le système informati- que peut être réamorcé une ou plusieurs autres fois pen- dant le processus de fabrication. Éventuellement, le sys- tème informatique se situera au niveau du bureau de Win- dows (c'est-à-dire, lorsque Microsoft Windows est le sys- tème d'exploitation). Lorsque le système informatique se situe au niveau du bureau de Windows, toutes les désigna- tions de lettre d'unité sont connues. Pour un système in- formatique générique, toutes les applications logicielles peuvent être préinstallées sur le système informatique en une seule configuration, puis les désignations d'unité seront toujours connues puisqu'il n'existe qu'une confi- guration. Avec un système informatique générique, un client souhaitant deux unités de disque dur de 8 gigaoc- tets ne pourrait pas l'obtenir si l'image logicielle du système informatique générique n'était possible que pour une unité de disque dur. Au cours du processus de fabri- cation de systèmes informatiques fabriqués sur commande personnalisés, l'installation des applications logiciel- les s'effectue suffisamment tôt au cours de l'installa- tion du système d'exploitation pour que le système d'ex- ploitation ne sache rien des unités de CD-ROM, des unités de disque dur à cartouche amovible et, potentiellement d'autres choses, par exemple, des cartes RAM. L'OS Drive du présent mode de réalisation, à ce stade de l'installa- tion logicielle, détermine quelles seront les désigna- tions d'unité au niveau du bureau de Windows. Les infor- mations obtenues (et/ou déterminées) par l'OS Drive sont utilisées pendant l'installation des applications logi- cielles de manière à ce que, lorsque les applications sont installées, les désignations d'unité liées aux ap- plications logicielles soient identiques à celles obte- nues lorsque le système informatique se situe au niveau O/S. En d'autres termes, l'OS Drive effectue une dé- termination de ce que sera l'état futur du bureau de Win- dows sur la base des informations de la commande-client, du nombre d'unités de disquette et d'unités de disque dur installées dans le système informatique à cet instant, et du nombre de partitions présentes sur l'unité de disque dur. Toutes ces entrées permettent de déterminer l'état futur qu'aura éventuellement le système d'exploitation lorsque le bureau sera pour la première fois complètement opérationnel. Le présent mode de réalisation fournit un proces- sus de fabrication amélioré pour des systèmes informati- ques fabriqués sur commande personnalisés. L'OS Drive travaille en association avec l'installation logicielle du processus de fabrication sur commande. L'OS Drive se présente sous la forme d'une DLL et permet une détermina- tion de lettre d'unité de CD-ROM d'un système informati- que cible. L'OS Drive inclut des modules Get CDROM Drive Letter, Get Fake CDROM Drive Letter, Get Expected Drive Type Lists and Get Drive Type, décrits plus amplement ci-après. Le présent mode de réalisation réduit d'une ma- nière avantageusement le besoin d'un support technique par le fabricant des systèmes informatiques s'agissant des désignations de lettre d'unité qui sont indétermi- nées. Un fort pourcentage de clients sont susceptibles d'acheter un système informatique pour la première fois et, par conséquent, de ne pas en savoir beaucoup sur les désignations des unités et les désignations des lettres d'unité. Get CDROM Drive Letter est un résumé du processus de détermination de désignation de lettre d'unité confor- mément à un mode de réalisation de la présente invention. Get CDROM Drive Letter est une interface fonctionnelle pour la DLL. Le fait d'appeler la fonction Get CDROM Drive Letter fera que l'on se verra retourner la désigna- tion de lettre d'unité de CD-ROM qu'aura l'unité de CD-ROM au moment d'atteindre le bureau de Windows (dans le cas du système d'exploitation Microsoft Windows) ou autre bureau OS. Get Fake CDROM Drive Letter est un module de l'interface fonctionnelle Get CDROM Drive Letter pour la DLL. On rappellera que certains systèmes informatiques ne peuvent inclure d'unité de CD-ROM. Get Fake CDROM Drive Letter détermine quelle serait la lettre de l'unité de CD-ROM si le fabricant (client) devait en installer une. Get Expected Drive Type Lists est un module qui utilise une combinaison de la commande-client, des compo- sants couramment installés du système informatique, des composants encore à installer du système informatique, de la manière dont le système d'exploitation a énuméré les choses dont il sait quelque chose dans le système infor- matique, et qui effectue ensuite une détermination de ce que seront les assignations de lettre d'unité. Get Expec- ted Drive Type Lists construit une table incluant les unités de disque dur à cartouche amovible, les unités de disquette, les unités de disque dur, les unités de CD-ROM, etc. La table est temporairement mémorisée dans la mémoire du système informatique. Une fois que la table est utilisée pour cette fonctionnalité et que la DLL en a fini, la table disparaît. Le but de la table est que les appels ultérieurs au module Get Expected Drive Type Lists, afin d'obtenir une lettre de CD-ROM, ne nécessi- tent pas un nouveau calcul de la désignation de lettre d'unité à chaque fois que le module se verra appeler. Une fois la table construite, son utilisation améliore la performance. Get Drive Type permet d'utiliser la table cons- truite en utilisant Get Expected Drive Type Lists pour qu'une application externe appelle chaque élément de la table et trouve ce qu'il est. Par exemple, si une appli- cation exige de savoir quelle est la lettre de désigna- tion de l'unité de CD-ROM, alors le module Get Drive Type peut être utilisé. Si l'application exige de savoir quelle est la lettre de désignation de l'unité de disque dur à cartouche amovible, alors le module Get Drive Type peut être utilisé. En se reportant maintenant à la figure 2, la fonction exportée de la DLL GetCdRomDriveLetter() va être décrite avec plus de détails. La fonction exportée de la DLL GetCdRomDriveLetter() retourne i) une désignation de lettre d'unité de l'unité de CD-ROM ou ii) un zéro (0) si l'unité de CD-ROM n'a pas été trouvée ou n'était pas at- tendue. Si la routine appelante passe un pointeur à un entier, la fonction exportée de la DLL GetCdRomDriveLet- ter() établira la valeur à i) zéro (0) si le système d'exploitation a assigné la lettre d'unité à l'unité de CD-ROM et ii) un (1) si la lettre d'unité a été assignée par la fonctionnalité DLL. A l'étape 50, la fonction in- terne de la DLL GetExpectedDriveTypeList() est appelée afin de construire une liste de types d'unités attendues telle qu'on la trouvera lorsque le bureau du système d'exploitation du système informatique cible sera entiè- rement initialisé. A l'étape 52, un drapeau utilisateur est établi à un (1) si la lettre d'unité de CD-ROM a été assignée par la DLL et à zéro (0) si la lettre d'unité a été assignée par le système d'exploitation. A l'étape 54, la fonction utilise DriveTypeList pour rechercher l'unité de CD-ROM. A l'étape 56, la fonction exportée de la DLL GetCdRomDriveLetter() retourne i) la lettre d'unité de l'unité de CD-ROM ou ii) un zéro (0) si l'unité de CD-ROM a été trouvée. En se reportant maintenant à la figure 3, la fonction exportée de la DLL GetFakeCdRomDriveLetter() va être décrite avec plus de détails. La fonction exportée de la DLL GetFakeCdRomDriveLetter() renvoie i) la lettre d'unité du CD-ROM si déjà assignée et ii), si une lettre d'unité de CD-ROM n'a pas encore été assignée, une lettre est assignée et la lettre d'unité correspondante est re- tournée. De plus, la fonction exportée de la DLL GetFa- keCdRomDriveLetter() retourne toujours une lettre d'unité de CD-ROM. A l'étape 60, la fonction exportée de la DLL GetCdRomDriveLetter() est appelée afin d'obtenir la let- tre d'unité de CD-ROM assignée. A l'étape 62, il est exa- miné si oui ou non une lettre d'unité de CD-ROM a été re- tournée. Si une lettre d'unité de CD-ROM valide a été re- tournée, alors le traitement se poursuit à l'étape 64. A l'étape 64, la fonction exportée de la DLL GetFakeCdRom- DriveLetter() retourne l'unité de CD-ROM assignée à l'ap- pelant. Si, à l'étape 62, une lettre d'unité de CD-ROM invalide a été retournée, alors le traitement se poursuit à l'étape 66. A l'étape 66, une fonction locale As- signCdRomDrive() est appelée de manière à assigner de force une lettre d'unité de CD-ROM à la DriveTypeList. Le traitement se poursuit ensuite à l'étape 68. A l'étape 68, la fonction exportée de la DLL GetCdRomDriveLetter() est appelée afin d'obtenir la lettre d'unité de CDROM assignée. Le traitement se poursuit ensuite à l'étape 64, au cours de laquelle la fonction exportée de la DLL Get- FakeCdRomDriveLetter() retourne l'unité de CD-ROM assi- gnée à l'appelant. En se reportant maintenant à la figure 4, la fonction interne de la DLL GetExpectedDriveTypeList () va être décrite avec plus de détails. En commençant à l'étape 70, il est examiné si oui ou non une table de ty- pes d'unités interne a déjà été construite. Si la table a déjà été construite, alors le traitement se poursuit à l'étape 72 avant un retour à l'appelant. Si, à l'étape 70, la table de types d'unités interne n'a pas encore été construite, alors le traitement se poursuit à l'étape 74. A l'étape 74, la table de types d'unités interne est construite à partir des assignations de type d'unité du système d'exploitation. A l'étape 76, il est examiné si oui ou non la dernière unité de disque dur est une unité SUBST (de substitution). Par exemple, dans certains sys- tèmes informatiques, un pansement ("patch") destiné aux unités de disque dur de grande capacité au format Fat32 peut utiliser l'instruction SUBST de Microsoft DOS pour assigner temporairement une lettre d'unité s'il y a une unité de disque dur à cartouche amovible dans le système informatique. Si la dernière unité de disque dur est une unité SUBST, alors le traitement progresse à l'étape 78. A l'étape 78, l'unité assignée par l'instruction SUBST est supprimée de la table de types d'unités interne et le traitement se poursuit à l'étape 80. A l'étape 76, si la dernière unité de disque dur n'est pas une unité SUBST, alors le traitement passe à l'étape 80. A l'étape 80, l'enregistrement descripteur du système (SDR) est contrô- lé de manière à vérifier la présence d'un CD-ROM installé ou d'une unité de disque dur à cartouche amovible (par exemple, unité Zip). A l'étape 82, il est examiné si oui ou non une unité de disque dur à cartouche amovible qui ne se trouve pas encore dans la table de types d'unités est installée dans le système informatique. Si une unité de disque dur à cartouche amovible est installée et ne se trouve pas encore dans la table de types d'unités, alors le traitement passe à l'étape 84. A l'étape 84, une unité de disque dur à cartouche amovible est insérée dans la table de types d'unités après toutes les unités de disque dur et avant les unités de CD-ROM éventuelles. Le traite- ment se poursuit ensuite à l'étape 86. Si, à l'étape 86, aucune unité de disque dur à cartouche amovible qui ne se trouvait pas déjà dans la table de types d'unités n'a été installée dans le système, alors le traitement passe à l'étape 86. L'étape 86 permet d'examiner si oui ou non une unité de CD-ROM qui ne se trouve pas déjà dans la ta- ble de types d'unités a été installée dans le système in- formatique. Si une unité de CD-ROM est installée et ne se trouve pas déjà dans la table de types d'unités, alors le traitement passe à l'étape 88. A l'étape 88, une unité de CD-ROM est insérée dans la table de types d'unités après toutes les unités de disque dur et les unités de disque dur à cartouche amovible. Le traitement se poursuit en- suite à l'étape 72. Si, à l'étape 86, aucune unité de CD-ROM qui ne se trouvait pas déjà dans la table de types d'unités n'a été installée dans le système, alors le traitement se poursuit à l'étape 72. A l'étape 72, la ta- ble est ainsi construite et la fonction retourne à l'ap- pelant. En se reportant maintenant à la figure 5, la fonction exportée de la DLL GetDriveType() va être dé- crite plus en détail. La fonction exportée de la DLL Get- DriveType() retourne le type d'unité associé au réper- toire racine passé par l'appelant. Les codes de retour vali- ' des peuvent inclure: DRIVE UNKNOWN = 0; DRIVE NO ROOT DIR = 1; DRIVE REMOVABLE = 2; DRIVE FIXED = 3; DRIVE _REMOTE = 4; DRIVECDRCM = 5; et DRIVE _RAMDISK = 6. D'autres codes de re- tour peuvent également être inclus tel que nécessaire pour une implémentation particulière. A l'étape 90, la fonction interne de la DLL GetExpectedDriveTypeList() est appelée afin de construire la liste de types d'unités at- * tendues telle qu'on la trouvera lorsque le bureau du sys- tème d'exploitation du système informatique cible sera entièrement initialisé. Lors d'une étape 92 consécutive, il est ordonné d'utiliser le répertoire racine passé par l'appelant et de procéder à un indexage dans DriveType- List afin d'obtenir le type d'unité. Après l'obtention du type d'unité, le traitement retourne le type d'unité à l'appelant ou un code de retour DRIVEUNKNOWN si le che- min fourni par l'utilisateur n'est pas valide (étape 94). Un code logiciel de fabrication 'Autotool' est chargé sur le système informatique et est utilisé pour installer des applications logicielles. Le code de fabri- cation inclut des instructions pour installer les appli- cations logicielles qui ont été chargées sur le système informatique. Le code de fabrication et le code OS Drive sont chargés sur l'unité de disque dur du système infor- matique fabriqué sur commande personnalisée avant un amorçage initial du système informatique. Get Drive Type permet à l'application 'Autotool' (ou à tout autre appli- cation externe qui utilise OS Drive) d'accéder à la table qui est construite par le module Get Expected Drive Type Lists. Les présents modes de réalisation incluent, d'une manière avantageuse, une DLL qui encapsule la fonctionna- lité qui permet de déterminer la lettre de l'unité de CD-ROM sur la base du système d'exploitation, des compo- sants installés, et, en outre, de la manière dont ces composants sont installés dans le système informatique cible respectif. L'application de fabrication de système informatique appelle cette DLL pendant l'installation du système afin d'obtenir la lettre d'unité du CD- ROM. La DLL agit pour obtenir une liste des dispositifs assignés dans le système informatique cible particulier. REVENDICATIONS 1. Système informatique (10) caractérisé en ce qu'il comporte: au moins un processeur, au moins une unité de support lisible par ordina- teur, et des moyens codés en processus de fabrication, in- cluant des instructions exécutables, aptes à amener le(s) processeur(s) à déterminer une désignation de lettre d'unité de l'(les) unité(s) de support lisible par ordina- teur. 2. Système informatique (10) selon la revendica- tion 1, caractérisé en ce que l'unité de support lisible par ordinateur inclut une unité de CD-ROM. 3. Système informatique (10) selon la revendica- tion 1, caractérisé en ce que l'unité de support lisible par ordinateur inclut une unité de disque dur (16) à car- touche amovible. 4. Système informatique (10) selon la revendica- tion 1, caractérisé en ce qu'il comporte en outre: un système d'exploitation incluant un bureau adapté pour l'implémentation de raccourcis et de sélec- tions de menu vers des applications logicielles basées sur l'unité de support lisible par ordinateur, et un enregistrement descripteur de système, dans lequel la désignation de lettre d'unité de l'unité de support lisible par ordinateur est une fonction du sys- tème d'exploitation et de l'enregistrement descripteur de système. 5. Système informatique (10) selon la revendica- tion 4, caractérisé en ce que les moyens codés en pro- cessus de fabrication sont également aptes à lancer une détermination de la désignation de lettre d'unité de sup- port lisible par ordinateur par le(s) processeur(s) avant que le bureau du système d'exploitation ne soit complète- ment initialisé, pour permettre d'établir en outre des liens avec les applications logicielles basées sur l'uni- té de support lisible par ordinateur lors de l'établisse- ment de raccourcis et de sélections de menu sur le bu- reau. 6. Système informatique (10) selon la revendica- tion 4, caractérisé en ce que l'unité de support lisible par ordinateur inclut une unité de CD-ROM. 7. Système informatique (10) selon la revendica- tion 4, caractérisé en ce que l'unité de support lisible par ordinateur inclut une unité de disque dur (16) à car- touche amovible. 8. Système informatique (10) selon la revendica- tion 1, caractérisé en ce que les moyens codés en proces- sus de fabrication incluent des moyens de mise en oeuvre de fonctions d'une bibliothèque de liens dynamiques. 9. Système informatique (10) selon la revendica- tion 8, caractérisé en ce que les fonctions de la biblio- thèque de liens dynamiques peuvent être appelées par un programme d'installation d'applications logicielles ex- terne, le programme d'installation d'applications logi- cielles externe incluant une routine d'installation uti- lisée lors de la fabrication d'un système informatique (10) fabriqué sur commande personnalisé. 10. Système informatique (10) selon la revendica- tion 8, caractérisé en ce que les fonctions de la biblio- thèque de liens dynamiques incluent une fonction GetCdRomDriveLetter et une fonction GetFakeCdRomDriveLet- ter. 11. Système informatique (10) selon la revendica- tion 10, caractérisé en ce que la fonction GetCdRomDrive- Letter utilise une combinaison d'une fonction GetExpec- tedDriveTypeList et d'une fonction GetDriveType. 12. Système informatique (10) selon la revendica- tion 11, caractérisé en outre en ce que la fonction GetCdRomDriveLetter est une fonction exportée de la bi- bliothèque de liens dynamiques et retourne à une routine appelante, par sélection dans un groupe, soit i) une dé- signation de lettre d'unité de l'unité de support lisible par ordinateur, soit ii) un zéro si l'unité de support lisible par ordinateur n'a pas été trouvée ou n'était pas attendue. 13. Système informatique (10) selon la revendica- tion 11, caractérisé en outre en ce que la fonction Get- FakeCdRomDriveLetter est une fonction exportée de la bi- bliothèque de liens dynamiques et renvoie à une routine appelante, par sélection dans un groupe, soit i) une dé- signation de lettre d'unité de l'unité de support lisible par ordinateur si déjà assignée, soit ii) une désignation de lettre d'unité qui est assignée à l'unité de support lisible par ordinateur si la lettre de l'unité de support lisible par ordinateur n'a pas été assignée auparavant. 14. Système informatique (10) selon la revendica- tion 11, caractérisé en ce que la fonction GetExpected- DriveTypeList est une fonction interne de la bibliothèque de liens dynamiques et permet la construction d'une table de types d'unités interne. 15. Système informatique (10) selon la revendica- tion 11, caractérisé en ce que la fonction GetDriveType est une fonction exportée de la bibliothèque de liens dy- namiques et renvoie à une routine appelante un type d'u- nité associé à un répertoire racine passé par la routine appelante. 16. Procédé pour système informatique (10), ca- ractérisé en ce qu'il comprend les étapes consistant à: produire au moins un processeur, produire au moins une unité de support lisible par ordinateur, et produire des moyens codés en processus de fabri- cation, incluant des instructions exécutables, aptes à a- mener le(s) processeur(s) à déterminer une désignation de lettre d'unité de l'(les) unité(s) de support lisible par ordinateur. 17. Procédé selon la revendication 16, caractéri- sé en ce que l'unité de support lisible par ordinateur inclut une unité de CD-ROM. 18. Procédé selon la revendication 16, caractéri- sé en ce que l'unité de support lisible par ordinateur inclut une unité de disque dur à cartouche amovible. 19. Procédé selon la revendication 16, caractéri- sé en ce qu'il comprend en outre les étapes consistant à: produire un système d'exploitation incluant un bureau adapté pour l'implémentation de raccourcis et de sélections de menu vers les applications logicielles ba- sées sur l'unité du support lisible par ordinateur, et produire un enregistrement descripteur de sys- tème, dans lequel la désignation de lettre d'unité de l'unité de support lisible par ordinateur est fonction du système d'exploitation et de l'enregistrement descripteur de système. 20. Procédé selon la revendication 19, caractéri- sé en ce que les moyens codés en processus de fabrication sont également aptes à lancer une détermination de la dé- signation de lettre d'unité de support lisible par ordi- nateur par le(s) processeur(s) avant que le bureau du système d'exploitation ne soit entièrement initialisé, pour permettre d'établir en outre des liens avec les ap- plications logicielles basées sur l'unité de support li- sible par ordinateur lors de l'établissement des raccour- cis et des sélections de menu sur le bureau. 21. Procédé selon la revendication 19, caractéri- sé en ce que l'unité de support lisible par ordinateur inclut une unité de CD-ROM. 22. Procédé selon la revendication 19, caractéri- sé en ce que l'unité de support lisible par ordinateur inclut une unité de disque dur à cartouche amovible. 23. Procédé selon la revendication 16, caractéri- sé en ce que les moyens codés en processus de fabrication incluent des moyens de mise en oeuvre de fonctions d'une bibliothèque de liens dynamiques. 24. Procédé selon la revendication 23, caractéri- sé en ce que les fonctions de la bibliothèque de liens dynamiques peuvent être appelées par un programme d'ins- tallation d'applications logicielles externe, le pro- gramme d'installation d'applications logicielles externe incluant une routine d'installation utilisée lors de la fabrication d'un système informatique (10) fabriqué sur commande personnalisé. 25. Procédé selon la revendication 23, caractéri- sé en ce que les fonctions de la bibliothèque de liens dynamiques incluent une fonction GetCdRomDriveLetter et une fonction GetFakeCdRomDriveLetter. 26. Procédé selon la revendication 25, caractéri- sé en ce que la fonction GetCdRomDriveLetter utilise une combinaison d'une fonction GetExpectedDriveTypeList et d'une fonction GetDriveType. 27. Procédé selon la revendication 26, caractéri- sé en outre en ce que la fonction GetCdRomDriveLetter est une fonction exportée de la bibliothèque de liens dynami- ques et renvoie à une routine appelante, par sélection dans un groupe, soit i) une désignation de lettre d'unité de l'unité de support lisible par ordinateur, soit ii) un zéro si l'unité de support lisible par ordinateur n'a pas été trouvée ou n'était pas attendue. 28. Procédé selon la revendication 26, caractéri- sé en outre en ce que la fonction GetFakeCdRomDriveLetter est une fonction exportée de la bibliothèque de liens dy- namiques et renvoie à une routine appelante, par sélec- tion dans un groupe, soit i) une désignation de lettre d'unité de l'unité de support lisible par ordinateur si déjà assignée, soit ii) une désignation de lettre d'unité qui est assignée à l'unité de support lisible par ordina- teur si la lettre de l'unité de support lisible par ordi- nateur n'a pas été assignée auparavant. 29. Procédé selon la revendication 26, caractéri- sé en ce que la fonction GetExpectedDriveTypeList est une fonction interne de la bibliothèque de liens dynamiques et permet la construction d'une table de types d'unités interne. 30. Procédé selon la revendication 26, caractéri- sé en ce que la fonction GetDriveType est une fonction exportée de la bibliothèque de liens dynamiques et ren- voie à une routine appelante un type d'unité associé à un répertoire racine passé par la routine appelante.