Netrix's devLog

Niedawno kupiłem sobie w końcu router z AP, ale zanim jeszcze to zrobiłem chciałem podłączyć PS3 do internetu za pomocą sieci WLAN. Niestety konsola nie obsługuje sieci Ad-hoc, więc potrzebny był AP.
Poszukując rozwiązania natrafiłem w końcu na pewną stronę  (link na dole). W skrócie trik polega na wykorzystaniu wirtualnego adaptera WiFi, który jest domyślnie zainstalowany w Windows 7 do utworzenia sieci bezprzewodowej w trybie AP. Oczywiście nie wszystkie karty sieciowe obsługują ten tryb. Lista obsługiwanych chipsetów również znajduje się na pod tym linkiem. Dodatkowo dodam od siebie, że karta Atheros AR9285 z Eee PC obsługuje ten tryb, natomiast Atheros AR5006EG już nie.

Obiecany link

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.

Udało mi się wreszcie opanować kawałek kodu, który męczył mnie od 2 dni. Okazało się, że umieściłem w strukturze, która była agregatem, referencję. Następnie zainicjalizowałem obiekt takiej struktury jako agregat. Wszystko było ładnie, dopóki nie postanowiłem przestawić kompilacji z Debug na Release. Aplikacja zaczęła się sypać. Dzisiaj udało mi się wreszcie znaleźć ten błąd, który tkwił w referencji umieszczonej w agregacie, po jej usunięciu wszystko było ok.

Myślę, że jest to błąd kompilatora, który powinien przynajmniej ostrzegać o próbie inicjalizacji referencji w agregacie. Wynik takiej operacji jest niestety niezdefiniowany.

Mała porada dla tych, którzy chcą otworzyć stare projekty, które zawierają pliki *.rc.
Przy próbie kompilacji takich projektów, może wyskoczyć błąd, który oznajmia, że nie mamy plików podanych w tytule.

Rozwiązanie jest proste, wystarczy nazwę tego pliku podmienić na windows.h. Dzięki temu można korzystać z zasobów ładowanych do pliku *.exe. (Sprawdzałem tylko na prostym projekcie z książki Programowanie w DirectX Masona McCuskey’a).

W Visualu C++ EE, zablokowana jest możliwość otwierania plików *.rc, jednak nie tak do końca, albowiem wystarczy kliknąć na takim pliku prawym przyciskiem myszy, a następnie wybrać Open with… i w oknie wybrać Source Code (Text) Editor. Według mnie zawsze jest to jakieś rozwiązanie.
EDIT: wystarczy kliknąć na takim pliku prawym przyciskiem myszy i opcję View Code. Thx Tarains.

Spotkałem się również z takim problemem, jak brak zdefiniowanej stałej IDC_STATIC (używanej do tworzenia szablonów okien dialogowych).
Kod błędu:
error RC2104 : undefined keyword or key name: IDC_STATIC

W takim przypadku należy do pliku resources.h dodać następujący kod:

#ifdef IDC_STATIC
#undef IDC_STATIC
#endif
#define IDC_STATIC (-1)