TEB/PEB (nie tylko) w WOW64 (cz. II)

28 listopada 2014

Dosyć długo to trwało, ale wreszcie dokończyłem przeredagowanie ostatniej notatki o strukturach PEB/TEB w Windowsie i dokończyć aktualną, bardziej ukierunkowaną na WOW64. Bo, tematem zainteresowałem się właśnie z tego powodu, szukając prostego i zarazem przenośnego (niezależnego od wersji systemu) sposobu dobrania się do tych struktur. Nawet o tym wspominałem w prologu poprzedniego wpisu.

W ramach krótkiego wstępu…

WOW64, czyli Windows 32-bit On Windows 64-bit (WOW64), jest warstwą emulacyjną umożliwiającą uruchomienie 32-bitowych aplikacji w środowisku 64-bitowym. W wielkim skrócie, warstwa ta gnieździ się pomiędzy 32-bitową aplikacją a natywnym API (ntdll), zawiera 32-bitowe wersje bibliotek systemowych i translującą wywołania z 32-bitowego ntdll do natywnego 64-bitowego i odwrotnie.

Jak można się domyślić, procesy WOW-owe zawierają obie wersje, 32- i 64- bitowe bloków procesu i wątku. Od strony systemu są to natywne wersje 64-bitowe, a dla subsystemu WOW64 – jego 32-bitowe odpowiedniki, które w większości są kopią wersji natywnych ( z małymi wyjątkami). Problemem może być dotarcie do interesującej nas wersji tych struktur. O ile pobranie natywnej wersji przebiega w standardowy sposób, o tyle sprawa z wersją WOW-ową się nieco komplikuje.

Na początek powinienem uściślić pojęcie natywnej wersji w aktualnym kontekście, choć może to być trochę kłopotliwe. Bo należy rozróżnić to, czy natywne struktury będą się odnosi do wersji systemu/platformy, czy do kodu aplikacji. Intuicja podpowiada, że powinien to być ten pierwszy przypadek, bo system jest natywny, a WOW to tylko emulacja. Choć z drugiej strony patrząc od kodu aplikacji, dla niej natywna wersja to ta przeznaczona dla niej, odpowiadająca jej natywnemu kodowi. Myślę, że druga definicja w moim dalszym rozważaniu będzie bardziej odpowiednia, ale będę starał się jawnie odwoływać do wersji 32/64-bitowej.

Dostęp do wersji natywnych, czyli spod systemu do wersji 64-bitowej (wskaże dla systemu proces mimo wszystko jest 64-bitowy), a także dostęp do 32-bitowej wersji wprost z 32-bitowego kodu uruchamianego pod WOW-em, przebiega standardowo, dostępnymi metodami jakie przedstawiłem w poprzednim poście. Tutaj nie ma się nad czym zastanawiać.

Ciekawe jest dobranie się do wersji WOW-owej. Mianem tym będę określał wersję nie natywną, czyli dla 64-bitowego procesu systemu będzie to wersja 32-bitowa, a dla kodu 32-bitowego uruchomionego w warstwie emulacji wersja 64-bitowa. Tutaj musimy zajrzeć nieco pod maskę systemu.

Wykorzystanie korelacji

W sieci można znaleźć informacje, o ułożeniu poszczególnych bloków w pamięci. Większość z tych informacji mówi jasno, że 32-bitowy TEB zawsze leży w odległości 2 stron (0x2000) za 64-bitową wersją (systemową), a 32-bitowy PEB 1 stronę (0x1000) przed wersją systemową (64-bitową).

Jako potwierdzenie tego, wystarczy zerknąć na adresy tych struktur wydedukowane przez WinDbg, za pomocą polecenia !wow64exts.info:

0:000> !wow64exts.info
 
PEB32: 0x7efde000
PEB64: 0x7efdf000
 
Wow64 information for current thread:
 
TEB32: 0x7efdd000
TEB64: 0x7efdb000
 
32 bit, StackBase   : 0xf0000
        StackLimit  : 0xdf000
        Deallocation: 0xb0000
 
64 bit, StackBase   : 0x18fd20
        StackLimit  : 0x18c000
        Deallocation: 0x150000

Na tym również jasno widać, że istnieją również dwie wersja stosu, co wydaje się logiczne, ale do tego może wrócimy kiedyś indziej.

