Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Vista to nie Vista, 7-ka to nie 7-ka

I stało się... Dziś, po raz pierwszy od dłuższego czasu straciłem "programistyczną cierpliwość". Nie będę jednak wylewał tu swoich żalów - nie. Przecież nikomu nie jest to do szczęścia potrzebne. Ale każdą ludzką złość i frustrację można, przy odrobinie kombinatoryki, przedstawić w sposób nieco przyjemniejszy, z pożytkiem dla świata zawsze-młodych-duchem programistów.

Rzecz dotyczy wersji systemu Windows, jego komponentów, i takich tam...

Na potrzeby wykonywanego zawodu wybrałem system operacyjny Windows 7 Enterprise. Swego czasu z wielkim trudem przyszło mi powiedzieć "nie" tej części społeczności, która do dnia dzisiejszego wykorzystuje zasłużonego XP. Bynajmniej nie powiedziałem tego dosłownie. Po prostu projekty, nad którymi pracuję (ich przeważająca większość) z góry nie przewidują współpracy ze starszymi wersjami Windowsa. Z różnych względów... Przed 7-ką pojawiła się jednak Vista, znienawidzona przez niektórych, uwielbiana przez pozostałych. Przygotowywując oprogramowanie desktopowe programista nie może od tak sobie pominąć użytkowników tego systemu bez naprawdę dobrego powodu. Problemy pojawiają się z chwilą, w której programista wyraża chęć integracji programu z wybranym, wbudowanym komponentem systemu.

Mały przykład

Komponent ABC znajduje się w wersji systemu 7. Komponent ABC znajduje się także w wersji systemu Vista. Jednakże funkcjonalność Komponentu ABC różni się pomiędzy systemami, oferując tylko i wyłącznie pewną wspólną bazę. Jeżeli takich komponentów mamy wiele - mamy problem. Niektóre, naprawdę dobre pomysły kończą swój żywot. Oprogramowanie musi przecież być spójne w ramach danej rodziny systemów spod znaku Microsoftu. Ale co w przypadku znacznie mniejszych różnic, pojedynczych funkcji? Można przecież napisać dwie (niedługo także i trzy: Windows 8) wersje kodu, jedną dla Visty, drugą dla 7-ki. Z tym, że wersji systemu mamy więcej, znacznie więcej. Bowiem Komponentu ABC nie ma w wersjach Vista/7 Starter, a wersje Vista/7 Home Basic mają jeszcze bardziej ograniczoną funkcjonalność. O ServicePack'ach nie wspomnę.

Patrząc na problem ze szczytu tej programistycznej piramidy (tj. oczami użytkownika edycji Enterprise) łatwo stracić cierpliwość. Tym bardziej kiedy autorzy dostępnych w sieci rozmaitych kodów źródłowych błędnie przyjmują, że Windows Vista to Windows Vista, a Windows 7 to Windows 7 i nie kwapią się sprawdzić "ile rzeczywiście jest cukru w cukrze".

Widziałem już wiele "sposobów" sprawdzania wersji systemu pod kątem współpracy z wybranymi komponentami Windowsa, ale każdy miał swoje wady, większość działała połowicznie. Droga koleżanko i drogi kolego, jeżeli Twoje oprogramowanie wykorzystuje specyficzne dla danej edycji funkcje systemowe to Twoim obowiązkiem jest wiedzieć z jakim konkretnie systemem masz do czynienia - co do najmniejszych różnic!

Jeśli jesteś entuzjastą technologii .NET, możesz poddać poniższy kod drobnej modyfikacji i pozbędziesz się problemu... ekhm... "raz na zawsze" :) Użytkownicy Javy oraz innych języków będą musieli poszukać odpowiedniej implementacji WMI (Windows Management Instrumentation) dla swojej platformy programistycznej. A takie z całą pewnością są dostępne, więc głowa do góry.

