Drogi Fiże, wielki generale Kenobi, czcigodny profesorze Kibonte...


> ktos moze udzielic jakiejs porady (glownie uwzgledniajace to co
> powiedzialem: bez dodatkowych libow i rownolegly dzwiek najlepiej
> z mala latencja) - zna chocby jakies dobre materialy do
> dokumentacji itp?


Zdaje się, że święcie wierzysz w:
1) boskość WinApi (szybkość, funkcjonalność, poprawność koncepcyjną)
2) nie omylność M$ (zwłaszcza jego WinApi jako dzieła więczącego rozwój
systemów operacyjnych)
3) wyższość programowania proceduralnego (język C)

Podczas gdy nawet M$ nie wierzy w 1) i 2) ani nawet w 3):

ad 1) wkrótce po premierze Windows 95 okazało się, że do gier jest
potrzebne coś lepszego niż WinApi - więc szybko dokręcono zestaw
bibliotek DirectX. Nie wiem czemu unikasz DirectX skoro (OIMW) są to
biblioteki C obecne we wszystkich windach od 1998 roku. OIMW DirectX
góruje zarówno szybkością jak i funkcjonalnością nad WinApi. OIMW w
nowszych windach pod WinApi śmiga DirectX.

ad 2) Brnięcie w zaparte w technologie M$ może być uzasadniane a)
stabilnością i b) funkcjonalnością oferowaną przez windę które
przewyższają konkurencję. I faktycznie przewaga M$ Windows jest ogromna
i raczej nie zagrożona. Tym nie mniej ograniczanie się do jednego
systemu to brnięcie w kanał. Można zrozumieć też pogląd że nie warto się
zajmować systemami które nie rokują jako alternatywa wobec Windows (na
ile poważne jest Kubuntu: ostatnie wyszło w kwietniu a do września nie
działały sterowniki NVidia Geforce 2MX (chyba dla pozostałych Geforców
też nie działały bo widziałem podobne nagłówki na liście błędów) bo
jakieś tam ABI nie grało i dopuki odpowiednia ilość użytkowników nie
potwierdziła tego błędu nikt się tym nie zajmował). Dlatego moim zdaniem
rozsądną strategią obronną przed dominacją M$ i przed brnięciem w nie
rokujące systemy są biblioteki wieloplatformowe. Konkretnie mam na
myśli, że zamiast WinApi czy DirectX raczej bym brnął w SDL lub OpenGL i
OpenAL (jeśli już się trzymać czystego C i robienia dem czy gier).

ad 3) Pewną zaletą czystego C jest to, że jest większa świadomość jakie
funkcje się wywołuje, oraz łatwość wywołania dowolnej metody. Jednak pod
względem architektury programu stosowanie C to praktycznie ciągła pogoń
za cechami C++. Plik źródłowy *.c opisuje zawartość pliku *.o w którym
oprócz funkcji często znajdują się również "zmienne globalne" konieczne
by przechowywać dane robocze programu. Więc czym jest taki plik *.o? No,
jest on po prostu obiektem typu singleton. I cały program to seria tych
singletonów zakodowanych w języku C. Więc wybierając język C nie ma
ucieczki przed obiektówką jeśli chodzi o architekturę programu. Dlatego
moim zdaniem naiwnością jest wypieranie się obiektówki rzekomo przez
kodowanie w czystym C. Natomiast łatwość wywołania jakiejś metody ma
znaczenie tam gdzie projekt programu jest zły i trzeba stosować triki.
Przyznam, że to jest problem z bibliotekami w C++ - kiedy nie wszystko
mogę zrobić po swojemu, albo zgodnie z jakimś najnowszym trendem. Tym
nie mniej te problemy raczej nie przekonają mnie by wyprzeć się
stringów, kontenerów i uogólnionych algorytmów oraz reszty oferowanej
przez takie biblioteki jak Qt.

W sumie ja mogę zrozumieć dlaczego ktoś brnie w C i WinApi. Może być
tak, że z projektowaniem programów nie najlepiej sobie radzi i go to nie
interesuje i chce poćwiczyć WinApi (zwłaszcza gdy wymaga tego pracodawca
czy uczelnia). W tym wypadku - ok - jest to świadoma decyzja.