Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un outil basé sur Clang et Wine permet d'exécuter des applications 32 bits sur macOS Catalina,
Bien qu'Apple ait annoncé le support exclusif des applis 64 bits pour le dernier macOS

Le , par Christian Olivier

8PARTAGES

5  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de rt15
Membre confirmé https://www.developpez.com
Le 20/01/2020 à 11:04
J'ai eu un peu de mal à comprendre cet article donc je vais essayer de le rectifier un peu.

Déjà le titre me semble complètement trompeur :
Un outil basé sur Clang et Wine permet d’exécuter des applications 32 bits sur macOS Catalina
Je pense qu'un titre beaucoup plus approprié serait :
Un Wine customisé compilé avec un Clang customisé lui aussi permet d'exécuter les applications Windows 32 bits sur macOS Catalina
Il n'y a pas d'outil basé sur Clang et Wine.
L'outil c'est Wine (en 64 bits), un peu modifié, point. Il est recompilé avec une version customisée de Clang.
Les applications 32 bits que l'on peut exécuter, ce sont uniquement les applications Windows 32 bits. Pas les applications macOS 32 bits. [gros troll]En même temps il n'y a pas d'applications dignes de ce nom sur mac...[/gros troll]

Ensuite, j'avoue, c'est un très beau tour de force.
Car leur Wine trafiqué, compilé en 64 bits, est utilisé pour faire tourner des applications Windows en 32 bits.
Ça pourrait intéresser les Linuxiens aussi à l'avenir vu que les distributions Linux risquent de ne plus supporter les applications 32 bits non plus (donc Wine 32 bits) à plus ou moins longue échéance.

Normalement c'est impossible. Un Wine 32 bits ne devrait pouvoir faire tourner que des applications 32 bits et un Wine 64 bits ne devrait pouvoir faire tourner que des applications 64 bits.
Par exemple, si on regarde l'API Win32 WriteFile qui est très souvent appelée par les applications Windows, on voit que le deuxième paramètre est un pointeur.
Dans une application 32 bits, ce deuxième paramètre est sur 32 bits. Dans une application 64 bits, ce même paramètre fait 64 bits.
Une application Windows 32 bits appelera WriteFile avec une pointeur sur 32 bits.
Et ensuite, Wine doit traduire cet appel Windows en appel du système hôte (macOS, Linux...) donc il doit appeler write. Sur un OS 64 bits, ce write utilise forcément des pointeurs 64 bits.

Pour que ça fonctionne, le Wine customisé expose donc des fonctions qui prennent en argument des pointeurs sur 32 bits et les convertis en pointeurs 64 bits avant de faire appel au système hôte.
Encore plus fort, quand une application Windows fournit une adresse de fonction (par exemple un pointeur sur une WNDPROC), le Wine customisé doit appeler cette fonction en 32 bits.

C'est pour ça qu'il y a des "thunks" dans tous les sens dans l'article d'origine, pour passer d'un monde à l'autre et inversement.

Là où c'est encore plus compliqué, c'est qu'un pointeur 64 bits ça rentre pas dans un pointeur 32 bits bien sûr ! Donc ils utilisent une technique de segments (proposée par macOS) qui doit être assez proche de celle qui était utilisée dans les archi 16 bits pour adressé plus de 64 ko. Le principe est d'avoir le pointeur en deux morceau : 32 bits désignent le segment, et 32 bits donnent l'adresse dans ce segment. J'imagine qu'il s'arrange que pour les applications 32 bits n'utilisent qu'un seul segment.
0  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 21/01/2020 à 9:17
Pour faire de la vulgarisation :

Lles applications appellent des fonctions systèmes. L'ensemble de ces fonctions s’appelle une API.

Qui peut le plus peut le moins. Un CPU en 64 bits peut fonctionner en mode 32, 16 bits sur Intel, les CPU sont rétrocompatibles. Ceux-ci démarrent d'ailleurs toujours en mode réel, c'est ensuite l'OS qui fixe l'utilisation et ses limites. Le prochaines évolutions des CPU pourront enlever cette possibilité afin de gagner en puissance, taille, etc.

Permettre la rétrocompatibilité au niveau OS c'est à dire gérer l'accès à des applis 32 et 64 bits permet de rester compatibles avec de vieilles applications mais impose de maintenir une double API.

Apple parle d'utiliser leur propre CPU à la place du x86, ceci simplifiera le migration. Tout comme l'époque du passage du 68000 au PowerPC, un émulateur permettait le fonctionnement des applis 68000, qui a posé des problèmes sur certaines applis.
Lors du passage du PowerPC vers Intel, il y avait les Universal Binaries qui contenait le code PowerPC et le code Intel, l'OS chargeant la partie adequat selon le CPU. Il y a avait aussi Rosetta pour les anciennes applis non universal binary.

OS X 10.4 datant de 2005 était le 1er OS à supporter les instructions Intel 64 bits, nous sommes en 2020. L'abandon du 32 bits n'est pas abhérent.

Wine permet d'émuler les appels systèmes Windows. Exemple : Writefile n'existe pas sous Linux ou Mac OS, il existe un équivalent qui fera la même chose. Wine va donc appeler la fonction équivalente avec les paramètres attendus par cet équivalent. Il pourra facilement prendre des pointeurs 32 bits et les "convertir" en pointeurs 64 bits.

Ce qu'explique l'article, c'est que des développeurs ont prit une partie du code/pratique utilisé par Wine pour l'appliquer à Catalina avec les applis windows 32 bits.

Il s'agit là essentiellement d'un proof of concept, car la désactivation nécessaire du SIP : protection de l'intégrité système, qui en plus nécessite une ligne de commande après démarrage en recovery, pose problème.
Et si j'ai bien compris, il ne s'agit pas de double-cliquer sur une ancienne appli Apple pour que ça marche. Il s'agit de pouvoir utiliser des applis Windows 32 bits avec Wine. Codeweavers étant les créateurs de Crossover, version payante et patchée de Wine.
0  0