{"partition": "head_middle", "source_domain": "www.nextinpact.com", "digest": "sha1:DV26QXAMDOWX2VTXNAR2FNBVOSPQBVPJ", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00019.parquet"}
Accueil > Logiciel > OS > Un brevet pour préserver la compatibilité de Windows
Un brevet pour préserver la compatibilité de Windows
La vraie panacée ?
La compatibilité sur les systèmes Windows est un cheval de bataille pour Microsoft. Consentante ou non, la firme n’a pas le choix, car c’est clairement l’un des critères majeures lors du passage d’une version spécifique à une plus récente. La garantie de pouvoir faire fonctionner les anciens logiciels est aussi importante que les nouveautés en elles-mêmes.
Lorsqu’une nouvelle version de Windows arrive, c’est le branle-bas de combat général, et le thème se répète inlassablement à chaque fois. Durant la première année qui suit, de nombreux logiciels apparaissent sur la liste des incompatibilités. À partir de là, c’est un travail de longue haleine qui est effectué par Microsoft d’un côté, et par les éditeurs tiers de l’autre.
La solution actuelle au défi
Actuellement, Microsoft emploie une méthode particulière, qui a ses avantages et ses inconvénients. Le principe est simple : écrire des morceaux de code spécifiques aux applications qui causent des problèmes pour les faire fonctionner sur le nouveau système. Actuellement, des milliers de ces morceaux de code sont dans Vista, tandis que d’autres sont en cours d’écriture. L’avantage est que cette méthode est rapide, mais elle implique un processus spécifique à chaque application problématique.
Ce qui serait possible
D’un autre côté, on parle beaucoup de la virtualisation. Microsoft a laissé plusieurs fois entendre qu’elle pourrait jouer un rôle très important dans les prochaines versions de Windows, sans en dire davantage. On imagine facilement que cette solution pourrait permettre la création d’un système neuf faisant table rase du passé. D’un autre côté, la virtualisation des anciennes applications a ses propres problèmes, tels que des soucis d'isolation qui perturbent la communication à divers degrés entre le système hôte et le système invité. Un fossé énorme entre les anciennes et nouvelles technologies pourrait ralentir ou compromettre la bascule des développeurs. On observe d’ailleurs ce phénomène avec Vista et l’environnement .NET 3.0.
Un brevet qui reprend un peu des deux mondes
Et si la solution était en quelque sorte un mélange de la situation actuelle et du thème de la virtualisation ? Un brevet déposé par Microsoft en avril 2007 et publié récemment pourrait donner des indications précieuses sur les intentions de l’éditeur quant au cours actuel de la réflexion. Le brevet est signé par Hoi Vo et Samer Arafeh, qui travaillent dans l’équipe chargée du développement du noyau de Windows.
Tous les problèmes de compatibilités proviennent des fichiers binaires DLL et EXE. Les appels lancés vers le système ne trouvent pas nécessairement de réponses favorables dans un nouvel environnement, car les choses s’y passent globalement de manière différente. La solution proposée dans le brevet serait donc non pas d’intervenir directement sur le logiciel, ni de créer une vaste couche de virtualisation, mais de placer des modules de compatibilité optionnels, que le système peut appeler ponctuellement en cas de besoin.
Fonctionnement et avantages supposés
La première étape est d’identifier pour quel système l’application a été initialement conçue. Une fois ce premier travail rapide effectué, un Application Compatibility Module (ACM) est appelé par le système pour orchestrer la conversion entre les appels système de l’application et leur équivalent dans le nouveau Windows. Les avantages sont en théorie multiples :
La consommation des ressources est bien plus faible que dans le cas de la virtualisation
Les performances sont meilleures, car il n’y a aucune émulation
Les applications peuvent toujours accéder directement au matériel, ce qui est vital dans le cas d’une application utilisant la 3D par exemple
Ce système peut être utilisé pour des applications 16 bits sur un environnement 32 bits et pour des applications 32 bits sur un environnement 64 bits
Les ACM peuvent n’être chargés qu’au lancement d’une application ayant des besoins particuliers (hypothèse logique)
Les développeurs n’ont plus besoin d’écrire des morceaux de code spécifique à une application donnée, du moins en théorie
Reste à savoir maintenant si Microsoft utilisera réellement un tel système, et pour quelle version de Windows.