Netrix's devLog

Korzystając z MS Visual Studio, czasami przydałaby się możliwość skompilowania całej solucji korzystając z wiersza poleceń (cmd/PowerShell), tak jak ma to miejsce w przypadku Unixowego make. Okazuje się, że można to zrobić, a służy do tego konsolowy programik MSBuild. Znajduje się on w jednym z katalogów:

C:\Windows\Microsoft.NET\Framework\[wersja] lub
C:\Windows\Microsoft.NET\Framework64\[wersja] (wersja x64).

W każdym z katalogów powyżej wersji 1.1 (czyli od 2.0) znajdują się kompilatory wszystkich języków zarządzanych oraz kilka dodatkowych narzędzi w tym właśnie MSBuild (dla ciekawych, kompilator cl.exe języka C++ znajduje się pod ścieżką [katalog Visual Studio]\VC\bin).

Pytanie: dlaczego porównałem MSBuild do make? Głównie ze względu na sposób użycia, czyli “odpal i idź na kawę” :). Aby zbudować solucję wystarczy, “być” w katalogu z plikiem .sln i uruchomić MSBuild, wtedy program skorzysta z domyślnych ustawień zapisanych w pliku solucji. Można dodatkowo podać jako argumenty

-p:”Configuration=Release;Architecture=x64″

wtedy cała solucja zostanie zbudowana zgodnie z ustawieniami Release pod platformę 64-bitową. Można również budować solucje z innego katalogu, aby to zrobić trzeba podać ścieżkę do pliku .sln.

Cały wyciąg budowania aplikacji opatrzony jest kolorami, więc nie trzeba specjalnie doszukiwać się poszczególnych etapów. Więcej informacji można znaleźć po następującymi linkami:

http://msdn.microsoft.com/en-us/library/ee662426.aspx
http://msdn.microsoft.com/en-us/library/ms164311.aspx

Podczas dalszego kodowania mojego silnika natrafiłem na bardzo dziwny błąd kompilatora Visual Studio. Zaczynając od początku – mam oto taki kod:

enum
{
	// Rozmiary pól
	MAX_BITS_INDEX = sizeof(Size_t) * 4,
	MAX_BITS_MAGIC = sizeof(Size_t) * 4,
	// Maksymalne wartości pól (Przesunięcie 1 w dwóch operacjach, ponieważ inaczej kompilator nie daje rady)
	MAX_INDEX = ((1 << MAX_BITS_INDEX / 2) << MAX_BITS_INDEX / 2) - 1,
	MAX_MAGIC = ((1 << MAX_BITS_MAGIC / 2) << MAX_BITS_MAGIC / 2) - 1
};
/* ... */
 
// handle = 0x0000000400000006;   - przykladowo
// Size_t ma rozmiar wskaźnika (jest zależny od platformy)
Size_t value = handle & MAX_MAGIC;

