Mityczna "Aplikacja Vista"

Kocham analityków. Niezależnie od tego, czy przewiduje on jutrzejszą kolejną dużą rzecz, czy też brzmi to na śmierć dla wczorajszego pioniera branży, analitycy nigdy nie zabraknie nowych sposobów, aby to zepsuć.

Przykład: Windows Vista i "luka w aplikacjach". Według Evans Data Corporation (EDC) , mniej niż 10 procent programistów pisze o aktualnym stanie wiedzy Microsoftu. Większość (49 procent) nadal pisze o XP, podczas gdy mały, ale rosnący kontyngent (13 procent) koncentruje się na Linuksie. Tymczasem niezliczone główne media wciąż potępiają brak nowych aplikacji Vista. "To system operacyjny, którego nikt nie chce", mówią, a programiści "reagują odpowiednio".

Oczywiście, oni się mylą. Ponownie.

[Dalsze czytanie: Nasze najlepsze triki, porady i poprawki w Windows 10]

Widzisz, nie ma czegoś takiego jak aplikacja Vista. Tak jak nie ma czegoś takiego jak aplikacja XP. Lub aplikacja Windows 2000. Twórcy, którzy piszą dla Windows rzadko celują w konkretną wersję. Zamiast tego wybierają konkretny framework API - na przykład MFC / ATL lub.Net - i kontynuują od tego. To, czy powstała aplikacja działa w danej wersji systemu Windows, zależy od tego, jakie, jeśli w ogóle, rozszerzenia API specyficzne dla wersji, które deweloper zatrudnia w swoim projekcie.

W przypadku większości typów aplikacji jest to niepotrzebne: używają Funkcje API, które umożliwiają uruchamianie dowolnej wersji systemu Windows obsługującego tę strukturę. A ponieważ Microsoft wykonuje dobrą robotę, przywracając nowe struktury do starszych platform OS, programiści rzadko mają do wyboru bogatą funkcjonalność API lub szeroką bazę instalacyjną (wyróżniającym się wyjątkiem są twórcy gier wideo, dla których wykorzystanie DirectX 10 oznacza zobowiązanie do Vista).

Więc cały argument "luki aplikacji" Vista jest trochę słomianym człowiekiem. Prawdziwe pytanie powinno brzmieć: Dlaczego deweloperzy nie używają różnych iteracji frameworka.Net? Każdy, kto będzie śledził rozwój mapy drogowej Microsoftu, potwierdza, że ​​większość ewolucyjnego rozwoju API firmy odbywa się w.Net. W rzeczywistości, gdy "eksperci" mówią o nowych programowych zasobach w systemie Vista - Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) i tak dalej - tak naprawdę mówią o środowisku.Net Framework 3.0. A ponieważ.Net 3.0 jest dostępny na platformach niższego poziomu (takich jak Windows XP), argumenty wracają do pytania o akceptację.Net wśród programistów - i dlaczego (jak dotąd) unikali tego.

Odpowiedź jest dwojaka: Po pierwsze, deweloperzy nie lubią kierować interfejsów API, które nie są szeroko dostępne w zainstalowanej bazie. Pomimo agresywnej obsługi przez Microsoft wersji niższego poziomu, wciąż istnieje duża różnica między "dostępnymi" i "dostępnymi po pobraniu 20 MB-plus skomplikowanych bibliotek i zainstalowaniem ich w różnych częściach systemu." Faktem jest, że.Net nie jest wysyłany jako część systemu Windows XP, co oznacza, że ​​programiści muszą przekonać użytkowników, aby najpierw zainstalowali wymaganą wersję środowiska.Net, zanim będą mogli zainstalować oprogramowanie - nie zawsze łatwa do sprzedania, zwłaszcza w zamkniętym świecie IT dla przedsiębiorstw.

Jako pierwszy system operacyjny z domyślną instalacją.Net, Vista miała zachęcać do rozwoju aplikacji.Net 3.0. Jednak, ponieważ obsługuje on także starsze wersje Win32, COM, ATL, MFC i aplikacje warstwy.Net na niskim poziomie, nie ma rzeczywistego niedoboru programów Vista. W rzeczywistości, chyba że masz właśnie najnowszą i najlepszą funkcjonalność frameworka WPF / WCF, niewiele możesz zmotywować ciebie, programistę, aby przejść do.Net 3.0, a nawet 2.0. Zakładając, że nie masz wpływu na mechanizm Kontroli konta użytkownika (UAC), Twoja "starsza" aplikacja Windows prawdopodobnie wygląda i działa świetnie pod Vistą tak jak jest. Wiem, bo tak było z moim własnym kodem: kilka usprawnień, które pozwoliłyby dostosować UAC (głównie przeniesienie niektórych plików tymczasowych z nowo chronionych struktur katalogów) i moje aplikacje i usługi działały jak mistrzowie pod Vistą - tak jak robią to pod Windows XP, Server 2003 i Windows 2000. Po co go naprawiać, gdy nie jest zepsuty?

Drugim powodem, dla którego deweloperzy unikają.Net jest to, że jest powolny. Wiele typowych funkcji po prostu trwa dłużej w sieci.Net, co zmusza programistów do wyboru między zaawansowaniem API a surową wydajnością. Nic dziwnego, że większość programistów wybiera tę drugą, jak kiedyś musiałem zrobić, gdy odkryłem, że odpowiednik.Net dla Performance Data Helper (PDH) był prawie bezużyteczny do próbkowania w czasie rzeczywistym danych licznika wydajności Windows. W rezultacie jestem zmuszony do utrzymywania starzejącej się (około 1997) bazy kodu Visual Studio 6, czekając aż Microsoft ostatecznie usprawni.Net do punktu, w którym jest realną alternatywą. To stara historia i zdecydowanie zbyt popularna wśród programistów Windows.

Podsumowanie: Kiedy analitycy (i ich wspólnicy medialni) potępiają brak "aplikacji Vista", po prostu trąbią o swojej ignorancji.

Zgaduję, że to jest Sprawa Mac: Tak wielu moich rówieśników zostało złapanych w polu zniekształceń rzeczywistości, że idea powiązania między funkcjonalnością API a wersją OS stała się akceptowaną częścią konwencjonalnej mądrości. Jest to szczery błąd, który zrównuje archaiczną mozaikę Apple z zależnościami wersji z niedoskonałym, ale znacznie bardziej elastycznym interfejsem API Microsoftu.

Za dużo owoców zrobi to tobie.