Les services pour UNIX de Windows NT

En dépit des affirmations de certains, Windows NT ne peut tout simplement pas remplacer UNIX dans toutes les situations. En outre, le coût d'une migration d'UNIX vers NT est prohibitif et, dans bien des cas, NT n'apporte pas aux administrateurs UNIX les applications qu'ils recherchent. La règle en la matière est plutôt l'intégration que le remplacement.Depuis le lancement de Windows par Microsoft, l'éditeur a toujours été en retrait en ce qui concerne le nombre et les fonctionnalités des utilitaires d'invite de commande de Windows au bénéfice des interfaces graphiques. Des sources tierces (notamment UNIX) proposent ces outils depuis plusieurs années, mais aucune solution intégrée n'était proposée.
Avec les Services pour UNIX de Windows NT (SPU), cette lacune a été comblée. Pourtant, le nom du produit est trompeur. SPU ne fournit pas de services NT pour UNIX, mais plutôt ce que beaucoup considèrent comme des services UNIX sur un système NT. Il est fondamental de bien percevoir cette distinction pour comprendre les services offerts par SPU et pour qui. SPU simplifie l'accès aux ressources, facilite la synchronisation des mots de passe et facilite l'administration des environnements mixtes Windows NT/UNIX.

Microsoft en quête de fiabilité

Ancien de Banyan Systems, Jim Allchin n'aime pas les bugs. Ex Senior Vice President de Microsoft en charge du développement de Windows 2000, désormais VP responsable des plates-formes, il est l'homme d'une mission : rendre Windows 2000 l'OS le plus fiable du marché. Après plus de 10 ans chez Microsoft à  travailler sur Windows NT, le penchant de Jim Allchin pour l'excellence et sa détermination pourraient bien porter leurs fruits Au cours d'un discours prononcé au dernier Comdex d'automne, Jim Allchin a déclaré : " vous avez devant vous le bureau des réclamations de Microsoft pour Windows. Je reçois des lettres à  propos de Windows 95, 98 et NT et je passe beaucoup de temps à  les lire. C'est une lecture pénible car, même si j'en reçois de nombreuses très gentilles, la plupart des lettres qui arrivent sur mon bureau sont celles dans lesquelles quelqu'un a vécu une mauvaise expérience. Il y a deux ans, Microsoft a décidé d'essayer de comprendre la réalité en ce qui concerne la fiabilité et la compatibilité de Windows NT. Parce qu'au moment où je recevais toutes ces lettres, je savais que Dell.com tournait sous Windows NT, que le Nasdaq ou le Chicago Board of Trade étaient sous NT. Nous savions en outre que ces clients étaient absolument ravis de la fiabilité de nos produits. "

Les options de déploiement de Windows 2000 Professional

Au cours des deux dernières années, le déploiement a été maintes fois évoqué, en référence au processus consistant à  installer un OS ou une application sur les postes de travail de l'entreprise. A l'origine de Windows NT, l'installation de l'OS nécessitait la présence d'un opérateur pour fournir des informations pendant le processus. Windows NT 4.0 comportait quelques des options pour simplifier ce processus, avec Windows 2000, l'OS en comporte beaucoup. Windows 2000 Professional offre de nombreuses méthodes de déploiement, que ce soit sur un poste de travail ou pour tout un réseau.

Aussi, avant de commencer à  installer l'OS, vous devez prendre en compte quelques considérations. Si vous installez Windows 2000 Pro sur du matériel flambant neuf garanti prêt pour Windows 2000, vous ne devriez pas rencontrer de problèmes.

En revanche, si vous envisagez de mettre à  jour des systèmes existants, vous devez vous préparer à  quelques pièges en termes de compatibilité.

