O czym pamiętać przy przejściu z x86 na x64

Zawartość strony

	Odrobina historii
	Życie w x64
	Dlaczego 64-bitowy?
	Wirtualizacja
	x64 Windows w firmie Pluck
	Wdrożenie i migracja x64
	Wnioski

Windows XP jest dostępny dla architektur 64-bitowych od ponad pięciu lat. Jednak czytelnicy, którzy nie uczestniczyli we wczesnej fazie wdrażania procesorów Intel Itanium (wersja Windows XP dla Itanium została opublikowana tego samego dnia, co Windows XP), prawdopodobnie usłyszeli o tym później wraz z udostępnieniem wersji Windows XP oraz Windows Server 2003 dla systemów x64. x64 (określana również w branży jako x86-64) to ogólna nazwa architektur AMD64 firmy AMD oraz EM64T firmy Intel. I jeśli w ciągu ostatniego roku kupiliśmy nowy komputer PC, istnieją duże szanse, że posiada on procesor oparty o architekturę 64-bitową, nawet jeśli aktualnie funkcjonuje jak procesor 32-bitowy (co jest wysoce prawdopodobne).

Autor tego artykułu pracuje obecnie dla niewielkiej początkującej firmy w Austin w Teksasie. Ze względu na wymagania jednego z produktów firma chciała wykorzystać bardzo specyficzne zalety architektury x64. Podążając śladami zespołu Microsoft® Ex­change 2007, który podjął rozstrzygającą decyzję i zaczął dostarczać wsparcie wyłącznie dla architektur x64. Podobnie zespół ds. rozwoju i testów zarządzany przez autora używa jedynie wersji x64 systemu Windows® XP oraz Windows Server® 2003 na stacjach roboczych, laptopach, serwerach fazy rozwoju oraz serwerach produkcyjnych. Co więcej autor używa wersji Windows XP Professional x64 na swoim prywatnym laptopie, aby móc testować i debugować produkt.

Co ciekawe, pierwszą reakcją większości osób na wzmiankę o stosowaniu 64-bitowej wersji Windows, w szczególności w systemie mobilnym, jest dość zdezorientowany wyraz twarzy. Gdy zaś osoby te są zaznajomione z tematyką architektur 64-bitowych, wyrażają coś w rodzaju niedowierzania, przechodzącego w zdegustowanie i zdumienie — ze względu na powszechne przeświadczenie, że trudno jest znaleźć sterowniki urządzeń dla systemów 64-bitowych. W niniejszym artykule autor wyjaśni, w jaki sposób i dlaczego używa systemów Windows XP oraz Windows Server 2003 x64 w trybie 64-bitowym oraz opisze pewne zalety (oraz trudności) wdrożenia, których można się spodziewać. Ponadto omówione zostaną pewne aspekty wsparcia, migracji oraz rozwoju systemu Windows Vista™ x64.

Odrobina historii

Jak już wspomnieliśmy, wsparcie 64-bitowe w systemie Windows w rzeczywistości rozpoczęło się od wsparcia dla procesora Intel Itanium (chociaż dostępny był także system Windows dla 64-bitowego procesora Alpha, system Windows nie był tak naprawdę 64-bitowy, gdy działał z wykorzystaniem procesora Alpha). W systemach Windows XP oraz Windows Vista nie istnieje wsparcie dla procesora Itanium, a zatem architektura x64 jest jedyną aktualnie wspieraną architekturą 64-bitowych, klienckich wersji systemu Windows. Ponadto wybór dostępnych edycji Windows Server 2003 dla procesorów x64 jest znacznie szerszy niż dla procesorów Itanium (które zostały zasadniczo ograniczone do obciążeń roboczych w najnowocześniejszych centrach danych). Jest to trend, który zdaniem autora będzie kontynuowany po opublikowaniu wersji Windows Server 2008 o nazwie kodowej "Longhorn".

