Version imprimable
J'ai oublié de spécifier que j'étais sur un disque de 3 T, Et dans ce cas c'est le mode EFI qui est utilisé et Linux utilise GRUB2. Deux systèmes beaucoup plus fragiles. Et quand ça merde, tu as deux système à réinstallés. parce que les programmes d'image et de reconstruction de GRUB2 ne fonctionne pas. Linux repart (quelque fois) Windows , jamais !Citation:
Envoyé par Pierre GIRARD
On peut ce procurer un disque de 500g pour une bagatelle, alors j'en profite.
Pour ma part, je n'ai aucun souci ni avec EFI ni avec Grub 2 et EFI permet de changer l'ordre des disques encore plus souplement que le BIOS. De plus, Linux permet de choisir le disque de démarrage de façon très souple. SUSE YaST fait ça très bien et je le laisse configurer Grub tout seul comme un grand avec 2 disques Linux ayant deux versions différentes. J'ai toujours retrouvé les deux choix dans le menu de démarrage vu que YaST repère toutes les partitions systèmes quelque soit l'OS qui est dessus. Pour les autres Linux, je ne sais pas.
Opensuse fait très bien cela également. Mais EFI, ce n'est pas qu'un bloc de disque qui est affecté comme GRUB 1, mais également une portion de ram lié au BIOS. Et quand Windows la salope, le problème est AVANT le démarrage du GRUB.Citation:
Envoyé par Pierre GIRARD
Au pire, quelques soient les dégâts causés par Windows, on démarre sur un DVD ou une clé USB et on refait le démarrage comme il faut. Au pire :
- On déconnecte le disque Windows.
- On reconnecte le disque Linux et on refait menu de démarrage.
Je pense que quelques soient les modifications faites dans l'EFI par Windows, un disque bootable absent lors de l'installation de Windows reste un disque bootable si on le remet à sa place et qu'on le déclare comme disque de boot dans le BIOS.
Maintenant, comme je l'ai dit, j'ai été plus radical en ayant un système Linux sur lequel tourne une Machine Virtuelle Windows. Comme ça, aucune pollution d'aucune sorte. ;)
Je pense plutôt à l'inverse, une machine virtuelle qui fait tourné Windows. S'il existait un moyen de faire tourner les jeux sur une alternative à Windows, je ne conserverais plus windows. Assez un disque SSD, Linux est un vrai charme.Citation:
Envoyé par Pierre GIRARD
C'est bien ce que j'ai dit non ? "Maintenant, comme je l'ai dit, j'ai été plus radical en ayant un système Linux". Windows est donc bien sur une machine virtuelle que je ne démarre que si j'en ai besoin (et pas pour les jeux ... depuis que je suis en retraite, je n'ai plus le temps pour ça :mrgreen: ).Citation:
Envoyé par Madmac
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
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 <unknwn.h> 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 <unknwn.h> 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 ?
:fleche: Qu'en pensez-vous ? Quelles nouveautés appréciez-vous le plus ?
Voir aussi :
:fleche: Windows 10 : Microsoft publiera des préversions de SDK pour les Windows Insider, à compter de ce mois
:fleche: Un nouveau SDK pour Windows 10 Anniversary Update est disponible, il apporte plusieurs améliorations à la Universal Windows Platform
:fleche: Windows 10 : Microsoft publie une mise à jour pour la Technical Preview, qui introduit le centre de notifications
