System Android, jak powszechnie wiadomo, jest licencjonowany kategorią open source, więc istnieje możliwość w miarę łatwego umieszczenia go na urządzeniach mobilnych bez konieczności współpracy z Google. Wykorzystują to producenci różnego rodzaju mniej lub bardziej “nieoficjalnego” sprzętu, działającego pod kontrolą tego systemu. Mogą to być produkty, które trudno klasyfikować inaczej niż jako tanie imitacje, ale także sprzęt produkowany przez (u)znane firmy – jak choćby tablet stworzony przez Creative. Ich wspólną cechą jest domyślny brak wsparcia przez narzędzia wspomagające pisanie aplikacji dostępne w ramach SDK Androida – przede wszystkim Android Debug Bridge (adb), czyli usługę umożliwiającą między innymi debugowanie aplikacji bezpośrednio na urządzeniu. Dla zwykłego użytkownika to oczywiście żadna wada, ale co mają zrobić biedni programiści?…
Okazuje się jednak, że przeszkodę tę da się pokonać. Dzisiaj udała mi się ta sztuka ze wspomnianym tabletem Creative’a i dlatego czuję się upoważniony podzielić się swoim rozwiązaniem :) Wydaje się ono przy tym na tyle ogólne, że powinno stosować do dowolnego urządzenia.
Ze sporym opóźnieniem i nie bez kłopotów zrobiłem wreszcie, co planowałem uczynić od dawna: pozbyć się Visty z komputera stacjonarnego i zamiast tego sprokurować tam sobie Windows 7. A że przy okazji mogłem ów nowy system zainstalować w wersji 64-bitowej, postanowiłem tak właśnie uczynić. Jakie są rezultaty tego eksperymentu?… Niestety dość kiepskie.
Nie znaczy to na szczęście, że 64-bitowy system na 64-bitowym procesorze jest nieużywalny – no nie, tak źle to nie jest :) Wydaje mi się, że istnieje tylko niewielka szansa, że podwojenie liczby systemowych bitów zaowocuje problemami z uruchomieniem jakieś aplikacji, która wcześniej działała dobrze. Jak wiadomo jest tu emulacja trybu 32-bitowego, która sprawdza się bardzo dobrze.
Skąd to wiem? Ano stąd, że okazji do jej wykorzystania jest mnóstwo – i w zasadzie to właśnie jest problem. Wersji aplikacji dedykowanych do x64 nie jest znowu tak dużo, a jeśli już da się takie znaleźć, to często są one pod znacznie gorszą opieką developerską i można mieć uzasadnione wątpliwości co do ich stabilności. Przykładem jest chociażby Firefox, którego 64-bitowa wersja jest tylko na wpół oficjalna i dostępna jedynie w angielskiej wersji językowej. W sumie więc mój Menedżer zadań pokazuje zdecydowaną większość procesów z dopiskiem * 32
, zaś pozostałe to albo usługi systemowe, albo aplikacje zarządzane .NET lub Javy.
O ile jednak cudów po aplikacjach nie ma sensu się spodziewać (zwłaszcza tych przeznaczonych dla użytkowników domowych), o tyle 64-bitowe sterowniki do urządzeń byłyby bardzo wskazane. I tu może spotkać nas niemiła niespodzianka, gdyż ich także często brakuje. W moim przypadku z zadania wywiązała się jedynie NVidia, dostarczając sterowniki w wersji x64 zarówno do karty graficznej, jak i chipsetu płyty głównej. Ale już np. Microsoft nie uważał za stosowne zapewnienia drivera dla firmowanej przez siebie myszki Sidewinder X5, wykręcając się kompatybilnością jego 32-bitowej wersji, opracowanej z myślą o Viście.
To zresztą typowy scenariusz i można się tylko cieszyć, że te vistowe sterowniki działają bez problemów. Nie można tego natomiast powiedzieć o ewentualnym oprogramowaniu dodatkowym, dołączanym do różnych sprzętów. Jego zainstalowanie wymaga co najmniej kombinowania z trybem zgodności. oszukującym je co do rzeczywistej wersji systemu. W niektórych przypadkach (jak chociażby wspomnianego gryzonia) i to nie jest wystarczające, gdyż system blokuje instalację aplikacji, tłumacząc się – cytuję – “znanymi problemami ze zgodnością” ;P
Konkluzja jest więc taka, że 64 bity to wciąż żadne udogodnienie, a jedynie konieczność powodowana oczywiście chęcią wykorzystania większej ilości RAM-u niż ok. 3GB obsługiwane przez systemy 32-bitowe. Doświadczenie korzystania z systemu x64 przypomina używanie aplikacji w wersji Release Candidate: żadnych błędów nie znajdziemy i rzecz zasadniczo będzie działać, ale widoczne będą jakieś zgrzyty, o których wiadomo już, że zostaną naprawione dopiero patchami do wersji finalnej – jeżeli w ogóle. Wydaję mi się, że dopóki 4GB RAM-u nie będą standardem dla komputerów w cenowej strefie średnio-niskiej, wsparcie dla x64 ze strony producentów oprogramowania może być w dużym stopniu dobrowolne.
A kiedy coś takiego może stać?… Cóż, prawdopodobnie dopiero wraz z kolejną wersją Windows.
Wczorajsza premiera Windows 7 to dobry pretekst, żeby nowy system w końcu przetestować – zwłaszcza, że większość opinii, których o nim słyszałem, była zdecydowanie przychylna. W połączeniu z faktem, iż system operacyjny na moim laptopie już od dobrych paru miesięcy domaga się skrócenia swoich cierpień, otrzymujemy tylko jeden logiczny wniosek: czas zakasać rękawy i zabrać się za reinstalację!
Ktokolwiek choć raz zajmował się ponownym stawianiem systemu od zera wie, że czynność ta nie należy do relaksujących. Chociaż drobne komplikacje są praktycznie gwarantowane: a to zapomnimy o jakimś sterowniku, a to zapodziejemy gdzieś numer seryjny systemu, i tak dalej. Posiadanie komputera “zapasowego” (w moim przypadku tradycyjnego – stacjonarnego) znacznie redukuje dolegliwość takich problemów, ale nawet i w tej sytuacji warto się do całej operacji dobrze przygotować.
I właśnie dlatego sporządziłem poniższą listę kontrolną czynności, które dobrze jest wykonać przed rozpoczęciem zabawy w reinstalację systemu. Nie gwarantuję oczywiście, że da się przy jej użyciu uniknąć wszelkich kłopotów. Powinna być ona jednak w dużym stopniu pomocna. A wygląda ona następująco:
Pamiętaj też o wszelkich kluczach produktów czy numerach seryjnych, jeśli któryś z systemów ich wymaga.
Uff, spora ta lista. Jej rygorystyczne przestrzeganie może nie zawsze jest konieczne, ale nie wydaje mi się, żeby mogło komukolwiek zaszkodzić :) Akurat w przypadku tej nieczęsto (i coraz rzadziej) wykonywanej czynności, jaką jest reinstalacja systemu, zbytnia przezorność na pewno nie zawadzi.