Otóż problem z tym kodem jest taki, że gdy zostanie skompilowany na platformę x64, zostaje wygenerowany następujący kod w assemblerze:

    79:                 {
    80:                         Size_t value = handle & MAX_MAGIC;
 
000000013FC96F94  mov         rax,qword ptr [handle]
000000013FC96F9C  mov         qword ptr [value],rax
 
    81:                         if(value == *it) return true; // Dalszy kod

Jak widać problem polega na braku kluczowej instrukcji and, której zadaniem jest odcięcie najstarszych 32-bitów. Dla porównania kod assemblera wygenerowanego dla platformy x86 jest następujący:

    79:                 {
    80:                         Size_t value = handle & MAX_MAGIC;
00DC9DDC  mov         eax,dword ptr [handle]
00DC9DDF  and          eax,0FFFFh
00DC9DE4  mov         dword ptr [value],eax
    81:                         if(value == *it) return true; // Dalszy kod

Tutaj instrukcja ta występuje.

Błąd ten jednak nie występuje gdy samemu sprecyzuję stałą, tj.:

Size_t value = handle & 0xffffffff;

W tym przypadku zostanie wygenerowany poprawny kod.

Wniosek jest taki, że kompilator widząc operację and zmiennej ze stałą typu enum (który przechowuje wartości 32-bitowe), traktuje tą zmienną jako typ 32-bitowy. W tym przypadku stwierdza, że instrukcja and nie ma sensu, bo wartość MAX_MAGIC zawiera maksymalną wartość (0xffffffff). Według mnie jest to ewidentny błąd i nie powinno takie coś wystąpić.

// Edit :)
Problemem oczywiście jest to, że enum jest tak naprawdę typem int, więc się dokładnie tak zachowuje.

Postanowiłem przekompilować aktualnie pisany framework pod platformę x64. Jest to już trochę napisanego kodu, więc objawiło się to trzema problemami, z których najważniejszym jest ten komunikat:

LNK1112: module machine type 'X86' conflicts with target machine type x64''

Zostaje on wyrzucony wtedy, gdy podczas składania programu x64 Linker napotka bibliotekę skompilowaną pod target x86.

Przyczyną tego konfliktu są błędne wpisy ścieżek do bibliotek statycznych, które znajdują się w opcjach Visual Studio. Niestety wpisy dla platformy x64 są po prostu kopiowane z platformy Win32 (nie wszystkie, bo jest ich mniej). Należy je poprawić tak aby wskazywały na foldery z bibliotekami x64. Obok jest obrazek z poprawnymi ustawieniami mojego Visual Studio.

Drugim, ale już mniej znaczącym problemem jest ostrzeżenie

conversion from 'size_type' to 'int', possible loss of data

powodowane rozrzeszeniem rozmiaru typu ‘size_type’ z 4 do 8. Typ ten jest zwracany przez funkcje size() w kontenerach biblioteki standardowe. W tym przypadku rozwiązaniem jest po prostu zamiana powszechnie używanego (unsigned) int na size_type bądź własny odpowiednik zdefiniowany w klauzulach #ifdef/#endif :).

Ostatnim problemem jest brak inline’owych wstawek assemblerowych. W moim przypadku za ten błąd odpowiadało makro NAssert, w środku którego jest wykorzystana konstrukcja:

__asm 
{
   int 3 
}

Powoduje ona wywołanie Breakpointa w miejscu asercji. Okazuje się, że rozwiązanie tego jest bardzo proste, ponieważ Visual Studio posiada następującą funkcję typu intrinsic:

__debugbreak()

Powoduje ona dokładnie tę samą akcję co podana wyżej wstawka w assemblerze.

A poniżej wynik całego procesu przenoszenia :).

Dzisiaj postanowiłem spróbować skompilować coś pod platformę 64-bitową. Jako że dysponuję teraz już odpowiednim sprzętem, systemem, więc nic nie stało na przeszkodzie aby to uczynić. Ze znalezionych w internecie informacji dowiedziałem się tyle, że wystarczy przestawić docelową platformę z Win32 na x64 i już można przystąpić do próby kompilacji.

Niestety tu pojawił się problem, ponieważ jedynymi dostępnym platformami oprócz Win32 są platformy ARM. Po kolejnym skorzystaniu z wyszukiwarki Google dowiedziałem się, że winę za to ponosi nieodpowiednia kolejność instalacji Windows SDK 7, Visual Studio oraz braku odpowiedniego dla niego Service Packa. Poprawna kolejność instalacji jest następująca:

1. Visual Studio 2008
2. Service Pack 1 dla Visual Studio 2008
3. Windows SDK 7

Oczywiście nie miałem ochoty robić reinstalacji VS i WSDK, dlatego poszukałem innego rozwiązania. Oto ono:

1. Deinstalacja “Microsoft Visual C++ Compilers 2008 Standard Edition – enu – x64” oraz “Microsoft Visual C++ Compilers 2008 Standard Edition – enu – x86”
2. Naprawa instalacji Visual Studio (Przez funkcję Repair)
3. Instalacja Service Packa

Należy zaznaczyć, że użycie funkcji Repair na instalacji WSDK7 usunie tę poprawkę.

Tutaj znajduje się oryginalna stronka z opisem naprawy.

Po trzech tygodniach wreszcie odzyskałem notebooka, w którym jak się okazało, popsuła się płyta główna (brak możliwości restartu, ponieważ po wyłączeniu systemu operacyjnego, komputer się przez pół godziny nie dawał uruchomić). Po powrocie z serwisu niestety kilka programów zaczęło szwankować, ale jest to konsekwencją wymiany płyty głównej. Przynajmniej dostałem w końcu dobry pretekst, żeby usunąć z dysku ostatni 32-bitowy system a zarazem Vistę :).

