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
Vincent Hermann
Rédacteur/journaliste spécialisé dans le logiciel et en particulier les systèmes d'exploitation. Ne se déplace jamais sans son épée.
Le 11 février 2008 à 16:31
(22 978
lectures)
Il y a 61 commentaires
Mais seuls les modules noyau nécessaires à la machine sont chargés il me semble, donc c'est pas très problématique niveau performances.
magnifique, le brevet décrit exactement ce qui ce passe quand on lance linux-opera sous FreeBSD.
( ou tout autre logiciel du monde linux dans FreeBSD )...
Bravo Microsoft d'avoir déposé la compatibilité binaire qui existe depuis 25 ans sur les Unices. . .
( ou tout autre logiciel du monde linux dans FreeBSD )...
Bravo Microsoft d'avoir déposé la compatibilité binaire qui existe depuis 25 ans sur les Unices. . .
Commentaire de
Ozzonn supprimé
le
01/01/1970 à 00:00:00
:
Réponse à un commentaire supprimé
wine for windows ... quelle évolution !
A quand la guerre des brevets du monde unix contre MS ? ;)
Edité par gRRosminet le lundi 11 février 2008 à 17:03
A quand la guerre des brevets du monde unix contre MS ? ;)
Edité par gRRosminet le lundi 11 février 2008 à 17:03
Dommage qu'ils ne veuillent pas aller plus loin : l'interopérabilité...
Mais bon, ça se comprend, une question de gros sous quoi.
Mais bon, ça se comprend, une question de gros sous quoi.
Microsoft va s'effondrer sous le poids de son héritage monopolistique... Je vois bien le module de compatibilité obligé de gérer Xp, Vista, seven, la suivante... Déjà que chez crosoft ils peuvent pas te sortir un OS non buggé alors avec un module de compatibilité écris par leur soin, je sens que ça va être drôle
Vincent_H
Le lundi 11 février 2008 à 17:05:41
#17
Inscrit
le jeudi 30 janvier 03
-
14907
commentaires
Il leur faut quand même écrire les ACM, non ?
Oui, mais tu as un ACM par système, et non un ACM par application. La différence est de taille non ?
Bravo Microsoft d'avoir déposé la compatibilité binaire qui existe depuis 25 ans sur les Unices. . .
25 ans ?
Tu situes le commencement du monde à la 4.2 de BSD ?
Sinon, les ACM ressemblent furieusement à ce qu'à fait Apple avec les "Box" (blue et yellow) de MacOS X et Carbon http://developer.apple.com/carbon/)
Oui, mais tu as un ACM par système, et non un ACM par application. La différence est de taille non ?
Oui, en effet...
J'avais pas tout bien compris comme il fallait
Dommage qu'ils ne veuillent pas aller plus loin : l'interopérabilité...
Mais bon, ça se comprend, une question de gros sous quoi.
Mais bon, ça se comprend, une question de gros sous quoi.
Ben faut voir ce que tu entends par l'interopérabilité...
Chaque OS ayant des API propres c'est pas gagné sauf a tous se retrouver avec le même OS
Il n'est plus possible de commenter cette actualité
Vous devez être connecté ou vous inscrire en haut pour pouvoir participer aux commentaires.













