L'application Mythical 'Vista Application'

J'aime les analystes. Qu'il s'agisse de prédire le prochain grand événement de demain ou de sonner le glas de l'industrie hier, les analystes ne manquent jamais de nouvelles façons de se tromper.

Exemple: Windows Vista et le «gap des applications». Evans Data Corporation (EDC) , moins de 10% des développeurs écrivent pour l'état de l'art actuel de Microsoft. La majorité (49%) écrit encore pour XP, alors qu'un petit contingent, mais en croissance (13%) se concentre sur Linux. Pendant ce temps, la myriade de grands médias continuent de dénoncer l'absence de nouvelles applications Vista. "C'est l'OS que personne ne veut", disent-ils, et les développeurs "réagissent en conséquence".

Bien sûr, ils ont tort. Encore.

[Lectures supplémentaires: Nos meilleures astuces, trucs et astuces pour Windows 10]

Vous voyez, il n'y a pas d'application Vista. Tout comme il n'y a pas d'application XP. Ou une application Windows 2000. Les développeurs qui écrivent pour Windows ciblent rarement une version spécifique. Au lieu de cela, ils sélectionnent un framework d'API particulier - par exemple, MFC / ATL ou.Net - et procèdent à partir de là. Que l'application résultante s'exécute sur une version Windows donnée ou non dépend des extensions API spécifiques à la version utilisées par le développeur dans leur projet.

Pour la majorité des types d'application, il s'agit d'un nonissue: Ils utilisent le générique Les fonctions de l'API, qui leur permettent de fonctionner sur n'importe quelle version de Windows prenant en charge ce framework. Et comme Microsoft fait un bon travail de rétroportage de nouveaux frameworks sur ses plates-formes OS héritées, les développeurs sont rarement confrontés au choix entre une fonctionnalité API riche ou une base installée étendue (à l'exception notable des développeurs de jeux vidéo pour lesquels DirectX 10 commettre à Vista).

Donc l'argument de Vista "app gap" entier est un peu un homme de paille. La vraie question devrait être: pourquoi les développeurs ne tirent-ils pas parti des différentes itérations du framework.Net? Comme l'attestera quiconque suivra la feuille de route du développement de Microsoft, la majeure partie de l'évolution des API de pointe de la société se déroule au sein de.Net. En fait, lorsque les «experts» parlent de nouvelles ressources programmatiques dans Vista - Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), etc. - ils parlent vraiment de.Net framework 3.0. Et puisque.Net 3.0 est disponible sur les plates-formes de bas niveau (comme Windows XP), l'argument tourne autour d'une question d'acceptation.Net parmi les développeurs - et pourquoi ils l'ont (jusqu'ici) évité.

La réponse est double: d'abord, les développeurs n'aiment pas cibler les API qui ne sont pas largement disponibles sur la base installée. Malgré la prise en charge agressive des versions de bas niveau par Microsoft, il existe toujours une grande différence entre "disponible" et "disponible après avoir téléchargé 20 Mo de plus de bibliothèques complexes et les avoir installées sur différentes parties de votre système." Le fait est que.Net ne fait pas partie de Windows XP, et cela signifie que les développeurs doivent convaincre les utilisateurs d'installer d'abord la version requise du framework.Net avant de pouvoir installer un logiciel - non

Comme le premier système d'exploitation à être livré avec le framework.Net installé par défaut, Vista était supposé encourager le développement d'applications.Net 3.0. Toutefois, comme il prend également en charge les anciennes applications de framework Win32, COM, ATL, MFC et down-level.Net, il n'y a pas vraiment de pénurie de programmes Vista. En fait, à moins que vous n'ayez besoin de la dernière et meilleure fonctionnalité du framework WPF / WCF, il n'y a pas grand chose à vous motiver, le développeur, à faire le saut vers.Net 3.0, ou même 2.0. En supposant que vous ne tombiez pas dans le mécanisme de contrôle de compte d'utilisateur (UAC), votre application Windows "ancienne" semble probablement et fonctionne bien sous Vista tel quel. Je sais, parce que c'était le cas avec mon propre code: quelques ajustements pour accommoder l'UAC (la plupart du temps en déplaçant certains fichiers temporaires des structures de répertoires nouvellement protégées) et mes applications et services fonctionnaient comme des champions sous Vista - comme ils le font sous Windows XP, Server 2003 et Windows 2000. Pourquoi le réparer quand il n'est pas cassé?

La deuxième raison pour laquelle les développeurs ont évité.Net est que c'est lent. De nombreuses fonctions courantes prennent simplement plus de temps sous.Net, obligeant les développeurs à choisir entre la sophistication de l'API et les performances brutes. Il n'est pas surprenant que la plupart des développeurs choisissent ce dernier, comme je l'ai déjà fait lorsque j'ai découvert que l'équivalent.Net de Performance Data Helper (PDH) était pratiquement inutilisable pour l'échantillonnage en temps réel des données du compteur de performance Windows. En conséquence, je suis obligé de maintenir une base de code Visual Studio 6 vieillissante (vers 1997) en attendant que Microsoft rationalise finalement.Net à un point où c'est une alternative viable. C'est une vieille histoire et beaucoup trop commune chez les développeurs Windows. Bottom Line: Lorsque les analystes (et leurs complices des médias) décrient le manque d'applications Vista, ils trompent simplement leur propre ignorance.

Je suppose que c'est un Mac chose: Beaucoup de mes contemporains ont été pris dans le domaine de la distorsion de la réalité que l'idée d'un lien entre la fonctionnalité API et la version OS est devenue une partie acceptée de la sagesse conventionnelle. C'est une erreur honnête, assimilant le patchwork archaïque de dépendances de versions d'Apple à l'étalement de l'API de Microsoft, imparfait mais beaucoup plus flexible.

Trop de fruits vous le feront.