Les drivers sont un des points sensibles potentiels : Windows 2000 Pro utilise une architecture de drivers différente de celle utilisée par Windows 9x. Bien que Windows 2000 soit en gros une mise à  jour de Windows NT, Microsoft a suffisamment changé l'OS pour que l'on ne puisse pas partir du principe que les drivers NT 4.0 fonctionneront sous Windows 2000 Professionnal. Ne croyez pas la propagande de Microsoft selon laquelle le Windows Driver Model (WDM) règlera tous ces problèmes de compatibilité de drivers.

Au cours d'une récente conversation avec un des développeurs de WDM, ce dernier m'a révélé que WDM ne s'applique à  aucune forme de driver d'affichage (écrans, imprimantes ou tout autre driver interagissant directement avec GDI - Graphical Driver Interface). Le développeur m'a également appris que Microsoft avait reconçu WDM pour les programmeurs et non les utilisateurs finaux et que, même lorsque WDM fonctionne, la compatibilité binaire entre Windows 2000 Pro et Windows 9x n'était pas garantie.

Même lorsque le Windows Driver Model fonctionne, la compatibilité binaire entre Windows 2000 Pro et Windows 9x n'était pas garantie La compatibilité des applications est également un problème. J'ai testé la RC3 de Windows 2000 Pro et, à  l'heure de mise sous presse, les applications suivantes présentaient des problèmes de compatibilité (peut-être résolus depuis la disponibilité de la version définitive) : Illustrator, Photoshop et Adobe Type Manager d'Adobe ; les logiciels d'Aldus Freehand, Compuserve et AOL ; Inoculan et InoculanIT de Computer Associates ; Exceed d'Hummingbird ; Diskshare et GeoMedia d'Intergraph ; cc:Mail, Notes, Organizer et SmartSuite de Lotus ; Macromedia Director ; iGraphx Designer de Micrografx ; Encarta, Office, Photodraw, les Services for UNIX de NT 4.0, Visual Basic, Visual C++, FoxPro, Visual Interdev et Visual Studio de Microsoft ; GroupWise de Novell ; Panda Antivirus ; PowerQuest Drive Image ; Crystal Report de Seagate ; et les application sde Symantec dont pcANYWHERE.

