Je reformule en : Est-ce qu'il y a beaucoup de développeurs pro, ici, qui ont volontairement choisit
.NET Framework pour faire du multiplateforme ?
=> Non .net framework est un framework comme son nom l'indique et il n'est pas multiplate-forme car il embarque du code spécifique à Windows genre Registry. .Net Core n'embarque pas ce type de code, il existe des paquets nuget pour faire ça mais du tout ça rend l'application non portable logique le code en question étant lié spécifiquement aux Apis d'un système particulier.
Vous mélangez plusieurs choses d'une toute l'infrastructure de COM3 (Aka .net) est standardisé, secondement la standardisation est bien actualisée régulièrement.
Concernant la CLI elle n'a rien de spécifique à Windows vous confondez l'interface et son implémentation. La JVM sous linux contient des tas de trucs spécifique à ce système. Il existe depuis toujours une implémentation complète de COM3 (Aka .net) sous linux et osx qui est Mono, qui est utilisé par Xamarin par exemple ou par Banshee.
- Le support de Visual Studio sur Mac, c'est la même chose. Alors la dernière maj de Visual studio for Mac partage le même code base que la version Windows, (Et macos est une horreur pour travailler la moindre chose un peu touchy devient un enfer car on est en taule sur sa propre machine).
- C++/CLI est normalisé cher ECMA ? Il ne peut pas l'être pour le moment seul Windows permet d'avoir deux images dans le même executable fonctionnant comme un tout. Il y'a de l'infra à faire sur Linux et Macos pour ce genre de chose. Sauf si MS trouve un moyen de gérer ça au niveau CLR sur ces os.
Vous commencez à voir avec ces exemples ce que j'essayais d'expliquer, maladroitement, dans mon 1er poste.
Pourquoi MS a choisit sont propre outillage pour faire exactement ce que des standard de fait permettaient déjà sous toutes les autres plateformes ?
Leur propre format binaire PE (générer par leur seul compilateur, au lieu de COFF/ELF/MachO), leur propre Build System, leurs propre API incompatible POSIX ...etc
Ce sont leurs choix, mais ne venez pas dire qu'ils ont fait ça pour le bien de tout le monde et pour améliorer la compatibilité.
Si MS voulait viser la compatibilité maximum, ils leur suffirait d'offrir une API POSIX et une chaine de compilation compatible.
La vraie question est pourquoi on devrait ce farcir Posix ? Ce truc est une horreur absolu, secondement MachO est une passoire le plus fun est de mettre des scripts pythons après EOF et de mettre un JUMP pour lancer directement dans les exécutables comment dire ... laissez MachO crever.
En plus vous confondez PE et COFF alors que PE utilise COFF mais pour ça vous avoir lu la spécification et pas juste débiter des termes technique sans en comprendre le sens. Le format PE a été créé car Windows NT fonctionne sur autre chose que Intel x86 à l'origine COFF a été spécifiquement conçu pour Unix System V et pour éviter d'avoir à gérer plusieurs formats d'images pour chaque architecture Microsoft a repris COFF et a modifié ce qui était spécifique lié à x86/SystemV (en ajoutant un niveau d'abstraction) pour en faire un format Portable d'ou le Portable Executable c-a-d portable sur différentes architectures ce qui n'était pas le cas de COFF. Ceci explique pourquoi les exécutables UEFI utilisent aussi le format PE et non des monstruosités comme COFF/ELF/MACHO. Par ailleurs, Windows 95,98,ME utilisaient le format NE de mémoire.
Pourquoi leur propre outillage et pourquoi pas en fait ? Je veux dire aux dernières nouvelles on a encore le droit de proposer des choses différentes, et de voir les problèmes sont d'autres angles. Sauf si s'est interdit pour le bien de tous bien évidement dans votre délire Stalinien (le délire de libriste de base, vous être libre de faire ce que JE VEUX).
Je note tout de même, qu'à ma connaissance, les personne qui travail avec VisualC++, ne font pas d' ISO/C++ mais bien du MS/VisualC++.
De la même façon que les gens qui font du GCC ne font pas de l'iso/c++ ... pareil pour CLANG le problème vient du langage C++ lui même. Le temps inouïe nécessaire pour valider la moindre fonctionnalité fait que les concepteurs de compilateurs compensent en créant leur propre extensions, sinon y'a la solution de foutre du boost partout en attendant éventuellement que dans 100 ans C++ permette de faire nativement des trucs basique. Heureusement de Microsoft propose des choses différentes on a enfin des lambdas en C++, merci les specs de .NET .
Ce que je trouve drôle pour ne pas parfaitement hilarant est que quand MS utilise des standards tout le monde s'en plaint exemple simple le standard HID, ou encore CGI qui fait que tout le monde se plaignait que Php marchiant mal sous IIS alors que le problème vient de Php lui même qui s'est éloigné du standard. Ce qui veut donc dire qu'apache n'est pas standard ^^
1 |
0 |
NET Core 3.0 est disponible depuis peu avec le support du développement d’applications Windows Desktop, C# 8.0, ARM64, la prise en charge native de JSON et de nombreuses autres améliorations.
Qu’en pensez-vous ?
Envoyé par ParseCoder
