Skip to main content

Comprendre la compatibilité des applications

Plusieurs raisons peuvent expliquer pourquoi une application qui fonctionnait sur les versions précédentes de Windows ne fonctionne plus dans Windows 8 tant que vous n'avez rien fait pour corriger cette application. Parmi toutes ces applications qui ne fonctionnent pas, combien dépendent, à une grande échelle, de la version de Windows que vous utilisez aujourd'hui. La transition de Windows XP à Windows Vista a sans aucun doute été la plus difficile au cours de ces dernières années. En comparaison, Windows 7 a été extrêmement compatible avec Windows Vista et Windows 8 s'avère être extrêmement compatible avec Windows 7. Par conséquent, si vous utilisez Windows Vista ou une version ultérieure, vous aurez probablement de la chance et vous ne devriez pas rencontrer de difficultés lors de la migration de vos applications vers Windows 8 ! Si vous utilisez toujours Windows XP (ou, gloups !, une version encore plus ancienne de Windows), vous avez probablement un peu plus de travail qui vous attend. Toutefois, comme l'ont démontré de très nombreux clients, ce défi est tout à fait surmontable et peut être relevé à condition d'adopter la bonne approche de la compatibilité des applications.

Pourquoi les applications cessent-elles de fonctionner lorsque vous migrez vers un système d'exploitation plus récent ? Dans certains cas, cela vient du fait qu'une application dépend d'un comportement non documenté du système d'exploitation, soit parce que le développeur a intentionnellement utilisé une API non documentée, soit parce qu'il s'est accidentellement appuyé sur un comportement qui s'est ensuite avéré être plus une coïncidence qu'une promesse. Aujourd'hui, avec une documentation aussi importante que celle proposée par MSDN, il est probablement difficile de comprendre totalement tous les comportements possibles du système d'exploitation ! Il arrive que des fonctionnalités ou des comportements soient abandonnés, souvent en raison de problèmes de sécurité, mais aussi par manque d'adoption sur le marché ou à cause d'un remplacement par une technologie supérieure. Mais il est surtout désespérant de constater que la cause la plus fréquente d'un échec de compatibilité d'une application est la vérification de version. En fait, l'application vérifie la version du système d'exploitation, puis elle choisit d'échouer intentionnellement si elle détecte une version autre que celle sur laquelle elle choisit d'être exécutée. Pour résumer, l'application refuse de vous laisser essayer de l'exécuter sur le nouveau système d'exploitation, alors qu'elle fonctionnerait parfaitement sans cette vérification !

Si vous êtes intéressé par des détails plus spécifiques, consultez le Guide pratique sur la compatibilité des applications Windows 8 et Windows Server 2012 qui vous expliquera les modifications en termes de compatibilité. Notez cependant que ce guide pratique est surtout destiné aux développeurs qui écrivent du code. En revanche, cet article se place du point de vue des professionnels de l'informatique qui tentent de migrer leurs organisations vers Windows 8. Nous parlerons ici de ce qui a motivé les modifications apportées à Windows 8, ainsi que de l'impact potentiel de ces modifications.

Les thèmes suivants sont abordés dans cet article :


Fiabilité accrue

Alors que Microsoft continue à améliorer la sécurité et la fiabilité globales du système d'exploitation, nous avons réalisé qu'aucun de ces investissements ne pouvait être totalement concrétisé si la majorité des utilisateurs se connectait en tant qu'administrateur local. Bien sûr, c'était le cas auparavant pour des raisons historiques. MS-DOS, puis les premières versions de Microsoft Windows, ne connaissaient absolument pas les concepts d'ordinateurs partagés et de vérifications de sécurité. Windows NT offrait non seulement une infrastructure de sécurité solide, mais également une compatibilité avec des applications MS-DOS et Windows existantes qui n'avaient jamais été conçues pour un système d'exploitation multi-utilisateur sécurisé. De nombreux clients se reposaient sur ces applications et ont donc conservé leurs utilisateurs en tant qu'administrateurs locaux. Toutefois, la gestion des utilisateurs administrateur a un coût nettement plus élevé que celle des utilisateurs standard et les clients du monde entier réclamaient une solution pour avoir un pourcentage plus important d'utilisateurs standard. Certains y sont bien évidemment arrivés, mais ce fut presque toujours un processus cher et douloureux et plusieurs brèches ont alors dû être ouvertes dans la configuration de la sécurité du système d'exploitation pour prendre en charge des applications qui reposaient sur les privilèges administrateur.