Wsparcie dla systemu Windows na platformie x64 stało się dostępne, gdy opublikowany został Windows Server 2003 Service Pack 1 (SP1). Choć może wydawać się to nieco dezorientujące, również wtedy dostępna stała się wersja x64 dla Win­dows XP, co oznacza, że 32-bitowe oraz 64-bitowe produkty Windows XP wywodzą się z różnych drzew kodu źródłowego systemu Windows. Podczas gdy dla 32-bitowych produktów dostępny jest już drugi pakiet Service Pack, dla 64-bitowej wersji systemu Win­dows XP, z technicznego punktu widzenia, nie wydano żadnego pakietu Service Pack (o ile nie liczymy pakietu SP1 dla Windows Server 2003 już wbudowanego w tę edycję).

Wymagania dla 64-bitowych systemów Windows - Win­dows XP, Windows Server 2003, Win­dows Vista lub Windows Server 2008 – są praktycznie takie same. Oczywiście najpierw musimy posiadać procesor 64-bitowy. W przypadku procesorów AMD oznacza to, że interesują nas systemy jedno, dwu lub czterordzeniowe systemy kompatybilne z architekturą AMD64 (patrz amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html). W przypadku procesorów Intel oznacza to, że interesują nas jedno, dwu lub czterordzeniowe systemy deklarujące wsparcie dla EM64T lub architektury Intel 64 (patrz intel.com/technology/intel64). Jednak diabeł jest pogrzebany w szczegółach. System Intel Core Duo na przykład nie posiada wsparcia dla architektury 64-bitowej, natomiast system Intel Core 2 Duo system posiada takie wsparcie, przy czy oba procesory wykorzystane zostały jako podstawa produktu o marketingowej nazwie Centrino Duo (jak w przypadku laptopa autora).

Do początku strony

Życie w x64

Po określeniu, czy nasz system wspiera 64-bitową wersję systemu Windows, musimy jeszcze poradzić sobie ze wsparciem urządzeń. Niestety, pomimo iż firma Microsoft zachęca dostawców i producentów (od przynajmniej dwóch lat w ramach konferencji WinHEC) do tworzenia i certyfikowania 64-bitowych sterowników dla swoich urządzeń i systemów, największym wyzwaniem, jakie napotkamy podczas korzystania z systemu Windows x64, będzie poszukiwanie sterowników dla sprzętu oraz oprogramowania. Z doświadczeń autora wynika, że największe sukcesy odnosimy, gdy uruchamiamy system x64 na serwerze, gdzie konieczność wsparcia dla egzotycznych urządzeń jest ograniczona, a korzyści z zastosowania architektury x64 są najbardziej oczywiste.

Najtrudniej jest znaleźć sterowniki dla systemów typu desktop oraz systemów mobilnych. Zasadniczo, możemy liczyć na większe szczęście w przypadku znanego producenta lub systemu zbudowanego z komponentów klasy korporacyjnej (gdzie prawdopodobieństwo zastosowania biznesowego skłania dostawców i producentów do tworzenia i certyfikowania sterowników dedykowanych systemom x64).

W przypadku systemu Windows Vista sytuacja ta na szczęście znacznie się poprawia. W rzeczywistości x86 nie jest już preferowaną architekturą, a x64 ignorowaną architekturą z ograniczoną dostępnością sterowników dla dużej części sprzętu, jest wręcz odwrotnie. W systemie Windows Vista dostawcy urządzeń muszą dostarczać x64 sterowniki do testów kompatybilności. W rzeczywistości sterowniki x86 nie muszą być dostarczane, choć niewątpliwie mogą. Ogólnie oznacza to, że niektóre urządzenia, w szczególności te wykorzystujące nowe możliwości systemu Windows Vista, mogą posiadać jedynie wsparcie dla architektury x64 Windows, bez wsparcia dla x86.

W rzeczywistości sterowniki to jedynie jeden z problemów, jakie napotkamy, usiłując uruchomić 64-bitową wersję Windows. Większym problemem jest samo rozpoczęcie pracy na tej platformie (lub migracja do niej), ale tym tematem zajmiemy się później.

Do początku strony

Dlaczego 64-bitowy?

