The Mythical 'Vista Application'

Ik ben gek op analisten. Of het nu het volgende grote ding van morgen voorspelt of de doodsteek luidt voor de industrie-industrie van gisteren, analisten hebben nooit te weinig nieuwe manieren om het verkeerd te krijgen.

Voorbeeld: Windows Vista en de "app gap". Volgens Evans Data Corporation (EDC) , schrijft minder dan 10 procent van de ontwikkelaars voor de huidige stand van zaken van Microsoft. De meerderheid (49 procent) schrijft nog steeds voor XP, terwijl een klein, maar groeiend, contingent (13 procent) zich richt op Linux. Ondertussen blijven de talloze grote mediakanalen het gebrek aan nieuwe Vista-applicaties afwijzen. "Het is het besturingssysteem dat niemand wil", zeggen ze, en ontwikkelaars reageren "dienovereenkomstig."

Natuurlijk hebben ze ongelijk. Nogmaals.

[Lees meer: ​​Onze beste Windows 10-tricks, tips en tweaks]

U ziet dat er niet zoiets bestaat als een Vista-toepassing. Net zoals er niet zoiets bestaat als een XP-applicatie. Of een Windows 2000-applicatie. Ontwikkelaars die schrijven voor Windows richten zich zelden op een specifieke versie. In plaats daarvan selecteren ze een bepaald API-framework - bijvoorbeeld MFC / ATL of.Net - en gaan vandaar verder. Of de resulterende applicatie wel of niet op een bepaalde Windows-versie wordt uitgevoerd, hangt af van welke API-uitbreidingsversies de ontwikkelaar in zijn project gebruikt.

Voor de meeste applicatietypen is dit een niet-uitbestedingsproduct: ze gebruiken de generieke API-functies, waarmee ze elke Windows-versie kunnen doorlopen die dit framework ondersteunt. En aangezien Microsoft goed werk verricht door nieuwe frameworks te back-porten naar zijn oudere OS-platforms, worden ontwikkelaars zelden geconfronteerd met een keuze tussen rijke API-functionaliteit of een brede installed base (de opmerkelijke uitzondering zijn ontwikkelaars van videogames, voor wie gebruikmaken van DirectX 10 betekent zich verbindend tot Vista).

Dus het hele Vista-app-gap-argument is een beetje een stroman. De echte vraag zou moeten zijn: waarom gebruiken ontwikkelaars de verschillende iteraties van het.Net-framework niet? Zoals iedereen die volgt op de ontwikkelingsroadmap van Microsoft zal bevestigen, vindt de meeste vernieuwende API-evolutie van het bedrijf plaats binnen.Net. Als de "experts" praten over nieuwe programmeermiddelen in Vista - Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), enzovoort, praten ze eigenlijk over het.Net Framework 3.0. En aangezien.Net 3.0 beschikbaar is op down-level platforms (zoals Windows XP), keert het argument terug naar een kwestie van.Net-acceptatie tussen ontwikkelaars - en waarom ze het (tot nu toe) hebben gemeden.

Het antwoord is tweeledig: ten eerste willen ontwikkelaars geen API's targeten die niet breed beschikbaar zijn op de geïnstalleerde basis. Ondanks de agressieve ondersteuning door Microsoft van down-levelversies, is er nog steeds een groot verschil tussen "beschikbaar" en "beschikbaar na het downloaden van 20 MB-plus complexe bibliotheken en deze te hebben geïnstalleerd op verschillende delen van uw systeem." Het feit is dat.Net niet wordt verzonden als onderdeel van Windows XP en dat betekent dat ontwikkelaars gebruikers moeten overtuigen eerst de vereiste versie van het.Net-framework te installeren voordat ze een stukje software kunnen installeren - niet altijd gemakkelijk te verkopen, vooral in de afgesloten IT-wereld van de onderneming.

Als eerste besturingssysteem dat standaard met het.Net-framework werd geleverd, moest Vista de ontwikkeling van.Net 3.0-applicaties stimuleren. Omdat het echter ook oudere Win32-, COM-, ATL-, MFC- en down-level.Net-framework-applicaties ondersteunt, is er geen echt tekort aan Vista-programma's. In feite, tenzij je net die nieuwste en beste WPF / WCF framework-functionaliteit moet hebben, is er weinig dat je, de ontwikkelaar, motiveert om de sprong naar.Net 3.0 of zelfs 2.0 te maken. Ervan uitgaande dat u niet tegen het User Account Control (UAC) -mechanisme aanloopt, ziet uw "legacy" Windows-toepassing er waarschijnlijk naar uit en werkt deze onder Vista uitstekend. Ik weet het, omdat dat het geval was met mijn eigen code: een paar tweaks om UAC te huisvesten (meestal verschuiving van een aantal tijdelijke bestanden weg van nieuw beschermde mapstructuren) en mijn applicaties en services liepen als champs onder Vista - net zoals ze dat doen onder Windows XP, Server 2003 en Windows 2000. Waarom repareren als het niet kapot is?

De tweede reden waarom ontwikkelaars hebben gemeden. Net is dat het langzaam is. Veel algemene functies duren eenvoudigweg langer onder.Net, waardoor ontwikkelaars moeten kiezen tussen API-verfijning en onbewerkte prestaties. Het is niet verrassend dat de meeste ontwikkelaars voor het laatste kiezen, zoals ik ooit moest doen toen ik ontdekte dat het.Net-equivalent van Performance Data Helper (PDH) vrijwel onbruikbaar was voor real-time sampling van Windows-prestatiemeteritemgegevens. Dientengevolge, ben ik genoodzaakt om een ​​verouderende (circa 1997) Visual Studio 6 codebasis te handhaven in afwachting van Microsoft om eindelijk.Net te stroomlijnen naar een punt waar het een uitvoerbaar alternatief is. Het is een oud verhaal en veel te gebruikelijk bij Windows-ontwikkelaars.

Bottom Line: wanneer analisten (en hun medeplichtigen) het ontbreken van 'Vista-toepassingen' afkeuren, overtreffen ze alleen hun eigen onwetendheid.

Ik vermoed dat het een Mac-ding: zo veel van mijn tijdgenoten zijn verstrikt geraakt in het realiteitsvervormingsveld dat het idee van een koppeling tussen API-functionaliteit en OS-versie een geaccepteerd onderdeel van de conventionele wijsheid is geworden. Het is een eerlijke fout, die het archaïsche patchwork van versievoorzieningen van Apple gelijkstelt aan de onvolkomen, maar veel flexibeler, API-uitbraak van Microsoft.

Te veel fruit zal dat voor je doen.