private void OperatingSystemInfo() { // Vista i wyżej - OSVersion nie określa zawartości cukru w cukrze if (System.Environment.OSVersion.Version.Major >= 6) { System.Management.ManagementObjectSearcher mos = new System.Management.ManagementObjectSearcher("SELECT * FROM Win32_OperatingSystem"); System.Management.ManagementObjectCollection moc = mos.Get(); foreach (System.Management.ManagementObject mo in moc) { foreach (System.Management.PropertyData property in mo.Properties) { Console.WriteLine("{0} {1}", property.Name, property.Value); } } } }

Zwróć uwagę na pole OperatingSystemSKU, które definiuje aktualnie zainstalowaną odmianę systemu operacyjnego. Wszystkie właściwości oraz ich dokładny opis przedstawia MSDN:msdn.microsoft.com/en-us/library/windows/desktop/aa394239(v=vs.85).asp...

Jeżeli interesuje nas wyłącznie edycja Starter prościej jest wywołać funkcję systemową GetSystemMetrics, której zastosowanie nie ogranicza się wyłącznie do poniższej czynności. Więcej na MSDN:msdn.microsoft.com/en-us/library/windows/desktop/ms724385(v=vs.85).asp...

using System.Runtime.InteropServices; [DllImport("user32.dll")] private static extern int GetSystemMetrics(int smIndex); private static int SM_STARTER = 88; private bool IsStarter() { return GetSystemMetrics(SM_STARTER) != 0; }

Powodzenia! 

windows porady programowanie

Komentarze

0 nowych
command-dos   18 #1 06.03.2012 14:22

Wiesz jak pominąć problem kompatybilności? Napisz aplikację webową, wtedy otworzysz ją nawet spod linuksa...

alucosoftware   7 #2 06.03.2012 14:30

@command-dos
Problem dotyczy wykorzystania komponentów systemu Windows w aplikacjach desktopowych

slepciu   11 #3 06.03.2012 18:33

@command-dos
Z webowymi tez tak lekko nie ma, co przeglądarka to inne standardy. Ostatecznie staje się przed całkiem podobnym problemem.

Draqun   9 #4 06.03.2012 18:54

@slepciu

Dokładnie!. Ostatnio pisałem stronę, na której miałem umieścić muzykę. Jako, że o html5 głośno się krzyczy postanowiłem wykorzystać go. Efekt był różny w zależności od przeglądarki. Na jednej działało ok, na drugie było widać "odtwarzacz" a na trzeciej w ogóle nie było dźwięku. Postanowiłem więc sięgnąć po starsze rozwiązania. I tutaj skutek był ten sam. Ostatecznie ograniczyłem się do jednej przeglądarki a resztę miałem w głębokim poważaniu.

@Alucosoftware
Niestety takie życie ;). Obyś więcej nie musiał kombinować i obym ja w przyszłości też nie musiał.

alucosoftware   7 #5 06.03.2012 19:09

@slepciu
Hmm... a czy przypadkiem to producenci przeglądarek nie respektują(-owali) standardów? Projektanci serwisów i aplikacji webowych (tych licznie wykorzystywanych) często na to jawnie pozwalają - nie zgłaszając stanowczych obiekcji.

command-dos   18 #6 06.03.2012 19:15

imho, kompatybilność pomiędzy przeglądarkami bywa większa od kompatybilności pomiędzy 2 produktami małomiękkiego...

alucosoftware   7 #7 06.03.2012 20:03

@command-dos
I tu się ideowo zgadzam, lecz zamiast słowa kompatybilność użyłbym innego. Dotyczy to pewnie nie tylko Microsoftu, ale nas wszystkich... Często implementujemy jakieś rozwiązania w oprogramowaniu tylko po to, aby w przyszłości je porzucić na korzyść innych, lepszych (bądź zostawiamy je w spokoju i przylepiamy etykietę "legacy support"...).