Pour être honnête, les problèmes de compatibilité n'affectent pas toutes les versions de tous ces produits et la plupart peuvent être contournés. Je n'ai évoqué ici que deux des nombreux problèmes de compatibilité que vous pouvez rencontrer.
Que peut-on y faire ?
Les bonnes vieilles règles de la mise à  niveau de Windows NT fonctionnent encore : vérifiez la liste de compatibilité matérielle (HCL) pour vérifier que Windows 2000 Pro supporte votre système, vérifiez tous les drivers d'éditeurs tiers et lisez la note accompagnant Windows 2000 Pro pour voir si un de vos logiciels présente un problème.
Pour faciliter la découverte de problèmes de compatibilité, on peut utiliser le commutateur \checkupgradeonly sur winnt32.exe. (Winnt32.exe est le nom du programme d'installation de Windows 2000 Professionnal et on peut le trouver dans le répertoire \i386 du CD-ROM de distribution.) On peut également utiliser le vérificateur de compatibilité de Microsoft (checkupgrade_1.exe) que l'on peut télécharger depuis le site Web de Microsoft.

Linux, l’aiguillon de Windows 2000

Alors que le procès antitrust contre Microsoft touche à  son terme, on pourrait croire, en lisant les annonces des fournisseurs ou la presse informatique, que Windows est sur le point de perdre de substantielles parts de marché face à  Linux. Il ne faut pas toujours croire ce que l'on vous dit.

Générer automatiquement des rapports de déploiement

De nombreuses grandes entreprises passent beaucoup de temps à  écrire des scripts et programmes pour générer automatiquement des rapports sur leurs bases de données. Certaines écrivent leurs programmes en Visual Basic ou Visual C++ ; certaines utilisent des applications comme Excel, Access ou Visual Basic for Applications ; et les autres utilisent d'autres méthodes. Avec Active Directory, les choses changent. Avec l'arrivée de Windows 2000 et d'Active Directory, il peut devenir intéressant d'apprendre comment utiliser de simples scripts pour utiliser Excel 2000 en mode automatique afin qu'il génère des rapports. Ces scripts peuvent en effet désormais bénéficier d'ADSI (Active Directory Services Interface) pour interroger AD. L'exemple qui suit devrait vous en faire prendre conscience.
Imaginons une entreprise dans laquelle un utilisateur désire installer Windows 2000 sur un client. L'utilisateur doit utiliser un système maison avec un frontal Web pour créer le compte machine du client. L'utilisateur devra entrer son profil et les détails de la machine. Les neuf détails de la machine sont : l'adresse MAC (Media Access Control) de la carte réseau ; le nom de l'installateur de la machine ; le département, le bâtiment, l'étage et le bureau ; et le nom, numéro de téléphone et l'adresse e-mail de la personne qui connaît le mot de passe d'administrateur de la machine. L'utilisateur peut également spécifier un nom qu'il souhaite utiliser pour la machine. Lorsque l'utilisateur envoie le formulaire Web, le système lance une série de procédures de vérifications contrôlant les détails de l'utilisateur et de la machine. Ensuite, le système affecte un nom à  la machine. Le système peut accepter le nom fournit par l'utilisateur, si tel est le cas, ou il peut en créer un. Ensuite, le système Web renvoie le nom résultant à  l'utilisateur et lui demande s'il accepte ce nom. Si le nom est accepté par l'utilisateur, le système Web crée un objet de compte utilisateur dans AD. Si l'utilisateur n'accepte pas le nom, le formulaire réapparaît avec les données d'origine inchangées et un processus de négociation s'engage, le système suggérant une liste de noms ou l'utilisateur en proposant.
L'ensemble du processus de la saisie des données à  la réception et l'accord sur le nom ne prend que quelques instants. Une fois ce processus effectué, l'utilisateur peut utiliser le compte d'ordinateur créé dans AD pour installer Windows 2000 sur le client. Le système Web fournit très facilement les 9 détails de la machine comme données pour les neuf attributs étendus du compte de l'ordinateur dans AD. On peut utiliser un script tel que celui du listing 1 pour afficher les attributs du système dans la boîte de message de l'écran 1.

Le blues du double boot

Lorsque Steve Balmer, Président de Microsoft, a annoncé la disponibilité de Windows 2000 Professional, il a qualifié l'OS de "meilleur système d'exploitation pour les utilisateurs d'entreprise", point ! A bien des égards, cette assertion est vraie, mais l'OS n'est pas entièrement compatible avec les matériels et logiciels pour Windows 9x. Le double boot est donc souvent une nécessité.J'attends toujours un driver de scanner/fax afin de pouvoir exploiter mon imprimante HP OfficeJet 710 sous Windows 2000 et j'utilise des logiciels de simulation de vol qui ne tournent pas sous Windows 2000. Je ne peux donc pas supprimer Windows 98, quelle que soit mon envie de le faire et, à  en juger par le courrier que je reçois, je ne suis pas le seul dans ce cas. Il est donc plus que possible que vous souhaitiez savoir comment créer un environnement à  double initialisation qui permette de passer de Windows 2000 à  Windows 98.

Accès distant, les changements

De nombreux salariés de l'entreprise basés à  l'extérieur de celle-ci - tels que les commerciaux ou les télétravailleurs - dépendent d'un accès distant au réseau de leur société. Je fais parti de ces salariés. A ce titre, je me suis intéressé aux changements apportés, dans le domaine de l'accès distant, par Microsoft à  Windows 2000 Professional. Ma première impression, lorsque j'ai découvert les modifications que Microsoft a mis en oeuvre dans le domaine de l'accès distant sous Windows 2000, a été négative. Les changements apportés à  l'interface utilisateur d'appel distant de Windows 2000, comparée à  l'interface de Windows NT 4.0 et Windows 98, m'ont laissé dubitatif et j'ai eu des difficultés à  trouver certaines fonctions. Avec l'expérience, cependant, j'ai appris à  apprécier la nouvelle version.

Les options offertes aux utilisateurs mobiles

Windows 2000 Professionnel est sans contexte un grand progrès par rapport à  Windows NT 4.0 pour les utilisateurs d'ordinateurs portables. Mais, même si vous voyagez beaucoup, peut-être n'êtes-vous pas prêts à  investir dans un portable capable de supporter Windows 2000. Dans ce cas, cet article propose une alternative moins chère qui répondra peut-être à  vos besoins. Les ordinateurs portables n'ont jamais été la tasse de thé de Windows NT. Après tout, l'OS a été conçu par Microsoft pour monter en charge et faire fonctionner des serveurs. Windows NT est lent à  démarrer et, jusqu'à  la version 3.51 incluse, Windows NT ne présente pas la moindre trace d'une gestion de l'alimentation ou de support du plug & play. Microsoft a néanmoins ajouté quelques fonctions à  Windows NT 4.0 (tels que les profils matériels, un porte-document pour les fichiers à  synchroniser ou le support de PC Card) pour les utilisateurs d'ordinateurs portables. Malheureusement, Windows NT 4.0 est apparu après Windows 95 qui, lui, supportait le plug & play et comprenait une gestion intégrée de l'alimentation. Conséquence, la plupart des portables sortis après la disponibilité de Windows 95 ne supportaient tout bonnement pas Windows NT 4.0 ou n'étaient pas adaptés car conçus pour être utilisés avec Windows 95. Avec Windows 2000 Professionnel, la situation est bien différente puisque l'OS offre de nombreuses fonctions pour les ordinateurs portables et qu'il évite les écueils qui rendaient NT impropre aux portables.

Les sites Active Directory (Partie 1)

De toutes les caractéristiques de Windows 2000, Active Directory (AD) est celle qui a le plus attiré l'attention. Or malgré cette focalisation, les utilisateurs se sont moins intéressés aux sites AD qu'à  la nouvelle structure des domaines et au Catalogue Global (GC) de Windows 2000. Même si les tâches associées à  la mise en oeuvre de Windows 2000 entraînent une surcharge de travail pour vous, vous devriez apprendre à  connaître les sites AD car ils peuvent faire une énorme différence quant aux retombées que vous pouvez attendre du déploiement de Windows 2000 sur le réseau de votre entreprise. Lorsque vous saurez utiliser les sites AD pour gérer la duplication sur le réseau Windows 2000, vous verrez que les sites AD méritent ce coup de projecteur

Les commandes clés de la console de reprise

Parfois, les systèmes refusent de démarrer et affichent un écran bleu ou un message indiquant que le système ne peut pas démarrer parce qu'un fichier est manquant ou corrompu. La première tentative pour régler ce problème est de rebooter, mais cette méthode ne fonctionne pas toujours. Dans une telle situation, la console de récupération, un nouvel outil de Windows 2000 Professionnel, peut ranimer votre système.

Les sites Active Directory (Partie 2)

La première partie de cet article (ici), publiée le moi dernier, était une introduction aux sites AD (Active Directory). Elle expliquait comment créer et configurer ces sites pour contrôler la duplication de la forêt Windows 2000. Vous voici donc prêts pour une exploration approfondie de la duplication, afin d'apprendre à  établir et maintenir des chemins de duplication au sein d'un site et entre sites. Il est temps de mettre en pratique vos connaissances sur les sites AD.

Les meilleurs composants logiciels enfichables de la MMC

Une des principales modification de Windows 2000 est le fait que l'OS recours à  la MMC (Microsoft( Management Console) pour l'administration du système. Microsoft a implémenté pratiquement toute la panoplie d'outils d'administration de Windows 2000 sous forme de composants logiciels enfichables pour la MMC. Dans cet article, nous allons voir le hit-parade des meilleurs composants logiciels enfichables intégrés à  Windows 2000. L'OS permet également de créer sa propre interface d'administration : saisissez simplement mmc à  l'invite de commande et cliquez sur OK pour afficher un shell MMC vierge. Ensuite, ajoutez les composants enfichables pour les fonctions d'administration que vous voulez mettre en oeuvre.

Offrez la

Le module RPG IV CallerID permet d'identifier le programme ayant provoqué une modification d'une base de données. Vous êtes-vous jamais demandé ce qui se cachait à  l'autre bout de l'appel d'un programme trigger ? Eh bien, il est maintenant possible d'installer "CallerID" (gratuitement) pour permettre aux programmes trigger de déceler l'origine des modifications survenues dans la base de données.

Techniquement, des opérations internes sur les fichiers OS/400 telles que QDBPUT (Database add a record) et QDBUDR (Database update, delete, or release a record) entraînent l'appel d'un programme trigger. Toutefois, avec l'aide de quelques API de gestion des messages, il est possible d'identifier le programme qui se cache derrière ces opérations.

La connaissance de l'origine des modifications de la base de données peut se révéler fort utile. Envisageons les scénari suivants :

Attention: inondation. Etant donné que les triggers interceptent toutes les modifications effectuées dans un fichier base de données, ils peuvent se révéler efficaces pour assurer la cohérence des données dans une ou plusieurs applications. Mais, un fichier qui change fréquemment peut imposer une charge très importante à  un programme trigger. Aussi, afin de limiter le surcroît de travail de ce type de programme, on peut choisir de filtrer certaines des modifications pour que le programme trigger n'exécute pas l'intégralité de sa routine à  chaque fois qu'une modification est effectuée.

Supposons que vous utilisiez un programme trigger pour introduire des modifications démographiques effectuées par une application sur une autre, et que l'application effectuant les modifications stocke des informations démographiques et financières dans le même fichier. Supposons également que vous ayez un traitement de nuit sur ce fichier, qui ne met à  jour que les informations financières mais agit sur un grand nombre d'enregistrements. Plutôt que de comparer systématiquement les images de chaque champ "démographie" avant et après que le programme trigger ait été appelé, vous pouvez simplement filtrer les modifications effectuées par le traitement de nuit.

Surveiller toutes les issues. Peut-être essayez-vous de faire un contrôle qualité en surveillant la fréquence à  laquelle il est nécessaire de "glisser" des modifications dans une base de données du fait de limitations des applications existantes. Il est possible de calculer le nombre de fois que DFU (Data File Utility ), SQL ou un utilitaire base de données quelconque a été utilisé pour modifier certains fichiers de la base. Même si vos applications standards sont excellentes, vous pouvez souhaiter garder une trace des interventions réalisées sur les fichiers sans utiliser d'application, pour identifier des violations de sécurités potentielles, ou d'éventuels besoins en formation.

Eviter les boucles sans fin. Imaginons que vous utilisiez des programmes triggers pour transmettre des modifications démographiques entre une application A et une application B. Quand un fichier est mis à  jour dans l'application A, le programme trigger met à  jour le fichier associé de l'application B, et vice versa. Ce processus paraît clair et simple. Cependant, il se pose un problème lorsque le programme trigger de l'application A met à  jour un fichier de l'application B, obligeant le trigger de cette dernière à  mettre à  jour l'enregistrement original qui a été modifié dans l'application A. Ce cas de figure peut provoquer l'appel récursif du programme trigger de l'application A, d'où risque de bouclage.

Des boucles inutiles peuvent également poser problème lorsqu'une interface EDI (Echange de Données Informatisées) est utilisée entre deux systèmes. Une modification de la base de données d'un système se répercuter de système en système jusqu'à  ce que le système récepteur sache que la modification provient du système émetteur, et que par conséquent il n'est pas nécessaire de lui renvoyer la modification.

Trouver les erreurs des données numériques avec SQL

SQL permet d'identifier les données erronées avant que le système ne se crashe, et cela sans programmes personnalisés La présence de données erronées dans un fichier peut provoquer des problèmes quels que soient le programme, la requête ou l'instruction SQL tentant d'accéder aux données du champ. Lorsqu'un programme rencontre des données erronées, il génère le fameux message d'erreur “MCH1202 Erreur dans une donnée décimale” et parfois des messages différents (tels que CPF5035, RPG0907, QRY5053 ou encore SQL0802), selon le type de détection d'erreurs interne effectué. Les langages Query et SQL peuvent néanmoins afficher ou imprimer des caractères de substitution à  la place des données erronées, mais ils ne mettront pas à  jour ni n'inséreront d'enregistrementdans un fichier contenant des données erronées.

La présence de données erronées dans un champ numérique peut également influer sur les enregistrements contenant des données correctes. C'est le cas lorsqu'un champ contenant des données erronées fait partie d'une jointure avec un autre fichier et que le moteur de recherche doit créer un chemin d'accès. De plus, les enregistrements erronés sont souvent difficiles à  localiser, et il n'existe pas de méthode évidente pour les débusquer et vérifier qu'il n'en reste plus dans la base de données.

Fort heureusement, SQL propose des méthodes pour aider à  localiser les données erronées sans écrire de programmes personnalisés ni laisser le système les détecter en s'arrêtant brutalement. Ces méthodes bénéficient du fait que l'OS/400 ne considère les données numériques comme valides que lorsque certains octets occupent certaines positions dans un champ.

Utilisation de tableaux noirs avec des programmes trigger

Quand l'information envoyée avec un buffer de trigger ne suffit pas, les programmes de service de type "tableaux noirs" peuvent relayer des données supplémentaires entre applications et programmes triggers Avant les panneaux de messages et la diffusion de courriers électroniques, on utilisait des tableaux noirs pour afficher les informations importantes sur les lieux publics. Aujourd'hui encore, les professeurs utilisent des tableaux noirs face à  leurs élèves, et comment, sans eux, les bistrots annonceraient-ils leur plat du jour ? Vous ne savez peut-être pas que ces applications et les programmes triggers qu'elles invoquent peuvent aussi recourir à  une technique que je baptise tableau noir pour échanger des informations.

Si vous n'avez besoin (outre les informations contenues dans le buffer de trigger) que du nom du programme applicatif ayant déclenché le trigger, un tableau noir est peut-être superflu. Il existe un moyen plus simple d'obtenir le nom de l'application : envoyer un message fictif du trigger à  l'application, puis extraire le message. Pour plus d'informations à  ce sujet, lisez “ Offrez la présentation du numéro à  vos programmes ”, NEWSMAGAZINE, avril 1999. En revanche, s'il vous faut relayer des informations supplémentaires entre une application et son trigger, un tableau noir est peut être parfaitement indiqué.

Message Queue Server : mettez vos données en rangs serrés

Microsoft Message Queue Server permet de concevoir un système de files d'attente de messages à  l'échelle de l'entreprise, apportant un surcroît de fiabilité et de sécurité aux applications transactionnelles. Les développeurs qui créent des applications transactionnelles (ou TP - par exemple pour les transactions boursières, les transactions bancaires ou le contrôle de fabrication), doivent s'assurer non seulement que ces applications traitent les transactions avec précision, mais également qu'elles transfèrent les données d'un processus à  un autre sans risque et méthodiquement.
Les données perdues ou dans le désordre réduisent à  néant l'objectif même d'une application TP. Voilà  pourquoi, les développeurs font souvent appel à  la technique des files d'attente de messages(Message Queuing en anglais), pour garantir une livraison fiable des données dans les applications TP. Un système de file d'attente augmente la fiabilité des échanges entre processus en utilisant un processus émetteur pour mettre les données dans une file d'attente et un processus récepteur pour les récupérer dans la file d'attente.

Traditionnellement, les développeurs développaient jusqu'ici leurs propres systèmes de files d'attente de messages ou se procuraient ces systèmes chez un éditeur différent de celui de leur OS. Le développement d'un système de files d'attente de messages sophistiqué exige de la part des développeurs d'être versés dans la communication de réseau de sous-couche, comme les protocoles de transport et l'acheminement des messages.

MSMQ permet de concevoir et mettre en oeuvre un système de files d'attente de messages au niveau de toute l'entreprise

Bien que les solutions du marché offrent des réponses immédiates, l'acquisition et la maintenance d'une technologie de ce type peut revenir cher. Microsoft propose sa technologie de files d'attente de messages Microsoft Message Queue Server (MSMQ), intégrée à  Windows NT 4.0 édition Entreprise (NTS/E) et à  l'Option Pack de Windows NT Server 4.0. MSMQ permet de concevoir et mettre en oeuvre un système de files d'attente de messages au niveau de toute l'entreprise pour supporter toutes les applications d'un réseau NT. Le SDK (Software Development Kit) de MSMQ permet de développer des applications de files d'attente de messages customisées sans devoir programmer une communication directe entre processus ni connaître la sous-couche réseau.
MSMQ est un véhicule crucial pour l'échange des messages dans votre réseau NT. Cet article a pour objet de vous aider à  comprendre la technologie de files d'attente des messages et l'application, par MSMQ, de cette technologie.

IBM Enterprise Suite pour NT :

Pour utiliser Windows NT Server 4.0 dans votre entreprise, vous avez besoin d'applications pour mettre sur pied votre infrastructure d'informations. Il vous faut un serveur de bases de données, un serveur de messagerie et une solution de contrôle et d'administration à  distance. En dehors de BackOffice de Microsoft, le choix est limité. Vous pouvez essayer d'intégrer des éléments provenant de divers éditeurs et espérer qu'ils interagissent, mais il existe une autre solution : les suites d'IBM pour Windows NT. L'IBM Enterprise Suite for Windows NT est un ensemble de packages qui offre davantage de fonctionnalité sous Windows NT que BackOffice lui-même. Les composants middleware des suites IBM aident à  une exploitation maximale du système.

Au coeur de la gestion de la mémoire sous Windows NT (II)

2ème partie

Dans notre numéro de novembre, nous avons commencé cette série en deux parties sur la gestion de la mémoire dans Windows NT en introduisant le concept de mémoire virtuelle. Nous avons vu l'utilisation par le processeur d'un système de traduction d'adresses virtuelles en adresses physiques à  deux niveaux. Nous avons évoqué la pagination et deux puissantes fonctions du Gestionnaire de mémoire : le mapping de fichiers en mémoire et la mémoire copy-on-write. Ce mois-ci nous allons détailler encore les structures de données internes utilisées par le Gestionnaire de mémoire pour faire le suivi de l'état de la mémoire. Nous évoquerons les working sets et la base de données PFN (Page Frame Number). Nous terminerons par une exploration d'autres structures de données utilisées par le Gestionnaire de mémoire pour faire le suivi de la mémoire partagée par deux ou plusieurs applications, et nous aborderons les Objets de section, structures de données utilisées par la base de données PFN pour mettre en oeuvre le mapping des fichiers en mémoire.

Windows NT contre Unix : y-a-t-il un gagnant ?

Les parts de marché grignotées par Windows NT ayant fini par éroder la domination d'Unix, le débat continue à  faire rage sur la supériorité éventuelle de l'un des deux OS. Beaucoup d'utilisateurs prétendent avec une ferveur quasi religieuse que, quel que soit le système d'exploitation, le meilleur est celui avec lequel on a travaillé en premier. Dans le clan Unix, en particulier, certains sont apparemment convaincus qu'il suffit de vanter haut et fort les mérites d'Unix pour endiguer la marée Windows NT.
Ce débat brûlant met en lumière, non sans ironie, que l'origine des deux OS remonte au milieu des années soixante-dix et qu'ils ont tous deux été influencés en grande partie par des concepts et des théories identiques. Personne ne sera surpris de découvrir que Windows NT et Unix ont beaucoup de similitudes, mais aussi de différences. Cet article va traiter en parallèle Windows NT et Unix et comparer leurs architectures, avec un examen des principales caractéristiques de chacun : gestion des processus, ordonnancement, gestion de la mémoire et traitement des I/O. Il se terminera par une présentation des résultats des mesures les plus objectives disponibles, à  savoir les résultats des benchmarks reconnus par l'industrie.

Enfin, il abordera la question qui s'impose dans toute comparaison : " Quel est le meilleur des deux OS ? "Peu importe de quel côté du débat Windows NT-Unix vous vous trouvez, quelques surprises vous attendent.

RDP ou ICA : encore une victime de la vitesse

Tout le monde le sait dans le domaine automobile, la vitesse tue. Mais ce qui est vrai pour les voitures s'applique également à  l'informatique, particulièrement aux deux principales technologies de clients légers offertes aux utilisateurs de Windows NT.Le slogan " la vitesse tue " convient très bien aujourd'hui à  la technologie du client léger ou thin client, bien que dans un registre légèrement différent (je doute que quiconque ne succombe pour avoir utilisé un produit trop rapide ou trop lent). Le slogan colle particulièrement bien à  la rivalité entre deux implémentations concurrentes des clients légers pour Windows NT : ICA (Independent Computing Architecture) de Citrix et RDP (Remote Desktop Protocol) de Microsoft. En effet, si l'un des deux (ou en l'occurrence les protocoles sous-jacents) l'emporte par la vitesse, le client le plus lent mourra, sera enterré et vite oublié.

Pourquoi la vitesse est-elle si importante sur ce marché ? Dans la technologie du client léger, un serveur central pousse tous les bits, qui composent l'image du bureau, jusqu'au client via le réseau. Par exemple, lorsque l'on démarre, redimensionne ou arrête les applications du bureau, le serveur doit pousser tous les bits affectés pour repeindre l'écran du client léger. Il n'est pas difficile d'imaginer qu'il faut une bonne dose de bande passante pour déplacer des bits d'affichage.

Comme l'interaction client-serveur est très gourmande en bande passante, l'efficacité du client est extrêmement importante. On peut convenir sans risque que dans un environnement de type réseau local, le client ICA et le client RDP offrent des performances similaires. Dans un environnement WAN ou dans un environnement commuté, le client ICA offre de meilleures performances que le client RDP, car Citrix a développé son client ICA pour les connexions modem lentes.

Comme l'interaction client-serveur est très gourmande en bande passante, l'efficacité du client est extrêmement importante

Une fois dressé ce tableau général, l'examen détaillé de chaque client se complique. Par exemple, le client ICA supporte le son, mais pas le client RDP. Or l'ajout du son demande plus de bande passante. De même le client ICA pour Windows 32 bits peut mettre en mémoire cache les bits des icônes, ce qui, théoriquement, accélère les opérations d'affichage. Les clients RDP pour Windows 16 et 32 bits ne peuvent pas mettre en mémoire ces mêmes bitmaps.

Un autre facteur vient compliquer l'étude des performances : le système d'exploitation des clients. Par exemple, un client ICA tournant sur un terminal avec un OS propriétaire risque d'être plus rapide qu'un client ICA tournant sur un terminal Windows CE. De même un client RDP tournant sur un terminal Windows NT ou Windows 95 sera sans doute plus rapide que ce même client RDP sur un terminal Windows CE. Comparer la rapidité de différentes implémentations de client léger n'est donc pas évident.