The Mythical 'Vista Application'

Adoro gli analisti. Sia che si tratti di predire la prossima grande cosa di domani o di suonare la campana a morto per l'industria del lavoro di ieri, gli analisti non si imbattono mai in nuovi modi per sbagliare.

Caso in questione: Windows Vista e "app gap". Secondo Evans Data Corporation (EDC) , meno del 10% degli sviluppatori sta scrivendo per lo stato dell'arte attuale di Microsoft. La maggioranza (49 percento) sta ancora scrivendo per XP, mentre un piccolo, ma in crescita, contingente (il 13 percento) si sta concentrando su Linux. Nel frattempo, la miriade di importanti media ha continuato a criticare la mancanza di nuove applicazioni Vista. "È il sistema operativo che nessuno vuole", dicono, e gli sviluppatori stanno "reagendo di conseguenza".

Naturalmente, si sbagliano. Ancora.

[Letture più approfondite: i nostri migliori trucchi, suggerimenti e trucchi per Windows 10]

Vedete, non esiste un'applicazione Vista. Proprio come non esiste un'applicazione XP. O un'applicazione Windows 2000. Gli sviluppatori che scrivono per Windows raramente scelgono come target una versione specifica. Piuttosto, selezionano un particolare framework API - per esempio, MFC / ATL o.Net - e procedono da lì. Se l'applicazione risultante viene eseguita su una determinata versione di Windows dipende da eventuali estensioni API specifiche della versione che lo sviluppatore impiega nel loro progetto.

Per la maggior parte dei tipi di applicazione, questo non è un problema: usano il generico Funzioni API, che consente loro di eseguire qualsiasi versione di Windows che supporti tale framework. E poiché Microsoft fa un buon lavoro di back-porting di nuovi framework alle piattaforme legacy del sistema operativo, gli sviluppatori raramente si trovano di fronte a una ricca funzionalità API o un'ampia base installata (la notevole eccezione è costituita dagli sviluppatori di videogiochi, per i quali sfruttare DirectX 10 significa impegnarsi a Vista).

Quindi l'intero argomento "app gap" di Vista è un po 'un uomo di paglia. La vera domanda dovrebbe essere: perché gli sviluppatori non stanno facendo leva sulle varie iterazioni del framework.Net? Come attesta chiunque segua la roadmap di sviluppo di Microsoft, la maggior parte dell'evoluzione delle API all'avanguardia della società si sta verificando all'interno di.Net. Infatti, quando gli "esperti" parlano di nuove risorse programmatiche in Vista - Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) e così via - stanno davvero parlando di.Net framework 3.0. E dal momento che.Net 3.0 è disponibile su piattaforme di livello inferiore (come Windows XP), la discussione gira intorno a una domanda di accettazione.Net tra gli sviluppatori - e perché lo hanno (finora) ignorato.

The la risposta è duplice: in primo luogo, agli sviluppatori non piace indirizzare API che non sono ampiamente disponibili sulla base installata. Nonostante il supporto aggressivo di Microsoft delle versioni di livello inferiore, c'è ancora una grande differenza tra "disponibile" e "disponibile dopo aver scaricato 20 MB di più librerie complesse e averle installate in varie parti del sistema". Il fatto è che.Net non viene fornito come parte di Windows XP, e ciò significa che gli sviluppatori devono convincere gli utenti a installare prima la versione richiesta del framework.Net prima di poter installare un pezzo di software - non sempre una vendita facile, soprattutto nel mondo bloccato dell'impresa IT.

Come il primo sistema operativo fornito con il framework.Net installato di default, Vista avrebbe dovuto incoraggiare lo sviluppo di applicazioni.Net 3.0. Tuttavia, dal momento che supporta anche applicazioni legacy Win32, COM, ATL, MFC e.NET di livello inferiore, non c'è alcuna reale mancanza di programmi Vista. Infatti, a meno che tu non abbia appena avuto la più recente e migliore funzionalità di framework WPF / WCF, c'è poco da motivare te, lo sviluppatore, a fare il salto a.Net 3.0, o anche a 2.0. Supponendo che non si imbatti nel meccanismo del Controllo dell'account utente (UAC), l'applicazione Windows "legacy" probabilmente ha un aspetto e funziona perfettamente con Vista così com'è. Lo so, perché era il caso del mio stesso codice: alcuni aggiustamenti per adattarsi a UAC (principalmente spostando alcuni file temporanei da nuove strutture di directory di protezione) e le mie applicazioni e servizi erano in esecuzione come champs sotto Vista - proprio come fanno sotto Windows XP, Server 2003 e Windows 2000. Perché correggerlo quando non è rotto?

La seconda ragione per cui gli sviluppatori hanno evitato.Net è che è lento. Molte funzioni comuni richiedono semplicemente più tempo con.Net, costringendo gli sviluppatori a scegliere tra la sofisticazione dell'API e le prestazioni non elaborate. Non sorprende che la maggior parte degli sviluppatori scelga quest'ultima soluzione, come ero costretto a fare una volta quando ho scoperto che l'equivalente.Net di Performance Data Helper (PDH) era quasi inutilizzabile per il campionamento in tempo reale dei dati del contatore delle prestazioni di Windows. Di conseguenza, sono costretto a mantenere un code code di Visual Studio 6 obsoleto (circa nel 1997) in attesa che Microsoft possa finalmente ottimizzare.Net in un punto in cui è un'alternativa valida. È una vecchia storia e fin troppo comune tra gli sviluppatori di Windows.

Bottom Line: quando gli analisti (e i loro media complici) denunciano la mancanza di "applicazioni Vista" si limitano a trombare la loro ignoranza.

Immagino che sia un Mac cosa: molti dei miei contemporanei sono stati coinvolti nel campo della distorsione della realtà che l'idea di un collegamento tra la funzionalità dell'API e la versione del sistema operativo è diventata una parte accettata della saggezza convenzionale. È un errore onesto, che equivale al patchwork arcaico di Apple delle dipendenze delle versioni dell'imperfetto Microsoft, ma molto più flessibile, sprawl dell'API.

Troppo frutto lo farà a te.