Część I
Podstawy
Rozdział 2
Zaczynamy

Ta książka pokazuje, jak możesz tworzyć programy, które działają w środowisku
Windows 98, Windows NT 4.0 i Windows NT 5.0 Microsoftu. Takie programy są
pisane w języku programowania C i wykorzystują rodzimy interfejs programo-
_ _ wania aplikacji Windows (ang. application programming interface, API). Jak dalej
wyjaśnię, nie jest to jedyny sposób tworzenia programów, które działają w tym
środowisku. Jednak bardzo ważne jest zrozumienie API Windows, niezależnie
od tego, w czym ostatecznie będziesz pisał swój kod.
jak zapewne wiesz, Windows 98 jest najnowszym wcieleniem graficznego syste-
mu operacyjnego, który w rzeczywistości stał się standardem dla komputerów
osobistych kompatybilnych z IBM-PC wykorzystujących 32-bitowe mikroproce-
sory Intela, jak 486 oraz Pentium. Windows NT to bardziej rozbudowana, prze-
mysłowa wersja Windows, która działa zarówno na komputerach kompatybil-
nych z PC, jak też na niektórych RISC-owych stacjach roboczych.
Po tę książkę możesz sięgnąć, jeśli spełniasz trzy podstawowe warunki. Po pierw-
sze, powinieneś znać Windows z perspektywy użytkownika. Nie masz co liczyć
na napisanie aplikacji dla Windows, jeśli nie poznałeś interfejsu użytkownika.
Z tego powodu sugeruję, abyś wykonywał swoje prace prograniistyczne (oraz inne
prace) na komputerze opartym na Windows, używając aplikacji działających
w tym środowisku.
Po drugie, powinieneś znać C. Jeżeli nie znasz, programowanie Windows praw-
dopodobnie nie jest najlepszą okazją do studiowania tego języka. Radzę ci, byś
uczył się C w środowisku znakowym, oferowanym w oknie wiersza poleceń MS-
DOS-a w Windows. Programowanie Windows czasem wykorzystuje takie aspekty
C, których nie sposób pokazać w programowaniu znakowym. W takich wypad-
kach omówię je bardziej szczegółowo. Zazwyczaj jednak wystarcza znajomość
języka, w szczególności struktur i wskaźników C. Pewne obycie ze standardową
biblioteką C jest przydatne, ale niekonieczne.
Po trzecie, powinieneś zainstalować na swoim komputerze 32-bitowy kompila-
tor C i środowisko projektowe odpowiednie do pisania programów Windows.
Przyjmuję, że używasz Visual C++ 6.0 Microsoftu, który możesz nabyć osobno
lub jako część pakietu Visual Studio 6.0.
I to już wszystko. Zakładam, że nie masz żadnego doświadczenia w programo-
waniu w środowisku graficznym, takim jak Windows.
Część I: Podstawy
Środowisko Windows
Windows wymaga wprowadzenia. Łatwo zapominamy, jak bardzo pod jego wpły-
wem zmienił się sposób obsługi komputerów osobistych. Windows pokonał wy-
boistą drogę wczesnych lat dziecięcych i zdobył mocną pozycję na rynku.
Historia Windows
Wkrótce po wprowadzeniu jesienią 1981 roku komputerów IBM PC stało się ja-
sne, że dominującym systemem operacyjnym dla pecetów (i zgodnych z nimi)
będzie MS-DOS, czyli w pełnym brzmieniu Microsoft Disk Operating System (dys-
kowy system operacyjny Microsoftu). MS-DOS był minimalnym systemem ope-
racyjnym. Użytkownikom umożliwiał dostęp (za pośrednictwem interfejsu wier-
sza poleceń) do takich poleceń, jak DIR i TYPE, oraz ładowanie do pamięci pro-
gramów aplikacji w celu ich wykonania. Programistom aplikacji oferował niewiele
więcej ponad zestaw wywołań funkcji do wykonywania operacji plikowego wej-
ścia-wyjścia (I/O). Przy innych zadaniach - w szczególności przy wyświetlaniu
na ekranie tekstu i (czasami) grafiki - aplikacje wykorzystywały bezpośredni do-
stęp do sprzętu.
Na skutek ograniczeń pamięciowych i sprzętowych skomplikowane środowisko
graficzne z trudem przenikało do małych komputerów. Apple Computer zaofe-
rował alternatywę w stosunku do środowiska znakowego, wprowadzając w stycz-
niu 1983 roku swój nieudany komputer Lisa, a w styczniu 1984 roku ustanowił
standard dla środowiska graficznego za pomocą modelu Macintosh. Pomimo
malejącego znaczenia na rynku, ciągle stanowi on wzorzec, z którym porówny-
wane są inne środowiska graficzne. Wszystkie środowiska graficzne, z Macinto-
shem i Windows włącznie, korzystają z wyników pionierskich prac prowadzo-
nych w połowie lat siedemdziesiątych w ośrodku badawczo-rozwojowym Xero-
xa - Palo Alto Research Center (PARC).
W listopadzie 1983 roku (po Lisie, ale przed Macintoshem) firma Microsoft Cor-
poration zapowiedziała system Windows. Pojawił się on na rynku dwa lata póź-
niej, w listopadzie 1985 roku. Przez następne dwa lata Windows 1.0 był stopnio-
wo uzupełniany o dodatkowe sterowniki adapterów graficznych i drukarek w celu
spełnienia wymagań rynku międzynarodowego.
Windows w wersji 2.0 pojawił się w listopadzie 1987. Sporo zmieniono w inter-
fejsie użytkownika. Przede wszystkim stało się możliwe zachodzenie na siebie
okien, a nie tylko ustawianie ich sąsiadująco, jak w wersji Windows 1.0. Windows
2.0 zawierał też rozszerzenia interfejsu klawiatury i myszy, ułatwiające posługi-
wanie się menu i oknami dialogowymi.
Ówczesny Windows wymagał tylko mikroprocesora Intel 8086 lub 8088 pracują-
cego w trybie rzeczywistym, który dawał dostęp do 1 megabajta (MB) pamięci
operacyjnej. Windows/386 (który pojawił się wkrótce po wersji 2.0) wykorzysty-
wał już tryb wirtualny mikroprocesorów 386 Intela do uruchamiania w oknach
wielu programów dosowych, mających bezpośredni dostęp do zasobów sprzęto-
wych. Dla zachowania zgodności nazw przemianowano wtedy Windows 2.1 na
Windows/286.
Rozdział 1: Zaczynamy
Windows 3.0 został przedstawiony 22 maja 1990 roku. Łączył on w jeden pro-
dukt wcześniejsze wersje Windows/286 i Windows/386. Dużą zmianą w Win-
dows 3.0 było wykorzystanie 16-bitowego trybu chronionego mikroprocesorów
Intel 286, 386 i 486. Umożliwiło to samemu systemowi i jego aplikacjom dostęp
do 16 megabajtów pamięci. Całkowicie zmieniono jądro systemu uruchamiające
programy i zarządzające plikami. Windows 3.0 był pierwszą wersją Windows,
która zyskała szersze zastosowanie w domu i biurze.
Każda historia Windows musi zawierać wzmiankę o OS/2, systemie alternatyw-
nym dla DOS-a i Windows, który został opracowany przez Microsoft we współ-
pracy z IBM-em. OS/2 w wersji 1.0 (działający tylko w trybie znakowym) praco-
wał na procesorach 286 (i późniejszych) Intela, a pojawił się pod koniec 1987 roku.
Interfejs graficzny o nazwie Presentation Manager (PM) pojawił się dopiero w wersji
1.1 OS/2, w październiku 1988 roku. Pierwotnie miał on stanowić wersję Win-
dows pracującą w trybie chronionym, ale interfejs API został zmieniony do tego
stopnia, że producenci oprogramowania nie byli w stanie obsłużyć jednocześnie
obu platform.
Konflikt pomiędzy IBM-em i Microsoftem osiągnął punkt kulminacyjny we wrze-
śniu 1990 roku i drogi obu firm rozeszły się. IBM przejął OS/2, a Microsoft skon-
centrował się na Windows. Chociaż OS/2 miewa jeszcze zagorzałych zwolenni-
ków, nigdy nie osiągnął popularności choćby zbliżonej do Windows.
Wersja 3.1 Windows Microsoftu pojawiła się w kwietniu 1992 roku. Najważniej-
szymi ulepszeniami były: TrueType (skalowalne czcionki Windows), multimedia
(dźwięk i muzyka), OLE (Object Linking and Embedding) i standaryzacja podsta-
wowych okien dialogowych. Windows 3.1 działał tylko w trybie chronionym i wy-
magał procesora 286 lub 386 oraz co najmniej 1 MB pamięci.
Windows NT, wprowadzony w lipcu 1993 roku, był pierwszą wersją Windows
umożliwiającą korzystanie z trybu 32-bitowego procesorów Intela 386, 486 i Pen-
tium. Programy uruchamiane pod Windows NT mają dostęp do 32-bitowej pła-
skiej przestrzeni adresowej i używają zestawu 32-bitowych instrukcji. (O prze-
strzeni adresowej powiem więcej w dalszej części tego rozdziału). Windows NT
został zaprojektowany jako system przenośny na procesory nie-Intelowskie i działa
na wielu RISC-owych stacjach roboczych.
Windows 95 został wprowadzony w sierpniu 1995 roku. Podobnie jak Windows
NT, Windows 95 także umożliwia 32-bitowy tryb programowania procesorów
Intela 386 i późniejszych. Chociaż nie posiada niektórych cech Windows NT, ta-
kich jak wysoki poziom bezpieczeństwa i przenośność na maszyny RISC-owe,
ma jednak mniejsze wymagania sprzętowe.
Windows 98 pojawił się w czerwcu 1998 roku; zawarte w nim ulepszenia zwięk-
szają wydajność oraz umożliwiają lepszą współpracę ze sprzętem i większą inte-
grację z Internetem i WWW.
Cechy Windows
Windows 98 i Windows NT są 32-bitowymi graficznymi systemami operacyjny-
mi, które cechuje wielozadaniowość z wywłaszczaniem (ang. preemptive multita-
sking) i wielowątkowość (ang. multithreading). Windows ma graficzny interfejs
Część I: Podstawy
użytkownika (ang. graphical user interface, GUI), czasem nazywany interfejsem
wizualnym lub okienkowym środowiskiem graficznym. Podstawy GUI stworzo-
no w połowie lat siedemdziesiątych w ośrodku PARC Xeroxa na komputerach
Alto i Star w środowisku typu SmallTalk. Te prace uzyskały później większe zna-
czenie i zostały spopularyzowane przez Apple Computer i Microsoft. Chociaż
niegdyś wydawało się to dosyć kontrowersyjne, obecnie całkiem oczywiste jest
że GUI to - jak uważa Charles Simonyi z Microsoftu - "najdonioślejszy consen-
sus" przemysłu komputerów osobistych.
Wszystkie GUI używają grafiki do wyświetlania rastrowego. Grafika pozwala na
lepsze wykorzystanie obszaru ekranu, zapewnia ciekawe środowisko wizualne
dla przenoszenia informacji i możliwość uzyskania WYSIWYG (ang. zvhat you see
is what you get - otrzymasz to, co widzisz), czyli pełnej zgodności wyglądu do-
kumentu na ekranie z jego wydrukiem.
Dawniej na ekranie można było jedynie wyświetlić tekst wprowadzany przez
użytkownika z klawiatury. W nowym typie interfejsu ekran staje się dla użyt-
kownika urządzeniem wejściowym. Na ekranie pokazywane są różne obiekty
graficzne w formie ikon i urządzenia wejściowe, jak przyciski i paski przewija-
nia. Posługując się klawiaturą (lub urządzeniami wskazującymi typu mysz) użyt-
kownik może bezpośrednio manipulować tymi obiektami na ekranie. Obiekty
graficzne mogą być przeciągane, przyciski - przyciskane, a suwaki pasków prze-
wijania - przesuwane.
Interakcja między użytkownikiem i programem staje się bliższa. Zamiast jedno-
stronnego przesyłania informacji z klawiatury do programu w celu wyświetlenia
na ekranie, użytkownik bezpośrednio oddziałuje na obiekty na ekranie, a te od-
powiadają na jego polecenia i ukierunkowują kolejne kroki.
Nikt nie lubi spędzać długich godzin na nauce obsługi komputera lub nowego
programu. Windows wychodzi nam naprzeciw, gdyż wszystkie aplikacje mają
zbliżony wygląd na ekranie i opierają swoje działanie na podobnych zasadach.
Program zajmuje zwykle na ekranie prostokątny obszar, zwany oknem. Każde
okno jest identyfikowane przez pasek tytułu. Większość funkcji programu jest do-
stępna w jego menu. Użytkownik może zobaczyć informację, która nie mieści się
na ekranie, wykorzystując paski przewijania. Niektóre pozycje menu wywołują
okna dialogowe, w których użytkownik może wprowadzić dodatkowe informa-
cje. Jedno z okien dialogowych (używane do otwierania pliku) można znaleźć w
każdym większym programie. To okno dialogowe wygląda tak samo (albo pra-
wie tak samo) we wszystkich programach i prawie zawsze jest wywoływane przez
tę samą opcję menu.
Ponieważ wiesz już, jak używać programów Windows, łatwo możesz nauczyć
się dalszych funkcji. Menu i okna dialogowe pozwalają użytkownikowi ekspery-
mentować z nowym programem i odkrywać jego możliwości. Większość progra-
mów Windows może być obsługiwana na dwa sposoby: z klawiatury i za pomo-
cą myszy. Chociaż większość funkcji programów jest dostępna z klawiatury, to
posługiwanie się myszą jest zdecydowanie wygodniejsze.
Z perspektywy programisty spójny interfejs użytkownika wynika z użycia wbu-
dowanych procedur do konstrukcji menu i okien dialogowych. Wszystkie menu
Rozdział 1: Zaczynamy 7
obsługuje się za pomocą klawiatury i myszy w ten sam sposób, ponieważ to
Windows, a nie aplikacja odpowiada za ich działanie.
Aby ułatwić jednoczesne korzystanie z wielu programów i wymianę informacji
między nimi, Windows oferuje wielozadaniowość. Wiele programów może działać
i wyświetlać wyniki w tym samym czasie. Każdy program posiada na ekranie
swoje okno. Użytkownik może przesuwać okna po ekranie, zmieniać ich rozmia-
ry, przełączać się między różnymi programami i przenosić dane z jednego pro-
gramu do drugiego. Ponieważ te okna przypominają trochę papiery rozłożone
na pulpicie biurka (zanim, oczywiście, biurka zostały opanowane przez kompu-
tery), Windows czasem używa metafory "pulpit" (ang. desktop) dla widoku wie-
lu programów na ekranie.
Wcześniejsze wersje Windows używały tzw. wielozadaniowości bez wywłaszcza-
nia (ang. nonpreemptive multitasking). Oznaczało to, że Windows nie używał ze-
gara systemowego do dzielenia czasu procesora między uruchomione programy.
Musiały one dobrowolnie oddać sterowanie, aby inne programy mogły działać.
W Windows NT i Windows 98 występuje wielozadaniowość z wywłaszczaniem
i programy mogą same dzielić się na wiele wątków, które wykonują się prawie
jednocześnie.
System operacyjny nie może realizować wielozadaniowości, jeśli nie zarządza
pamięcią. W miarę jak uruchamiane są nowe programy, a stare się kończą, pa-
mięć ulega fragmentacji. System musi konsolidować wolną pamięć. Wymaga to
przemieszczania bloków kodu i danych w pamięci.
Nawet Windows 1.0, pracujący na procesorze 8088, potrafił w ten sposób zarzą-
dzać pamięcią. Mając na uwadze ograniczenia trybu rzeczywistego, możemy
uznać to za majstersztyk autorów systemu. Tak oto ograniczenie pamięci archi-
tektury PC do 640 kilobajtów (KB) zostało skutecznie przełamane bez dokłada-
nia dodatkowej pamięci. Ale Microsoft poszedł dalej: Windows 2.0 dawał aplika-
cjom dostęp do pamięci rozszerzonej (EMS), a Windows 3.0 pracował w trybie
chronionym dając aplikacjom dostęp do 16 MB pamięci rozszerzonej. Windows
NT i Windows 98, jako 32-bitowe systemy operacyjne z płaską przestrzenią adre-
sową, przełamały te ograniczenia.
Programy pracujące w Windows mogą współużytkować procedury, które znaj-
dują się w innych plikach nazywanych bibliotekami dynamicznymi (ang. dyna-
miclink libraries, DLL). Windows zawiera mechanizm łączący procedury w DLL-
ach z programem podczas jego pracy. Sam system zasadniczo jest także zbiorem
takich bibliotek.
Windows to interfejs graficzny i programy windowsowe mogą w pełni wykorzy-
stywać grafikę i sformatowany tekst na ekranie i w drukarce. Interfejs graficzny
nie tylko jest bardziej atrakcyjny, ale może dostarczyć użytkownikowi więcej in-
formacji.
Programy pisane w środowisku Windows nie mają bezpośredniego dostępu do
kart graficznych i drukarek. W zamian Windows zawiera język programowania
grafiki, nazywany GDI (ang. Graphics Display Interface), pozwalający na łatwe
wyświetlanie grafiki i sformatowanego tekstu. Windows wirtualizuje urządze-
nia wyświetlające. Program powinien działać na każdej karcie graficznej i każdej
8 Część I: Podstawy
drukarce, dla których dostępne są sterowniki Windows. Nie potrzebuje sam okre-
ślać rodzaju sprzętu dołączonego do systemu.
Stworzenie dla pecetów interfejsu graficznego, niezależnego od urządzeń, nie
było łatwym zadaniem dla projektantów Windows. Z założenia PC był systemem
o otwartej architekturze. Wielu niezależnych wytwórców opracowywało więc
urządzenia peryferyjne. Chociaż powstało kilka standardów, konwencjonalne pro-
gramy MS-DOS-a musiały indywidualnie obsługiwać wiele różnych konfiguracji
sprzętowych. Najczęściej dotyczyło to programów do obróbki tekstu, sprzeda-
wanych z kilkoma dyskietkami małych plików, z których każdy służył do obsłu-
gi konkretnego typu drukarki. Programy windowsowe nie wymagają takich ste-
rowników, ponieważ stanowią one część systemu operacyjnego.
Łączenie dynamiczne
Zasada pracy Windows oparta jest na koncepcji łączenia dynamicznego (ang.
dynamic linking). Windows dostarcza mnóstwa wywołań funkcji, które aplikacja
może wykorzystać przy realizacji interfejsu użytkownika i wyświetlaniu tekstu
i grafiki. Funkcje te zostały umieszczone w dynamicznych bibliotekach, inaczej
DLL-ach. Są to pliki o rozszerzeniach .DLL lub czasami .EXE, przeważnie znaj-
dujące się w podkatalogu \WINDOWS\SYSTEM Windows 98 oraz podkatalo-
gach \WINNT\SYSTEM i \WINNT\SYSTEM32 Windows NT.
Dawniej duża część Windows była zrealizowana w postaci zaledwie trzech bi-
bliotek dynamicznych. Reprezentowały one trzy podstawowe podsystemy Win-
dows, czyli Kernel, User i GDI. Ilość podsystemów wzrosła w ostatnich wersjach
Windows, ale większość funkcji, których używa typowy program, znajduje się
nadal w tych trzech modułach. Kernel (aktualnie zrealizowany w 16-bitowym
KRNL386.EXE i 32-bitowym KERNEL32.DLL) obsługuje wszystkie funkcje jądra
systemu operacyjnego, jak zarządzanie pamięcią, plikowe I/O i uruchamianie
zadań. User (zrealizowany w 16-bitowym USER.EXE i 32-bitowym USER32.DLL)
obsługuje interfejs użytkownika i całą logikę okien. GDI (zrealizowany w 16-bi-
towym GDI.EXE i 32-bitowym GDI32.DLL) jest interfejsem urządzeń graficznych,
pozwalającym programowi wyświetlić tekst i grafikę na ekranie lub wydruko-
wać na drukarce.
Windows 98 oferuje aplikacjom kilka tysięcy funkcji do wykorzystania. Każda
funkcja posiada opisową nazwę, na przykład CreateWindozu. Ta funkcja (jak mo-
żesz się spodziewać) tworzy okno twojego programu. Wszystkie funkcje Windows,
których może używać aplikacja, są zadeklarowane w plikach nagłówkowych.
W swoim programie będziesz korzystał z wywołań funkcji Windows praktycz-
nie w ten sam sposób, w jaki posługujesz się funkcjami bibliotecznymi C, takimi
jak strlen. Podstawową różnicą jest to, że kod maszynowy dla funkcji bibliotecz-
nych C jest włączony do kodu twojego programu, podczas gdy kod funkcji Win-
dows jest umieszczony na zewnątrz twojego programu, w DLL-ach.
Kiedy uruchamiasz program windowsowy, łączy się on z Windows poprzez proces
zwany łączeniem dynamicznym (ang. dynamic linking). Plik EXE w Windows za-
wiera odnośniki do różnych bibliotek dynamicznych i do znajdujących się w nich
funkcji wykorzystywanych w programie. Gdy program jest ładowany do pamię-
Rozdział 1: Zaczynamy 9
ci, odwołania programu są odwzorowane na wejścia funkcji w bibliotekach, któ-
re są w miarę potrzeb ładowane do pamięci.
Kiedy łączysz program, by stworzyć plik wykonywalny, musisz połączyć go ze
specjalnymi bibliotekami importowymi, dostarczanymi razem ze środowiskiem
programistycznym. Te biblioteki importowe zawierają nazwy bibliotek dynamicz-
nych i informację o wszystkich wywołaniach funkcji Windows. Konsolidator (ina-
czej linker) używa tej informacji do zbudowania tabeli w pliku EXE, którą Win-
dows wykorzystuje do odwzorowania wywołań na funkcje Windows podczas ła-
dowania programu.
Opcje programowania Windows
Ta książka zawiera dużo przykładowych programów, które pozwolą zilustrować różne
techniki programowania w Windows. Są one napisane w C i używają czystego API
Windows. Jest to klasyczny sposób programowania w Windows. Tak pisaliśmy pro-
gramy dla Windows 1.0 w 1985 roku, i tak można to robić również dzisiaj.
API i modele pamięci
Z punktu widzenia programisty system operacyjny jest definiowany przez swoje
API. Obejmuje ono wszystkie wywołania funkcji, które może wykorzystywać apli-
kacja oraz definicje powiązanych typów danych i struktur. W środowisku Windows
API wymusza pewną architekturę programu, którą wyjaśnimy w następnych roz-
działach.
W zasadzie API Windows niewiele się zmieniło od czasów Windows 1.0. Dla pro-
gramisty, który ma do czynienia z Windows 98, kod źródłowy programów dla
Windows 1.0 będzie wyglądał znajomo. API zostało tylko znacznie rozszerzone.
Windows 1.0 zawierał mniej niż 450 funkcji; obecnie są ich tysiące.
Największą zmianę w API Windows i jego składni spowodowało przejście z ar-
chitektury 16-bitowej na 32-bitową. Wersje Windows od 1.0 do 3.1 posługiwały
się pamięcią segmentową trybu 16-bitowego procesorów Intel 8086, 8088 i 286.
Tryb ten jest w dalszym ciągu używany dla zapewnienia kompatybilności w 32-
bitowych procesorach Intela, począwszy od 386. Wielkość rejestru procesora w
tym trybie wynosiła 16 bitów, więc typ danych int w C zawierał także 16 bitów.
W segmentowym modelu pamięci adresy pamięci składały się z dwóch części:
16-bitowego wskaźnika segmentu (ang. segment pointer) i 16-bitowego wskaźni-
ka przesunięcia (ang. offset pointer). Z perspektywy programisty było to bardzo
skomplikowane i wymagało rozróżniania wskaźników long lub far (zawierających
segment i przesunięcie adresu) i wskaźników short lub near, zawierających jedy-
nie przesunięcie adresu (segment adresu był domyślny).
Już w Windows NT i Windows 95 skorzystano z 32-bitowego płaskiego modelu
pamięci, używając 32-bitowych trybów procesorów Intela 386, 486 i Pentium. Typ
danych int w C został rozszerzony do 32 bitów. Programy napisane dla 32-bito-
wych wersji Windows używają prostych, 32-bitowych wartości wskaźników, które
adresują płaską, liniową przestrzeń adresową.
10 Część I: Podstawy
API dla 16 bitowych wersji Windows (od 1.0 do 3.1) jest znane teraz jako Winló.
API dla 32-bitowych wersji Windows (Windows 95, Windows 98 i wszystkich
wersji Windows NT) nazywane jest Win32. Przy przejściu z Winl6 do Win32 wiele
funkcji pozostało takich samych, ale niektóre musiały być rozszerzone lub zmie-
nione. Na przykład współrzędne graficzne zmieniły się z 16-bitowych w Win16
na 32-bitowe w Win32. Ponadto niektóre funkcje Win16 zwracały dwie współ-
rzędne, spakowane w 32-bitową liczbę całkowitą. Takie rozwiązanie było niemoż-
liwe w Win32, więc dodano nowe funkcje, które działały nieco inaczej.
Wszystkie 32-bitowe wersje Windows zawierają zarówno API Win16 zapewniają-
ce kompatybilność ze starymi aplikacjami, jak i API Win32 do uruchamiania no-
wych aplikacji. Ciekawe, że cały ten proces działa inaczej w Windows NT niż w
Windows 95 i Windows 98. W Windows NT wywołania funkcji Win16 przechodzą
przez warstwę translacji i są zamieniane na wywołania funkcji Win32, obsługiwa-
nych przez system operacyjny. W Windows 95 i Windows 98 proces przebiega od-
wrotnie: wywołania funkcji Win32 przechodzą przez warstwę translacji i są zamie-
niane na wywołania funkcji Win16, obsługiwanych przez system operacyjny.
Przez pewien czas istniały dwa różne (przynajmniej z nazwy) zestawy API Win-
dows. Win32s, gdzie "s" oznaczało podzbiór (ang. subset) pozwalało programi-
ście na pisanie 32-bitowych aplikacji dla Windows 3.1. To API zawierało tylko
32-bitowe wersje funkcji już zrealizowanych w Win16. API Windows 95 było na-
zywane przez pewien czas Win32c, gdzie "c" oznaczało kompatybilność (ang.
compatibility), ale to określenie przestało być używane.
Teraz przyjmuje się, że zarówno Windows NT, jak i Windows 98 umożliwiają ko-
rzystanie z API Win32. Jednocześnie każdy z tych systemów operacyjnych ma
pewne cechy własne niedostępne w drugim. Ponieważ jednak przeważają funk-
cje wspólne, możliwe jest pisanie programów, które działają w obu systemach.
Uważa się, że te dwa produkty staną się kiedyś jednym systemem operacyjnym.
Opcje języka programowania
Używanie C i czystego API nie jest wprawdzie jedynym sposobem pisania pro-
gramów Windows 98, pozwala jednak na najwszechstronniejsze i najefektywniej-
sze wykorzystanie cech tego systemu. Programy wykonywalne są względnie małe
i nie wymagają do pracy zewnętrznych bibliotek (poza DLL-ami samych Win-
dows, oczywiście). A co najważniejsze, poznanie API umożliwi ci głębsze zrozu-
mienie budowy wewnętrznej Windows, niezależnie od tego, jak ostatecznie bę-
dziesz pisał aplikacje dla tego systemu.
Sądzę, że nauka klasycznego programowania Windows jest ważna dla każdego pro-
gramisty, nie zmuszam cię jednak do stosowania C i API w każdej aplikacji Win-
dows. Wielu programistów - szczególnie opracowujących programy do wewnętrz-
nego użytku firmy lub programujących hobbystycznnie w domu - docenia prosto-
tę takich środowisk projektowych, jak Visual Basic Microsoftu czy Delphi Borlanda
(które jest obiektowym dialektem Pascala). Te środowiska pozwalają programiście
skupić uwagę na interfejsie użytkownika i dołączają kod z obiektami interfejsu użyt-
kownika. Jeśli chcesz nauczyć się Visual Basica, możesz skorzystać z innych ksią-
żek wydawnictwa Microsoft Press, na przykład Learn Visual Basic Now (1996), na-
pisanej przez Michaela Halvorsona.
Rozdział 1: Zaczynamy 11
Wśród zawodowych programistów - zwłaszcza piszących aplikacje handlowe -
szczególnie popularną alternatywą stał się w ostatnich latach Visual C++ Micro-
softu z biblioteką klas MFC (Microsoft Foundation Class Library). MFC hermetyzu-
je wiele trudniejszych zagadnień programowania Windows w zbiorze klas C++.
Podręcznikiem MFC jest książka Jeffa Prosise'a Programming Windows with MFC
Second Edition (Microsoft Press, 1999).
Rosnąca popularność Internetu i WWW spowodowała ostatnio duże zainteresowa-
nie językiem Java firmy Sun Microsystems. Jest to język niezależny od procesora,
inspirowany przez C++ i zawierający pakiet narzędziowy do pisania aplikacji gra-
ficznych, które mogą działać w wielu systemach operacyjnych. Dobrą książką Mi-
crosoft Press o J++ Microsoftu (środowisku projektowym Javy Microsoftu) jest Pro-
gramming Visual j++ 6.0 (1999), napisana przez Stephena R. Davisa.
Trudno jest wskazać ten jedyny, właściwy sposób pisania aplikacji dla Windows.
Prawdopodobnie sam rodzaj pisanej aplikacji określi narzędzia. Ale poznanie API
umożliwi ci wgląd w pracę Windows, która nie zależy od używanej przez ciebie
metody kodowania. Windows to złożony system; umieszczenie warstwy opro-
gramowania ponad API nie eliminuje złożoności - pozwala tylko na jej ukrycie.
Prędzej czy później ta złożoność da znać o sobie. Znajomość API ułatwi ci przy-
wrócenie poprawnego działania aplikacji.
Każda dodatkowa warstwa oprogramowania ponad API ogranicza cię do podzbioru
jego pełnej funkcjonalności. Na przykład możesz stwierdzić, że Visual Basic jest
idealny dla twojej aplikacji, z wyjątkiem tego, że nie pozwala na kilka istotnych
prac pomocniczych. W tym wypadku powinieneś użyć wywołań czystego API. API
definiuje wszechświat, w którym istniejemy jako programiści Windows. Nic nie
otworzy przed tobą takich możliwości, jak bezpośrednie wykorzystanie API.
Szczególnie problematyczne jest zastosowanie MFC. Chociaż bardzo upraszcza
wykonywanie wielu zadań (takich jak OLE), zwykle musiałem męczyć się z inny-
mi jego cechami (takimi jak architektura dokument/widok), aby zmusić je do dzia-
łania po mojej myśli. MFC nie stało się panaceum dla programowania Windows,
chociaż wiele osób miało nadzieję, że tak będzie. Mało kto uzna je za przykład do-
brego projektu obiektowego. Programiści MFC, chcąc zrozumieć, co się dzieje w
używanych przez nich klasach, zmuszeni są często zaglądać do kodu źródłowego.
Zrozumienie kodu źródłowego to jedna z korzyści nauczenia się API Windows.
Środowisko programistyczne
W tej książce przyjąłem, że używasz Visual C++ 6.0 Microsoftu, który jest do-
stępny w wersji Standard, Professional i Enterprise. Tańsza wersja Standard wy-
starczy do uruchomienia programów z tej książki. Visual C++ jest także częścią
Visual Studio 6.0.
Pakiet Visual C++ Microsoftu zawiera nie tylko kompilator C i inne narzędzia
i pliki konieczne do kompilowania i łączenia programów Windows. Zawiera także
Visual C++ Developer Studio - środowisko, w którym możesz prowadzić edycję
swojego kodu źródłowego, z łatwością tworzyć takie zasoby, jak ikony i okna dia-
logowe oraz kompilować, uruchamiać i testować swoje programy.
12 Część I: Podstawy
Jeśli używasz Visual C++ 5.0, powinieneś pobrać nowe wersje plików nagłówko-
wych i bibliotek importowych dla Windows 98 i Windows NT 5.0. Są one dostęp-
ne na stronie WWW Microsoftu. Połącz się z http://www.microsoft.com/msdn/ i
wybierz Downloads, a potem Platform SDK (Software Development Kit). Będziesz
miał możliwość pobrać i zainstalować zaktualizowane pliki w dowolnie wybra-
nym katalogu. Aby zmusić Microsoft Developer Studio do szukania plików w tym
katalogu, wybierz Options z menu Tools i przejdź na kartę Directories.
Cząstka msdn w adresie URL strony Microsoftu oznacza "Microsoft Developer
Network". Jest to program, który zapewnia projektantom często aktualizowane
CD-ROM-y z informacjami, potrzebnymi w zaawansowanych pracach programi-
stycznych. Prawdopodobnie będziesz chciał zaprenumerować MSDN, aby nie
ściągać tych informacji ze strony Microsoftu.
Dokumentacja API
Ta książka nie zastępuje oficjalnej dokumentacji API Windows. Dokumentacja ta
nie jest już dostępna w formie drukowanej; teraz występuje tylko na CD-ROM-
ach i w Internecie.
Instalując Visual C++ 6.0, uzyskasz system pomocy bezpośredniej, zawierający do-
kumentację API. Możesz zaktualizować tę dokumentację, prenumerując MSDN lub
używając sieciowego systemu pomocy bezpośredniej Microsoftu. Zacznij od połą-
czenia się z http://www.microsoft.com/msdn/ i wybierz MSDN Library Online.
W Visual C++ 6.0 wybierz Contents z menu Help, aby wywołać okno MSDN. Do-
kumentacja API ma strukturę drzewa. Znajdź część oznaczoną etykietą Platform
SDK. Cała dokumentacja cytowana w książce pochodzi z tej części. Lokalizacja
dokumentacji jest opisana za pomocą kolejnych poziomów oddzielonych ukośni-
kami, poczynając od poziomu Platform SDK. (Wiem, że Platform SDK jest bardzo
małą częścią całości wiedzy w MSDN, ale zapewniam, że jest to podstawa progra-
mowania Windows). Na przykład, szukając dokumentacji na temat używania
myszy, zobacz /Platform SDK/User Interface Services/Llser Input/Mouse Input.
Jak wspomniałem wcześniej, większość Windows jest podzielona na podsyste-
my: Kernel, User i GDI. Opis funkcji Kernela znajdziesz w /Platform SDK/Win-
dows Base Services, opis funkcji podsystemu User w /Platform SDK/User Interface
Services, a GDI jest opisane w /Platform SDK/Graphics and Multimedia Services/GDI.
Pierwszy program windowsowy
Już czas zacząć pisać programy. Rozpoczniemy od obejrzenia bardzo krótkiego
programu Windows i porównania go z programem trybu znakowego. Pomoże
nam to oswoić się ze środowiskiem programistycznym i przejść przez proces two-
rzenia i kompilacji programu.
Tryb znakowy
Ulubioną książką programistów jest The C Programming Language (Prentice Hall,
1978 i 1988); polskie tłumaczenia kolejnych wydań to: Język C, WNT 1988 oraz
Rozdział 1: Zaczynamy 13
język ANSI C, WNT 1997, napisana przez Briana W. Kernighana i Dennisa M.
Ritchiego, często nazywana w skrócie K&R. Rozdział 1 tej książki zaczyna się pro-
gramem w C, który wyświetla słowa "hello, world".
Oto program, jaki znajduje się na stronie 6 pierwszego wydania The C Program-
ming Language:
main ()
ł
printf ("hello, world\n") ;
Dawniej programiści C używali funkcji bibliotecznych, takich jak printf, bez
uprzedniego ich deklarowania. Ale teraz mamy lata dziewięćdziesiąte i chcemy,
żeby nasze kompilatory miały szansę oznaczania błędów w naszym kodzie. Oto
poprawiony kod z drugiego wydania K&R:
ipinclude
main ()
l
printf ("hello, world\n") ;
l
Ten program nie jest tak mały, jak się wydaje. Na pewno skompiluje się i będzie
dobrze działał, ale w dzisiejszych czasach wielu programistów woli jawnie okre-
ślić wartość zwracaną przez funkcję main, bo ANSI C określa, że zwraca ona
wartość:
#include
int main ()
(
printf ("hello, world\n") ;
return 0 ;
Moglibyśmy jeszcze wydłużyć ten program, włączając argumenty funkcji main,
ale zostawmy go takim - z instrukcją include, punktem startowy'programu, wy-
wołaniem funkcji bibliotecznej i instrukcją return.
Odpowiednik windowsowy
Odpowiednik windowsowy programu "hello, world" zawiera dokładnie takie
same składniki, jak wersja znakowa. Posiada instrukcję include, punkt startowy
programu, wywołanie funkcji i instrukcję powrotu. Oto ten program:
``/*
HelloMsg.c -- Wyświetla "Hello, Windows 98!"
w oknie komunikatów
(c) Charles Petzold, 1998
*/
#include
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
14 Część I: Podstawy
MessageBox (NULL, TEXT ("Hello, Windows 98!"),TEXT ("NelloMsg"), 0) ;
return 0 ;
Zanim zacznę omawiać ten program, prześledźmy proces tworzenia programu
w Visual C++ Developer Studio.
Najpierw z menu File wybierz opcję New. W oknie dialogowym New wybierz
kartę Projects. Na tej karcie wybierz opcję Win32 Application, a w polu Location
wprowadź podkatalog. W polu Project Name wpisz nazwę projektu, którą w tym
przypadku jest HelloMsg. Będzie to także nazwa podkatalogu dla katalogu wpi-
sanego w polu Location. Pole opcji Create New Workspace powinno być zazna-
czone. W częśei Platforms powinno być wybrane Win32. Naciśnij OK.
Pojawi się okno dialogowe Win32 Application - Step 1 Of 1. Wskaż, że chcesz
utworzyć Empty Project i wciśnij przycisk Finish.
Wybierz ponownie New z menu File. W oknie dialogowym New zaznacz kartę
Files. Wybierz C++ Source Files. Powinno być zaznaczone pole opcji Add to Pro-
ject i wskazane HelloMsg. Wpisz HelloMsg.c w polu File Name. Wybierz OK.
Teraz możesz wpisać podany powyżej plik HELLOMSG.C. Albo możesz wybrać
menu Insert i opcję File As Text, aby skopiować zawartość tego pliku z towarzy-
szącego książce CD-ROM-u.
Strukturalnie HELLOMSG.C jest identyczny z programem "hello, world" K&R.
Plik nagłówkowy STDIO.H został zastąpiony przez WINDOWS.H, punkt starto-
wy programu main przez WinMain, a funkcja biblioteki wykonawczej C printf przez
funkcję MessageBox API Windows. Jednak program zawiera też dużo nowych
rzeczy, włącznie z dziwnie wyglądającymi identyfikatorami pisanymi wielkimi
literami.
Omówimy wszystko po kolei.
Pliki nagłówkowe
HELLOMSG.C zaczyna się instrukcją preprocesora, którą znajdziesz na począt-
ku w zasadzie każdego programu Windows pisanego w C:
�include
WINDOWS.H jest głównym plikiem nagłówkowym, który włącza inne pliki na-
główkowe Windows, a niektóre z nich włączają jeszcze inne pliki nagłówkowe.
Podstawowe i najważniejsze z nich to:
ł WINDEF.H podstawowe definicje typów
ł WINNT.H definicje typów dla unikodu
ł WINBASE.H funkcje Kernela
ł WINUSER.H funkcje interfejsu użytkownika
ł WINGDI.H funkcje interfejsu urządzeń graficznych.
Te pliki nagłówkowe definiują wszystkie typy danych, wywołania funkcji, struk-
tury danych i stałe Windows. Są one istotną częścią dokumentacji Windows.
Do przeszukiwania ich możesz użyć opcji Find In Files z menu Edit w Visual C++
Rozdział 1: Zaczynamy 15
Developer Studio. Możesz także otworzyć te pliki nagłówkowe w Developer Stu-
dio i przeszukać je ręcznie.
Punkt startowy programu
Tak jak punktem startowym programu w C jest funkcja main, tak punktem star-
towym programu windowsowego jest funkcja WinMain, która zawsze wygląda
w ten sposób:
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance.
PSTR szCmdLine, int iCmdShow)
Punkt startowy jest opisany w /Platform SDIC/�Iser Interface Services/Windowing/
Windows/Window Reference/Window Functions. Jest on zadeklarowany w WINBA-
SE.H w następujący sposób (zachowane zostało łamanie linii):
int
WINAPI
WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nShowCmd
):
Zauważ, że zrobiłem kilka drobnych zmian w HELLOMSG.C. Trzeci parametr
jest zdefiniowany jako LPSTR w WINBASE.H, a ja zdefiniowałem go jako PSTR.
Oba te typy danych są zdefiniowane w WINNT.H jako wskaźniki do łańcucha
znaków. Przedrostek LP oznacza "daleki wskaźnik" (ang. long pointer) i jest za-
szłością z 16 bitowych Windows.
Zmieniłem także nazwy dwóch parametrów z deklaracji WinMain; wiele progra-
mów Windows używa do nazywania zmiennych tzw. notacji węgierskiej. W tym
schemacie nazwy zmiennych są poprzedzane krótkim przedrostkiem oznaczają-
cym typ zmiennej. Szerzej omówię tę koncepcję w rozdziale 3. Na razie zapamię-
taj, że przedrostek i reprezentuje int, a sz oznacza "łańcuch znaków zakończony
zerem" (ang. string terminated with a zero).
Funkcja WinMain jest zadeklarowana jako funkcja zwracająca int. Identyfikator
WINAPI jest zdefiniowany w WINDEEH jako:
ildefine WINAPI �stdcall
Ta instrukcja określa konwencję wywoływania funkcji, związaną z rodzajem kodu
maszynowego, generowanego w celu umieszczenia na stosie argumentów wy-
wołania funkcji. Większość wywołań funkcji Windows jest zadeklarowana jako
WINAPI.
Pierwszy parametr WinMain jest czasem nazywany uchwytem realizacji (ang.
instance handle). W programowaniu Windows uchwyt to po prostu liczba, której
aplikacja używa do identyfikacji czegoś. W tym wypadku uchwyt jednoznacznie
identyfikuje program. Jest on wymagany jako argument przy niektórych innych
wywołaniach funkcji Windows. Gdy we wcześniejszych wersjach Windows uru-
chamiałeś jednocześnie kilka kopii danego programu, tworzyłeś wiele realizacji
(ang. multiple instances) programu. Wszystkie realizacje tej samej aplikacji korzy-
stają z tego samego kodu i pamięci tylko do odczytu (zwykle takich zasobów, jak
16 Część I: Podstawy
menu i wzorce okien dialogowych). Program jest w stanie określić, czy działają
jego inne realizacje przez sprawdzenie parametru hPrevInstance (ang. prevoins in-
stance-poprzednia realizacja). Może wtedy opuścić część działań pomocniczych
i pobrać dane z poprzedniej realizacji do własnego obszaru danych.
W 32-bitowej wersji Windows zrezygnowano z tej koncepcji. Drugi parametr
WinMain ma zawsze wartość NULL (zdefiniowaną jako 0).
Trzecim parametrem WinMain jest wiersz poleceń użyty do uruchomienia pro-
gramu. Niektóre aplikacje Windows wykorzystują go do ładowania do pamięci
plików w czasie uruchamiania programu. Czwarty parametr WinMain wskazuje,
w jakiej postaci program powinien się zgłaszać po uruchomieniu w oknie stan-
dardowym - czy maksymalnie wypełniającym ekran, czy też w postaci zmini-
malizowanej do ikony na pasku listy zadań. Zastosowanie tego parametru omó-
wimy w rozdziale 3.
Funkcja MessageBox
Funkcja MessageBox ma służyć do wyświetlania krótkich komunikatów. Małe okno
wyświetlane przez MessageBox jest nazywane oknem dialogowym, chociaż nie
jest ono aż tak uniwersalne.
Pierwszym argumentem MessageBox jest zwykle uchwyt okna. Co to oznacza, do-
wiemy się w rozdziale 3. Drugim argumentem jest tekst, który ukazuje się w oknie
komunikatu, a trzecim argumentem -napis, który występuje na pasku tytułu tego
okna. W HELLMSG.C każdy z tych napisów jest dołączony w postaci makra TEXT.
Zwykle nie musisz tak robić, ale umieszczenie wszystkich napisów w makrach
TEXT pomoże ci przy ewentualnej konwersji programu do zestawu znaków uni-
kod. Omówię to bardziej szczegółowo w rozdziale 2.
Czwartym argumentem MessageBox może być połączenie stałych, zaczynające się
od przedrostka MB-, a zdefiniowane w WINUSER.H. Możesz wybierać jedną stałą
z pierwszego zestawu, by wskazać, jakie przyciski powinny ukazać się w oknie
dialogowym:
�tdefine MB_OK 0x00000000L
ttdefine MB_OKCANCEL 0x00000001L
�idefine MB�ABORTRETRYIGNORE 0x00000002L
�idefine MB YESNOCANCEL 0x00000003L
��define MB_YESNO 0x00000004L
��define MB RETRYCANCEL 0x00000005L
Jeśli w HELLOMSG ustawisz czwarty argument na 0, pojawi się tylko przycisk
OK. Możesz użyć operatora OR ( I ) z C do połączenia jednej z wymienionych
powyżej stałych ze stałą wskazującą na przycisk domyślny:
��define MB_DEFBUTTON1 0x00000000L
ttdefine MB_DEFBUTTON2 0x00000100L
tkdefine MB_DEFBUTTON3 0x00000200L
��define MB�DEFBUTTON4 0x00000300L
Możesz także użyć stałej, która wskazuje na wystąpienie ikony w oknie dialogo-
wym:
Rozdział 1: Zaczynamy
4ldefine MB�ICONHAND 0x00000010L
��define MB_ICONOUESTION 0x00000020L
�ldefine MB_ICONEXCLAMATION 0x00000030L
ildefine MB ICONASTERISK 0x00000040L
Niektóre z tych ikon mają alternatywne nazwy:
ildefine MB_ICONWARNING MB_ICONEXCLAMATION
�ldefine MB_ICONERROR MB_ICONHAND
��define MB ICONINFORMATION MB_ICONASTERISK
��define MB ICONSTOP MB�ICONHAND
Jest jeszcze kilka innych stałych MB , ale sprawdź je samodzielnie w pliku na-
główkowym lub w dokumentacji w /Platform SDK/Llser Interface Services/Windo-
zving/Dialog Boxes/Dialog Box Reference/Dialog Box Funetions.
W tym programie funkcja MessageBox zwraca wartość 1; bardziej poprawne jest
stwierdzenie, że zwraca IDOK, które jest zdefiniowane w WINUSER.H jako równe
1. Zależnie od obecności w oknie dialogowym innych przycisków, funkcja Mes-
sageBox może także zwracać IDYES, IDNO, IDCANCEL, IDABORT, IDRETRY albo
IDIGNORE.
Czy ten mały program Windows jest rzeczywiście odpowiednikiem programu
"hello, world" z K&R? Możesz mieć wątpliwości, ponieważ funkcja MessageBox
nie ma możliwości takiego formatowania tekstu, jak funkcja printf w "hello, world".
Ale w następnym rozdziale dowiesz się, jak napisać wersję MessageBox, która
wykonuje formatowanie w stylu printf
Kompilowanie, łączenie i uruchamianie
Gdy już będziesz gotowy do skompilowania HELLOMSG, możesz wybrać Build
Hellomsg.exe z menu Build albo nacisnąć [F7], albo wybrać ikonę Build z paska
narzędzi Build. (Możesz zobaczyć tę ikonę w menu Build. Jeśli pasek narzędzi
Build nie jest aktualnie wyświetlany, wybierz Customize z menu Tools, a następ-
nie kartę Toolbars. Wybierz Build albo Build MiniBar).
Możesz także wybrać Execute Hellomsg.exe z menu Build albo [Ctrl+F5], lub klik-
nąć na ikonę Execute Program (wygląda jak czerwony wykrzyknik) z paska na-
rzędzi Build. Pokaże się okno z pytaniem, czy chcesz skompilować program.
Podczas fazy kompilacji, kompilator tworzy zazwyczaj plik OBJ (obiektowy) z pli-
ku źródłowego C. Podczas fazy łączenia konsolidator łączy pliki OBJ z plikami
LIB (bibliotekami), aby stworzyć plik EXE (wykonywalny). Możesz zobaczyć li-
stę plików bibliotecznych, wybierając Settings z karty Project i klikając kartę Link.
Zobaczysz między innymi KERNEL32.LIB, USER32.LIB i GDI32.LIB. Są to biblio-
teki importowe dla trzech głównych podsystemów Windows. Zawierają one na-
zwy bibliotek dynamicznych i informacje odnośników, umieszczane w pliku EXE.
Windows używa tej informacji do odwzorowania wywołań programu na funkcje
w bibliotekach dynamicznych KERNEL32.LIB, USER32.LIB i GDI32.LIB.
W Visual C++ Developer Studio możesz kompilować i łączyć programy w róż-
nych konfiguracjach. Domyślnie są one nazwane Debug i Release. Pliki wykony-
walne są umieszczone w podkatalogach o nazwach konfiguracji. W konfiguracji
Debug do pliku EXE zostaje dodana informacja, która umożliwia poprawianie
programu i śledzenie kodu źródłowego programu podczas wykonywania.
18 Część I: Podstawy
Jeśli wolisz posługiwać się wierszem poleceń, dołączony CD-ROM zawiera pliki
MAK (make) dla wszystkich przykładowych programów. (Możesz zmusić Deve-
loper Studio do tworzenia plików MAK, wybierając Options z menu Tools i za-
znaczając odpowiednie pole opcji na karcie Build). Będziesz musiał uruchomić
VCVARS32.BAT, znajdujący się w podkatalogu BIN w Developer Studio, aby
ustawić zmienne środowiskowe. Aby uruchomić pliki make z wiersza poleceń,
przejdź do katalogu HELLOMSG i wpisz:
NMAKE /f HelloMsg.mak CFG="HelloMsg - Win32 Debug"
albo
NMAKE /f HelloMsg.mak CFG="HelloMsg - Win32 Debug"
Następnie możesz uruchomić z wiersza poleceń plik EXE, pisząc:
DEBUG\HELLOMSG
lub
RELEASE\HELLOMSG
W plikach projektów na dołączonym do książki CD-ROM-ie wprowadziłem jed-
ną zmianę do domyślnej konfiguracji Debug. W oknie dialogowym Project Set-
tings, po wybraniu karty C/C++, w polu Preprocessor Definitions, zdefiniowa-
łem identyfikator UNICODE. Znacznie więcej na ten temat powiem w następ-
nym rozdziale.