Microsoft : Windows 10 SDK Preview Build 17709 est maintenant disponible,
Avec la liste des fonctionnalités qui ont été appréciées et dépréciées

Le , par Blondelle Mélina, Expert confirmé
Microsoft a publié récemment Windows 10 SDK Preview Build 17709 à utiliser conjointement avec Windows 10 Insider Preview (Build 17709 ou supérieur) et Visual Studio 2017. Le SDK Preview Build 17709 contient des corrections de bogues et des modifications de développement de l'API. Le SDK Preview peut être téléchargé à partir de la section développeur sur Windows Insider.


Liste des fonctionnalités appréciées et dépréciées

La prise en charge des interfaces non-WinRT est désactivée par défaut. Pour activer : #include <unknwn.h> avant tout en-tête C++/WinRT.

winrt::get_abi(winrt::hstring) renvoie maintenant void* au lieu de HSTRING.

Le code nécessitant HSTRING ABI peut simplement utiliser static_cast. winrt::put_abi(winrt::hstring) renvoie void** au lieu de HSTRING*.
Le code nécessitant HSTRING ABI peut simplement utiliser reinterpret_cast.

HRESULT est maintenant projeté en tant que winrt::hresult.
Le code nécessitant un HRESULT peut simplement utiliser static_cast si vous avez besoin de vérifier la typographie ou le type de support, mais il est aussi convertible tant que est inclus en premier.

GUID est maintenant projeté comme winrt::guid. Le code implémentant les API avec les paramètres GUID doit utiliser winrt::guid à la place, mais il est sinon convertible tant que est inclus en premier.

Les signatures de WINRT_CanUnloadNow et WINRT_GetActivationFactory ont changé. Le code ne doit pas déclarer ces fonctions et doit utiliser plutôt winrt/base.h pour les appeler.

winrt::clock::from_FILETIME est obsolète. Le code doit utiliser winrt::clock::from_file_time à la place.

Mise à jour C++/WinRT

Cette mise à jour introduit de nombreuses améliorations et corrections pour C++/WinRT. Elle introduit la possibilité de construire du C++/WinRT sans aucune dépendance sur le SDK Windows. Cela signifie une réduction spectaculaire du nombre de macros qu'un développeur C++/WinRT doit utiliser. La suppression de la dépendance sur les en-têtes de Windows signifie que C++/WinRT est plus portable et conforme aux normes. Ce qui nous permet d'en faire une bibliothèque cross-compilateur et multi-plateforme. Cela signifie également que les en-têtes C++/WinRT ne seront jamais altérés par des macros. Si vous utilisiez auparavant C++/WinRT pour inclure divers en-têtes Windows, vous devrez maintenant les inclure vous-même. Il a toujours été judicieux d'inclure explicitement les en-têtes dont vous dépendez et de ne pas compter sur une autre bibliothèque pour les inclure pour vous.

Les supports get_strong et get_weak pour créer des délégués

Cette mise à jour permet à un développeur d'utiliser get_strong ou get_weak au lieu d'un pointeur brut lors de la création d'un délégué pointant vers une fonction membre.

Simplification de l'utilisation des API qui attendent les paramètres IBuffer

Bien que la plupart des API préfèrent les collections ou les tableaux, un nombre suffisant d'API dépend d'IBuffer pour qu'il soit plus facile d'utiliser ces API à partir du C++. Cette mise à jour fournit un accès direct aux données derrière une implémentation IBuffer en utilisant la même convention de dénomination de données utilisée par les conteneurs de bibliothèque standard C++. Cela évite également de se heurter aux noms de métadonnées qui commencent habituellement par une lettre majuscule.

Suppression de la récursivité inutile

Lorsque la ligne de commande fait référence à un dossier plutôt qu'à un winmd spécifique, cppwinrt ne recherche plus récursivement les fichiers winmd. Le compilateur cppwinrt gère désormais les doublons plus intelligemment. Ce qui le rend plus résistant aux erreurs de l'utilisateur et aux fichiers winmd mal formés.

Déclaration de WINRT_CanUnloadNow et WINRT_GetActivationFactory dans base.h

Les développeurs n'ont pas besoin de les déclarer directement.

Support MSIX

Vous pouvez maintenant emballer vos applications en tant que MSIX. Ces applications peuvent être installées et exécutées sur n'importe quel périphérique avec 17682 build ou version ultérieure.
Pour empaqueter votre application avec MSIX, l’outil MakeAppx est disponible.

MC.EXE

Des modifications importantes ont été apportées à la génération du code ETW C/C ++ de mc.exe (compilateur de messages).
Le paramètre « -mof » est obsolète. Ce paramètre indique à MC.exe de générer un code ETW compatible avec Windows XP et antérieur.
Tant que le paramètre « -mof » n'est pas utilisé, l'en-tête C/C++ généré est maintenant compatible à la fois avec le mode noyau et le mode utilisateur, que « -km » ou « -um » soit spécifié sur la ligne de commande. L'en-tête utilisera la macro _ETW_KM_ pour déterminer automatiquement s'il est compilé en mode noyau ou en mode utilisateur et appellera les API ETW appropriées pour chaque mode.

Source : Windows

Et vous ?

Qu'en pensez-vous ? Quelles nouveautés appréciez-vous le plus ?

Voir aussi :

Windows 10 : Microsoft publiera des préversions de SDK pour les Windows Insider, à compter de ce mois
Un nouveau SDK pour Windows 10 Anniversary Update est disponible, il apporte plusieurs améliorations à la Universal Windows Platform
Windows 10 : Microsoft publie une mise à jour pour la Technical Preview, qui introduit le centre de notifications


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :
Contacter le responsable de la rubrique Accueil