Dans Windows Vista, nous avons introduit la fonctionnalité Contrôle de compte d'utilisateur (UAC) pour mettre enfin un terme au cycle des administrateurs locaux sur lequel reposaient les applications qui dépendaient des droits d'administrateur locaux et avaient donc besoin d'un plus grand nombre de ces administrateurs. Les clients ont enfin pu réduire de façon significative le coût total des opérations et améliorer leur situation en termes de sécurité avec un environnement utilisateur standard. Cette fonctionnalité était avant tout une fonctionnalité de compatibilité. Elle fournissait des solutions automatisées à un certain nombre de problèmes de compatibilité, par exemple l'écriture dans des fichiers ou le Registre situés dans des emplacements protégés ou l'échec de programmes d'installation qui reposaient sur des autorisations administrateur pour une installation dans des emplacements globaux. Elle offrait également des options de correction supplémentaires qui pouvaient être appliquées aux applications afin de résoudre des problèmes de compatibilité supplémentaires liés à l'exécution d'applications avec des autorisations utilisateur standard.

Outre la correction des applications tierces, le Contrôle de compte d'utilisateur améliorait l'expérience des utilisateurs standard de plusieurs façons. Par exemple, nous avons alors permis aux utilisateurs standard de modifier leur fuseau horaire lorsqu'ils voyageaient (une réclamation très courante de la part des clients qui réussissaient à déployer les utilisateurs standard sur Windows XP ou les versions antérieures). Nous avons également introduit une nouvelle infrastructure de sécurité reposant sur l'approbation des applications, outre l'identité des utilisateurs, ce qui nous a permis de mettre en œuvre le comportement de bac à sable. Des logiciels tels que les applications Internet Explorer et Microsoft Office 2010 se sont servis de ces bacs à sable pour améliorer en profondeur leur sécurité. Windows 8 étend encore plus cette infrastructure de sécurité reposant sur la confiance grâce aux conteneurs d'applications.

Notez que, dans la mesure où la fonctionnalité UAC fournit l'infrastructure de sécurité aux conteneurs d'applications, si vous la désactivez, vous ne pourrez pas exécuter les applications du Windows Store. C'est la raison pour laquelle les clients qui ont choisi de désactiver UAC pour Windows Vista ou Windows 7 devraient maintenant fortement envisager de l'activer pour Windows 8 et de résoudre les problèmes de compatibilité avec les utilisateurs standard qui les ont probablement poussés à désactiver UAC initialement.

UAC offre des avantages concrets même pour les administrateurs locaux. Si les administrateurs locaux sont exécutés avec des informations d'identification de sécurité fortement similaires à celles des utilisateurs standard la plupart du temps, les utilisateurs qui ont le plus souvent légitimement besoin de conserver des droits d'administrateur locaux (développeurs et administrateurs informatiques) peuvent avoir un environnement dans lequel les logiciels et les scripts qu'ils créent n'entraînent pas de dépendances accidentelles supplémentaires par rapport aux droits d'administrateur locaux. Ce changement a déjà eu un impact significatif sur les fournisseurs de logiciels indépendants qui créent désormais des logiciels dont l'exécution ne pose presque jamais de problèmes avec les droits d'utilisateur standard grâce à UAC. L'impact a été le même au sein des entreprises.

Dans Windows Vista et dans les versions ultérieures, nous avons également ajouté une fonctionnalité nommée Protection des ressources Windows (WRP), qui utilise une autre extension de l'infrastructure de sécurité Windows : la capacité de sécuriser les ressources afin de permettre uniquement l'accès à un service particulier plutôt qu'en fonction de l'identité du compte sous laquelle le service est exécuté. Il est ainsi particulièrement difficile pour une application (presque toujours un programme d'installation qui comprenait toutes les dépendances DLL lors de sa création) d'écrire accidentellement une copie d'une très ancienne version d'un système DLL Windows NT 4.0 (par exemple, shell32.dll) sur la copie utilisée par Windows 8, ce qui, comme vous pouvez l'imaginer, a des conséquences relativement catastrophiques ! Désormais, seul le service qui gère Windows Update (le service du programme d'installation pour les modules Windows) est capable de modifier ces fichiers par défaut. Bien évidemment, nous avons également fourni des options de correction pour ces applications afin que l'échec d'écriture dans ces fichiers n'entraîne pas l'échec irrémédiable de vos applications !