Oczywiście firmy AMD, Intel oraz Microsoft nie zdecydowały się na architekturę 64-bitową tylko dla zabawy. Przejście na architekturę 64-bitową oferuje szereg kluczowych korzyści. Jak widzimy na Rysunku 1, najważniejszą z zalet architektury x64 jest możliwość adresowania znacznie większego zakresu pamięci, czyli aż do 16 terabajtów (TB) kontra 4GB, które może adresować 32-bitowy system Windows. Przy czym choć 64-bitowe wskaźniki mogą adresować do 16TB, aplikacje mają dostęp jedynie do około 8TB.

Rysunek 1: Limity przestrzeni adresowej pamięci.

Ponadto wersje x64 systemu Win­dows oferują sprzętowy mechanizm zabezpieczeń Data Execution Prevention (DEP), dostępny również w systemach x86 z wsparciem dla technologii NX (No Execute). Dzięki temu system Windows może wykorzystywać wspomagane sprzętowo rozwiązanie do zapobiegania przepełnieniu bufora. Zapobiega to wykonywaniu kodu ze stron danych w pamięci (więcej informacji na ten temat zawiera artykuł support.microsoft.com/kb/875352).

Wersje x64 systemu Windows umożliwiają wewnętrzne wspieranie wielu procesorów lub procesorów wielordzeniowych, podobnie jak w wersji x86 systemu Windows. A problem z kompleksowym adresowaniem potrzeb różnych wersji systemu Windows XP został wyeliminowany poprzez zastosowanie pojedynczej warstwy abstrakcji sprzętu (HAL) na wszystkich instalacjach Windows x64. Koniec męczenia się w celu zidentyfikowania wykorzystywanej warstwy HAL w systemach niezgodnych z interfejsem ACPI lub jednoprocesorowych.

Zasadniczo Windows x64 jako architektura umożliwia nam wykorzystywanie istniejącej infrastruktury zarządzania oraz istniejącego oprogramowania 32-bitowego (poprzez emulację), a także 64-bitowego programowania z możliwością uzyskiwania dostępu do znacznie wzbogaconej pamięci. W rzeczywistości jedynymi niepożądanymi efektami ubocznymi przeniesienia się na platformę Windows x64 są: całkowity brak wsparcia dla aplikacji 16-bitowych (w tym także takich pułapek jak 32-bitowe aplikacje z 16-bitowymi instalatorami), problemy z aplikacjami, które nie działają stabilnie, gdy włączony jest sprzętowy mechanizm DEP (choć mechanizm DEP może być wyłączany niezależnie dla każdego procesu, a zespół Windows Application Compatibility wspiera pewne aplikacje, które nie działają odpowiednio przy włączonym DEP) i wreszcie fakt, iż w 64-bitowym systemie Windows Vista, wszystkie sterowniki muszą zostać podpisane cyfrowo.

Ten ostatni element został dodany po to, aby zapobiegać majstrowaniu w pamięci przy użycia jądra Windows, techniki często wykorzystywanej przez programy typu rootkit. Oczekuje się, że ponieważ firma Microsoft zachęca dostawców, aby rozwijali sterowniki najpierw dla architektury x64 (w celu przeprowadzenia na nich testów zgodności sprzętu z systemem Windows), wymaganie to nie jest już tak przerażające, jak mogło jawić się w przeszłości.

Istnieje kilka innych godnych uwagi kwestii, które dotyczą wersji Windows dla systemów x64. Nie istnieje wersja Windows XP dla systemów x64, która zawierałaby funkcjonalność edycji Windows Media® Center Edition lub Windows Tablet PC Edition. Jednak zmienia się to w systemie Windows Vista, w którym wersje x64 mają taką samą funkcjonalność jak wersje x86.

Do początku strony

Wirtualizacja

Jedną z kwestii, które nie zostały jeszcze poruszone, jest wirtualizacja. I nie chodzi tu o produkty do wirtualizacji Microsoft Virtual PC lub VMWare PC, mowa o wirtualizacji systemu operacyjnego dla 32-bitowych plików wykonywalnych. W wersjach 32-bitowych systemu Windows wszystkie 16-bitowe aplikacje są uruchamiane w kontekście NTVDM (Virtual MS-DOS® Machine). Jak wspominano już wcześniej, nie istnieje wsparcie dla aplikacji 16-bitowych w 64-bitowych wersjach systemu Windows. Zamiast tego, choć większość zintegrowanych składników systemu Windows jest uruchamiana jako 64-bitowe binaria, pewne składniki i programy zewnętrzne mogą działać jak aplikacje 32-bitowe.