Przechodząc do meritum, po próbach zainstalowania Windows XP 64-bit, Windows 2k8 Server x64, dopiero Windows Seven 64-bit okazał się być odpowiednim systemem, ponieważ jako jedyny posiada sterowniki do mojej, jakże wydajnej karty “GeForce 6100 Go!”. Z innymi sterownikami też nie było problemu, gdyż na stronie ASUS mimo tego, że sterowniki oznaczone są jako 32-bitowe, zawierają również wersje 64-bit.
Po sterownikach przyszedł czas na oprogramowanie. Starałem się instalować programy x64, jeżeli były one dostępne. Wśród nich są między innymi Mozilla Firefox (Minefield) oraz Mozilla Thunderbird (Shredder) dostępne na tej stronie. Niestety największą bolączką przeglądarki 64-bitowej jest brak programu Adobe Flash Player w tej samej wersji (istnieje wersja testowa, ale przeznaczona tylko na systemy Linux).
Oprócz przeglądarki, ważnym programem (przynajmniej dla mnie) jest Visual Studio. Samo IDE jest aplikacją opartą o .NET więc jest 32-bitowa, ale kompilator w nim zawarty ma już wsparcie dla 64-bitów. W ustawieniach projektu jest możliwość wyboru docelowej platformy x86/x64/IA-64 (pozostaję póki co przy x86). Niestety przy instalacji DirectX SDK pojawił się drobny dylemat. W Visualu, w opcjach (dla ułatwienia oczywiście) można podać ścieżkę do katalogu z bibliotekami statycznymi, jednak w przypadku gdybym chciał kompilować program w dwóch wersjach, dochodzi problem żonglowania ze ścieżkami do wersji x64 i x86. Lepiej by było, gdyby Visual sam wybierał ścieżki na podstawie tego, na jaką platformę kompilujemy dany projekt.
Ostatnią ciekawostką jest brak możliwości zainstalowania NVIDIA SDK 9, którego instalator wyrzuca komunikat o braku wsparcia dla x64.

Podsumowując muszę stwierdzić, że przejście na platformę 64-bitową jest dla mnie krokiem naprzód, ponieważ jakby nie patrzeć mogę wykorzystać posiadany sprzęt w 100% (2x więcej rejetrów xmm :)), a dodatkowo dobrze się bawić poznając dokładniej tę architekturę. Ogólnie programów 64-bitowych nie ma jeszcze za wiele, ale myślę, że ich ilość stale wzrasta. Mam również nadzieję, że system Windows Seven będzie ostatnim systemem, który jest dostępny w wersji 32-bitowej, dzięki temu producenci nie będą mieli problemy z wyborem platformy docelowej dla sterowników.

Któż by mógł przypuszczać, że Linux jest taką fajną zabawką. Okazuje się jednak, że ten system operacyjny może sprawić dużo frajdy. Ostatnio dużo czasu spędzam na Ubuntu i muszę stwierdzić, że jestem z niego zadowolony. Wybrałem tę dystrybucję, ponieważ jest bardzo prosta w obsłudze, a konkurencyjna Fedora miała problemy z instalacją. Sam system jest 64-bitowy, gdyż chciałem zobaczyć różnicę między nim, a wersją 32-bitową, którą miałem wcześniej. Wrażenie jest czysto subiektywne (wydaje się lepiej). Ze sterownikami nie było żadnych problemów, ponieważ Ubuntu zawiera wszystkie, jakie są potrzebne.

Wygląd Ubuntu można bardzo prosto dostosować, wystarczy tylko aby w systemie znalazł się dekorator okien Emerald oraz Compiz-Fusion. Dzięki temu tandemowi można Linuksa przerobić z wyglądu na Windowsa, a nawet jeszcze lepiej. Mój system wygląda jak na zdjęciu :).

Inną rzeczą, która mnie w Linuksie zainsteresowała, to możliwość uruchamiania aplikacji windowsowych, szczególnie że udało mi się załapać na darmową wersję aplikacji CrossOver. Osobiście korzystam z dwóch wersji: Linux i Games, dlatego mogę przyznać, że są to bardzo dobre aplikacje.