Retour au début


Renforcement de la sécurité

Presque par définition, le renforcement de la sécurité signifie que vous empêchez le déroulement de certaines choses et que vous ne donnez pas la possibilité aux méchants d'effectuer ces choses. Toutefois, il est possible que les applications dépendent de la capacité à faire certaines de ces choses, particulièrement dans le cadre d'applications plus anciennes développées avant que nous ne découvrions comment ces méchants pouvaient exploiter une capacité pour faire de mauvaises actions. Dans certains cas, nous avons ajouté la capacité de bloquer un nouveau comportement. Dans d'autres, nous avons modifié les paramètres par défaut de façon à bloquer un comportement par défaut alors que celui-ci était autorisé par défaut auparavant et que nous vous demandions de choisir de le bloquer.

Le mode de protection d'Internet Explorer, par exemple, fournit un bac à sable de sécurité qui limite grandement la capacité d'accéder au système d'exploitation pour les contrôles ActiveX hébergés sur une page. Depuis Internet Explorer 8, le mode protégé est activé par défaut dans les zones Internet et Sites sensibles. De nombreux clients qui dépendent des contrôles ActiveX découvrent que leurs tailles internes ne définissent pas correctement la zone Intranet local (mode protégé désactivé par défaut) et trouvent donc que ces applications sont moins compatibles.

