Une équipe de passionnés a récemment publié les détails sur leur dernière création : un utilitaire basé sur une version personnalisée du compilateur Clang et sur la couche logicielle de compatibilité grâce à laquelle il est possible d’utiliser des applications Windows sur Linux, FreeBSD et macOS plus connue sous le nom de Wine (Wine Is Not an Emulator). Cet utilitaire permet la création de segments de code 32 bits dans un processus 64 bits sur macOS Catalina qui est disponible depuis octobre dernier. Autrement dit, il permet d’exécuter des applications 32 bits sur macOS Catalina.En ce qui concerne le support des applications 32 bits avec les récentes versions de son système d’exploitation macOS (à partir de High Sierra 10.13.4), il faut rappeler comme la marque à la pomme l’indique sur son site : « ;Apple a travaillé avec les développeurs pour la transition de leurs apps et, en 2018, Apple les a informés que macOS Mojave serait la dernière version de macOS à exécuter des apps 32 bits. La transition d’Apple vers la technologie 64 bits est maintenant terminée. À partir de macOS Catalina, les apps 32 bits ne sont plus compatibles avec macOS ;».
Le compilateur personnalisé conçu par le groupe « ;the CodeWeavers ;» dispose d’un certain nombre de fonctionnalités qui prennent en charge la conception « ;32-on-64-bits Wine ;». Ces fonctionnalités sont activées lorsque vous compilez avec l’option « ;-mwine32 ;» (par opposition à -m32 ou -m64) qui est une variante de -m64 avec des fonctionnalités supplémentaires telles que la prise en charge des conventions d’appel 32 bits de Microsoft (cdecl32, stdcall32, thiscall32, thiscall32, fastcall32), la prise en charge des pointeurs 32 et 64 bits, la définition de la macro « ;__i386_on_x86_64_64__ ;» et même la création automatique d’un thunk (translation ou mappage de données) 64 bits vers 32 bits approprié.
Quelques précisions sur les aspects techniques du projet
Le compilateur développé par « ;the CodeWeavers ;» met en avant le concept « ;d’espaces d’adresse ;». Il maintient un espace d’adresse de pile implicite courant, un espace d’adresse de stockage implicite courant et un espace d’adresse de pointeur implicite courant. L’espace d’adresse implicite de la pile indique au compilateur où réside une variable de la pile. Le type d’adresse de l’opérateur appliqué à une variable de pile est un pointeur de la taille appropriée. Si la variable se trouve dans l’espace d’adressage 32 bits, le pointeur qui en résulte a une taille de 32 bits. S’il se trouve dans l’espace d’adressage 64 bits, l’adresse est un pointeur 64 bits.
Par défaut, lors de la compilation avec -mwine32, l’espace d’adresse implicite de la pile est l’espace d’adresse 32 bits. Il y existe une option de ligne de commande, -mstack64, pour remplacer cela. Le compilateur ne contrôlant pas l’emplacement de la pile au moment de l’exécution, c’est à Wine que revient la responsabilité de s’assurer que les threads qui exécutent du code compilé avec l’espace d’adressage de la pile 32 bits sont bien situés dans les 4 Go de mémoire virtuelle du processus et que les modules avec du code compilé avec l’espace d’adressage de stockage de 32 bits sont effectivement chargés dans les 4 Go.
L’espace d’adresse de stockage implicite indique au compilateur où les données statiques et le code se trouvent. Ainsi, si vous prenez l’adresse d’une variable statique ou d’une fonction, vous obtenez un type de pointeur de la taille appropriée. Il en va de même pour les chaînes de caractères littéraux.
Par défaut, lors de la compilation avec -mwine32, l’espace d’adresse de stockage implicite correspond à l’espace d’adresse 32 bits. Cela peut être modifié par l’option en ligne de commande « ;-mstorage-address-space={default | ptr32} ;». De plus, il peut être modifié en code à l’aide de :
| Code : | Sélectionner tout |
1 2 3 | #pragma clang storage_addr_space ({default | ptr32})
#pragma clang storage_addr_space(push, {default | ptr32})
#pragma clang storage_addr_space(pop) |
Les développeurs notent que leur travail a été couronné de succès parce que macOS Catalina donne la possibilité de créer des segments de code 32 bits dans un processus 64 bits, ce qui leur a permis d’activer l’utilisation de « ;i386_set_ldt () ;» dans les processus 64 bits. Ils précisent toutefois que cette fonctionnalité est limitée par la protection de l’intégrité du système (SIP), une limitation qui impose pour le moment la désactivation de ce dernier.
« ;Le reste du travail consistait à modifier Wine pour utiliser ce compilateur et cette fonctionnalité de l’OS. Il s’agissait essentiellement de corriger les erreurs de compilation résultant de l’interfaçage des bibliothèques système (utilisant des pointeurs 64 bits) et des API Win32 (utilisant des pointeurs 32 bits). De plus, partout où il y avait une dépendance architecturale, il fallait revoir et éventuellement modifier l’architecture. Cela, bien sûr, inclut tout le code du langage d’assemblage ;», a expliqué Ken Thomases, un membre des CodeWeavers.
De plus amples informations sur le projet sont disponibles sur le site dédié mis en place par les développeurs de CodeWeavers.
Source : Apple, Winehq
Et vous ?
Que pensez-vous de cette initiative ? Pensez-vous que Wine, au vu des nombreuses opportunités qu’il offre en matière de portage et de recyclage d’anciens logiciels, puisse devenir un élément clé des projets futurs touchant au domaine du logiciel libre ?Voir aussi
Wine 4.0 : le logiciel pour faire tourner les applications Windows sur Linux et macOS est disponible avec le support de Direct3D 12 et Vulkan Comme avec iOS 11, Apple va mettre fin au support des applications 32-bits sur macOS, son plan sera amorcé dès janvier 2018 Sortie de LLVM et Clang 9.0 avec une implémentation finalisée de la génération de code pour RISC-V l'architecture libre de processeur 
