Microsoft facilite l’emploi de Win32 pour les développeurs C# et Rust
Le 22 janvier 2021 à 09h23
1 min
Logiciel
Logiciel
L’éditeur cherche à se débarrasser de son environnement Win32 depuis longtemps. Mais la situation s’est stabilisée sur une étrange dichotomie : les initiatives continuent pour l’éliminer (Windows RT, 10S, 10X…), mais des efforts sont faits pour mieux l’intégrer dans des applications modernes.
Win32 est surtout disponible aux développeurs C et C++. L’utilisation de ces API est techniquement faisable pour d’autres langages, mais elle est malaisée et peut facilement conduire à des erreurs.
Microsoft propose donc win32metadata (dépôt GitHub) qui fournit, comme son nom l’indique, une description complète de la surface des API Win32, qui peut alors être projetée vers n’importe quel langage. Le résultat en sortie est un fichier de métadonnées Windows (winmd), compatible ECMA-335 et publié sur Nuget.org.
win32metadata peut donc être utilisé pour générer des wrappers vers les API Win32, simplifiant le travail d’écriture et réduisant drastiquement les erreurs potentielles.
Deux sont déjà proposés, C#/Win32 pour le C# et windows-rs pour le Rust. Il s’agit d’un début, l’éditeur espérant en proposer d’autres plus tard.
Le 22 janvier 2021 à 09h23
Commentaires (11)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 22/01/2021 à 11h05
à savoir que ms utilise de plus en plus de rust en intern pour windows et ça c’est cool !
ce system de méta data aurrait dut être fait il y as 15 ans par contre, ça parait “tout con” mais niveau facilité d’utilisation pour l’interop ça aurrait été génial…
Le 22/01/2021 à 17h18
Ca fait 15 ans que MS tente par tous les moyens de dégoûter les développeurs de faire du Win32. Ils ont déjà proposé un nombre impressionnant de couches, de surcouches et de sur-surcouches…
Toues incompatibles les unes avec les autres, bien sûr. Y’a qu’à voir Raymon Chen expliquer comment faire un truc simple. Il est obligé de faire quatre articles, un pour chacune des technologies, Win32, C++/CX, C++/RT, .Net et encore quelques variantes…
Auraient-ils enfn compris ?
Le 22/01/2021 à 22h47
Moi qui espère a chaque update voit une facon facile de créer des app WPF avec rust au lieu de C#
mais bon je continue d’espérer un jours peut être.
Le 23/01/2021 à 11h07
C’est possible ça ? WPF est intrinsèquement basé sur .NET, dont la philosophie est à l’opposé de Rust…
Le 23/01/2021 à 12h38
.net est pour l’interface graphique, c# est pour le code (intelligence derrière l’interface), donc a priori ce n’est pas impossible d’utilisé WPF (avec .NET) avec du RUST pour le code
Le 23/01/2021 à 13h57
Ben moi ce qui m’inquiète c’est la gestion de la mémoire. .Net utilise un ramasse-miettes, alors que Rust se base sur des free() explicites et le traçage de l’unique pointeur qui contrôle chaque bloc alloué… Ce sont deux méthodes qui me semblent irréconciliables.
Le 23/01/2021 à 18h07
sauf que encore une fois .net c’est coté interface et rust coté code, tous comme WPF standard utilise .net coté interface et c# coté code.
Il existé déjà plein de projet pour tuilisé rust avec .net, et je trouve simplement domage que microsoft qui utilise beaucoup rust pour sa sécurité (coté dépassement de mémoire), n’accélère pas ces projets quitte a poussé petit a petit le c/c# vers la sortie.
Bien entendu pas faire cela en un jours mais une intégration pourrais être simpas.
Le 24/01/2021 à 08h33
Hmmmmm…. Je crois qu’on ne se comprend pas, je vais me permettre de préciser ma pensée. Préambule: ceci est ce que je pense en fonction de mon expérience de programmation, c’est mon avis personnel et pas nécessairement une vérité universelle que je tente d’imposer.
Autant je comprends qu’on puisse vouloir déléguer un traitement lourd à une routine en Rust (ou en tout autre langage non-managé) pour des raisons de performances lisibilité ou fonctionnalités, j’imagine mal qu’il soit souhaitable de vouloir traiter systématiquement les événements ponctuels (genre OnClick, OnTextChange) par des routines en Rust.
D’abord parce que les composants WPF sont écrits nativement en .NET, donc ça va être une galère pour les sous-classer en Rust qui a un système de types complètement différent. Ensuite parce que passer systématiquement d’une plateforme à l’autre aura un coût non non négligeable en termes de marshalling des valeurs structurées, ce qui annihile tout gain de performance dû à la nature de la plateforme Rust.
À mon sens, il est préférable dans l’UI (et lui seul) de prendre la pilule bleue et de rester dans l’univers managé .NET, et ne passer dans l’autre monde que pour des traitements lourds.
Une solution pour les callbacks UI serait évidemment de porter la syntaxe Rust pour qu’elle tourne nativement en .NET, on appellerait ça “IronRust”, mais comme le nom le suggère, ça ne semble pas une très bonne idée, on ne porterait que la syntaxe, pas la philosophie sous-jacente.
Le 24/01/2021 à 16h03
oui en effet on se comprenait pas, car je pensait pas a remplacé le .net par du rust, just permettre au rust d’accédé au contenu du .NET, exemple textebox.Text = variable Rust qui est un string, autrement dit commandé une interface en .NET avec du rust, mon but ne serait pas la vitesse mais uniquement le gain sécuritaire du .RUST qui est imunisé au attaque par dépassement de mémoire.
Le 25/01/2021 à 07h37
De manière générale, les langages .NET sont eux aussi immunisés contre ça. Il faut explicitement utiliser le mot clé
unsafepour bricoler soi-même avec les adresses mémoire.En tout cas, C#, VisualBasic/.NET et F# sont safe par défaut. Je ne sais pas pour C++/.NET.
Dans ces conditions, MS n’a aucune raison particulière de favoriser Rust pour piloter WPF, sauf à, éventuellement, fournir un compilateur Rust vers .NET, mais n”importe qui peut démarrer ce projet… S’il existe un front-end Rust et un backend .NET pour LLVM, c’est emballé pesé livré, mais en attendant…
Le 25/01/2021 à 17h00
.net est imunisé mais pas le c#, de plus le rust, est de plus bas niveau et a donc de meilleur performance en général (possibilité d’activé une fonction ayant pour but de détecté d’eventuel dépassement de mémoire, et s’il y a un détecteur c’est que les dit dépassement sont possible.