Microsoft a ajouté la prise en charge du système d'exploitation pour la prévention de l'exécution des données (DEP) avec Windows XP SP2. DEP est une fonctionnalité de protection de mémoire prise en charge dans les logiciels et le matériel. Elle réduit de façon significative les risques d'attaques contre le système par un programme malveillant à l'aide de techniques telles que les dépassements de mémoire tampon. Elle offre une protection contre le code malveillant injecté à travers les points d'entrée de données d'une application. Toutefois, Windows 8 conserve la configuration DEP qui permet des choix afin d'optimiser la compatibilité. De nouvelles applications du Windows Store incluront DEP, mais les restrictions DEP seront appliquées dans les applications de bureau existantes uniquement si elles acceptent cette fonctionnalité. Internet Explorer proposait la fonctionnalité d'acceptation de DEP depuis Internet Explorer 7, mais il l'a activée par défaut depuis Internet Explorer 8. Cela signifie que les contrôles ActiveX qui génèrent et exécutent du code activement, mais qui ne sont pas parvenus à marquer la mémoire comme exécutable, entraîneront la génération d'une exception (qui, si elle n'est pas gérée par l'application, provoquera un arrêt brutal de l'application) à chaque tentative d'exécution du code.

Pour les clients qui migrent encore depuis Windows XP ou des versions antérieures, l'isolation de la session 0 posera peut-être encore quelques problèmes lors du passage à Windows 8. Un service Windows est historiquement exécuté dans la session 0 et il continue à l'être aujourd'hui. Dans Windows XP et les versions antérieures, le premier utilisateur qui se connectait à l'ordinateur travaillait également dans la session 0. Lorsque les ressources de l'ordinateur étaient bien plus limitées, cette approche était plus efficace. Toutefois, même si elle utilisait les ressources avec parcimonie, cette solution exposait une zone de sécurité non négligeable puisque les applications généralement exécutées avec des privilèges de système local cohabitaient avec d'autres applications exécutées avec nettement moins de privilèges, ce qui offrait une occasion tentante d'élévation de privilège. C'est la raison pour laquelle les utilisateurs ne sont plus connectés à la session 0 qui est uniquement réservée aux services. Les applications de service qui s'attendent à pouvoir communiquer directement avec l'utilisateur ou ses programmes doivent souvent trouver de nouveaux mécanismes pour cette communication.

Nous continuons à ajouter des fonctionnalités de sécurité à Internet Explorer étant donné qu'il s'agit de la partie du système d'exploitation la plus souvent en contact avec des agents potentiellement malveillants. Par exemple, la fonctionnalité Protection contre le tracking disponible dans Internet Explorer 9 et Internet Explorer 10 permet aux utilisateurs de protéger la confidentialité de leurs données en bloquant les agents de tracking énumérés. Toutefois, la plupart des sites qui suivent le comportement en ligne sont également ceux qui proposent une fonctionnalité d'application Web. Le chargement et l'exécution de nombreux scripts peuvent donc échouer lorsque ceux-ci se trouvent dans un domaine bloqué par l'une de vos listes Protection contre le tracking.

De la même manière, la fonctionnalité Filtre SmartScreen disponible dans Internet Explorer permet de vous protéger contre des téléchargements malveillants. Dans Internet Explorer 8, le filtre SmartScreen vous protégeait contre une liste de téléchargements malveillants connus. Depuis Internet Explorer 9, cette fonctionnalité a été améliorée de façon à ajouter la réputation. Les téléchargements doivent ainsi se créer une réputation avant de pouvoir être signalés comme bons, faute de quoi un avertissement est généré afin d'indiquer que le téléchargement est nouveau et que l'on ignore encore s'il est bon. Windows 8 reprend ce concept pour l'appliquer au système d'exploitation, ce qui vous permet de vous protéger contre les téléchargements qui ne bénéficient pas encore d'une réputation positive, et ce quel que soit le navigateur utilisé pour les obtenir. Toutefois, cela peut entraîner des échecs dans certains cas, lorsque vous téléchargez des fichiers exécutables qui changent souvent mais ne sont pas signés, ou si vous effectuez uniquement des téléchargements occasionnels dont le nombre a été insuffisant pour développer une réputation de l'application.

Retour au début


Amélioration des performances et des fonctionnalités

En ce qui concerne la migration vers la dernière version de Windows, l'une des modifications les plus couramment mentionnées par les entreprises clientes est la capacité à bénéficier des fonctionnalités et des performances d'un système d'exploitation 64 bits. Bien que la version 64 bits permette d'exécuter des applications qui ont besoin d'accéder à de grandes quantités de mémoire, et qu'elle vous donne la possibilité de bénéficier de beaucoup de RAM, elle peut avoir un impact sur la compatibilité. Bien que le système Windows 64 bits puisse exécuter vos applications 32 bits existantes, il ne peut pas exécuter vos applications 16 bits existantes. En outre, il ne prend pas en charge vos pilotes de périphériques 32 bits existants. Si vous disposez d'un périphérique qui n'a pas de pilote 64 bits, ou si vous utilisez des applications 16 bits stratégiques, vous devrez les exécuter sur un système d'exploitation 32 bits.

Lorsque vous exécutez un système Windows 64 bits, les applications .NET qui interopèrent avec du code natif, via COM Interop ou P/Invoke Interop, risquent également de rencontrer des problèmes. Le paramètre de compilateur par défaut pour les applications .NET se nomme « N'importe quelle UC », ce qui signifie que ces applications deviendront des applications 64 bits sur un système d'exploitation 64 bits, mais qu'elles seront des applications 32 bits sur un système d'exploitation 32 bits. Si elles font appel à du code natif, celui-ci devra être du même type (32 ou 64 bits) que l'application qui l'appelle. Par conséquent, si l'application appelle un code natif et que celui-ci est compilé en 32 bits, l'appel ne parviendra pas à charger la DLL. Fort heureusement, il s'agit d'un problème relativement simple à résoudre, soit en changeant le paramètre de compilateur, soit en modifiant l'exécutable directement à l'aide de l'utilitaire CorFlags. Nous prenons cependant le temps de mentionner ce point en raison de la fréquence à laquelle il semble toucher les applications des clients en entreprise.

Windows Vista propose un nouveau mode d'affichage nommé Gestionnaire de fenêtres du Bureau (DWM). DWM a changé le modèle historique dans lequel les applications étaient rendues directement dans une mémoire à l'écran. En effet, les applications sont désormais rendues en bitmaps hors écran, bitmaps qui sont ensuite composées par le DWM afin de créer l'affichage vu par l'utilisateur. Cette approche présente des avantages importants pour les performances et l'expérience utilisateur. Toutefois, plusieurs types d'applications sont incompatibles avec le DWM. Dans le cadre d'une entreprise, ce sont surtout les applications de communication à distance qui ont été touchées et qui utilisaient donc souvent des pilotes miroir pour rediriger l'affichage. Depuis Windows 8, il n'est plus possible de désactiver le DWM puisqu'il est désormais au cœur du fonctionnement du système d'exploitation. Bien que nous ayons fait de notre mieux pour que la plupart des applications continuent à fonctionner, les applications qui utilisent des approches historiques ne fonctionneront pas toujours.

La durée de vie des batteries est l'un des aspects les plus importants pour les utilisateurs mobiles en termes de performances. Avec le nouveau modèle des applications du Windows Store dans Windows 8, les applications ne sont pas seulement plein écran et immersives, elles sont également suspendues lorsqu'elles ne sont pas visibles. Elles ne consomment pas de cycles du processeur et ne vident donc pas la batterie. Toutefois, historiquement, les applications existantes ont toujours été en cours d'exécution, c'est-à-dire qu'elles ont toujours consommé du processeur et de la batterie, du moment où vous les démarrez jusqu'à leur fermeture. Afin de permettre aux utilisateurs d'allonger la durée de vie des batteries comme ils l'espèrent (et l'attendent), même avec les applications de bureau existantes, Windows 8 met des actions en œuvre pour limiter les applications de service existantes (en appliquant des restrictions à la quantité d'UC utilisée) et pour suspendre les applications interactives lorsqu'elles ne sont pas utilisées et que l'écran est arrêté. Bien que cela réponde aux attentes de l'utilisateur (lorsque vous appuyez sur le bouton de mise en marche de votre appareil mobile, vous vous attendez à ce que votre application cesse d'être exécutée à plein régime), vous risquez de rencontrer des problèmes avec les applications qui ne prévoient pas une suspension. Fort heureusement, cet impact est relativement minime.