Innym potwierdzeniem słuszności tych informacji może być zerkniecie do kodu biblioteki systemowej w wersji dla WOW64, gdzie dokładnie widać do jakich danych dobiera się system, w zależności od procesu. Taką krótką analizę można znaleźć na redplait w notatce teb32 of wow64 process.

Znając rozmieszczenie danych w pamięci, z łatwością można zaimplementować funkcje pobierające wybrane dane, które będą zwraca wskaźniki na bloki WOW-owe (przeciwne do natywnych wersji):

inline PTEB GetWowCurrentTeb() {
	const int offset = 0x2000;
#if defined _M_IX86		// x86
	return (PTEB)((ULONG_PTR)GetCurrentTeb() - offset);
#elif defined _M_X64	// x64
	return (PTEB)((ULONG_PTR))GetCurrentTeb() + offset);
#else
	#error "Unknown platform."
#endif
}
 
inline PPEB GetWowCurrentPeb() {
	const int offset = 0x1000;
#if defined _M_IX86		// x86
	return (PPEB)((ULONG_PTR)GetCurrentPeb() + offset);
#elif defined _M_X64	// x64
	return (PPEB)((ULONG_PTR)GetCurrentPeb() - offset);
#else
	#error "Unknown platform."
#endif
}

Niestety jak to bywa, w pewnym momencie nowa wersja systemu musi wprowadzić zmiany, od wersji Windows 8, rozlokowanie danych w pamięci uległo modyfikacji:

0:000> !wow64exts.info
PEB32: 0x7f086000
PEB64: 0x7f088000
 
Wow64 information for current thread:
 
TEB32: 0x7f08f000
TEB64: 0x7f08d000
 
.restart /f
 
0:000> !wow64exts.info
PEB32: 0x7f39f000
PEB64: 0x7f39a000
 
Wow64 information for current thread:
 
TEB32: 0x7f39e000
TEB64: 0x7f39c000

Korelacja miedzy TEB-ami nadal pozostaje taka sama, zmieniła się natomiast lokacja struktur PEB. Przy każdym uruchomieniu jest inna, losowa, wiec nie da się znaleźć żadnej deterministycznej metody jej wyznaczenia.

Wygląda na to, że zmieniła się ścieżka wykonywania kodu, i zależnie od okoliczności przydział pamięci następuje w inny sposób. Możliwe jest również to, że włączono losowy przydział adresów (nie mogę przypomnieć sobie nazwy) i dla bezpieczeństwa każda alokacja otrzymuje niedeterministyczną wartość adresu z wolnej przestrzenia dresowej. Ciekawe, ale obecnie nie mam czasu, aby zajrzeć głębiej pod maskę systemu, aby się dowiedzieć co tak naprawdę się wydarzyło.

Mimo to nadal możemy bez problemu polegać na korelacji między TEB-ami, ciągle obowiązuje ten sam offset. Myślę, że nie powinno się to szybko zmienić, szczególnie, że w WRK (Windows Research Kernel) można znaleźć takie oto makra:

//
// Macro to round to the nearest page size
//
 
#define WOW64_ROUND_TO_PAGES(Size) \
	(((ULONG_PTR)(Size) + PAGE_SIZE - 1) & ~(PAGE_SIZE - 1))
 
//
// Get the 32-bit TEB without doing a memory reference.
//
 
#define WOW64_GET_TEB32_SAFE(teb64) \
	((PTEB32) ((ULONGLONG)teb64 + WOW64_ROUND_TO_PAGES (sizeof (TEB))))
 
#define WOW64_GET_TEB32(teb64) \
	WOW64_GET_TEB32_SAFE(teb64)

A dla PEB-a możemy zmodyfikować kod w bardziej przenośną implementację – używającą pola ProcessEnvironmentBlock z TEB-a.

Inną opcją jest skorzystanie z dostępnych funkcji API tych jawnych oraz nieudokumentowanych, albo znaleźć inne sztuczki, a takie jeszcze istnieją, o czym dalej.

PEB/TEB64 z procesu WOW64 (32-bit)

