Limitations UWP dans les applications de bureau
Je sais que le nouveau modèle d'application UWP a certaines limites par rapport aux applications Win32 "traditionnelles".
Prenons Visual Studio Code comme exemple d'application de bureau.
Quelles fonctionnalités de Visual Studio Code manquaient ou devaient être différentes du point de vue de l'utilisateur, s'il s'agissait d'une application UWP?
EDIT: J'ai fait des examens pour la certification Microsoft "Essentials of Developing Windows Store Apps Using C #" et Exam 70-355: Universal Windows Platform - App Data, Services, and Coding Patterns. Je sais donc quelque chose sur win rt api.
S'il vous plaît ne vous embêtez pas avec des réponses comme "l'application uwp s'exécute dans le bac à sable". Ils sont inutiles, car ils ne disent rien sur les limites du point de vue des utilisateurs. J'ai délibérément pris l'exemple de la vie réelle, afin que nous puissions être concrets.
La limitation pourrait être que votre application ne peut pas prendre en charge les plugins tiers comme le surligneur de syntaxe personnalisé ou l'extension refactorin (c'était une limitation des applications Windows Store, je ne sais pas si elle est toujours valide).
Une autre limitation pourrait être que votre application ne peut pas prendre de capture d'écran, car il n'y a pas d'api dans uwp pour elle (pas sûr que ce soit vrai, en fait)
L'expression "application de bureau Win32" est mal définie car le modèle de programmation de l'API Win32 existe depuis Windows NT 3.1. Il peut également couvrir des dizaines de langages de développement et de cadres d'interface utilisateur au cours des deux dernières décennies.
Voici un aperçu rapide des principales différences UWP:
Surface de l'API. La plate-forme UWP prend en charge de nombreuses API Win32 et COM, mais pas toutes, et introduit de nouvelles API. Si votre "application de bureau Win32" utilise principalement des API ANSI qui remontent à Windows 95, vous devez effectuer de nombreuses mises à jour. Si vous utilisez principalement des API UNICODE de l'ère Windows Vista, alors beaucoup de choses "fonctionnent". Voir Win32 et l'API COM pour les applications Windows Runtime (système) .
Contexte de sécurité. La plate-forme UWP exécute des applications dans un contexte de sécurité AppContainer. Les "applications de bureau Win32" sous Windows Vista ou version ultérieure s'exécutent en tant qu '"utilisateur standard" ou "administrateur". Les applications UWP ont moins de droits d'accès que "Utilisateur standard" et ne peuvent jamais s'exécuter en tant qu '"Administrateur". Les applications UWP peuvent demander des capacités supplémentaires pour obtenir quelques droits supplémentaires avec la permission de l'utilisateur, mais ont un accès limité au système et aux données utilisateur. Par exemple, vous ne pouvez pas lire la plupart du système de fichiers, uniquement votre emplacement installé, un dossier de données d'application isolé et un dossier de fichiers temporaires isolé. Voir Accès aux fichiers et autorisations (applications Windows Runtime) . Cela signifie également que les applications UWP ont un accès limité aux appareils. Voir Aperçu des appareils et des capteurs .
Le contrôle de compte d'utilisateur Windows Vista qui a introduit l'utilisateur standard était axé sur la protection du système et des données des autres utilisateurs par rapport à l'ancien modèle "tout est administrateur", mais n'a pas fait grand-chose pour protéger les fichiers de données de l'utilisateur actuel, car toutes les applications pouvaient y accéder ou même le modifier. L'isolement AppContainer protège à la fois le système et les données et paramètres de l'utilisateur actuel. Les "applications de bureau Win32" ont été encouragées à installer sur
C:\Program Filesqui était en lecture seule au moment de l'exécution et pour utiliser les dossiers de données d'application, mais ils n'y étaient pas tenus.
Déploiement AppX. Les "applications de bureau Win32" utilisent un certain nombre de façons de déploiement, souvent quelque chose utilisant la technologie MSI et fonctionnant comme "Administrateur". Les applications UWP sont regroupées dans des fichiers AppX et sont toujours déployées par le système. Il n'y a pas d '"étape d'installation personnalisée" et les applications UWP ne peuvent donc pas installer de pilotes ou de services, modifier les listes de contrôle d'accès, etc. Le système se charge de déployer le runtime C/C++ (qui doit être Visual C++ 2015 uniquement).
Modèle d'interface utilisateur . Il existe une multitude de cadres d'interface utilisateur pour les "applications de bureau Win32" comme WinForms, MFC, WPF, etc. La grande majorité d'entre elles ne sont pas compatibles avec UWP car UWP ne prend pas en charge le fenêtrage Win32 classique,
WM_messages, ou GDI/GDI +. Pour les applications UWP, vous pouvez utiliser XAML avec C++ ou C # code-behind, DirectX (Direct2D et/ou Direct3D) avec C++ (ou C # via des assemblages tiers comme SharpDX), ou HTML5 avec JavaScript.
Répondre à votre question est donc extrêmement difficile, voire impossible, sans une compréhension complète de la base de code et des dépendances du produit.