Retour au début


Convivialité avancée

Alors que les écrans d'ordinateur sont de plus en plus petits tout en contenant de plus en plus de pixels, il est important de modifier l'affichage de façon à ce que tout soit plus grand, avec les mêmes capacités d'affichage complètes et non interpolées. Windows prend en charge le mode haute résolution depuis plusieurs versions et cette prise en charge est améliorée avec chaque version. Depuis Windows 7, cette prise en charge est suffisamment solide pour commencer à détecter et à utiliser par défaut les paramètres de haute résolution les plus appropriés en fonction de l'affichage. Toutefois, les paramètres de haute résolution restent un problème dans certaines applications et si une grande partie des appareils que vous avez l'intention de déployer a besoin de cette fonctionnalité, il serait judicieux de tester vos applications avec ce scénario.

Retour au début


Suppression des composants hérités

Bien que nous fassions de notre mieux pour garantir la compatibilité avec les applications héritées, il arrive que la prise en charge d'une fonctionnalité ne soit plus possible, soit parce que cela bloque notre capacité à fournir une nouvelle fonctionnalité supérieure, soit parce que cette fonctionnalité présente des défauts qui nous empêchent d'atteindre nos objectifs en termes de performances, de fiabilité ou de sécurité. Le cas échéant, nous cessons de prendre en charge cette fonctionnalité. Bien qu'il ne s'agisse pas d'une liste exhaustive, voici quelques suppressions de fonctionnalités obsolètes qui ont entraîné des soucis de compatibilité dans les entreprises et qu'il est intéressant de mentionner ici.

Commençons par Windows Vista, dans lequel nous avons supprimé la prise en charge des pilotes d'imprimante en mode noyau. Nous avons effectué cette suppression pour des motifs de fiabilité. En effet, une défaillance du pilote en mode noyau provoque l'affichage d'un écran bleu d'erreur générale de tout le système, tandis que la défaillance d'un pilote en mode utilisateur provoque l'arrêt du pilote uniquement. En général, nous avons exclu tout ce que nous pouvions du mode noyau, particulièrement lorsque la fiabilité était un problème, sans compromettre notre capacité à atteindre nos objectifs en termes de performances. Bien que la plupart de nos clients ne disposent plus d'imprimantes qui fournissent uniquement des pilotes en mode noyau, nous rencontrons parfois des imprimantes et des traceurs particulièrement haut de gamme qui, en raison de leur prix, ont une durée de vie supérieure à la moyenne. Nous rencontrons surtout des problèmes avec les imprimantes virtuelles, par exemple celles qui génèrent des fichiers PDF. En effet, les versions plus anciennes de ces imprimantes utilisent souvent des pilotes en mode noyau qui ne seront plus exécutés.

