Die mythische 'Vista-Anwendung'

Ich liebe Analytiker. Ob es das nächste große Ding von morgen vorhersagt oder den Todesstoß für den gestrigen Schrittmacher der Branche schlägt, den Analysten mangelt es nie an neuen Wegen, es falsch zu machen.

Beispiel: Windows Vista und die "app gap". Laut Evans Data Corporation (EDC) , schreiben weniger als 10 Prozent der Entwickler für den aktuellen Stand der Technik von Microsoft. Die Mehrheit (49 Prozent) schreibt noch immer für XP, während ein kleines, aber wachsendes Kontingent (13 Prozent) sich auf Linux konzentriert. Inzwischen kritisieren die unzähligen großen Medien den Mangel an neuen Vista-Anwendungen. "Es ist das Betriebssystem, das niemand will", sagen sie, und die Entwickler "reagieren entsprechend".

Natürlich liegen sie falsch. Wieder.

[Lesen Sie weiter: Unsere besten Windows 10 Tricks, Tipps und Verbesserungen]

Sie sehen, es gibt keine Vista-Anwendung. Genauso wenig wie eine XP-Anwendung. Oder eine Windows 2000-Anwendung. Entwickler, die für Windows schreiben, zielen selten auf eine bestimmte Version ab. Vielmehr wählen sie ein bestimmtes API-Framework aus - zum Beispiel MFC / ATL oder.Net - und gehen von dort aus weiter. Ob die resultierende Anwendung auf einer bestimmten Windows-Version ausgeführt wird oder nicht, hängt davon ab, welche versionsspezifischen API-Erweiterungen der Entwickler in seinem Projekt verwendet.

Für die meisten Anwendungstypen ist dies kein Problem: Sie verwenden das generische API-Funktionen, mit denen sie über jede Windows-Version laufen können, die dieses Framework unterstützt. Und da Microsoft gute Back-Porting-Funktionen für neue Frameworks auf seinen älteren Betriebssystemplattformen bietet, stehen Entwickler selten vor der Wahl zwischen umfangreichen API-Funktionen oder einer breiten installierten Basis (die Ausnahme sind Videospielentwickler, die DirectX 10 einsetzen) nach Vista).

Also das ganze Vista "app gap" Argument ist ein bisschen wie ein Strohmann. Die eigentliche Frage sollte lauten: Warum nutzen Entwickler nicht die verschiedenen Iterationen des.NET-Frameworks? Jeder, der die Entwicklungs-Roadmap von Microsoft befolgt, wird bestätigen, dass der Großteil der innovativen API-Entwicklung des Unternehmens innerhalb von.Net stattfindet. In der Tat, wenn die "Experten" über neue programmatische Ressourcen in Vista sprechen - Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) und so weiter - sprechen sie wirklich über das.Net-Framework 3.0. Und da.Net 3.0 auf Down-Level-Plattformen (wie Windows XP) verfügbar ist, dreht sich das Argument um eine Frage der.Net-Akzeptanz bei den Entwicklern - und warum sie es (bisher) gemieden haben.

Die Die Antwort ist zweifach: Erstens möchten Entwickler nicht auf APIs abzielen, die nicht überall in der installierten Basis verfügbar sind. Trotz Microsofts aggressiver Unterstützung von Down-Level-Versionen gibt es immer noch einen großen Unterschied zwischen "verfügbar" und "verfügbar nach dem Herunterladen von 20 MB plus komplexer Bibliotheken und ihrer Installation über verschiedene Teile Ihres Systems". Tatsache ist, dass.Net nicht als Teil von Windows XP ausgeliefert wird, und das bedeutet, dass Entwickler Benutzer davon überzeugen müssen, zuerst die erforderliche Version des.Net-Frameworks zu installieren, bevor sie eine Software installieren können - nicht immer ein einfacher Verkauf, besonders in der gesperrten Welt der Unternehmens-IT.

Als erstes Betriebssystem, das standardmäßig mit dem.Net-Framework ausgeliefert wurde, sollte Vista die Entwicklung von.Net 3.0-Anwendungen fördern. Da es jedoch auch ältere Win32-, COM-, ATL-, MFC- und Down-Level-.NET-Framework-Anwendungen unterstützt, gibt es keinen Mangel an Vista-Programmen. In der Tat, es sei denn, Sie müssen nur die neuesten und besten WPF / WCF-Framework-Funktionalität haben, gibt es wenig, um Sie als Entwickler zu motivieren, den Sprung zu.Net 3.0 oder sogar 2.0 zu machen. Angenommen, Sie stoßen nicht auf den UAC-Mechanismus (User Account Control, Benutzerkontensteuerung), so sieht Ihre "alte" Windows-Anwendung wahrscheinlich unter Vista aus wie sie ist. Ich weiß, weil das bei meinem eigenen Code der Fall war: Ein paar Optimierungen für die UAC (hauptsächlich das Verschieben einiger temporärer Dateien weg von neu geschützten Verzeichnisstrukturen) und meine Anwendungen und Dienste liefen wie Champs unter Vista - genau wie unter Windows XP, Server 2003 und Windows 2000. Warum beheben Sie es, wenn es nicht kaputt ist?

Der zweite Grund, warum Entwickler.Net gemieden haben, ist, dass es langsam ist. Viele gängige Funktionen benötigen unter.NET einfach mehr Zeit und zwingen Entwickler dazu, zwischen API-Raffinesse und roher Leistung zu wählen. Es überrascht nicht, dass die meisten Entwickler letzteres wählen, wie ich einmal gezwungen war, als ich entdeckte, dass das.Net-Äquivalent von Performance Data Helper (PDH) für Echtzeit-Sampling von Windows-Leistungsindikatordaten nahezu unbrauchbar war. Aus diesem Grund bin ich gezwungen, eine Codecode-Basis für Visual Studio 6 (ca. 1997) zu pflegen, während ich darauf warte, dass Microsoft schließlich.Net bis zu einem Punkt rationalisiert, an dem es eine brauchbare Alternative ist. Es ist eine alte Geschichte und viel zu häufig unter Windows-Entwicklern.

Fazit: Wenn Analysten (und ihre Medienkomplizen) den Mangel an "Vista-Anwendungen" anprangern, trompeten sie nur ihre eigene Ignoranz.

Ich schätze, es ist ein Mac-Sache: So viele meiner Zeitgenossen waren im Bereich der Realitätsverzerrung gefangen, dass die Idee einer Verbindung zwischen API-Funktionalität und OS-Version ein akzeptierter Teil der herkömmlichen Weisheit geworden ist. Es ist ein ehrlicher Fehler, Apple's archaisches Patchwork von Versionsabhängigkeiten gleichzusetzen mit Microsofts unvollkommener, aber viel flexiblerer API-Sprawl.

Zu ​​viel Obst wird Ihnen das antun.