Jeszcze nie miałem okazji spojrzeć na najnowsze dzieło giganta z Redmond. Ciekawe jak pod tym względem różni się od 7-ki?

sgj   11 #8 06.03.2012 20:51

"Jeśli jesteś entuzjastą technologii .NET"

WMI jest za wolne zeby go uzywać do identyfikacji systemu np podczas uruchamiania systemu.
Już lepiej użyć GetProductInfo z kernel32.dll.

sgj   11 #9 06.03.2012 20:52

Poprawka do tego wyżej. Uruchamiania programu, nie systemu.

alucosoftware   7 #10 06.03.2012 21:50

@sgj
W tym konkretnym przypadku nie mogę się zgodzić, że WMI jest za wolne. Na starym Intel Atomie wywołanie i dostęp do wszystkich pól w/w klasy zajmuje średnio 170 ms przy użyciu WMI, wobec 1 ms dla GetProductInfo. Czy jednak za każdym razem podczas uruchamiania oprogramowania będziesz sprawdzał edycję?

Z drugiej strony programista może potrzebować większej ilości informacji dotyczących zainstalowanego systemu. WMI wprowadza jeden, schludny, spójny i prosty interfejs umożliwiający dostęp do większości potrzebnych nam danych. Owszem, można niektóre operacje wykonać szybciej, ale biorąc pod uwagę prostotę SQL-podobnych zapytań wobec konieczności nieustannego wywoływania zewnętrznych funkcji z kodu zarządzanego, z których każda zawiera tylko element układanki - wybieram WMI, bo zależy mi na jakości.

Jeśli ktoś przeczytał powyższy wpis, to jest duża szansa, że zwróci uwagę na WMI i jego zalety - niekoniecznie jak w temacie - więc "wartość dodana" jest :)

GetProductInfo ma wysokie wymagania dotyczące wersji systemu. Co ze staruszkami? Niemniej, dziękuję za komentarz :)

sgj   11 #11 06.03.2012 22:54

"GetProductInfo ma wysokie wymagania dotyczące wersji systemu. Co ze staruszkami? "

Na staruszkach jest jeszcze szereg innych opcji. Osobiście mam do tego napisaną specjalną klasę. Z WMI jest ten problem że nie zawsze jest dostępne. Natywne funkcje bibliotek działają zawsze.

Nie twierdzę, że WMI jest złe. Sam często używam, jednak nie zawsze jest to najlepszy wybór.

  #12 07.03.2012 08:17

Ciekawe o jakie funkcje chodzi albo o jakie oprogramowanie. Kiedyś pracowałem w firmie i pisaliśmy oprogramowanie dość duże które działało od win98 po XP. Może na Viście i 7 też by działało ale nie mogę tego sprawdzić bo już tam nie pracuję.

alucosoftware   7 #13 08.03.2012 12:02

@bitx
Jest wiele takich komponentów. Może najbardziej "widocznym" dla zwykłego użytkownika przykładem jest Desktop Window Manager.

  #14 12.03.2012 09:17

Wpis ciekawy, ma tylko uwagę odnośnie Java. Jeżeli ktoś pisze w Javie to nie powinien używać natywntych bibliotek itp. Istotą Javy jest to, że ma być przenośna, a pisanie w Javie tylko pod Windowsa jest bez sensu. Lepiej użyć do tego .Net
Pozdrawiam.

alucosoftware   7 #15 12.03.2012 13:08

@koneton
Hmm... nie jestem przedstawicielem Javy, ale rynek przemawia sam za siebie. Drugą sprawą wartą poruszenia jest fakt, że większość "przenośnych" komponentów ogranicza się tylko do pojęcia "jednego, wspólnego i zewnętrznego interfejsu nad różnymi wewnętrznymi implementacjami adekwatnymi dla danej platformy". Środowisko uruchomieniowe Javy też jakoś musi rysować na ekranie...

Dziękuję za komentarz i pozdrawiam :)