Chcąc dobrać się do systemowego 64-bitowego bloku danych wprost z kodu aplikacji 32-bitowej uruchomionej w warstwie emulacyjnej WOW64, można skorzystać z oficjalnie dostępnych w WinAPI funkcji. Wraz w WOW-em pojawiło się kilka specjalnych wersji funkcji przeznaczonych do tego celu – interakcji z natywnym podsystemem spoza warstwy WOW64. Można je rozpoznać po podsłowie Wow64 w nazwie, np. funkcje NtWow64*, RtlWow64*. Dostępne są tylko w 32-bitowych wersjach bibliotek systemowych używanych przez WOW64.

Adres do 64-bitowego systemowego bloku procesu można pobrać używając funkcji NtWow64QueryInformationProcess64:

NTSTATUS WINAPI NtWow64QueryInformationProcess64(
  _In_       HANDLE ProcessHandle,
  _In_       PROCESSINFOCLASS ProcessInformationClass,
  _Out_      PVOID ProcessInformation,
  _In_       ULONG ProcessInformationLength,
  _Out_opt_  PULONG ReturnLength
);

Jest to nic innego jak WOW-owy wrapper na natywny 64-bitowy syscall NtQueryInformationProcess, a ten jak już wiadomo w strukturze PROCESS_BASIC_INFORMATION w polu PebBaseAddress dostarczy adres na poszukiwany obszar pamięci.

Niestety nie istnieje WOW64-owa wersja odpowiadająca podobnemu działaniu w kontekście wątku, ani żadne inne wywołanie API.

Za to grzebiąc w źródłach i kodach systemowych można znaleźć inne sposoby na zdobycie adresu do 64-bitowej struktury TEB. WOW64 (i nie tylko) w różnych nie używanych (w danym kontekście) polach i fragmentach (tutaj PEB/TEB) wrzuca inne dane. Można się zdziwić co zawiera pole GdiBatchCount w TEB procesu 32-bitowego w WOW-ie – jest to adres do wersji 64-bitowej!

Świadczyć o tym mogą znalezione fragmenty kodu w WRK:

#define NtCurrentTeb64()	((PTEB64)((PTEB32)NtCurrentTeb())->GdiBatchCount)
#define NtCurrentPeb64()	((PPEB64)NtCurrentTeb64()->ProcessEnvironmentBlock)

Aby się przekonać, że to wciąż jest prawda, wystarczy odpalić debuggera:

// !wow64exts.info
TEB32: 0x7efda000
TEB64: <strong>0x7efd8000</strong>
 
// dt -r _TEB 7efda000
TEB32: 
...
	+0xf6c WinSockData				: (null) 
	+0xf70 GdiBatchCount			: <strong>0x7efd8000</strong>
	+0xf74 CurrentIdealProcessor	: _PROCESSOR_NUMBER
...

albo pogrzebać w kodzie systemowych dll-ek. ReWolf analizując działanie GetSystemFileCacheSize trafił na podobny ślad potwierdzający te doniesienia…

PEB/TEB32 z procesu natywnego (64-bit)

W drugą stronę, z natywnego procesu systemowego dostęp do bloków danych procesu i wątku również jest prosty, wystarczy tylko wykorzystać odpowiednią funkcje z API. A jest nią znane już NtQueryInformationProcess. Posiada ona możliwość pobrania specyficznych danych dla procesu uruchomionego pod WOW64. Mowa tutaj o info klasy typu ProcessWow64Information.

Dokumentacja nie mówi jasno wprost o tym, że dostaniemy adres, pod którym leży PEB32:

When the ProcessInformationClass parameter is ProcessWow64Information, the buffer pointed to by the ProcessInformation parameter should be large enough to hold a ULONG_PTR. If this value is nonzero, the process is running in a WOW64 environment; otherwise, if the value is equal to zero, the process is not running in a WOW64 environment.

ale skoro zwracany jest typ mogący pomieścić adres, i tylko dla procesów WOW64 jest to wartość niezerowa, to znak, że trzeba to zbadać.

Jak prześledzimy źródła to dojdziemy do wniosku ze zwracane jest wartość pola Wow64Process struktury PROCESS. A ona przechowuje dokładnie to co nas interesuje. Żeby nie zarzucać za dużo kodu binarnego, można to potwierdzić za pomocą WinDbg listując zawartość struktury PROCESS:

[Mam mały problem z dostępem do debugera kernela pod Windows 7, wiec na razie nie mogę nic tutaj pokazać. Jak tylko będę miał okazję to wrzucę potrzebne fragmenty z jego outputu…]

