Den mytiske Vista applikasjonen

Jeg elsker analytikere. Uansett om det forutser morgendagens neste store ting eller klinger dødsklokken for gårsdagens industripasetter, går analytikere aldri ut av nye måter å gjøre feil.

Case in point: Windows Vista og "app gap". Evans Data Corporation (EDC) , skriver mindre enn 10 prosent av utviklerne for Microsofts nåværende toppmoderne. De fleste (49 prosent) skriver fortsatt for XP, mens en liten, men voksende, kontingent (13 prosent) fokuserer på Linux. I mellomtiden fortsetter de utallige store medieavdelingene å mangle nye Vista-applikasjoner. "Det er operativsystemet som ingen vil ha," sier de, og utviklerne "reagerer tilsvarende." Selvfølgelig er de feil. Igjen.

[Videre lesing: Våre beste Windows 10-triks, tips og tweaks]

Du ser, det er ikke noe som et Vista-program. Akkurat som det ikke er noe som en XP-applikasjon. Eller et Windows 2000-program. Utviklere som skriver for Windows, retter sjelden mot en bestemt versjon. I stedet velger de et bestemt API-rammeverk - for eksempel MFC / ATL eller.Net - og fortsett derfra. Hvorvidt den resulterende applikasjonen kjører på en gitt Windows-versjon, avhenger av hvilke, hvis noen, versjonsspesifikke API-utvidelser som utvikleren bruker i prosjektet.

For de fleste bruksområder er dette et nonissue: De bruker generisk API-funksjoner, som lar dem kjøre over alle versjoner av Windows som støtter rammen. Og siden Microsoft gjør en god jobb med å sende nye rammer til sine eldre OS-plattformer, blir utviklerne sjelden utsatt for et valg mellom rik API-funksjonalitet eller en bred installert base (det bemerkelsesverdige unntaket er videospillutviklere, for hvem som utnytter DirectX 10 forplikte seg til Vista).

Så hele Vista-app-gapet-argumentet er litt av en halmmann. Det virkelige spørsmålet bør være: Hvorfor bruker ikke utviklere de ulike iterasjonene av. Net-rammen? Som alle som følger Microsofts utviklingsplan vil bevise, går det meste av selskapets banebrytende API-utvikling i.Net. Faktisk, når "eksperter" snakker om nye programmatiske ressurser i Vista - Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) osv., Snakker de egentlig om.Net Framework 3.0. Og siden.Net 3.0 er tilgjengelig på plattformer på nivånivå (for eksempel Windows XP), går argumentet rundt om til et spørsmål om. Net aksept blant utviklere - og hvorfor de har (så langt) fjernet det. svaret er todelt: For det første liker utviklere ikke å målrette mot APIer som ikke er bredt tilgjengelige over den installerte basen. Til tross for Microsofts aggressive støtte av versjoner på nivellerivå, er det fortsatt stor forskjell mellom "tilgjengelig" og "tilgjengelig etter nedlasting av 20 MB-pluss komplekse biblioteker og å ha dem installert på tvers av ulike deler av systemet." Faktum er at.Net ikke sendes som en del av Windows XP, og det betyr at utviklere må overbevise brukerne om å først installere den nødvendige versjonen av. Net-rammen før de kan installere et stykke programvare - ikke alltid en lett salg, spesielt i den nedlåste IT-bransjen.

Som det første OS som skulle leveres med.Net-rammen som ble installert som standard, skulle Vista oppmuntre til utvikling av. Net 3.0-applikasjoner. Men siden det også støtter eldre Win32-, COM-, ATL-, MFC- og down-level. Net rammeprogrammer, er det ingen reell mangel på Vista-programmer. Faktisk, med mindre du bare må ha den nyeste og beste WPF / WCF-rammefunksjonaliteten, er det lite å motivere deg, utvikleren, til å gjøre hoppet til.Net 3.0 eller 2.0. Hvis du antar at du ikke støter på UAC-mekanismen (User Account Control), ser du "arven" Windows-programmet sannsynligvis ut og fungerer bra under Vista som det er. Jeg vet, fordi det var tilfellet med min egen kode: Noen få tweaks for å imøtekomme UAC (for det meste skifte noen midlertidige filer fra nybeskyttede katalogstrukturer) og mine applikasjoner og tjenester løp som champs under Vista - akkurat som de gjør under Windows XP, Server 2003 og Windows 2000. Hvorfor fikse det når det ikke er ødelagt?

Den andre grunnen til at utviklere har shunned. Net er at det er tregt. Mange vanlige funksjoner tar bare lengre tid under. Net, og tvinge utviklere til å velge mellom API-raffinement og rå ytelse. Ikke overraskende, de fleste utviklere velger sistnevnte, da jeg en gang var tvunget til å gjøre da jeg oppdaget at.Net-ekvivalenten til Performance Data Helper (PDH) var alt annet enn ubrukelig for sanntidsprøving av Windows-prestasjonsdiskdata. Som et resultat, er jeg tvunget til å opprettholde en eldre (ca. 1997) Visual Studio 6-kodebase mens jeg venter på Microsoft for endelig å strømline.Net til et punkt der det er et levedyktig alternativ. Det er en gammel historie og altfor vanlig blant Windows-utviklere.

Bunnlinjen: Når analytikere (og deres mediapartnere) beklager mangelen på "Vista-applikasjoner", taster de bare sin egen uvitenhet.

Jeg antar at det er en Mac thing: Så mange av mine samtidige har blitt fanget opp i realitetsforvrengningsfeltet at ideen om en kobling mellom API-funksjonalitet og OS-versjon har blitt en akseptert del av den konvensjonelle visdommen. Det er en ærlig feil, som likner Apples arkaiske patchwork av versjonen avhengig av Microsofts ufullkomne, men langt mer fleksible, API-sprawl.

For mye frukt vil gjøre det for deg.