System Windows oferuje całkiem nową warstwę emulacji o nazwie Windows On Windows (WOW), która oferuje dedykowany 32-bitowym aplikacjom widok systemu operacyjnego, a w efekcie umożliwia uruchamianie aplikacji w emulowanej 32-bitowej wersji systemu Windows. W podsystemie WOW aplikacje x86 widzą Program Files (X86) jako po prostu Program Files. Podobnie %WIN­DIR%\SysWOW64 jawi się dla aplikacji x86 jako %WINDIR%\System32. Aplikacje x86 widzą klucz rejestru HKLM\SOFT­WARE\Wow6432Node tak, jakby widziały sam węzeł HKLM\SOFT­WARE.

Wykorzystując narzędzie Process Explorer, możemy poznać inną perspektywę wirtualizacji. Ponieważ wiele 32-bitowych aplikacji oczekuje interakcji z zintegrowanymi plikami binarnymi 32-bitowych systemów Windows, wiele z tych plików jest dostarczanych zarówno w wersji 64- jak i 32-bitowej. Możemy łatwo to zobaczyć, dodając dodatkową kolumnę do narzędzia Process Explorer. Na Rysunku 2 zobaczymy dwa wystąpienia cmd.exe, jedno w wersji 32-bitowej,a drugie w wersji 64-bitowej. W zaznaczonym 32-bitowym wystąpieniu widzimy kilka bibliotek DLL o nazwach wow64* załadowanych w procesie 32-bitowym. To ilustruje zastosowanie wirtualizacji, która pozwala 32-bitowym aplikacjom funkcjonować w 64-bitwowym systemie Windows. Warto także zwrócić uwagę na katalog roboczy (Path) wykorzystywany przez 64- oraz 32-bitowe wersje cmd.exe.

Rysunek 2: Narzędzie Process Explorer wykrywa 32-bitowe oraz 64-bitowe wersje cmd.exe.

Na zakończenie jeszcze jedna uwaga na temat wirtualizacji. System Win­dows uruchamia program explorer.exe jako aplikację 64-bitową, co pociąga za sobą pewne wady i zalety. Największą wadą jest to, że każde rozszerzenie powłoki Eksploratora musi zostać przekompilowane dla architektury x64, aby mogło zacząć działać (większość producentów niestety jeszcze nie udostępnia takiej wersji).

Natomiast w przypadku programu Internet Ex­plorer® jest odwrotnie, domyślnie działa on w wersji 32-bitowej. Głównym powodem takiego rozwiązania jest wymaganie, aby większość formantów ActiveX® wykorzystywanych obecnie w Internecie mogła z powodzeniem działać bez konieczności dokonywania zmian. Jest tak, ponieważ 64-bitowe aplikacje nie mogą ładować 32-bitowych bibliotek DLL lub sterowników w ramach procesu. Praktycznie nie byłoby możliwości otwierania 32-bitowych formantów ActiveX, które stanowią znakomita większość dostępnych obecnie formantów ActiveX, w ramach procesu 64-bitowej przeglądarki. A to z kolei oznaczałoby, że spora część zawartości sieci Internet stałaby się niedostępna. Aby zobaczyć to w praktyce, spróbujmy otworzyć program C:\Program Files\Internet Explorer\iexplore.exe w 64-bitowym systemie Windows i odwiedzić dowolną witrynę, która ładuje zawartość formantu ActiveX (choćby Win­dows Update), efektem będzie mniejsza bądź większa porażka. Witryna Windows Up­date (patrz Rysunek 3) została zmodyfikowana tak, aby uruchamiać w takie sytuacji 32-bitową wersję przeglądarki Internet Explorer. W przyszłości z pewnością zawartość formantu ActiveX zostanie zmodyfikowana tak, aby wykorzystywać przeglądarkę 64-bit Internet Explorer. Ale ponieważ większość dostępnych obecnie systemów Windows działa w architekturze 32-bitowej, konieczność uaktualnienia zawartości formantu ActiveX nie jest krytyczna. I prawdopodobnie przez pewien czas tak już pozostanie.