Pole to jest wypleniane adresem do zaalokowanej pamięci przez MiCreatePebOrTeb na potrzeby PEB32 w funkcji MiInitializeWowPeb, która inicjalizuje dla procesów WOW64-owych dane w MmCreatePeb.

Historycznie wypada mi wspomnieć, że przed Windows 7, Wow64Process w rzeczywistości nie był bezpośrednim wskaźnikiem na PEB32 tylko prowadził do danych zawartych w strukturze WOW64_PROCESS, która zawierała nieco więcej informacji o procesie w kontekście subsystemu WOW64:

typedef struct _WOW64_PROCESS {
	PVOID Wow64;
#if defined(_IA64_)
	FAST_MUTEX AlternateTableLock;
	PULONG AltPermBitmap;
	ULONG AltFlags;
#endif
} WOW64_PROCESS, *PWOW64_PROCESS;

Adres do bloku środowiska procesu zawierało pole Wow64.

W kernel-mode do pobierania tej wartości z PROCESS można użyć następujących funkcji:

#if defined (_WIN64)
	#define PS_GET_WOW64_PROCESS(Process) ((Process)->Wow64Process)
#else
	#define PS_GET_WOW64_PROCESS(Process) ((Process), ((PWOW64_PROCESS)NULL))
#endif
 
PVOID PsGetProcessWow64Process(__in PEPROCESS Process)
{
	return PS_GET_WOW64_PROCESS (Process);
}
 
PVOID PsGetCurrentProcessWow64Process(VOID)
{
	return PS_GET_WOW64_PROCESS (PsGetCurrentProcess());
}

Funkcje te w każdej wersji zwracały wartość wskaźnika zapisanego w polu Wow64Process, niezależnie od tego, czy zawarty adres wskazywał na WOW64_PROCESS, czy bezpośrednio na PEB32.

Podobnie jak w przypadku dostępu do TEB64 w aplikacji 32-bitowej w WOW64, tutaj również istnieją pewne tricki i nieudokumentowane miejsca, gdzie kernel wrzuca adres do WOW-owego bloku wątku.

Jak wiadomo, w 64-bitowy kod nie ma obsługi wyjątków stack-based, zatem w polu ExceptionList przechowuje adres do TEB32, jeśli proces jest WOW-owy, lub 0, gdy jest to proces natywny 64-bitowy.

Mechanizm ten jest używany przez jądro, o czym mogą świadczyć następujące fragmenty kodu w WRK:

//
// Update the first qword in the 64-bit TEB.  The 32-bit rdteb instruction
// reads the TEB32 pointer value directly from this field.
//
 
#define WOW64_SET_TEB32(teb64, teb32) \
	(teb64)->NtTib.ExceptionList = (struct _EXCEPTION_REGISTRATION_RECORD *)(teb32);
 
#define WOW64_TEB32_POINTER_ADDRESS(teb64) \
	(PVOID)&((teb64)->NtTib.ExceptionList)

Potwierdzić to można za pomocą WinDbg, lub innego debuggera:

// !wow64exts.info
TEB32: <strong>0x7efda000</strong>
TEB64: 0x7efd8000
 
// dt -r _TEB 0x7efd8000
TEB64: 
...
	+0x000 NtTib            : _NT_TIB
		+0x000 ExceptionList    : <strong>0x00000000`7efda000</strong> _EXCEPTION_REGISTRATION_RECORD
			+0x000 Next             : 0x01fa0000`ffffffff _EXCEPTION_REGISTRATION_RECORD
...

Słowem zakończenia…

Jak widać, istnieje wiele dróg prowadzących do celu. Dużo ciekawych nieudokumentowanych rzeczy można znaleźć w internalsach systemu Windows. Niektóre do tej pory znane sposoby na zlokalizowanie odpowiednich struktur w procesach WOW64 uległy zmianie., Mowie tutaj szczególnie o rozmieszczeniu w pamięci struktur PEB. Ukazuje to jeden istotny mankament – poleganie na nieudokumentowanych elementach prędzej czy później może przynieść problemy. Ale z drugiej strony, większość tych mechanizmów jest powszechnie znana i używana, wiec wybór pomiędzy używaniem tych elementów a innych sposobów, jak systemowe API (o ile istnieje), zależy ściśle od potrzeb i możliwości jakie chce się osiągnąć.

