A mitikus "Vista alkalmazás"

Case point: Windows Vista és az "app gap". Evans Data Corporation (EDC), a fejlesztők kevesebb, mint 10 százaléka ír a Microsoft jelenlegi állapotára. A többség (49 százalék) még mindig ír az XP-nek, míg egy kicsi, de növekvő, függő (13 százalék) a Linuxra összpontosít. Eközben a számtalan nagy média továbbra is megkérdőjelezi az új Vista alkalmazások hiányát. "Ez az operációs rendszer, amit senki nem akar" - mondják, és a fejlesztők "reagálnak ennek megfelelően". Természetesen tévednek. Újra. [További olvasmány: A legjobb Windows 10 trükkök, tippek és csípés]

Látod, nincs olyan, mint a Vista alkalmazás. Csakúgy, mintha nem lenne olyan, mint egy XP alkalmazás. Vagy Windows 2000 alkalmazás. A Windows -ra író fejlesztők ritkán célozzák meg egy adott verziót. Inkább egy adott API keretrendszert választanak - például MFC / ATL vagy.Net - és innen továbbhaladnak. Függetlenül attól, hogy a létrehozott alkalmazás egy adott Windows-verzióban fut-e vagy sem, attól függ, hogy a fejlesztő milyen verzióspecifikus API-bővítményekkel rendelkezik.

Az alkalmazástípusok többségénél ez nem eredeti: API-függvényeket, amelyek lehetővé teszik számukra, hogy a keretrendszereket támogató bármilyen Windows-verziót fussanak le. És mivel a Microsoft jó munkát végez az új keretrendszerek háttértámogatásával a korábbi OS platformokra, a fejlesztőknek ritkán kell szembenézniük a gazdag API-funkciók vagy a széleskörű telepített bázis (a figyelemre méltó kivételként a videojáték-fejlesztők számára, akik számára a DirectX 10 elkötelezett a Vista-ra).

Tehát a teljes Vista "app gap" argumentum egy kicsit szalma ember. Az igazi kérdés a következő: Miért nem használják a fejlesztők a.Net keret különböző iterációit? Mivel a Microsoft fejlesztési ütemterveit követõ bármely személy tanúsítja, a vállalat legfejlettebb API-evolválása a.Net-en belül zajlik. Valójában, amikor a "szakértők" a Vista - Windows Presentation Foundation (WPF), a Windows Communication Foundation (WCF) és így tovább - új programozási forrásokról beszélnek - valójában a.Net keretrendszer 3.0-ról beszélnek. Mivel a.Net 3.0 lefelé irányuló platformokon (például a Windows XP rendszerben) elérhető, az argumentum visszavág a fejlesztők által elfogadott.Net elfogadás kérdésére - és miért (eddig) megakadályozták.

a válasz kettős: Először is, a fejlesztők nem szeretnek olyan API-kat célozni, amelyek nem állnak rendelkezésre széles körben a telepített bázisban. Annak ellenére, hogy a Microsoft agresszív támogatja a lefelé irányuló verziókat, még mindig nagy a különbség a "rendelkezésre álló" és a "bonyolult könyvtárak 20 MB-pluszának letöltése után, amelyek telepítése a rendszer különböző részein". Az ügy ténye, hogy a Net nem szállít a Windows XP részeként, és ez azt jelenti, hogy a fejlesztőknek meg kell győzniük a felhasználókat, hogy először telepítsék a.Net keretrendszer szükséges verzióját, mielőtt telepítenék a szoftvereket - nem mindig könnyű eladni, különösen a vállalati informatika zárolt világában.

Az alapértelmezés szerint telepített.NET keretrendszerhez történő első operációs rendszerként a Vista-nak elő kell segítenie a.Net 3.0 alkalmazások fejlesztését. Mivel azonban támogatja a korábbi Win32, COM, ATL, MFC és down-level.Net keretrendszereket is, nincs veszteség a Vista programokban. Valójában, hacsak nem csak a legfrissebb és legnagyobb WPF / WCF keretfunkciókat kell megkapnunk, kevéssé motiválhatjuk Önt, a fejlesztőt, hogy a.Net 3.0-hoz vagy akár a 2.0-hoz ugorjon. Feltéve, hogy nem ugrik be a felhasználói fiókok felügyeletére (UAC), a "legacy" Windows alkalmazás valószínűleg úgy néz ki és működik jól, mint Vista. Tudom, mert ez volt a saját kódom esetében: Néhány csípés az UAC befogadására (többnyire ideiglenes fájlok áthelyezése az újonnan védett könyvtárak struktúráiról), alkalmazásom és szolgáltatásaim hasonlóan futottak a Vista alatt, mint ahogy azt a Windows XP, Server 2003 és Windows 2000. Miért kell ezt javítani, ha nem sérült meg?

A második ok miatt a fejlesztők elhagyták a.Net-et, hogy lassú. Sok közös funkció egyszerűen hosszabb időt vesz igénybe a.Net alatt, ami arra kényszeríti a fejlesztőket, hogy válasszanak az API kifinomultságától és a nyers teljesítménytől. Nem meglepő, hogy a legtöbb fejlesztő választja ki az utóbbit, ahogy azt egyszer megtettem, amikor rájöttem, hogy a Performance Data Helper (PDH).Net-egyenértéke mindenképpen felhasználhatatlan a Windows teljesítményszámlálójának valós idejű mintavételezéséhez. Ennek eredményeképpen kénytelen vagyok fenntartani egy öregedő (kb. 1997-es) Visual Studio 6 kódbázisot, miközben arra várakozik, hogy a Microsoft végül továbbfejlessze a.Net-et olyan pontig, ahol ez egy életképes alternatíva. Ez egy régi történet és túlságosan gyakori a Windows-fejlesztők körében.

Alsó sor: Amikor az elemzők (és a médiakomplexisták) a "Vista alkalmazások" hiányát kiabálják, csak trombitálják saját tudatlanságukat.

Azt hiszem, ez egy Mac dolog: Sok kortársaim el vannak ragadva a valóság torzítása terén, hogy az API funkcionalitás és az operációs verzió közötti kapcsolat ötlete a hagyományos bölcsesség elfogadott részévé vált. Ez egy becsületes hiba, amely megegyezik az Apple archaikus változatának függvényében a Microsoft tökéletlen, de sokkal rugalmasabb API terjeszkedésétől.

Túl sok gyümölcs lesz hozzád.