Rysunek 3: Niepowodzenie ładowania 32-bitowego formantu ActiveX w 64-bitowej przeglądarce Internet Explorer.

Do początku strony

x64 Windows w firmie Pluck

Na początku tego artykułu jego autor wspomniał, że firma Pluck rozpoczęła przechodzenie na system x64 Windows. Proces ten objął trzy różne wersje systemu Windows: Windows XP Professional x64 Edition, Windows Server 2003 Enter­prise Edition x64 oraz Windows Vista x64.

Firma Pluck jest na tyle małą organizacją, że gdy rozpoczęła rozwijanie najnowszego produktu, mogła zacząć migrację do systemu Windows dla architektury x64 po to, aby wykorzystać jej zalety. To oznaczało, że cały nowy sprzęt, który został zakupiony, oferował wsparcie dla architektury x64. W gruncie rzeczy to właśnie funkcja rozszerzonej pamięci w architekturze x64 w połączeniu z wirtualizacją umożliwiła stworzenie produktu o takim działaniu. Wszystkie fizyczne serwery są uruchomione jako 64-bitowe serwery wirtualne na 64-bitowym serwerze hosta. Każdy serwer hosta ma 16GB pamięci RAM rozdzielonych między rozmieszczone na nim serwery wirtualne (generalnie po 2GB dla każdej maszyny wirtualnej fazy rozwoju oraz 3GB dla każdej produkcyjnej maszyny wirtualnej).

Użycie systemów Tier 1 oraz zwirtualizowanych serwerów pozwoliło osiągnąć prawie 100 procentowe wsparcie dla sprzętu. Na przykład laptop autora posiada trzy urządzenia, dla których sterowniki x64 nie są dostępne. Wszystkie one okazują się być urządzeniami pomocniczymi, które nie są kluczowe i system dobrze sobie bez nich radzi. Co ciekawe, instalacja Windows Vista RC1 x64 oferowała dokładnie takie samo wsparcie dla tych urządzeń, chociaż autor spodziewa się prędkiego dostarczenia brakujących sterowników, gdyż system nosi logo Windows Vista Capable. Ponieważ zastosowanie systemów zostało zasadniczo ograniczone do Microsoft Of­fice, Visual Studio® oraz kilku dodatkowych narzędzi wykorzystywanych w procesie programowania i budowania, firma Pluck nie posiada wielu starszych aplikacji, które mogłyby powodować problemy ze zgodnością w procesie migracji. Chociaż część organizacji wykorzystuje 32-bitowe wersje systemu Windows, rozpoczęła ona migrację do architektury 64-bitowej z wykorzystaniem nowego sprzętu i proces ten odbywa się dość bezboleśnie.

Do początku strony

Wdrożenie i migracja x64

Istnieje kilka kwestii dotyczących wdrożenia, które należy wziąć pod uwagę. Firma Microsoft dostarcza wersję środowiska Windows Pre-installation Environment (Windows PE) specjalnie dla architektury x64. Jednak ponieważ istnieje emulacja x86 na systemach x64, możemy również wykorzystać x86 Windows PE do wdrażania, w szczególności gdy wykorzystujemy obrazy systemu. Jeśli wdrażamy Windows XP przy użyciu nienadzorowanej instalacji, środowisko Windows PE będzie musiało być specyficzne dla architektury, gdyż program winnt32.exe musi działać w tej samej architekturze, jaką instaluje. Ponieważ środowisko Windows PE nie posiada 32-bitowej warstwy zgodności, a winnt32.exe w architekturze x64 stanowi aplikację 64-bitową, 32-bitowy system Windows wymaga 32-bitowego środowiska Windows PE. To samo odnosi się do 64-bitowych wersji systemu Windows, które wymagają 64-bitowego środowiska Windows PE.