Wywołanie funkcji API zawsze pociąga jakiś narzut, a szybki dostęp bezpośrednio do poszczególnych pól struktur, w niektórych sytuacjach ma bardzo istotne znaczenie. Poza tym patrząc na przeprowadzone „śledztwo”, mogę rzec, że użycie tych samych mechanizmów, jakie używa jądro powinno być bezpieczne. Na pewno do czasu, aż kolejna wersja systemu nie wprowadzi zmian.

Do zmian i problemów z tego wynikłych zawsze można się jakoś przygotować. Jednym ze sposób może być badanie, czy to na czym bazujemy nadal jest dostępne lub spełnia określone wymagania. Można porównać zwracane wartości różnych metod, a gdy to zwróci wynik negatywny, zasygnalizować występujący problem reakcja typu „Unsuportded version„. Da to wyraźny sygnał, że cos zostało zmienione. Na pewno jest to lepsze niż błądzenie po nie swojej pamięci i rzucenie Access Violation przez aplikację.

U mnie obecnie faworytem jest skorzystanie z wiedzy w jakich polach sam kernel trzyma dane, szczególnie te, które dostępne są w przestrzeni adresowej użytkownika. Korzystając z tych tajnych informacji można zaimplementować funkcje w sposób podobny do poniższego zapisu:

inline PTEB GetWowCurrentTeb() {
#if defined _M_IX86		// x86
	// return TEB64
	return (PTEB)GetCurrentTeb()->GdiBatchCount;
#elif defined _M_X64	// x64
	// return TEB32
	return (PTEB)GetCurrentTeb()->NtTib.ExceptionList;
#else
	#error "Unknown platform."
#endif
}
 
inline PPEB GetWowCurrentPeb() {
	// return PEB32 or PEB64
	return GetWowCurrentTeb()->ProcessEnvironmentBlock;
}

Wykorzystanie poszczególnych pól różnych struktur do innego celu niż zostały przywidziane, jest dosyć częsta praktyką, nie tylko w WOW64. Pozwala to zminimalizować użycie pamięci, szczególnie że większość istniejących pól w różnych kontekstach użycia nie jest używana. A skoro nie jest używana, to nie ma sensu dodawać nowych zwiększać użycie pamięci, bo czasem w takich sytuacjach ma to znaczenie. Podobnie pozwala to uchronić się przed załamaniem kompatybilności.

Z punktu widzenia deweloperskiego, może to zaciemni kod, ale dobre tego zaimplementowanie, nie powinno stwarzać takiej iluzji.

BTW. WOW64 trzyma jeszcze masę ciekawych informacji w innych polach i slotach TLS (Thread Local Storage), może kiedyś o tym napiszę, jak znajdę coś szczególnie interesującego.

TEB/PEB (nie tylko) w WOW64 (cz. I)

20 listopada 2014

Pogłębiając swoją wiedzę nad internalsami systemu Windows, moje badania przesunęły się ostatnio trochę w stronę WOW64. Jest to całkiem ciekawy fragment architektoniczny systemu, o którym kiedyś jeszcze mam nadzieję będę pisał, bo wypływa wiele ciekawych rzeczy w trakcie jego analizowania. Przy okazji tego zahaczyłem o struktury bloków danych procesu PEB i wątku TEB, głównie w […]

czytaj całość »

Nowy biquad dla DVB-T

5 listopada 2014

Moja ostatnia, która w rzeczywistości była pierwsza, konstrukcja bi-quada była typową prowizorką, więc z czasem jak to można ładnie rzec „trafił ją szlag”. Jak o tym kiedyś pisałem, wersja tej anteny (prowizorki) bazowała na żyle koncentryka, a jak wiadomo drut w kablu antenowym jest cienki, przez co podatny jest na odkształcenia. Taka konstrukcja wisząca na […]

czytaj całość »

Blood2: Analiza cracka

14 października 2014

Kolejna część dotycząca mojej starej ulubionej (ostatnio) gry, którą potraktowałem jako narzędzie analizy i zabawy w reverse enginering. Jak wspomniałem w poprzedniej (pierwszej) części, miałem problem ze znalezieniem odpowiedniego programu neutralizującego wymóg posiadania płyty CD. A wszystko na co trafiłem było jednosegmentowymi aplikacjami DOS-a. A jak wiadomo Windowsy 64-bitowe nie posiadają już subsystemu do odpalania […]

