Microsoft a finalisé son Desktop Bridge, qui permet de proposer des applications Win32 classiques dans le Store de Windows 10. Il s’agit d’une étape importante pour la boutique en ligne, qui s’accompagne d’ailleurs d’une version finale du Desktop App Converter. Explications.
Depuis environ quatre ans que le Windows Store existe, Microsoft lutte pour remplir sa boutique. Petit à petit cependant, les éditeurs y sont venus, avec des applications plus ou moins bien réussies et entretenues. Cette arrivée dans le Store supposait que le travail se fasse essentiellement autour d’UWP (Universal Windows Platform), le framework permettant de réaliser des applications utilisables sur PC, tablette, smartphone, Xbox One ou encore HoloLens.
Migrer les logiciels existants dans le Store
En avril dernier, Microsoft présentait son Desktop App Converter. Il ne s’agissait que d’une bêta, mais l’objectif était alors clair : permettre aux éditeurs de proposer leurs logiciels Win32 existants dans le Store. Ce dernier devait alors devenir une boutique proposant à la fois des applications UWP pouvant être exploitées par tous les appareils (à la discrétion du développeur bien sûr) et des versions Win32 utilisables uniquement sur les PC.
Le Desktop App Converter et le Windows Bridge, qui propose la technologie sous-jacente, sont maintenant disponibles pour tous en version finale, le DAC étant même récupérable directement sur le Store. N’importe quel éditeur a le choix désormais entre créer un logiciel Win32 directement pour le Bridge, ou convertir son projet actuel via le DAC.
Notifications, vignettes dynamiques, Cortana, mises à jour...
La seconde solution risque d’être de loin la plus utilisée. Comme nous l’avions expliqué en avril, il ne s’agit pas vraiment de « convertir » le code, puisque le code ne change pas vraiment. Le processus d’installation est par contre modifié pour être adapté. Le logiciel prend place dans un conteneur, les développeurs pouvaient s’ils le souhaitent ne plus rien toucher. Le Bridge s’occupe du reste, avec des avantages qui peuvent être exploités plus tard.
Ces avantages peuvent être plus ou moins importants selon ce qui est choisi. Une application « convertie » peut ainsi profiter de fonctionnalités que Windows 10 réservait jusqu’à présent aux applications UWP. Par exemple, les Live Tiles (vignettes dynamiques), la compatibilité avec le centre de notifications pour avertir l’utilisateur de certains évènements, ou encore celle avec Cortana. Par ailleurs, une application Win32 récupèrera la gestion spécifique par le Store, avec notamment la diffusion par les serveurs de Microsoft des mises à jour. Sur ce point, il s’agit d’une option, l’éditeur pouvait dans tous les cas utiliser sa propre infrastructure de distribution.
L’ouverture du Windows Bridge s’accompagne de la distribution du DAC dans le Store, donc accessible à n’importe quel développeur. Microsoft en profite pour préciser que le Converter prend maintenant en charge les trois solutions d’installation les plus populaires sous Windows : InstallShield (Flexera Software), WiX (FireGiant) et Advanced Installer (Caphyon). Si le paquet d’installation utilise l’une d’entre elles, le DAC saura donc quoi faire.
Des logiciels Win32 déjà disponibles
Dans la foulée, Microsoft précise que des logiciels tels que Evernote, Arduino IDE, doubleTwist, PhotoScape, MAGIX Movie Edit Pro, Virtual Robotics Kit, Relab, SQL Pro, Voya Media, Predicted Desire et korAccount débarquent ou vont débarquer dans les prochains jours.
Pour Evernote, c’est déjà le cas, mais il faut préciser un point important. En cherchant l’application dans le Store, on trouve la référence « Evernote Touch », qui renvoie vers le logiciel Win32 classique. Aucune trace par contre de l’application UWP qui était jusqu’ici disponible, en tout cas pour l’instant. La fiche n’est d’ailleurs pas remplie correctement, car Microsoft précise que les logiciels Win32 ainsi distribués ont besoin de l’Anniversary Update de Windows 10 pour fonctionner, alors qu’Evernote précise pour sa part que son produit est utilisable à partir de Windows 8.
Un danger pour UWP ?
La question est bien entendu de savoir maintenant combien d’éditeurs vont convertir de cette manière leurs logiciels existants. Au vu de la première vague, il semble évident que le DAC et le Windows Bridge suscitent l’intérêt. Mais cet intérêt peut justement être un frein pour UWP : si les développeurs peuvent se contenter de ce qu’ils ont déjà, ne risquent-ils pas de faire l’impasse sur la nouvelle plateforme ?
Quoi qu’en dise Microsoft, il s’agit effectivement d’un danger. Un tel logiciel peut être aménagé pour tirer parti de certaines fonctionnalités d’UWP (vignette, notifications…), tout en étant utilisable sur PC et tablettes. Compte tenu de l’écroulement du marché Windows Phone et d’une Xbox One qui reste une cible particulière pour de nombreuses applications, le Bridge pourrait bien s’avérer suffisant pour de nombreux éditeurs. D’un autre côté, le Store offrira des débouchés supplémentaires et continuera de se remplir, aboutissant à un résultat alors plus proche du Mac App Store, qui ne propose que des logiciels taillés pour macOS.
Commentaires (43)
#1
L’API Win32 est décidément dure à tuer…
" />
#2
C’est depuis Windows 8 (2012) que des logiciels WIN 32 sont dispos dans le Store en fait…
#3
Apple cela a pris au moins dix ans pour que cocoa perce parmi les développeurs. Pour Microsoft je pense que ce sera pire ^^
#4
L’API Win32 ne disparaitra jamais. Trop de logiciels tournent avec. La plupart du temps il n’y a aucun gain à migrer, donc les développeurs ne migrent pas.
#5
Ce n’était pas juste des liens ? Ou on avait la possibilité de télécharger l’application directement à partir du Store ?
#6
Espérons que, quand les dévs n’auront plus le choix dans la date, ça aide à finir la transition
" />
#7
Ce qui est bien avec la bonne vieille api Win32, c’est qu’on peut sortir de la “sandbox” que propose WinRT. C’est certes moins sécurisé mais ca laisse plus de possibilité au développeur pour exécuter des batchs, scripts externes pour des fonctionnalités spécifiques, difficile a mettre en place sur WinRT.
" />
Mais en vrai, sur le store y a tellement de mélange de types d’apps: celles Windows 8, celles Windows 10 mais rendue UWP, les “fausses” apps Windows 10 qui sont en réalité que des sortes de iFrame qui pointe vers un site web aux allures web-app. Finalement, de très bonnes apps authentique et intéressantes ne courent pas la rue. La faute aussi au manque d’utilisateurs et très faible revenue
#8
Les logiciels vont pouvoir utiliser une chose dont je me fiche la plupart du temps (les tuiles) et une autre qui peut vite devenir agaçante (les notifications) s’ils décident de faire n’importe quoi.
Bref, pour le moment, je ne suis pas emballé par l’idée et je n’ai pas envie d’encourager la mise aux oubliettes d’UWP, parce que c’est ni plus moins ce qu’ils sont en train de faire.
#9
#10
#11
Il confond. Tu pouvais mettre des fiches de logiciels win32 avec les urls des éditeurs. Mais les applications win32 ne pouvaient pas être téléchargés directement du store comme indique cette actu.
#12
#13
#14
Youpee, on peut continuer à utiliser WINAPI et faire ce que l’on veut !!
Jprefere encore garder une API dégueu, mais qui fait tout ce que l’on veut sur le PC, plutôt que leur UWP aseptisé et pas complet…
#15
#16
Mince alors, si les logiciels passent par Windows Store ils seront plus difficiles à cracker, voire incrackables !
#17
Ce n’est pas si horrible que ça. Il faut juste “oublier” comment on faisait en win32 car généralement, on fait tout autrement en UWP, à commencer par les appels asynchrones de toutes les fonctions I/O.
#18
Cela donne l’impression que les applis UWP n’arrivent pas assez vite, alors pour remplir le Store ils ajoutent les applis win32…
Sauf que, comme dit en fin d’article, s’il suffit de faire une bonne vieille appli win32, cela incitera encore moins les développeurs à adopter UWP…
Je sens qu’on va encore se traîner win32 pendant 30 ans…
#19
ça serait cool si vlc firefox eu acesteeam soient disponible directement sur le store ferai en sorte qu’il RAM moins sur mon ordinateur à 220 euros le lenovo g50-45
#20
#21
C’était juste les liens, avec installation classique après.
#22
Non, justement, aucun retard, mais pas du tout la même logique. J’ai fait une app Silverlight a l’époque de Windows Phone 7 et je l’ai migré en WP 8.1 (universel) puis maintenant en W10 (UWP) et il faut penser différemment.
Au final, c’est plus simple et efficace en 8.1 universel (UWP garde la même logique mais les API sont beaucoup plus complètes) mais il faut “oublier” ce qu’on savait et réapprendre.
Les briques de base XAML sont plus simples mais aussi plus universelles, on peut faire plus avec moins, mais faut bien en comprendre la logique !
Je bosse sous Delphi (Firemonkey), qui a des milliers de composants graphiques et pourtant, ça fait moins bien que les 10 éléments de bases de XAML pour UWP…
#23
#24
L auteur de l article, un peu victime du marketing Microsoft, a oublié un pt très important entre win32 et winRT, soulevé par Edtech et d autres ds les commentaires: c est que la sandbox de UWP est bcp plus limitant que les app win32 ou .NET classiques!
Une app UWP a donc un espace virtualisé et ne peut PAS accéder (et donc modifier/casser) le reste du syteme: pas de clef ds la base de registre, et PAS d accès aux fichiers hors de ceux déjà virtualisés (par ex on peut accéder aux bibliothèques de photos/videos), PAS d acces kernel/drivers, etc.
Or la large majorité d app win32 et .NET existantes utilisent ces accès.
Evidemment, pas de magie avec l outil bridge ainsi proposé: les app win32 converties auront les mêmes limitations que les app UWP
Donc il ne faut pas attendre à une grosse arrivée d app sur le store: la majorité des app win32 existantes ne peuvent PAS être si simplement converties.
plus d info par ex ici: http://www.dotnetcurry.com/windowsapp/1294/project-centennial-uwp-desktop-app-co…
#25
Je croyais justement que même les apps Win32 (même non converties) allaient être sandboxées quoi qu’il arrive.
#26
Justement si elles sont sandboxés mais pas prévues pour, il y a de fortes chance qu’elles essaie d’accéder a des ressources auxquelles elles n’ont plus droit et que ça provoque des plantages ou des bugs.
#27
Je viens de terminer un gros bedo et mes idées fusent plus vite que ce que je peux écrire
" />
#28
A mon avis c’est plus un bon point pour développer le store qu’un frein pour les UWP. Toutes les nouvelles applis seront faites en UWP, il n’y a que les historiques qui pourraient être tentés de rester un win32.
Et si ça permet de développer le store, ça attirera des développeurs, qui eux seront en UWP, donc au final UWP est gagnant, tout comme le store, tout comme MS!
#29
Cela présente un énorme avantage : la possibilité d’avoir les mêmes fonctionnalités qu’un linux la centralisation des mises à jours: exemple ccleaner, vlc, etc…, tout mis à jour tout seul et plus ergonomiquement qu’avec chocolatey
Seul bémol , je pense pas que les softs indépendants soient acceptés
#30
#31
#32
La conversion des applications WinAPI/MFC/Winforms/WPF vers des applications UWP (disons store) est une très bonne chose.
Plus de Store se remplit, plus cela attire des utilisateurs, plus il y aura des développeurs, qui, si ils sont nouveaux, utiliseront UWP et pas Win32 et le cercle vertueux s’opérera…enfin normalement ;).
Sur la base de registre…il me semble que les applications WinAPI “UWP”, ont accès à une simulation de la base de registre…et donc peuvent se permettent des écritures/lecture “factices”…à confirmer…
Le gros problème reste la plateforme mobile…dommage que ces applications ne soient pas accessibles…au travers par exemple du mode Continuum et de la virtualisation (dans Azure !?). HP le propose avec son dernier téléphone et VMware aussi avec Horizon…je pense qu’il y a un coup à jouer chez MS à ce niveau…
Le plus gros problème de MS c’est qu’ils ont dégouté les développeurs, d’abord avec WPF, puis avec Silverlight et enfin avec la première version de WinRT (semi universelle)…maintenant cela semble plus stable mais le mal est fait, les développeurs se sont tournés vers d’autres plateformes (Andoid, IOS, QT, Electron, etc) qui sont pour certaines multiplateformes…
De ce point de vu, MS a bien fait de racheter Xamarin…et créer .NetCore…
Deux articles à lire absolument :
http://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-ne…
Et surtout :
http://arstechnica.com/information-technology/2016/05/onecore-to-rule-them-all-h…
#33
#34
Oui le plus gros frein au développement de UWP, c’est Windows 7…mais bon petit a petit sa part diminue…
Je ne vois pas trop en quoi UWP limite la création d’applications…
Pour les drivers ils faut utiliser cela :
https://msdn.microsoft.com/en-us/windows/hardware/drivers/develop/getting-starte…
En tout cas pour ma part, ma prochaine application utilisera UWP et pas WinAPI…tant pis pour les utilisateurs de Windows 7, surtout que sur le store mon application sera bien plus visible (sinon il faut que je l’ héberge etc)…
#35
#36
Les drivers universels c juste une unification au niveau des api pour que les drivers marchent à la fois sur mobile et PC. Ca change en rien le fait qu’il n’existe pas d’équivalent à DeviceIoControl sur UWP. Il n’y en aura sans doute jamais ça permettrait de contourner la sandbox de UWP.
#37
Si tu relis bien, je causais de WinRT… pour UWP, on s’y est mis il y a peu de temps, et effectivement, je suis d’accord avec toi sur le fait qu’il y a eu un gros effort.
N’empeche que le sandboxing, c’est pas toujours pratique pour des applications industrielles :-).
Il y a des manieres pour “contourner” tout en restant dans la logique de la sandbox, mais dixit mon patron, c’est pas facile pour le neuneu moyen.
#38
Arrêtez de croire au père Noël, le store et UWP ne prendront pas. Même sur OS X où pourtant les utilisateurs ont plus l’habitude d’acheter du logiciel, l’habitude de passer par un store (iOS) et où celui-ci est mieux exécuté et intégré au système depuis Lion, c’est un semi-flop. Donc sur Windows où rien de tout ça n’est préé-existant, couplé avec des softs qui ont une UI ridicule et les bugs à répétitions en plus du fait que les API sont limitées t chiantes à utiliser ça va pas le faire du tout. D’ailleurs Microsoft essaie de nous le faire bouffer depuis 3 ans, on voit le résultat…
#39
Vampire7, je ne suis pas spécialiste non plus :). Effectivement il faudrait essayer…et j’espère pouvoir confirmer mes dires…je voudrais créer une application UWP qui aura besoin de ces fonctionnalités.
Mis à part la partie Service qu’il faut remplacer par une “background task”, et d’après ce que j’ai vu…le reste est possible…
charon.G, l’accès à DeviceIoControl ne semble pas interdit (ok il faut donner accès à Win32 d’après ce que j’ai compris et donc…je ne sais pas trop les conséquences ! Peut-être interdiction du Store, mais cela n’empêche pas le sideloading…(je fais une supposition)):
https://developer.microsoft.com/en-us/windows/iot/samples/deviceiocontroller
Je me trompe ?
v6relou, le Store ne prendra peut-être pas…mais UWP sera imposé puisque à terme il doit remplacer WinAPI dans son ensemble…si MS continue dans ce sens bien sûr (ça serait pas la première fois qu’ils font machine arrière…ceci dit ce coup ci…).
#40
Apparemment c’est une bidouille c’est une appli desktop qui peut utiliser des api UWP. On peut le faire depuis le début. Ce genre d’applications ne sera jamais certifié par Microsoft sur le store. De plus je doute fort que ça marche sur Windows phone…
Par contre les logiciels systèmes qui nécessitent un accès aux drivers sont plus que minoritaires. 2% de la logithèque windows sont concernés au plus…
Pour la sandbox je pense que la plupart des app win32 avec centennial peuvent être facilement adapté. Il faut juste mettre les fichiers dans le bon dossier et revoir les mécanismes IPC. On peut aussi remplacer l’utilisation de la BDR par un système de settings similaire dans le fonctionnement interne mais sandboxé.
Ensuite la version actuelle de centennial est préliminaire. Elle agit comme un app-v like. Les fichiers sont rediriges dans le bon dossier mais en réalité il n’y a pas de sandbox. Il existe aussi certaines limitations avec les services. Du moins c’était le cas au départ. Je pense que centennial va être amélioré avec barcelona qui est apparemment présent dans RS2. C’est une évolution des conteneurs pour windows client. Elle gère une isolation matérielle optionnelle(intel SGX). Les api d’enclave sont déjà présentes dans windows 10.
#41
Merci charon.G pour la précision. C’est toujours cool d’avoir ce genre d’infos…
Il me semblait que WindowsIOT n’acceptait que des applications UWP c’est pour ça que j’ai envoyé le lien vers l’article.
Du coup c’est plutôt l’inverse, de l’UWP qui accède à Win32…ok je joue sur les mots…
Ils proposent d’ailleurs de passer par “Windows.Devices.Custom” mais je suppose que ce n’est pas équivalent…
Et oui, ce n’est disponible que pour Windows 10 desktop et IOT et le store c’est mort…mais ça n’empêche pas de proposer l’application au téléchargement de manière classique…
#42
Pour Windows.Devices.Custom tu ne dois pouvoir ouvrir que certains drivers précis. J’avais cherché sur le sujet. Ils en parlent dans ce doc:
http://go.microsoft.com/fwlink/p/?LinkId=306693
Il serait possible dans certains cas précis d’accéder à des drivers d’une appli UWP mais ils doivent être prévus pour être utilisé uniquement par ton application. Ce feature n’est disponible que pour les constructeurs apparemment et il faut une autorisation spéciale de Microsoft.
Comme je l’expliquais au dessus si ils donnaient l’autorisation aux applications UWP d’accéder aux drivers ce serait assez facile de percer la sandbox vu qu’un driver kernel mode a absolument tous les droits.
De toute façon sur le long terme je pense que les drivers kernel mode disparaîtront….
#43
Je n’ai pas essayé mais si tu utilises ces api directement je pense que ça sortira une erreur 5 (accés refusé).