In bed with Windows 7 & Windows 2008

Les nouveaux OS Microsoft pérennes sont coté serveur Windows 2008 R2 (x64bits uniquement), et coté poste client la gamme Windows 7 (32 & 64bits). 

Les migrations seront complexes car ces OS sont une véritable évolution des noyaux et de l'environnement utilisateur. 

De plus Windows 2003 et Windows Xp arrivant en fin de cycle de vie ,la migration se fait pressante,  « ce n'est pas comme si nous avions le choix » pour reprendre l'expression favorite d'un de mes amis bloggeurs.

Déjà bon nombre d'éditeurs ou constructeur de matériel ne prévoient plus d'ailleurs de compatibilité/drivers/logiciels sur ces OS vieillissants. 

Sur le périmètre logiciel, les évolutions sont en cours, et il faut être vigilant sur les roapmaps annoncées ainsi que sur le coût de migration et la gestion du changement nécessaires, surtout sur le périmètre très vaste des applications.

Concernant la portabilité des applications sous ces nouveaux OS, 3 cas de figure sont possibles :

• portabilité native
• portabilité sous réserve d'apporter des adaptations
• non portabilité nécessitant soit une évolution de version, soit un changement de produit

Pourquoi la portabilité semble t elle si délicate? Pour comprendre entrons dans l'intimité de ces nouveaux socles.

• Pour framework .net, même si les anciennes versions sont supportées, la V4.0 est la version officielle sous Windows 2008 et Windows 7, et est actuellement la seule à prendre réellement en charge le 64 bits.
• Windows 7 et 2008 sont très axés sécurité, et n'autorisent que des privilèges très faibles aux utilisateurs et applications. Attention aux applications ayant été développées avec des forts niveaux de privilèges requis.  Cela se ressent également sur l'environnement utilisateur qui est par défaut plus restreint, moins permissif.
• Session 0 non-interactive. Les processus systèmes et les services fonctionnent dans la session 0. Le premier utilisateur  se connecte à la session 1 (sous XP il se connectait à la session 0). Cette approche signifie que les services ne fonctionnent jamais dans la même session que les applications des utilisateurs pour être protégés contre les attaques provenant du code de l'application.

IE8 est le navigateur natif par défaut, et IE6 ne peut pas être installé

• IE8 affiche une compatibilité descendante, embarquant nativement 3 modes de fonctionnement, mode quircks (IE5), mode IE7 et mode IE8.Nécessité de porter/migrer les applications web/activex sous IE8
• IE8 fonctionne en mode protégé (privilèges très restreints)
• DEP / NX activée par défaut dans Internet Explorer 8. DEP/NX, pour « Data Execution Prevention/No Execute », le but de cette fonctionnalité est d'empêcher des services et applications d'exécuter du code dans des zones non habilitées. Les applicatifs doivent donc embarquer dans leur code la pris en charge de DEP/NX
• IE8 est conforme aux standards CSS 2.1, mais reste en retard vis-à-vis de CSS 3.0

Pour le passage de 32 bits à 64 bits, Il ne suffit pas d'avoir une machine avec processeur 64 bits et d'installer les versions « habituelles » du système d'exploitation et des logiciels. En faisant cela, le processeur 64 bits tournera en mode 32 bits (compatibilité descendante). Pour effectivement utiliser un ordinateur 64 bits en full 64 bits il faut disposer des versions 64 bits des :

• système d'exploitation 
• drivers 
• logiciels d'application

Le passage de 32 bits à 64 bits augmente la consommation de mémoire. Le codage des entiers et des adresses passent de 32 bits (4 octets) à 64 bits (8 octets). Il faut donc deux fois plus d'octets pour les représenter. Attention, cela ne veut pas du tout dire que si un programme consomme 256 MB en 32 bits qu'il consommera automatiquement 512 MB en 64 bits 
Le coté 32bits, est géré via une émulation sous-système WOW64 

• les pilotes/drivers 32 bits (mode noyau) ne sont pas pris en charge
• les applications 32bits sont prises en charge, mais devront être testées
• coté exécution, les applications peuvent s'exécuter avec les même performances, plus lentement, ou plus vite que sur du 32bits natif, il n'y a pas de règle !

les applications, modules ou composants 16bits ne fonctionnent plus

• programmes compilés pour des systèmes d'exploitation 16 bits 
• programmes 16 bits en mode noyau compilés pour des systèmes d'exploitation 32 bits (setup.exe par exemple)
• programmes 16 bits

Aucun processus 64 bits/32-bit mixtes

• 64 bits Microsoft Internet Explorer ne peut pas charger les contrôles ActiveX 32 bits.
• L'environnement 64 bits ne peut pas charger les extensions d'environnement 32 bits.
• Les programmes de programme d'installation 32 bits ne peuvent pas charger et enregistrer des dll 64 bits
• isolation des fichiers et registres entre le mode 32 bits émulé et mode 64bits
• le sous-système WOW64 isole les fichiers binaires 32 bits des fichiers binaires 64 bits en redirigeant les appels au Registre et certains appels au système de fichiers 
• Le Registre des versions 64 bits de Windows est divisé en clés 32 bits et 64 bits. La plupart des clés 32 bits portent le même nom que leurs équivalents 64 bits, et vice-versa, mais le redirecteur de Registre WOW64 présente des programmes 32 bits avec des clés différentes pour les entrées de Registre programme 32 bits. 
• les communications/appels 64bits / 32bits devront être validés (ex client oracle 64bits et applications métiers  en 32bits)

Sous Windows 2008 R2 même si l'OS est 64bits et Windows 7 64bits, il existe deux navigateurs un IE8 64bits et un IE8 32bits. Chaque navigateur est indépendant et n'utilise que les add-on, plugin, activex etc...correspondant à sa version.Toutefois ils partagent la page de démarrage par défaut, le menu Favoris et le dossier Temporary Internet Files.

En environnement virtuels Windows 7 (type HDV) et Windows 2008 R2 (type SBC) 

Les applications à contenu riche et multimédia sont soumises à de nombreux pré-requis pour fonctionner correctement aussi bien en central (HVD/SBC) que coté poste client distant

Cela a pour impacts pour répondre aux besoins multimédias, et afin d'utiliser les nouvelles fonctionnalités proposées, de respecter ces pré requis et donc de migrer les plateformes existantes. 

On focalise souvent sur la migration OS qui va intervenir dans les mois qui suivent, mais il faut bien avoir à l'esprit que la principale difficulté sera donc dans la portabilité des applications vers ces nouveaux socles OS, avec de plus l'utilisation de IE8 en remplacement natif de IE6. 
Le constat est que la migration d'OS/socle impose que toutes les applications  devront passer par une phase de test/homologation.

Pour faciliter les tests et qualification, il existe des outils pouvant aider à cartographier les matrices de compatibilités comme Microsoft Windows Application Compatibility Toolkit 5.6 ou plus complet Apptitude de APPDNA

Lors des phases d'intégration des applications, l'utilisation de packages virtualisés (Microsoft APP-V, Vmware Thinapp...) sera également une des voies techniques intéressantes à  évaluer. Ces solutions offrant en effet moins d'adhérence aux socles, et une plus grande flexibilité d'utilisation et de portabilité applicative.