czytaj całość »

Blood2: Crack me!

10 października 2014

Jak zapewne niektórzy zauważyli na moim twitterze, (który staje się mini blogiem), ostatnio – tweet – uruchamiałem taką starą, wspaniałą grę z przełomu milenium, jaką jest Blood2: The Chosen. W młodości trochę w nią grywałem, jakiś sentyment pozostał. A że chciałem się trochę zrelaksować w weekend, a przy okazji spróbować skonteneryzować i uruchomić tą gierkę […]

czytaj całość »

Portfel akcji 3Q 2014

1 października 2014

Kolejny kwartał za nami, pora na krótkie przedstawienie wyników moich akcyjnych portfeli, małą analizę i być może jakieś trafne wyciagnięcie wniosków, które mogą pomoc skonkretyzować plan działania na najbliższy czas. Może od razu przejdźmy do meritum. Sytuacja na GPW Nastroje na GPW umiarkowane, momentami Ukraina i Rosja nadal lubią postraszyć inwestorów polskiego rynku, ale nie […]

czytaj całość »

Portfel akcji 2Q 2014

1 lipca 2014

Kolejny kwartał moich zmagań na rynku akcji za nami wymaga chociażby małego podsumowania. Niestety wciąż napięta sytuacja na wschodzie Ukrainy odciska piętno na GPW. Co skutkuje takimi, a nie innymi wynikami. Ale główny cel, jakim jest staranie się wyjść, w najgorszym przypadku, w okolicach zera, a najlepiej oczywiście nad nim, udało jako tako się spełnić. […]

czytaj całość »

Sezon dywidendowy rozpoczęty

13 kwietnia 2014

Jedna z inspiracji dla mojego prywatnego funduszu emerytalnego było oparcie części aktywów akcyjnych na strategii dywidendowej. Szerzej o tym pisałem w memo odnośnie ukierunkowania się i spróbowania swoich sił na rynku GPW. Strategia oparta na stabilnych spółkach dzielących się swoimi zyskami z akcjonariuszami, wydaje się być jedną z głównych strategii, jakie można spotkać w długoterminowej […]

czytaj całość »

Metodologia wyceny portfela

5 kwietnia 2014

Jednym z kluczowych problemów dotyczących inwestowania jest pomiar i ocena wyników zarządzania portfelem inwestycji. Pierwszym i najbardziej popularnym sposobem jest wyznaczenie stopy zwrotu i porównanie jej do benchmarku. O ile wyznaczenie stopy zwrotu ze stałych, czy jednorazowych inwestycji jest sprawą prostą, to problemem może być określenie stopy zwrotu z portfela, w którym ciągle coś się […]

czytaj całość »

Portfel akcji 1Q 2014

1 kwietnia 2014

Mam już za sobą pierwszy, pełny kwartał bojów na GPW, więc niejako wymusza to szybką analizę działania wraz z podsumowaniem i oceną wyników, jakie udało mi się osiągnąć w tym czasie na warszawskim parkiecie. W istocie moje „zabawy” i eksperymenty z rynkiem akcyjnym zacząłem pod koniec zeszłego roku, ale dopiero miniony kwartał wydaje się bardziej […]

czytaj całość »

miniBlog

