Karta WiFi jako Access-Point

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

Problemów z x64 ciąg dalszy

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.Poprawne ustawienie bibliotek

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 :).
End

Problem z kompilacją x64 na Win7 RC

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.Przed poprawką

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ę.

Po poprawce

Tutaj znajduje się oryginalna stronka z opisem naprawy.

Windows Seven 64-bit

TaskMan

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.
sbdksohtaOstatnią 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.