Usługi Remote Installation Services (RIS) różnią się pod tym względem i z tego względu firma Pluck wykorzystuje usługi RIS. Usługi RIS, począwszy od wersji Windows Server 2003 SP1, mogą instalować zarówno architektury x64 systemu Windows, jak i x86 lub Itanium. Gdy system x64 łączy się z serwerem RIS, serwer (w konfiguracji domyślnej) zaoferuje maszynom x86 oraz x64 obrazy RISetup lub RIPrep. Usługi RIS mogą również zostać skonfigurowane tak, aby oferować klientom x64 wyłącznie obrazy x86 lub wyłącznie obrazy x64. Opcja ta jest ustawiona jako domyślna, w celu zapewnienia optymalnej wydajności w przypadku użycia sprzętu x64.

Jak widać, nie wspomnieliśmy jeszcze o aktualizacji. Jest ku temu dobry powód. Niestety akt aktualizacji całego systemu operacyjnego z architektury x86 do architektury x64 stanowi ogromne przedsięwzięcie. Z tego powodu oraz ze względu na ograniczone zastosowanie edycji Windows XP Pro x64 Edition, niestety nie możemy dokonać aktualizacji do wersji Windows XP x64 z jakiejkolwiek wersji x86, ani aktualizować jakiejkolwiek wersji Windows XP (x86 lub x64) do Windows Vista x64. Windows Vista w systemach x64 jest, podobnie jak wcześniej Windows XP Pro x64 Edition, produktem przeznaczonym tylko do bezpośredniej instalacji. Z tego względu wiele organizacji zastanawia się nad migracją do systemu x64 tylko wtedy, gdy przeprowadzana jest kompleksowa wymiana sprzętu - podobną strategię wiele organizacji przyjmie prawdopodobnie w odniesieniu do samego systemu Windows Vista (czyniąc podwójny krok w tym samym czasie potencjalnie najlogiczniejszym wyborem).

Ale to nie oznacza, że osoby lub organizacje przechodzące z wersji x86 Windows do x64 Windows nie posiadają żadnych gotowych do użytku narzędzi, niewątpliwie są one dostępne. Obie wersje User State Migration Tool (USMT) dla systemu Windows XP oraz dla systemu Windows Vista zostały rozszerzone tak, aby wspierać migrację z jednej instalacji systemu Windows do innej (w przeciwieństwie do aktualizacji systemu operacyjnego "w miejscu"). Obecnie większość organizacji wykorzystuje metodę "formatowania i instalowania od zera", nawet na tym samym komputerze PC, a zatem wykorzystanie tego samego mechanizmu do przejścia do systemu Windows w całkiem nowej architekturze nie powinno być bardziej kłopotliwe niż dawniej.

Do początku strony

Wnioski

Zapewne stopniowa migracja do architektury x64 w małej organizacji, jaką jest firma Pluck, jest znacznie łatwiejsza niż rozległy proces migracji, który czeka większe organizacje. Jednak każdy specjalista IT musi zacząć zastanawiać się nad ostatecznym przejściem na architekturę x64. Rzeczywistość jest taka, że choć architektura x86 oraz wersje x86 systemu Windows będą nadal obecne na rynku przez co najmniej dziesięć lat, architektura x64 z pewnością stanowi przyszłość informatyki korporacyjnej. Ponieważ firma Microsoft już dziś w pełni wykorzystuje możliwości architektury x64 w serwerze Exchange 2007 oraz innych produktach, powinniśmy zacząć zdawać sobie sprawę, jak będą one pasować do naszej architektury. Musimy też zastanowić się jak dostosować je do planu migracji do systemu Windows Vista - niezależnie od tego, czy obecnie na swoich systemach x64 wykorzystujemy edycję Windows XP czy Windows Server 2003.

O autorze

Wes Miller pełni stanowisko Development Manager w firmie Pluck (www.pluck.com) w Austin w Teksasie. Wcześniej pracował w firmie Winternals Software oraz firmie Microsoft jako Program Manager oraz Product Manager dla systemu Windows. Można skontaktować się z Wesem za pośrednictwem adresu technet@getwired.com.

Do początku strony