Nous avons également procédé au retrait progressif des fichiers WinHelp comme format de fichier d'aide. Ce format de fichier avait été lancé en 1990 pour Windows 3.0. Nous avons présenté son successeur, HTML Help, en 1997 avec Internet Explorer 4.0. Nous avions continué à prendre en charge les fichiers WinHelp, mais le problème de zone de sécurité supplémentaire avec Windows Vista nous a conduit à supprimer WinHelp du système d'exploitation lui-même. Le contenu des fichiers d'aide était si puissant dans ce format que l'on obtenait l'équivalent d'un fichier exécutable. Toutefois, étant donné le volume important de contenu WinHelp généré depuis plus de 20 ans de prise en charge, nous continuons à fournir une prise en charge téléchargeable pour Windows Vista et Windows 7, et nous ferons de même pour Windows 8.

La façon dont vous vous connectez à Windows est extensible depuis longtemps, mais le mécanisme utilisé depuis toujours ne permettait la connexion que d'un seul fournisseur à la fois. Avec ce mécanisme, les fournisseurs devaient également développer tout le code et créer la totalité de l'expérience utilisateur pour le processus de connexion. Depuis Windows Vista, nous avons remplacé de modèle par celui du fournisseur d'informations d'identification dans le cadre duquel les développeurs doivent seulement implémenter la partie de l'authentification qui diffère de celle déjà fournie. En outre, ce modèle permet à plusieurs fournisseurs de travailler ensemble. Toutefois, en raison de ce changement d'architecture, les applications ayant fourni une autre méthode de connexion pour Windows XP ou une version antérieure doivent être réécrites.

Retour au début


Résumé

Cet article nous a permis d'explorer certains des investissements qui ont été faits dans Windows et qui pourraient avoir un impact inverse sur la compatibilité de vos applications existantes. La compatibilité est le credo du développement de Windows depuis longtemps et nous prenons toujours très au sérieux les régressions de compatibilité. J'espère que cet article vous aura permis de comprendre certaines des motivations qui ont entraîné ces changements, ainsi que les compromis que nous devons faire et que vous devez faire.

Bien que la transition de Windows XP ou des versions antérieures vers Windows 8 connaisse souvent un taux d'échec de 20 % ou plus (si vous utilisez des logiciels particulièrement anciens et que vous exécutez des ordinateurs de bureau en tant qu'administrateur local aujourd'hui), vous disposez d'un certain nombre d'options de correction pour remédier rapidement à la plupart de ces échecs et vous permettre de vous concentrer rapidement sur les applications qui ont besoin d'actions plus importantes. Le taux d'échec d'une migration de Windows Vista ou d'une version ultérieure vers Windows 8 semble avoir été très faible jusqu'à présent, bien inférieur à 10 % (le coupable principal étant ces pénibles vérifications de versions codées en dur). Vous devriez donc pouvoir étendre et optimiser vos investissements en ressources logicielles encore plus longtemps avec Windows 8. Bonne chance dans la mise en œuvre de vos efforts de compatibilité !

Retour au début

Tâches importantes

À propos de l'auteur

Photo de Chris JacksonChris Jackson, alias «  le superman de la compatibilité des applications », est conseiller en chef chez Microsoft et responsable technique de l'équipe d'intervention Windows Application Experience SWAT Team. Expert reconnu dans le domaine de la compatibilité des applications Windows, Chris a créé la documentation technique et les offres de formation et de service utilisées au sein et en dehors de Microsoft, exploitant avec savoir-faire sa longue expérience auprès de clients d'entreprise et d'éditeurs de logiciels indépendants.

Chris est l'auteur et le co-auteur de nombreux documents techniques et articles sur la compatibilité des applications, et contribue à l'élaboration de TechNet Magazine. Il est également conférencier vedette lors de conférences majeures du secteur informatique dans le monde entier, y compris TechEd, IT Forum et Microsoft Management Summit.

Ressources connexes

Rester informé