malcom.pinger.pl
23:24:40 27/03/2014
Po dluzszej przerwie, dzisiejszy wypiek chleba, mozna zaliczyc do najlepszego ;)
00:04:03 08/01/2013
Taki tu spokoj.... sialala...
23:37:56 16/09/2012
A gdzie C64?... :(
http://www.youtube.com/watch?&v=3qaF9-W2Dvg
14:45:25 15/09/2012
Moze czas znalezc jakies inne miejsce na mini-bloga? A moze dodac cos do samego devbloga... a moze czas na blipa, twittera? Bo cos tutaj zycie zamarlo...
20:00:55 01/09/2012
Powrot w blasku i chwale na MaldevBlogu ;)
11:54:50 02/06/2010
Wreszcie kilka dni odpoczynku w domku ;)
22:15:23 07/03/2010
Powrot do zycia ;)
19:32:00 04/01/2010
first day on a new job ;)
18:33:32 14/12/2009
Popularnosc jezykow programowania
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
17:54:43 02/12/2009
Moge powiedziec poki co tylko tyle ze intro i muzyka z #Paradox mi sie wybitnie podoba ;p
01:35:01 02/12/2009
Lin Xu przedstawia nowe usprawnienia optymalizacyjne w VC2k10:
http://blogs.msdn.com/vcblog/archive/2009/12/01/gl-and-pgo.aspx
13:35:46 01/12/2009
Secret #Perl Operators
http://www.catonmat.net/blog/secret-perl-operators/
15:58:58 30/11/2009
Interlocked* Win32 - ciekawe zadanie dla chetnych ;p
http://groups.google.pl/group/pl.comp.lang.c/browse_thread/thread/c4ccf09a972ed50d
11:23:06 26/11/2009
W ostatnich dniach troche moich patchy do wxWidgets sie "przeforsowalo"...
23:00:04 22/11/2009
Troche sie rozczarowalem, mialem nadzieje, ze bedzie kontynuacja watku z ostatniego odcinka Stargate Universe...
22:14:56 21/11/2009
Pwtornie motyw "Polscy chłopcy w językach obcych" w Strefa rokendrola wolna od angola na "trocjce" ;)
14:35:39 17/11/2009
"People often write less readable code because they think it will produce faster code. Unfortunately, in most cases, the code will not be faster."
Krotka prezentacja o tym co potrafia wspolczesne kompilatory (odnosnie optymalizacji):
http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf
01:10:43 17/11/2009
The Pirate Movie - swietny film z swietnym soundtrackiem, szczegolnie utwor (Song of) Victory.
Dla odmiany nieco metalowa wersja, cover Mayhayrona
http://www.youtube.com/watch?v=Ud8uAKW3U4o
00:11:46 08/11/2009
Bezstykowe karty Mifare sa bardzo wygodne w uzyciu. Gorzej jak ma sie ich kilka np. w portfelu (legitymacja, karta miejska) i chce sie jednej uzyc bez wyjmowania... co ostatnio doswiadczylem przy bramkach na WAT-cie. Zapewne przy metrze i kasownikach bedzie podobnie ;p
01:14:00 06/11/2009
Dziwny swiat, dziwni ludzie, teraz beda dublowoac wszelkie swoje "smieci" w sieci.
Moze warto zintegrowac rowniez wiekszosc for dyskusyjnych i wysylajac na jedno, wysylac na pol sieci?
23:10:46 20/10/2009
Ostatnio babralem sie z COM i XPCOM przy embedowaniu #IE i #Gecko do prostej aplikacji. Moze w xime oprze API na czyms podobnym... Latwe i przyjemne uzywanie spod C++ i C, czyli zewszad ;)
20:48:44 13/10/2009
Musialem napisac co mysle o nowym #tlen, bo nie potrafilem dluzej sie powstrzymac, przepraszam.
http://ekipa.tlen.pl/forum/index.php?showtopic=11310
10:38:53 12/10/2009
Kolumna "This Week in Boost" na "C++Next" mam nadzieje, ze bedzie ciekawa ;p
http://cpp-next.com/archive/2009/10/introducing-%e2%80%9cthis-week-in-boost%e2%80%9d/
13:53:47 06/10/2009
Polskie brzmienia w lacisnkim rocku - Amaryllis ;)
Mi szczegolnie przypadl do gustu utwor "Magnificat".
12:03:14 06/10/2009
Podazajac kierunkiem ostatniej wolnej strefy - "Polscy chłopcy w językach obcych", dzisiejsze poludnie sponsoruje Percival Schuttenbach ;)
http://www.youtube.com/watch?v=uQvvE5qNxi4
http://www.youtube.com/watch?v=Gb36Qyq8DyY
09:15:37 06/10/2009
Paskudny ten #tlen na #qt, kontrolki takie bleee, emulwoane/malowane nijak maja sie do natywnych.
18:22:56 29/09/2009
s2s @ #tlen jest online [via kaworu]
19:50:34 25/09/2009
Maly bug w wx'ach, a juz chcialem klnac na MS...
13:26:02 23/09/2009
Dla tych, ktorzy wciaz nie wiedza, ze jabber != xmpp ;p
http://forum.jabberpl.org/index.php?showtopic=7380
23:05:32 22/09/2009
Na USiu tez mnie "chca", ale zostane przy WAT, tylko 2x drozej ;p