Discussion :

[Christian Olivier]

Comme avec iOS 11, Apple va mettre fin au support des applications 32-bits sur macOS
son plan sera amorcé dès janvier 2018

Apple a prévu d’enterrer définitivement les logiciels 32-bits sur tous ses systèmes d’exploitation, que ce soit sur mobile avec iOS ou sur les ordinateurs de type desktop et laptop avec macOS dans leurs prochaines déclinaisons respectives.

La firme de Cupertino avait annoncé, dès le début de la WWDC 2017 que son futur système d’exploitation pour mobile, iOS 11, devrait amorcer un changement important par rapport aux anciennes versions en ce qui concerne la prise en charge des applications 32 bits et 64 bits. Apple a annoncé que son futur iOS 11 a été conçu pour supporter exclusivement des applications 64 bits et, donc l’installation ou le lancement d’applications 32 bits ne sera pas pris en charge. L'utilisateur recevra simplement un message d'erreur lui demandant de procéder à la mise à jour vers la version 64 bits de l'application qu'il essaye d'ouvrir.

Il semble que cette mesure devrait aussi affecter le système d'exploitation pour ordinateurs, desktop et laptop, de la marque à la pomme. Les dernières informations émanant de la conférence Platform State of the Union d’Apple lors du WWDC laissent penser que macOS suivra vraisemblablement la même voie qu’iOS 11 pour ce qui est de la prise en charge des logiciels 32-bits avec l'OS.

En effet, pendant la présentation de macOS High Sierra, Apple a précisé aux développeurs que ce système d’exploitation serait « la dernière version de macOS à prendre en charge les applications 32 bits sans aucun compromis. »

Que ce soit sur iOS ou sur macOS, Apple a prévu de laisser un temps d’adaptation aux utilisateurs et aux développeurs avant de bannir de manière définitive les logiciels 32 bits de ses systèmes d’exploitation. Avec le système d’exploitation macOS High Sierra, Apple va commencer à alerter de plus en plus « fréquemment » l’utilisateur pendant le lancement ou l’utilisation de logiciels 32 bits, au fur et à mesure que l’échéance se rapprochera.

À partir du mois de janvier 2018, toutes les applications qui seront répertoriées sur le Mac App Store devront obligatoirement et exclusivement être de type 64 bits. Apple n’acceptera plus d’applications 32 bits sur son portail, mais autorisera encore des mises à jour d’applications 32 bits déjà installées. À partir du mois de juin 2018, toutes les mises à jour d’applications devront être obligatoirement et exclusivement de type 64 bits.

Les utilisateurs qui souhaiteront continuer d'utiliser des applications 32 bits avec des systèmes d'exploitation d'Apple devront utiliser des versions plus anciennes de macOS (Sierra ou antérieur), ou tout simplement passer chez Windows ou Linux si le fait d'utiliser d'anciennes versions de macOS les dérange.

Source : ibTimes

Et vous ?

Qu'en pensez-vous ?

Voir aussi

WWDC 2017 : Apple dévoile iOS 11, avec un Siri plus intelligent et le support de la réalité augmentée pour iPad et iPhone

[Markand]

Yes. Bien joué. J'ai hâte que toutes les distributions Linux abandonnent aussi cette architecture qu'on ai une en moins à maintenir et pousser les réfractaire à migrer.

[RyzenOC]

Yes. Bien joué. J'ai hâte que toutes les distributions Linux abandonnent aussi cette architecture qu'on ai une en moins à maintenir et pousser les réfractaire à migrer.

Ban non, le i386 et i686 sont encore maintenue dans les archi x86 32bits
Et puis en plus exotique rien que pour debian : https://wiki.debian.org/SupportedArchitectures

m68k Motorola Unofficial Amiga, !AtariST, very old Macintoshes, some old Sun hardware (sun3)

y'en as qui utilise encore ce truc

[Christian Olivier]

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

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 - Visualiser dans une fenêtre à part

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

[rt15]

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.

[chrtophe]

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.