Version stable de Wine 7.0

Après un an de développement et 30 versions expérimentales, la version stable de l'implémentation open source de l'API Win32 — Wine 7.0, a été présentée, contenant plus de 9100 modifications. Parmi les réalisations clés de la nouvelle version, on note la conversion de la majorité des modules Wine au format PE, le support des thèmes, l'élargissement de la pile pour les manettes et les appareils d'entrée avec une interface HID, et la mise en œuvre de l'architecture WoW64 pour exécuter des programmes 32 bits dans un environnement 64 bits.

Wine confirme la compatibilité totale avec 5156 programmes Windows (contre 5049 l'année dernière), tandis que 4312 programmes (contre 4227 l'année dernière) fonctionnent parfaitement avec quelques réglages et DLL externes. Pour 3813 programmes (contre 3703 l'année dernière), on observe de légers problèmes de fonctionnement, qui n'entravent pas l'utilisation des fonctionnalités principales des applications.

Les nouveautés clés de Wine 7.0 :

• Modules au format PE
  • Presque toutes les bibliothèques DLL ont été converties pour utiliser le format de fichier exécutable PE (Portable Executable, utilisé sous Windows) au lieu de l'ELF. L'utilisation du PE résout des problèmes de prise en charge de divers schémas de protection contre la copie qui vérifient l'identité des modules système sur le disque et en mémoire.
  • Une interaction entre les modules PE et les bibliothèques Unix a été réalillée en utilisant l'appel système natif NT, ce qui permet de cacher l'accès au code Unix des débogueurs Windows et de suivre l'enregistrement des threads.
  • Les DLL intégrées ne sont désormais chargées que si un fichier correspondant en format PE est présent sur le disque, indépendamment de qu'il s'agisse d'une véritable bibliothèque ou d'un stub. Ce changement permet au programme de toujours voir un lien correct avec les fichiers PE. Pour désactiver ce comportement, il est possible d'utiliser la variable d'environnement WINEBOOTSTRAPMODE.
• WoW64
  • L'architecture WoW64 (Windows-on-Windows 64 bits) a été mise en œuvre pour exécuter des applications Windows 32 bits dans des processus Unix 64 bits. La prise en charge a été réalisée à travers l'ajout d'un intermédiaire qui convertit les appels système NT 32 bits en requêtes 64 bits vers NTDLL.
  • Les intermédiaires WoW64 sont préparés pour la plupart des bibliothèques Unix et permettent aux modules 32 bits au format PE d'accéder aux bibliothèques Unix 64 bits. Après la conversion de tous les modules au format PE, il sera possible d'exécuter des applications Windows 32 bits sans installer les bibliothèques Unix 32 bits.
• Thèmes
  • La prise en charge des thèmes a été mise en œuvre. Les thèmes « Light », « Blue » et « Classic Blue » peuvent être sélectionnés via le configurateur WineCfg.
  • Ajout de la possibilité de personnaliser l'apparence de tous les éléments de contrôle de l'interface via des thèmes. La mise à jour automatique de l'apparence des éléments après le changement de thème a été assurée.
  • Tous les applications intégrées à Wine prennent désormais en charge les thèmes. Les applications ont été adaptées pour les écrans haute densité de pixels (High DPI).
• Sous-système graphique
  • Une nouvelle bibliothèque Win32u a été ajoutée, dans laquelle des parties des bibliothèques GDI32 et USER32 liées au traitement graphique et à la gestion des fenêtres au niveau du noyau ont été extraites. Dans un avenir proche, le travail commencera pour transférer vers Win32u les composants des pilotes tels que winex11.drv et winemac.drv.
  • La prise en charge de la spécification de l'API graphique Vulkan 1.2.201 a été mise en œuvre dans le pilote Vulkan.
  • Support de la sortie via l'API Direct2D pour des objets géométriques hachurés, avec la possibilité de vérifier les clics (hit-test).
  • Une prise en charge initiale des effets visuels appliqués à l'aide de l'interface ID2D1Effect a été mise en œuvre dans l'API Direct2D.
  • Ajout du support de l'interface ID2D1MultiThread dans l'API Direct2D, utilisée pour organiser l'accès exclusif aux ressources dans des applications multi-thread.
  • Le jeu de bibliothèques WindowsCodecs a introduit la prise en charge du décodage d'images au format WMP (Windows Media Photo) et du codage d'images au format DDS (DirectDraw Surface). La prise en charge du codage d'images au format ICNS (pour macOS), qui n'est pas pris en charge sous Windows, a été interrompue.
• Direct3D
  • Le nouveau moteur de rendu a été considérablement amélioré, réalisant la translation des appels Direct3D en API graphique Vulkan. Dans la plupart des situations, le niveau de prise en charge des Direct3D 10 et 11 dans le moteur basé sur Vulkan a été porté à la parité avec l'ancien moteur basé sur OpenGL. Pour activer le moteur de rendu via Vulkan, il convient de définir la variable de registre Direct3D « renderer » à « vulkan ».
  • De nombreuses fonctionnalités des Direct3D 10 et 11 ont été mises en œuvre, y compris des contextes différés (Deferred Contexts), fonctionnant dans le contexte des appareils d'objets d'état, des décalages constants dans les tampons, le nettoyage des présentations non ordonnées des textures, ainsi que le transfert de données entre des ressources de formats non typés (DXGI_FORMAT_BC3_TYPELESS, DXGI_FORMAT_R32G32B32A32_TYPELESS), etc.
  • Ajout de la prise en charge des configurations multi-moniteurs, permettant de choisir le moniteur pour afficher l'application Direct3D en mode plein écran.
  • L'API DXGI a mis en œuvre la possibilité de correction gamma de l'écran, ce qui peut être utilisé par les applications basées sur Direct3D 10 et 11 pour modifier la luminosité de l'écran. L'extraction des compteurs de tampons de trame virtuels (SwapChain) est assurée.
  • Direct3D 12 a ajouté la prise en charge des signatures racines de version 1.1.
  • Le code de rendu via l'API Vulkan a amélioré l'efficacité du traitement des requêtes en cas de prise en charge de l'extension VK_EXT_host_query_reset dans le système.
  • Ajout de la possibilité de sortir des tampons de trame virtuels (SwapChain) via GDI, si OpenGL ou Vulkan ne peuvent pas être utilisés pour l'affichage, par exemple lors de l'affichage dans une fenêtre à partir de différents processus, comme dans les programmes basés sur le framework CEF (Chromium Embedded Framework).
  • Lors de l'utilisation du backend pour les shaders GLSL pour les instructions de shader, l'application du modificateur « precise » est assurée.
  • L'API DirectDraw a ajouté la prise en charge du rendu 3D en mémoire système, en utilisant des appareils logiciels tels que « RGB », « MMX » et « Ramp ».
  • La base de données des cartes graphiques Direct3D a ajouté les cartes AMD Radeon RX 5500M, AMD Radeon RX 6800/6800 XT/6900 XT, AMD Van Gogh, Intel UHD Graphics 630 et NVIDIA GT 1030.
  • La clé « UseGLSL » a été supprimée du registre HKEY_CURRENT_USER\Software\Wine\Direct3D, à la place de laquelle à partir de Wine 5.0, il faut utiliser « shader_backend ».
  • Pour prendre en charge Direct3D 12, la bibliothèque vkd3d d'au moins la version 1.2 est désormais nécessaire.
• D3DX
  • L'implémentation de D3DX 10 a amélioré le support du framework des effets visuels et ajouté le support du format d'image Windows Media Photo (JPEG XR).
  • Ajout de fonctions de création de textures fournies dans D3DX10, telles que D3DX10CreateTextureFromMemory().
  • Les interfaces logicielles ID3DX10Sprite et ID3DX10Font ont été partiellement mises en œuvre.
• Son et vidéo
  • Les surcouches GStreamer pour DirectShow et le framework Media Foundation ont été fusionnées en un backend commun WineGStreamer, ce qui devrait simplifier le développement de nouvelles API de décodage de contenu.
  • Sur la base du backend WineGStreamer, des objets Windows Media pour la lecture synchronisée et asynchrone ont été réalisés.
  • Le développement de l'implémentation du framework Media Foundation a été poursuivi, avec l'ajout de la prise en charge de la fonctionnalité IMFPMediaPlayer, du répartiteur d'échantillons (sample allocator), ainsi qu'une meilleure prise en charge de l'EVR et des tampons de rendu SAR.
  • La bibliothèque wineqtdecoder, fournissant un décodeur pour le format QuickTime (GStreamer est désormais utilisé pour tous les codecs), a été supprimée.
• Périphériques d'entrée
  • La pile pour les dispositifs d'entrée prenant en charge le protocole HID (Human Interface Devices) a été considérablement améliorée, intégrant des fonctionnalités telles que l'analyse des descripteurs HID, le traitement des messages HID et la fourniture de mini-drivers HID.
  • Dans les backends du driver winebus.sys, la traduction des descriptions des appareils en messages HID a été améliorée.
  • Un nouveau backend DirectInput pour les manettes prenant en charge le protocole HID a été ajouté. La possibilité d'utiliser des effets de retour haptique sur les manettes a été mise en œuvre. Amélioré le panneau de contrôle les manettes. L'interaction avec les appareils compatibles avec XInput a été optimisée. Dans WinMM, la prise en charge des manettes a été transférée à DInput, au lieu d'utiliser le backend evdev sous Linux et IOHID sous macOS. L'ancien driver de manette winejoystick.drv a été supprimé.
  • De nouveaux tests basés sur l'application de dispositifs HID virtuels et ne nécessitant pas d'appareil physique ont été ajoutés au module DInput.
• Texte et polices
  • Un objet Font Set a été ajouté à DirectWrite.
  • L'interface TextHost a été correctement mise en œuvre dans RichEdit.
• Noyau (interfaces du noyau Windows)
  • Lors du lancement d'un fichier exécutable non reconnu dans Wine (par exemple, ‘wine foo.msi’), start.exe est désormais appelé, qui invocate les gestionnaires associés au type de fichier.
  • Ajout d'une prise en charge des mécanismes de synchronisation NtAlertThreadByThreadId et NtWaitForAlertByThreadId, proches des futilities sous Linux.
  • Ajout de la prise en charge des objets de débogage NT, utilisés pour déboguer les fonctions du noyau.
  • Ajout de la prise en charge des clés de registre dynamiques pour stocker des données de performance.
• C Runtime
  • Un ensemble complet de fonctions mathématiques a été mis en œuvre dans le C runtime, principalement transféré de la bibliothèque Musl.
  • Pour toutes les plateformes CPU, un support correct des fonctions de calculs en virgule flottante a été assuré.
• Fonctionnalités réseau
  • Le mode de compatibilité avec Internet Explorer 11 (IE11), qui est désormais utilisé par défaut pour le traitement des documents HTML, a été amélioré.
  • La bibliothèque mshtml a implémenté le mode JavaScript ES6 (ECMAScript 2015), assurant la prise en charge de fonctionnalités telles que l'expression let et l'objet Map.
  • L'installation de packages MSI Wine avec des compléments pour le moteur Gecko dans le répertoire de travail se fait maintenant au besoin, et non lors de la mise à jour de Wine.
  • Ajout de la prise en charge du protocole DTLS.
  • Mise en œuvre du service NSI (Network Store Interface), qui stocke et transmet à d'autres services des informations sur le routage et les interfaces réseau sur l'ordinateur.
  • Les gestionnaires d'API WinSock, tels que setsockopt et getsockopt, ont été transférés dans la bibliothèque NTDLL et le pilote afd.sys, pour se conformer à l'architecture Windows.
  • Les fichiers propres aux bases de données réseau de Wine sont désormais installés dans le répertoire de travail, tels que /etc/protocols et /etc/networks, au lieu de faire appel à des bases de données Unix similaires.
• Plateformes alternatives
  • Ajout de la prise en charge du matériel Apple basé sur les puces ARM M1 (Apple Silicon).
  • Pour prendre en charge les fonctions BCrypt et Secur32 sur la plateforme macOS, l'installation de la bibliothèque GnuTLS est désormais requise.
  • Les fichiers exécutables 32 bits pour les plateformes ARM sont maintenant construits en mode Thumb-2, tout comme sous Windows. Un préchargeur est utilisé pour charger de tels fichiers.
  • La prise en charge du déballage (unwinding) des exceptions a été implémentée pour les plateformes ARM 32 bits.
  • Pour FreeBSD, le nombre de demandes d'informations système de bas niveau prises en charge a été étendu, telles que les données sur l'état de la mémoire et le niveau de charge de la batterie.
• Applications et outils intégrés pour le développement
  • L'outil reg.exe a été mis à jour pour prendre en charge les représentations 32 et 64 bits du registre. La prise en charge de la copie des clés du registre a également été ajoutée.
  • L'outil WineDump a ajouté la prise en charge de l'exportation de dumps de métadonnées Windows et d'affichage d'informations détaillées sur les entrées CodeView.
  • Le débogueur Wine Debugger (winedbg) prend désormais en charge le débogage des processus 32 bits à partir d'un débogueur 64 bits.
  • Le compilateur IDL (widl) a été amélioré avec la possibilité de charger des bibliothèques intégrées dans des fichiers PE, prenant en charge les attributs et constructions spécifiques à WinRT, ainsi que la recherche de bibliothèques en fonction de la plateforme.
• Système de construction
  • Dans les répertoires spécifiques aux architectures matérielles, les bibliothèques sont maintenant enregistrées avec des noms reflétant l'architecture et le type de fichiers exécutables, par exemple, ‘i386-windows’ pour le format PE et ‘x86_64-unix’ pour les bibliothèques unix, permettant la prise en charge de différentes architectures dans une seule installation de Wine et facilitant la cross-compilation de Winelib.
  • Pour définir dans les en-têtes des fichiers PE des options contrôlant le passage à l'utilisation de bibliothèques DLL natives, un drapeau ‘—prefer-native option’ a été ajouté à winebuild (le traitement de DLL_WINE_PREATTACH dans DllMain a été arrêté).
  • La prise en charge de la version 4 du format de données de débogage Dwarf, qui est maintenant utilisée par défaut lors de la construction de bibliothèques Wine, a été ajoutée.
  • Une option de compilation ‘—enable-build-id’ a été ajoutée pour enregistrer des identifiants de construction uniques dans les fichiers exécutables.
  • Ajout de la prise en charge du compilateur Clang en mode de compatibilité avec MSVC.
• Divers
  • Les noms des répertoires standards dans l'interface utilisateur de Windows (Windows Shell) ont été alignés sur le schéma utilisé depuis Windows Vista, c'est-à-dire qu'au lieu de 'Mes Documents', le répertoire 'Documents' est maintenant créé, et la plupart des données sont enregistrées dans le répertoire 'AppData'.
  • La couche pour la bibliothèque OpenCL a ajouté la prise en charge de la spécification OpenCL 1.2.
  • Le pilote WinSpool a ajouté la prise en charge de différentes tailles de page lors de l'impression.
  • Ajout d'un support initial pour MSDASQL, le fournisseur Microsoft OLE DB pour les pilotes ODBC.
  • Le moteur Wine Mono avec l'implémentation de la plateforme .NET a été mis à jour vers la version 7.0.0.
  • Les données Unicode ont été mises à jour vers la spécification Unicode 14.
  • Des bibliothèques Faudio, GSM, LCMS2, LibJPEG, LibJXR, LibMPG123, LibPng, LibTiff, LibXml2, LibXslt et Zlib ont été intégrées dans l'arbre des sources, compilées au format PE et ne nécessitant pas de version au format Unix. Ces bibliothèques peuvent également être importées depuis le système pour utiliser des assemblages externes au lieu des versions intégrées au format PE.

Source : opennet.ru