Rozdział 1.
Specyfikacja interfejsu
sterownika sieciowego
Dogłębnie
Specyfikacja interfejsu sterownika sieciowego (NDIS) to dokument opracowany przez firmy
Microsoft i 3Com. Interfejsy sterowników urządzeń systemu Windows, napisane według tej
specyfikacji, umożliwiają pojedynczej karcie sieciowej (NIC) wiązanie wielu protokołów
sieciowych za pomocą interfejsu NDIS. Biblioteka interfejsów sterowników urządzeń, znana jako
obwoluta NDIS, pozwala dowolnemu typowi karty sieciowej, dla dowolnego obsługiwanego
nośnika, wiązać się z dowolnym lub ze wszystkimi spośród protokołów pracy sieciowej (TCP/IP,
NWLink, czy NetBEUI) zainstalowanych na komputerze. Kolejność, w jakiej dana karta sieciowa
wykorzystuje owe protokoły, zwana kolejnością powiązań, może być modyfikowana, przy czym
danej karcie sieciowej można przydzielić więcej niż jeden numer IP.
Przed pojawieniem się specyfikacji NDIS kwestie zgodności pomiędzy różnymi implementacjami
pracy sieciowej przysparzały problemów związanych z wykonywaniem niektórych jej
podstawowych funkcji (na przykład implementowanie dwóch protokołów na tej samej karcie
sieciowej). Rozwiązaniem tradycyjnym było zastosowanie dwóch sterowników, ale w momencie
kiedy jeden ze sterowników przejmował kontrolę nad płytą, wykazywał on tendencję do
przerywania lub zakłócania pracy drugiego. Potrzebny był pojedynczy sterownik, który mógłby
sterować kartą i który te dwa protokoły mogłyby współużytkować. By wyjść naprzeciw owej
potrzebie, w maju 1988 wydano dokument NDIS.
Interfejs NDIS
W skład interfejsu NDIS wchodzi menedżer protokołów, który przyjmuje żądania ze strony
sterownika sieciowego (w warstwie transportu) i przekazuje te żądania do karty sieciowej (w
warstwie łącza danych). W ten sposób może ze sobą współistnieć wiele sterowników sieciowych
zgodnych z NDIS. Poza tym, jeżeli dany komputer posiada wiele podłączeń i zawiera wiele kart
sieciowych, interfejs NDIS może wyznaczać trasę ruchu do prawidłowej karty.
NDIS umożliwia dostęp do usług sieciowych w warstwie łącza danych. Programiści, którzy muszą
stosować swoje własne implementacje protokołu sieciowego, mogą programować zgodnie z tą
specyfikacją i wykorzystywać zgodne z NDIS sterowniki sprzętu sieciowego dostarczane przez
różnych producentów. Uwalnia to programistę protokołów od konieczności pisania osobnych
programów dla każdego typu kart sieciowych. Rozwiązuje to również problemy zgodności w
przypadku komputerów korzystających z wielu protokołów. Wszystkie składniki oprogramowania
sieciowego, które są zgodne z wytycznymi NDIS, to sterowniki. Sterowniki te można
sklasyfikować w dwóch typach:
" sterowniki protokołów,
" sterowniki kontroli dostępu do nośnika (MAC).
Rysunek 1.1 przedstawia koncepcję architektoniczną interfejsu i obwoluty NDIS.
NetBEUI NWLink TCP/IP
Powiązania
Obwoluta NDIS NDIS
Sterownik karty sieciowej Sterownik karty sieciowej
Karta sieciowa Karta sieciowa
Rysunek 1.1. Architektura NDIS
Edycje specyfikacji NDIS
Edycje specyfikacji NDIS były raczej budowane na poprzednich specyfikacjach, niż je
zastępowały; NDIS4 oraz NDIS4.1 zawierają wszystkie funkcje NDIS3.1, jak również własne
funkcje dodatkowe, z kolei NDIS5 rozszerza NDIS4. W związku z tym, aby uzyskać pełną
specyfikację dla NDIS5, należy przyjrzeć się również NDIS3.1, NDIS4 oraz NDIS4.1.
NDIS3.1
NDIS3.1 zapewnia obsługę podstawowych usług, które umożliwiają modułowi protokołu
wysyłanie pakietów poprzez urządzenie sieciowe i dają możliwość zawiadamiania tego modułu o
przychodzących pakietach otrzymywanych przez urządzenie sieciowe.
NDIS4
NDIS4 dodaje kilka nowych funkcji do NDIS3.1. Funkcje te wymienione są poniżej.
Obsługa danych pozapasmowych
W sygnalizacji pozapasmowej wraz z sygnałem informacyjnym przesyłany jest dodatkowy sygnał,
służący do monitorowania i kontroli transmisji. Korzysta on z oddzielnego kanału sieci lokalnej
(LAN) i pozwala urządzeniom zarządzania siecią na dostęp do urządzeń LAN nawet kiedy sam
LAN nie funkcjonuje, co zapewnia dodatkową warstwę elestyczności. Obsługa sygnalizacji
pozapasmowej jest konieczna w przypadku komputera osobistego emisji.
Wskazówka: Komputer osobisty emisji (Broadcast PC) pozwala komputerowi importować i
przetwarzać strumienie multimedialne pochodzące z całej gamy z
ródeł, łącznie z kablem,
systemem bezpośredniej transmisji satelitarnej (DBS) oraz cyfrowym dyskiem wideo (DVD).
Urządzenia, które obsługują komputer osobisty emisji powinny być zgodne z wymogami wizji i
emisji Microsoft PC 99, które są dostępne pod adresem www.microsoft.com.
Rozszerzenie nośników bezprzewodowych sieci rozległej
Nośniki bezprzewodowe mogą korzystać z transmisji w podczerwieni lub transmisji
ultradz
więkowej. Jednakże w przypadku sieci rozległych, jako metodę komunikacji stosuje się
bezprzewodową transmisję mikrofalową o bardzo wysokiej częstotliwości. Jest ona zazwyczaj
wykorzystywana przy komunikacji satelitarnej.
Szybkie wysyłanie i odbieranie pakietów
Możliwość wysyłania danych poprzez szybkie nośniki, takie jak tryb transferu asynchronicznego
(ATM), zapewnia istotny wzrost wydajności.
Szybkie rozszerzenie nośników IrDA
Stowarzyszenie ds. przesyłania danych przy użyciu podczerwieni (IrDA) to grupa producentów
urządzeń, publikująca standardy transmisji danych za pomocą fal podczerwonych.
Bezprzewodową transmisję IrDA można, przykładowo, implementować pomiędzy komputerem
typu laptop a drukarką w tym samym pomieszczeniu, o ile pomiędzy urządzeniami występuje
wyraz
na linia widzenia.
Wykrywanie nośników
Wykrywanie nośników pozwala karcie sieciowej (NIC) informować stos protokołu o zdarzeniach
przyłączenia i odłączenia nośników. Protokół TCP/IP systemu Windows 2000 wykorzystuje te
informacje do wspomagania automatycznej konfiguracji. Kiedy w przypadku poprzednich
implementacji Windows zdarzyło się, że dany komputer został przeniesiony do innej podsieci bez
przeładowania, albo też został w ogóle zdjęty z sieci, to stos protokołu nie otrzymywał żadnych
wskazań dotyczących tego zdarzenia. W związku z tym parametry konfiguracji stawały się
nieaktualne, czy też przedawnione. Obsługa wykrywania nośników pozwala stosowi protokołu
reagować na zdarzenia i unieważniać przedawnione parametry. Jeżeli komputer działający w
systemie Windows 2000 zostanie wyłączony z sieci, to TCP/IP unieważni związane z nim
parametry po upływie okresu wygaśnięcia (obecnie 20 sekund).
Filtr wszystkich pakietów lokalnych
Filtr wszystkich pakietów lokalnych zapobiega monopolizowaniu procesora (CPU) przez Monitor
sieci. Monitor sieci jest omówiony szczegółowo w rozdziale 2.
Wskazówka: NDIS komunikuje się ze sprzętem sieciowym za pomocą sterowników miniportu.
Sprzęt zyskuje dostęp do interfejsu NDIS poprzez przeprowadzenie wywołania funkcji
sterownika miniportu; przy użyciu tej samej metody odbiera i transmituje informacje. Szczegóły
dotyczące sterowników miniportu oraz wywołań funkcji znajdują się w zestawie do rozbudowy
sterowników systemu Windows 2000 (DDK), który został omówiony w dalszej części
niniejszego rozdziału.
NDIS4.1
NDIS4.1 (znany również jako CoNDIS) umożliwia dostęp surowy do nośników zorientowanych
połączeniowo. Został on zaprojektowany, aby ułatwić opracowywanie i testowanie sterowników
miniportu ATM.
NDIS5
NDIS5 znacząco rozszerza zestaw dostępnych funkcji. Ponieważ zestaw możliwości NDIS5 jest
tematem głównym niniejszego rozdziału, jest on szczegółowo omówiony w następnym
podrozdziale. W związku z tym tutaj nowe funkcje są jedynie wypunktowane w celu póz
niejszego
omówienia:
" zarządzanie zasilaniem,
" obsługa Plug and Play (PnP),
" obsługa instrumentacji zarządzania systemu Windows (WMI),
" obsługa formatu informacji dotyczących pojedynczego urządzenia (INF),
" miniport zdeserializowany,
" mechanizmy rozładowywania zadań,
" rozszerzenie nośnika emisji,
" NDIS zorientowany połączeniowo,
" obsługa jakości usługi (QoS),
" obsługa sterownika pośredniego.
Zestaw możliwości NDIS5
NDIS5 dodaje do NDIS3.1, NDIS4 oraz NDIS4.1 istotną liczbę nowych funkcji. Microsoft określa
zadania tych nowych funkcji w następujący sposób:
" zwiększenie łatwości użycia i ograniczenie całkowitego kosztu eksploatacji (TCO);
" poprawa wydajności;
" udostępnienie nowych typów nośników, usług oraz aplikacji;
" poprawa elastyczności architektury sterowników.
Uwaga! Większość nowych funkcji w NDIS5 dostępnych jest tylko przy zastosowaniu modelu
sterownika miniportu i nie są one obsługiwane w przypadku pełnych sterowników MAC ani
starszych sterowników miniportu.
Interfejs NDIS5 pozwala wielu sterownikom protokołów różnych typów tworzyć powiązania z
pojedynczym sterownikiem karty sieciowej, a pojedynczemu protokołowi tworzyć powiązania z
wieloma sterownikami kart sieciowych. Sterowniki zgodne z NDIS5 są dostępne dla szerokiej
gamy kart sieciowych, od wielu różnych producentów. Dokument NDIS5 opisuje mechanizm
zwielokrotniania, dzięki któremu udało się to osiągnąć. Powiązania można przeglądać lub
zmieniać z interfejsu użytkownika połączeń sieciowych systemu Windows, w sposób opisany w
podrozdziale rozwiązań natychmiastowych tego rozdziału.
System Windows 2000 TCP/IP zapewnia obsługę następujących nośników:
" Ethernet,
" protokół dostępu do podsieci (SNAP) 802.3,
" Fiber Distributed Data Interface (FDDI),
" Token Ring (802.5),
" ATM,
" ARCNET,
" nośniki sieci rozległej (WAN) przełączanego obwodu wirtualnego, takie jak cyfrowa sieć
z integracją usług (ISDN), X.25, łącza dostępu telefonicznego lub wydzielone łącza
asynchroniczne (zauważ, że niektóre karty ATM obsługują emulację LAN i ukazują się
stosowi protokołu jako typ nośnika, jak, na przykład, Ethernet).
Wskazówka: Emulacja LAN zapewnia przezroczystą obsługę starych protokołów, jak również
mechanizmy wydajniejszego tłumaczenia określonych adresów starych protokołów, na przykład
adresów IP, na ich własne formaty adresów.
Zarządzanie zasilaniem
Zarządzanie zasilaniem wymaga zintegrowanego, ogólnosystemowego podejścia do
wykorzystania i oszczędzania energii. Systemy komputerowe, które zapewniają sprzętową i
programową obsługę zarządzania zasilaniem posiadają następujące zalety:
" Minimalne opóz
nienia przy uruchamianiu i zamykaniu  system może być uśpiony w
stanie niskiego zasilania, z którego może wznowić pracę bez całkowitego przeładowania.
" Większa ogólna wydajność energetyczna i wydłużony czas pracy akumulatora 
zasilanie jest dostarczane do urządzeń tylko wtedy, gdy te dostarczają usług
użytkownikowi. Jeżeli dane urządzenie nie jest używane, może ono być wyłączane i
włączane na żądanie.
" Cichsza praca  sprzęt i oprogramowanie mogą zarządzać obciążeniem prądem
elektrycznym oraz obciążeniem termicznym, w rezultacie czego komputery są prawie
niesłyszalne w trybie uśpienia.
Zarządzanie zasilaniem działa na dwóch poziomach, z których jeden odnosi się do
indywidualnych urządzeń, natomiast drugi do systemu jako całości. Jeżeli wszystkie sterowniki w
systemie obsługują zarządzanie zasilaniem, to menedżer zasilania (część jądra systemu
operacyjnego [OS]) może zarządzać zużyciem energii na zasadzie ogólnosystemowej,
wykorzystując nie tylko stany pełnego włączenia i pełnego wyłączenia, lecz także różne pośrednie
stany uśpienia systemu. Stare sterowniki, napisane zanim system operacyjny zaczął obsługiwać
zarządzanie zasilaniem, dalej pracują tak jak wcześniej. Jednakże systemy, które posiadają stare
sterowniki, nie mogą wchodzić w żaden z pośrednich stanów uśpienia i pracują tylko w stanach
pełnego włączenia lub pełnego wyłączenia.
Zarządzanie zasilaniem urządzeń odnosi się do pojedynczych urządzeń. Sterownik, który
obsługuje zarządzanie zasilaniem może włączać i wyłączać swoje urządzenie według potrzeb.
Urządzenia, które posiadają odpowiednie możliwości sprzętowe, mogą wchodzić w stan
pośredniego zasilania. Obecność starych sterowników nie wpływa na zdolność nowszych
sterowników do zarządzania zasilaniem swoich urządzeń.
Zarządzanie zasilaniem NDIS jest wymagane do sieciowego zarządzania energią oraz do
uaktywniania sieciowego. Implementacja NDIS5 oparta jest na specyfikacji wzorcowej
zarządzania zasilaniem dla kategorii urządzeń sieciowych, która określa zachowanie urządzeń
sieciowych w odniesieniu do zarządzania zasilaniem, a w szczególności w odniesieniu do
wzorcowej specyfikacji zarządzania zasilaniem dla kategorii urządzeń sieciowych, zdefiniowanej
dla inicjatywy architektury OnNow. Celem owej inicjatywy jest wyeliminowanie opóz
nień przy
uruchamianiu i zamykaniu, ograniczenie zużycia energii poprzez wyłączanie bezczynnych
urządzeń oraz pozwalanie komputerowi, by  spał kiedy jest bezczynny, a na żądanie szybko się
 budził .
Specyfikacja OnNow określa cztery stany zasilania urządzeń, przedstawione w tabeli 1.1.
Wskazówka: Specyfikacja wzorcowa zarządzania zasilaniem dla kategorii urządzeń sieciowych
dostępna jest pod adresem www.microsoft.com/hwdev/onnow/.
Tabela 1.1. Stany zasilania urządzeń określone przez OnNow
Stan Opis
Stan zasilania D3 Możliwe, że urządzenie zostało w pełni pozbawione zasilania. Kiedy
urządzenie znajduje się w tym stanie, jego kontekst zostaje zapisany przez
sprzęt. Podczas przechodzenia ze stanu zasilania D3 w stan zasilania D0
każdy ze sterowników związanych z tym urządzeniem musi ponownie
zainicjować lub przywrócić urządzenie do w pełni włączonego trybu pracy.
W stanie zasilania D3 całkowity czas przywrócenia urządzenia jest
najdłuższy, ponieważ może być konieczna ponowna całkowita inicjalizacja
urządzenia.
Stan zasilania D2 Zużycie energii jest równe lub większe niż w stanie D3. Wykorzystanie
energii jest ograniczone do minimalnego poziomu, na którym
przywrócenie stanu urządzenia jest wciąż możliwe. Kontekst urządzenia
może być zachowywany lub może ulegać utracie w zależności od definicji
dla poszczególnych kategorii. Funkcja sterownika urządzenia w tym stanie
jest również zgodna z definicjami dla poszczególnych kategorii. Czas
wymagany do przywrócenia urządzenia ze stanu D2 do stanu D0 jest
równy lub dłuższy, niż czas wznowienia ze stanu D1. Faktyczne czasy
reakcji są zgodne z definicjami dla poszczególnych kategorii.
Stan zasilania D1 Zużycie energii jest równe lub większe niż w stanie D2, ale mniejsze niż w
stanie D0. Kontekst urządzenia może być zachowywany lub może ulegać
utracie w zależności od definicji dla poszczególnych kategorii. Czas
wymagany do przywrócenia urządzenia ze stanu D1 do stanu D0 jest
krótszy, niż czas wznowienia ze stanu D2 (o ile to tylko możliwe). W tym
stanie minimalizacja opóz
nienia w przywracaniu urządzenia jest
priorytetem wyższym, niż zużycie energii. Faktyczne czasy reakcji są
zgodne z definicjami dla poszczególnych kategorii.
Stan zasilania D0 Jest to stan przyjęty jako stan najwyższego poziomu zużycia energii.
Urządzenie jest całkowicie aktywne i reagujące. Sterownik działa
normalnie.
NDIS ustala, że karty sieciowe mogą obniżać zasilanie kiedy albo użytkownik, albo system zażąda
zmiany poziomu zasilania. Na przykład system może zażądać zmiany poziomu zasilania w
związku z brakiem aktywności klawiatury lub myszy albo też użytkownik może zechcieć
wprowadzić komputer w stan uśpienia. Odłączenie kabla sieciowego również może inicjować
żądanie wyłączenia pod warunkiem, że karta sieciowa obsługuje tę funkcję. W tym przypadku,
jako że odłączenie może być wynikiem tymczasowych zmian w okablowaniu sieci, a nie
odłączenia kabla od samego urządzenia sieciowego, system czeka przez dający się skonfigurować
okres czasu, zanim wyłączy kartę sieciową.
Zasady zarządzania zasilaniem NDIS opierają się na braku aktywności sieci. Oznacza to, że
wszystkie stosowne składniki sieci muszą wyrazić zgodę na żądanie, zanim można będzie
wyłączyć daną kartę. Jeżeli w obrębie sieci są jakieś aktywne sesje lub otwarte pliki, to żądanie
wyłączenia może zostać odrzucone przez którykolwiek lub wszystkie zaangażowane składniki,
Komputer może również zostać wzbudzony ze stanu niższego zasilania. Sygnał do uaktywnienia
może być spowodowany:
" wykryciem zmiany w stanie łącza sieciowego ( na przykład ponownego podłączenia
kabla),
" otrzymaniem ramki uaktywnienia sieci,
" otrzymaniem pakietu magicznego.
Kiedy inicjalizowany jest sterownik miniportu, NDIS sprawdza możliwości miniportu, aby
określić, czy obsługuje on pakiet magiczny, dopasowanie do wzorca czy uaktywnienie po zmianie
łącza, jak również po to, aby określić najniższy konieczny stan zasilania w przypadku każdej z
metod uaktywniania. Następnie protokoły sieciowe sprawdzają możliwości miniportu. Protokół
konfiguruje zasady uaktywniania w momencie uruchamiania, wykorzystując identyfikatory
obiektów (OID-ów), takie jak Włącz uaktywnianie, Ustaw wzorzec pakietu, Usuń
wzorzec pakietu.
Wskazówka: Szczegóły dotyczące OID-ów są dostępne w zestawie Windows 2000 DDK, który
został omówiony w dalszej części niniejszego rozdziału.
Protokół TCP/IP systemu Windows 2000 rejestruje następujące wzorce pakietów przy inicjalizacji
miniportu:
" skierowany pakiet IP,
" emisja ARP dla adresu IP stacji,
" emisja NetBIOS przez TCP/IP dla przypisanej nazwy komputera danej stacji.
Zarządzanie zasilaniem oraz Plug and Play (PnP) to główne funkcje Windows 2000 z punktu
widzenia programisty sterowników. (Patrz: paragraf Plug and Play). Prawie każdy składnik
systemu, który jest związany ze sterownikami, został zmodyfikowany tak, aby wchodził w
interakcję z menedżerem PnP i menedżerem zasilania systemu Windows 2000. Biblioteka NDIS5
zapewnia obsługę PnP i zarządzania zasilaniem dla wszystkich sterowników sieciowych, które
komunikują się z NDIS lub poprzez NDIS  łącznie z miniportami kart sieciowych, pośrednimi
sterownikami NDIS oraz protokołami NDIS  tak jak to czynią dostarczane przez system
sterowniki portu wideo dla miniportów wideo i sterowników monitora.
O ile to możliwe, sterowniki Windows 2000 powinny obsługiwać zarówno PnP, jak i zarządzanie
zasilaniem. Pomimo iż system Windows 2000 w dalszym ciągu obsługuje stare sterowniki,
obsługa sterowników dla PnP i zarządzania zasilaniem rozszerza potencjalny rynek dla urządzeń
peryferyjnych.
Plug and Play
Obsługa sprzętu PnP oraz oprogramowania PnP umożliwia komputerowi rozpoznawanie i
przystosowywanie się do zmian w konfiguracji sprzętowej przy niewielkiej ingerencji, lub wręcz
bez ingerencji ze strony użytkownika. Użytkownik może dodawać urządzenia i usuwać urządzenia
z komputera bez konieczności ręcznej rekonfiguracji i nie posiadając szczegółowej wiedzy na
temat sprzętu komputerowego. Z pomocą PnP użytkownik może, przykładowo, dokować
komputer przenośny oraz używać klawiatury, myszy i monitora stacji bazowej bez potrzeby
ręcznej zmiany konfiguracji.
Jeżeli chodzi o implementację NDIS, to obsługa PnP systemu Windows 2000 wzorowana jest na
obsłudze PnP systemu Windows 95. Z punktu widzenia użytkownika wygląda ona tak, jak
obsługa PnP systemu Windows 98 (która jest również oparta na modelu Windows 95), ale jest to
raczej funkcja biblioteki PnP, niż NDIS. Obsługa PnP jest przezroczysta dla sterowników
miniportu. Po zidentyfikowaniu karty sieciowej PnP następuje zainstalowanie, załadowanie i
powiązanie miniportu. Po usunięciu karty sieciowej powiązanie miniportu zostaje zniesione, po
czym następuje zamknięcie i rozładowanie miniportu. Główny wpływ obsługi PnP na stos
protokołu jest taki, że karty sieciowe mogą dochodzić i odchodzić w dowolnym momencie.
PnP posiada następujące możliwości i funkcje:
" Dynamiczne rozpoznawanie zainstalowanego sprzętu. Zawiera się w tym wstępna
instalacja systemu, rozpoznanie wszelkich zmian sprzętu statycznego, jakie mają miejsce
pomiędzy rozruchami, a także reakcja na zdarzenia uruchomienia sprzętu, takie jak
zadokowanie, wydokowanie oraz włożenie lub wyjęcie kart.
" Uproszczona konfiguracja sprzętu, łącznie z dynamiczną aktywacją sprzętu,
przyznawaniem dostępu do zasobów, ładowaniem sterowników sprzętowych oraz
montażem napędu.
" Obsługa uproszczonej konfiguracji sprzętu oraz poszczególnych magistral i innych
standardów sprzętowych, które ułatwiają automatyczne i dynamiczne rozpoznawanie
sprzętu. W skład obsługiwanych standardów wchodzi architektura zgodna ze standardami
branżowymi (ISA) PnP, architektura magistrali kanału peryferyjnego (PCI), standard
Międzynarodowego Stowarzyszenia Producentów Kart Pamięci Komputerów Osobistych
(PCMCIA), karta-magistrala karty PC, uniwersalna magistrala szeregowa (USB) oraz
IEEE 1394 (standard Firewire Instytutu Inżynierów Elektryków i Elektroników).
" Infrastruktura PnP, mająca na celu wspomaganie tworzenia nowych sterowników
urządzeń. W jej skład w chodzą interfejsy INF, interfejsy programowania aplikacji (API),
powiadomienia trybu jądra oraz interfejsy wykonawcze.
" Mechanizmy, które umożliwiają aplikacjom użytkownika odkrywanie zmian w
środowisku sprzętowym, dzięki czemu mogą one podejmować właściwe działania.
Rysunek 1.2 przedstawia składniki oprogramowania, które obsługują PnP.
Wskazówka: Jeżeli aktualnie piszesz sterowniki urządzeń, lub masz takie plany, to powinieneś
być świadomy, że tylko pozycja DriverEntry() powinna być ustawiona na init. Cała reszta
kodu inicjalizacji powinna być ustawiona na page, ponieważ może zostać wykorzystana po
inicjalizacji systemu. Skorzystaj ze standardowych słów kluczowych określonych w zestawie
Windows 2000 DDK.
Menedżer PnP
Menedżer PnP jest podzielony na dwie części: menedżer PnP trybu jądra oraz menedżer PnP
trybu użytkownika. Menedżer PnP trybu jądra wchodzi w interakcję z systemem operacyjnym w
celu konfiguracji, zarządzania oraz utrzymania urządzeń. Menedżer PnP trybu użytkownika
wchodzi w interakcję ze składnikami ustawień trybu użytkownika w celu konfiguracji oraz
instalacji urządzeń. Menedżer PnP trybu użytkownika rejestruje również aplikacje w celu
zawiadamiania o zmianach urządzeń i zawiadamia daną aplikację, kiedy wystąpi zdarzenie
urządzenia.
Aplikacje Usługi Win32
Menedżer PnP Składniki ustawień
Tryb użytkownika Pliki INF, pliki Cat, rejestr
Tryb jądra
Mechanizm wykonawczy
Menedżer PnP Menedżer I/O Menedżer zasilania
Sterowniki PnP WDM
Rysunek 1.2. Składniki Plug and Play
Sterowniki PnP obsługują urządzenia fizyczne, logiczne i wirtualne w komputerze. Sterownik
modelu sterowników systemu Windows (WDM) obsługuje urządzenia zarówno w systemie
Windows 2000, jak i Windows 98. Sterowniki PnP WDM komunikują się z menedżerem PnP i
innymi składnikami jądra poprzez interfejsy API oraz pakiety żądań wejścia-wyjścia (IRP).
Zestaw Windows DDK daje pełny opis interfejsów API i pakietów IRP. Zwróć uwagę, że
komputer działający w systemie Windows 2000 może posiadać pewne sterowniki PnP, które nie
obsługują WDM.
Wskazówka: Jeżeli konstruujesz lub instalujesz sterowniki, upewnij się, że obsługują one PnP i
zarządzanie zasilaniem. Jeżeli dany sterownik nie obsługuje PnP i zarządzania zasilaniem, to
ogranicza obsługę PnP i zarządzania zasilaniem systemu jako całości.
Obsługa PnP
Urządzenia, które nie posiadają sprzętowej obsługi sprzętu PnP wciąż mogą korzystać z pewnych
funkcji PnP, jeżeli sterowniki PnP je obsługują. Na przykład karta dz
więkowa zgodna ze
standardami branżowymi (ISA) może być ręcznie instalowana, a następnie traktowana jak
urządzenie PnP przez odpowiedni sterownik PnP. Z drugiej strony, jeżeli ów sterownik nie
obsługuje PnP, to sprzęt nie będzie mógł korzystać z żadnych funkcji PnP, niezależnie od tego czy
jest zgodny z PnP, czy nie.
Stare sterowniki, napisane zanim system operacyjny zaczął obsługiwać PnP, będą nadal działać
tak jak wcześniej, bez funkcji PnP. Jeżeli dokonujesz zakupu urządzeń sprzętowych zgodnych z
PnP, to powinien on być wyposażony w sterowniki PnP. Wszystkie nowe sterowniki powinny
zapewniać obsługę PnP.
Instrumentacja zarządzania systemu Windows (WMI)
Instrumentacja zarządzania systemu Windows (WMI) zapewnia kontrolę nad miniportami NDIS i
związanymi z nimi kartami, która jest zgodna z zarządzaniem przedsiębiorstwem opartym na sieci
WWW (WBEM). Pozwala to aplikacjom wykonywać następujące funkcje:
" wyliczać klasy urządzeń, urządzenia przypadające na klasę oraz właściwości
przypadające na urządzenie;
" sprawdzać i ustawiać właściwości przypadające na urządzenie;
" rejestrować w celu powiadamiania zdarzeniowego o stosownych właściwościach
(właściwości WMI przekładają się na identyfikatory obiektów NDIS).
W momencie inicjalizacji NDIS sprawdza sterowniki miniportu pod kątem właściwości
specyficznych dla urządzeń. NDIS rejestruje te właściwości za pomocą WMI. W skład tych
właściwości wchodzą standardowe właściwości wszystkich sterowników miniportu (określone
jako obowiązkowe identyfikatory obiektów zestawu NDIS DDK) oraz wszelkie właściwości
specyficzne dla urządzeń dostarczane przez sterownik miniportu.
WMI jest usługą trybu jądra, wykorzystywaną przez sterowniki w celu udostępnienia danych
pomiarowych oraz instrumentacyjnych aplikacjom trybu użytkownika. Sterownik może stosować
mechanizmy WMI, aby publikować informacje, zezwalać na konfigurację swojego urządzenia
oraz dostarczać powiadomień o zdarzeniach i rejestracji zdarzeń. Sterownik, który obsługuje WMI
posiada następujące zalety:
" Może sprawić, iż dane definiowane przez sterownik oraz zdarzenia będą dostępne dla
aplikacji trybu użytkownika. Każda aplikacja będąca klientem WMI może mieć dostęp do
tych danych. W momencie inicjalizacji sterownik rejestruje swoje globalnie unikatowe
identyfikatory (GUID) za pomocą usługi WMI, która następnie dodaje bloki danych
sterownika do bazy danych menedżera obiektów modelu wspólnych informacji
(CIMOM), udostępniając bloki sterowników aplikacjom klienta WMI. Kiedy dany klient
WMI uzyskuje dostęp do danego bloku danych, składnik jądra WMI wysyła do
sterownika kwerendę z żądaniem jego danych. Format danych definiowanych przez
sterownik jest przezroczysty dla WMI, która po prostu przekazuje dane do klienta trybu
użytkownika.
" Może określać pozycje odczyt-zapis, które mogą być ustawiane przez klienty WMI. Kiedy
dany użytkownik klienta WMI ustawia wartość pozycji odczyt-zapis, składnik jądra WMI
wysyła do sterownika żądanie ustawienia zawierające nową wartość. Pozwala to
aplikacjom trybu użytkownika konfigurować dane urządzenie poprzez standardowy
interfejs, zamiast poprzez specjalną aplikację panelu sterowania.
" Może powiadamiać aplikacje trybu użytkownika o zdarzeniach definiowanych przez
sterownik bez wymagania, aby aplikacja odpytywała, albo wysyłała pakiety IRP. Pewne
bloki w obrębie sterownika są definiowane jako bloki zdarzeń. Definiują one zdarzenia,
które sterownik może wysyłać. Kiedy użytkownik klienta zażąda powiadomienia o
danym zdarzeniu, składnik jądra WMI wysyła do sterownika żądanie uruchomienia
zdarzeń. Po uruchomieniu zdarzenia sterownik wysyła blok zdarzenia do WMI przy
każdym wystąpieniu tego zdarzenia, do momentu gdy WMI wyśle żądanie wyłączenia
zdarzeń. WMI routuje blok zdarzeń do wszystkich użytkowników, którzy zażądali
powiadomienia o tym zdarzeniu,
" Zmniejsza narzut sterownika poprzez zbieranie i wysyłanie tylko żądanych danych do
pojedynczego z
ródła. Kiedy sterownik zarejestruje swoje dane i bloki zdarzeń, musi
dostarczać dane i zdarzenia tylko wtedy, kiedy użytkownicy ich zażądają. Sterownik
może zaprzestać gromadzenia danych, kiedy WMI wyśle żądanie wyłączenia zbierania, a
zaprzestać wysyłania zdarzenia może wtedy, kiedy WMI wyśle żądanie wyłączenia
zdarzeń.
" Dokumentuje dane i bloki zdarzeń niejawnie, za pomocą opisowych nazw klas oraz
dodatkowych opisów. Klienty WMI mogą zyskiwać dostęp do nazw klas definiowanych
przez sterownik oraz do dodatkowych opisów wszystkich bloków danych i zdarzeń, a
ponadto mogą ukazywać je użytkownikom, czyniąc bloki danych i zdarzeń
samodokumentującymi.
Zestaw DDK systemu Windows 2000 dostarcza szczegółów dotyczących budowania i testowania
sterowników obsługujących WMI. Pobieranie DDK oraz korzystanie z niego jest omówione w
podrozdziale rozwiązań natychmiastowych niniejszego rozdziału.
Obsługa formatu pojedynczego INF
Plik INF to plik tekstowy, który zawiera wszelkie niezbędne informacje dotyczące urządzeń oraz
plików, które mają być zainstalowane  na przykład obrazy sterowników, informacje dotyczące
rejestru oraz informacje dotyczące wersji. Wszystkie sterowniki NDIS5 muszą mieć plik INF do
dyspozycji składników ustawień. Pliki INF interfejsu NDIS nie zawierają skryptów instalacyjnych.
Procedury instalacyjne są częścią aplikacji instalatora Win32, takich jak kreator nowych urządzeń
oraz kreator dodawania/usuwania sprzętu, przy czym każdy z plików INF pełni funkcję zasobu.
Wspólny format INF interfejsu NDIS5 oparty jest na formacie Windows 95 z rozszerzeniami.
Ponieważ system Windows 2000 wykorzystuje sterowniki, a system Windows 95 wykorzystuje
sterowniki urządzenia wirtualnego (VxD), format został rozszerzony w sposób bezinterwencyjny,
aby umożliwić INF instalację usługi w systemie Windows 2000. NDIS obsługuje format
pojedynczy INF. Aby zrozumieć co to oznacza, konieczne jest spojrzenie na różnice pomiędzy
INF-ami systemów Windows 95 i Windows NT4.
INF-y sieciowe systemu Windows NT4 są interpretowane. Umożliwia to zastosowanie języka INF
o skomplikowanych pojęciach  takich jak zmienne definiowalne oraz polecenia IF i GOTO.
Interpretatorem plików INF jest instalator klas. INF-y systemu Windows NT4 są elastyczne, lecz
złożone, więc usuwanie z nich błędów oraz ich obsługa mogą być trudne. Co więcej, mają one
złożone definicje powiązań. Jednak mogą one być rozszerzane poprzez wywoływanie plików
bibliotek dołączanych dynamicznie (DLL-i).
INF-y systemu Windows 95 są deklaracyjne. Określają one i spisują informacje, z których będzie
korzystał instalator klas poziomu systemowego. Sprawia to, że są one prostsze, ale mniej
elastyczne niż INF-y interpretowane. Są one łatwiejsze jeżeli chodzi o obsługę i usuwanie błędów,
i mają proste definicje powiązań.
W systemie Windows NT4 składniki sieci nie korzystają z formatu INF systemu Windows 95. W
związku z tym INF-y sieciowe systemu Windows NT4 różnią się od innych INF-ów i niemożliwe
jest uzyskanie zgodnych INF-ów pomiędzy tymi dwoma systemami operacyjnymi. Z tej
przyczyny konstruktorzy sterowników sieciowych zmuszeni są pisać oddzielne INF-y dla
systemów Windows 95 i Windows NT4.
NDIS5 zapewnia zwiększoną rozszerzalność INF-om korzystającym z interfejsów COM do DLL-i
i wykorzystuje te same definicje powiązań, co system Windows 95. Tak więc INF-y interfejsu
NDIS5 powinny być zgodne z poprzednimi wersjami; zarówno z systemem Windows 95 jak i
NT4, przy założeniu, że te systemy operacyjne obsługują odpowiednie urządzenie. Pliki INF
nowego formatu Windows 2000 (oraz Windows 98) muszą być pisane w taki sposób, by mieściły
wszystkie sterowniki sieciowe, łącznie ze sterownikami NDIS, sterownikami transportu,
dostawcami pliku/wydruku sieciowego i innymi urządzeniami peryferyjnymi.
Istniejące sieciowe pliki INF stworzone dla systemu Windows 95 czy Windows NT4 (lub
wcześniejszych) nie będą działały pod Windows 2000. Podobnie mają się sprawy w sytuacji, gdzie
dana karta, protokół, czy usługa jest już zainstalowana i działa w systemie Windows NT4 lub
Windows 9x, a następnie system operacyjny zostaje uaktualniony do systemu Windows 2000.
Jeżeli karta, protokół, lub usługa nie posiada plików INF w nowym stylu, napisanych dla systemu
Windows 2000, to przestanie działać po uaktualnieniu.
Wskazówka: Szczegóły dotyczące struktury INF-ów, jak również próbkę kodu, można znalez
ć w
zestawie Windows 2000 DDK.
Miniport zdeserializowany
Miniport zdeserializowany zapewnia znaczący zysk wydajności w porównaniu ze standardowym
miniportem, który nie jest w stanie wykonywać żadnych funkcji równocześnie, a także w
porównaniu z pełnodupleksowym miniportem systemu Windows NT4, który jest w stanie
wykonywać tylko równoczesne wysyłanie i odbieranie (narzucając ograniczenia nawet na tak
niewielki zestaw możliwości). Jeżeli dana karta sieciowa jest w stanie działać w trybie
zdeserializowanym na komputerze symetrycznej wieloprocesowości (SMP), to komunikacja
pomiędzy NDIS5 a miniportem kart sieciowej może zostać zdeserializowana, czego efektem jest
jednoczesne wykonywanie wszelkiego typu funkcji.
W czasie inicjalizacji sterownik miniportu sygnalizuje, że obsługuje operacje zdeserializowane.
Wtedy NDIS5 rozładowuje zarządzanie synchronizacją i kolejką do sterownika miniportu.
Wskazówka: W przypadku kart sieciowych, które nie obsługują komunikacji zdeserializowanej
nadal zapewniana jest obsługa pełnego dupleksu. Pełny dupleks umożliwia sterownikowi
miniportu równocześnie wysyłanie i odbieranie informacji zarówno do systemu operacyjnego,
jak i do warstwy MAC w komputerze SMP.
Mechanizmy rozładowywania zadań
Jeżeli karta sieciowa obsługuje tę funkcję sprzętowego rozładowywania operacji intensywnie
wykorzystujących procesor, mogą z tego wynikać znaczne zyski wydajności. Za pomocą OID-ów
kwerendy protokół może zażądać od miniportu maski funkcji rozładowywania zadań. NDIS5
ustawia tę maskę i wstępnie definiuje zadania, które mogą być rozładowywane. Wtedy protokół
określa zadania, które chce rozładować do miniportu. Do negocjacji parametrów zadań mogą być
wymagane dodatkowe OID-y specjalne dla danego zadania. W momencie uruchamiania protokół
oddelegowuje przetwarzanie zadań do sterownika miniportu oraz do karty sieciowej. NDIS5
obsługuje opisane poniżej mechanizmy rozładowywania zadań.
Obliczanie sumy kontrolnej TCP/IP
TCP/IP sprawdza możliwości miniportu i określa obliczenia sumy kontrolnej, które mają być
rozładowane. W ich skład wchodzą Dodaj (Wyślij) oraz Sprawdz
(Odbierz) dla TCP, UDP oraz
sum kontrolnych IP. Podczas wysyłania, TCP/IP przekazuje pakiety do miniportu z ustawionym
bitem znacznika, aby zażądać obliczenia sumy kontrolnej. Podczas operacji sprawdzania, miniport
przekazuje pakiet z ustawionym bitem znacznika, jeżeli obliczanie sumy kontrolnej się nie
powiedzie.
Szybkie przekazywanie pakietów
Szybkie przekazywanie pakietów (albo ścieżka szybkiego przekazywania) występuje, kiedy albo
multiport, albo jednoportowe karty sieciowe, takie jak 802.3, FastEthernet, czy FDDI są
wykorzystywane, wraz z kodem wyboru trasy systemu Windows 2000, do przekazywania
pakietów z jednego portu do drugiego na tej samej albo podobnej karcie, bez przekazywania
pakietu do procesora macierzystego.
Przy inicjalizacji protokół routingu sprawdza możliwości miniportu i żąda szybkiego
przekazywania pakietów. Przy uruchamianiu karty sieciowe monitorują i zapisują, które porty są
wykorzystywane w przypadku których tras. Jeżeli trasa jest znana w momencie otrzymania
pakietu, karta sieciowa przekazuje pakiet bezpośrednio do drugiego portu. Jeżeli trasa ulegnie
zmianie, to protokół routingu każe miniportowi (za pomocą OID), opróżnić znane trasy.
Szyfrowanie za pomocą zabezpieczeń protokołu IP
Kiedy do szyfrowania danych wykorzystywany jest IPSec, wydajność sieci spada z powodu
narzutów związanych z przetwarzaniem szyfrowania. IPSec przeprowadza kwerendę miniportu,
aby ustalić, czy na karcie sieciowej zaimplementowany jest odpowiedni sprzęt do szyfrowania.
Następnie IPSec żąda tej funkcji, a szyfrowanie IPSec jest implementowane przez kartę sieciową,
a nie przez procesor hosta.
Rozszerzenie nośników emisji
NDIS5 zawiera rozszerzenie, które obsługuje szybkie nośniki emisji jednokierunkowej, takie jak
Direct Tv, PrimeStar, czy Intercast. Rozszerzenie to zawiera nowe OID-y i definicje dla:
" dostrajania odbiornika,
" negocjacji strumienia wielonośnikowego i szybkiego strumieniowego przesyłania danych
do trybu użytkownika,
" obsługi pakietów multiemisji UDP/IP poprzez dostarczony przez Microsoft sterownik
emulacji multikomputera lokalnego (LAM), który implementuje pełną implementację
interfejsu przekazywania komunikatów (MPI).
Rozszerzenie nośników emisji mieści w sobie również usługi emisji dla Windows (Broadcast PC).
NDIS zorientowany połączeniowo
NDIS4 obsługiwał konstruowanie sterowników kart sieciowych oraz wdrażanie nośników sieci
bezpołączeniowych, takich jak Ethernet, Token Ring, ArcNet oraz FDDI. NDIS5 rozszerza ten
interfejs, aby zapewnić wydajną obsługę nośników zorientowanych połączeniowo, takich jak ATM
 łącznie z ATM/ADSL (asymetryczną cyfrową linią abonencką) oraz ATM/modem kablowy 
ISDN i nośników przesyłu danych, które obsługują jakość usługi. Nowa architektura umożliwia
również obsługę przesyłania strumieniowego danych multimedialnych.
NDIS5 określa interfejsy pomiędzy sterownikami protokołu klientów zorientowanych
połączeniowo, znajdującymi się przeważnie na dole stosu transportu, a samodzielnymi
protokołami zarządzania wywołaniami, takimi jak dostarczany przez system menedżer wywołań
dla sieci ATM. Określa on również interfejsy pomiędzy wszystkimi samodzielnymi,
zorientowanymi połączeniowo menedżerami wywołań a stanowiącymi ich podstawę miniportami,
które sterują zorientowanymi połączeniowo kartami sieciowymi. Zdefiniowane są następujące
zestawy funkcji sterowników standardowych:
" funkcje wspólne zarówno dla klientów zorientowanych połączeniowo, jak i
samodzielnych menedżerów wywołań;
" funkcje specyficzne dla klientów zorientowanych połączeniowo;
" funkcje specyficzne dla zorientowanych połączeniowo menedżerów wywołań;
" funkcje specyficzne dla zorientowanych połączeniowo sterowników kart sieciowych.
Wskazówka: Aby uzyskać szczegółowe informacje dotyczące funkcji sterowników
zorientowanych połączeniowo, znajdz
ProtocolCoXxx, ProtoclClXxx, ProtocolCmXxx oraz
MiniportCoXxx w dokumentacji zestawu Windows 2000 DDK.
NDIS zapewnia zestaw funkcji, które umożliwiają zorientowanym połączeniowo sterownikom
NDIS wzajemną komunikację. Zapewnia on również obsługę zintegrowanych menedżerów
wywołań miniportu (MCM-ów), które sterują kartami sieciowymi posiadającymi zintegrowane na
płycie, zorientowane połączeniowo możliwości sygnalizowania protokołów. Miniport, który
steruje taką kartą sieciową zapewnia obsługę protokołom klienta NDIS5, zarówno jako
zorientowany połączeniowo miniport NDIS, jak i zorientowany połączeniowo menedżer wywołań.
Obsługa QoS (jakość usługi)
Zwykle kiedy dany segment sieci ulega przeciążeniu, to na skutek obciążenia roboczego
koncentratorów i przełączników następuje opóz
nienie (zwłoka) pakietów, albo utrata pakietów.
Jeżeli jednak jest obsługiwana jakość usługi, to pakiet o wyższym priorytecie otrzymuje
traktowanie preferencyjne i zostaje obsłużony przed pakietem o niższym priorytecie. Na przykład
priorytet pakietu 802.1p jest implementowany przez rozszerzenie standardowego nagłówka MAC
w pakietach sieciowych. Rozszerzenie to zawiera 3-bitową wartość, którą koncentratory i
przełączniki wykorzystują do ustanawiania priorytetów pakietów w sieciach nośnika wspólnego
802. Składniki systemu operacyjnego, które są przeznaczone do użytku w ramach QoS,
dostarczają informacji dotyczących priorytetów 802.1p sterownikom miniportu. Struktura pakietu
NDIS, która opisuje każdy przesyłany pakiet, wykorzystywana jest do wysyłania informacji
dotyczących priorytetów. Składniki przeznaczone do użytku w ramach QoS uzyskują owe
informacje o priorytetach poprzez odwzorowywanie typów usługi na wartości priorytetu 802.1p.
Jeżeli komputer hosta nie wynegocjuje z siecią jakości usługi, to będzie oznaczał transmitowane
pakiety wartością 802.1p  dostarczanie przy użyciu dostępnych możliwości . Jeżeli jednak
komputer macierzysty ma zainstalowany harmonogram pakietów, to wykorzystuje odpowiednie
składniki sygnalizujące QoS, by wynegocjować z siecią wyższe wartości priorytetu 802.1p. Wtedy
harmonogram pakietów przekazuje do sterownika miniportu odpowiednie wartości priorytetu w
pakietach NDIS.
Nadawca wywołania w przełączanym obwodzie wirtualnym (SVC) może określać parametry QoS
dla wywołania. W zależności od zastosowanego protokołu sygnalizacyjnego menedżer wywołań
(MCM), który przygotowuje wywołanie wychodzące lub przychodzące, może negocjować QoS z
jednostką sieciową, taką jak przełącznik sieciowy lub z klientem zdalnym. Klient zorientowany
połączeniowo może zażądać zmiany QoS w aktywnym połączeniu wirtualnym (VC) dla
wywołania wychodzącego lub przychodzącego  przy założeniu, że protokół sygnalizacyjny
obsługuje tę funkcję. Klient zdalny również może zgłosić takie żądanie. W tym przypadku
menedżer wywołań, lub sterownik MCM, sygnalizuje żądanie zmiany QoS klienta zdalnego.
Połączenia wirtualne
Pojęcie połączeń wirtualnych jest istotne dla zrozumienia działania negocjacji QoS. W systemie
lokalnym VC stanowi węzeł końcowy (lub skojarzenie) pomiędzy klientem, menedżerem
wywołań (MCM) a miniportem, który może pełnić rolę hosta pojedynczego wywołania. W sieci
VC odnosi się do połączenia pomiędzy dwoma komunikującymi się węzłami końcowymi, takimi
jak dwa klienty zorientowane połączeniowo. Na karcie sieciowej może być aktywnych kilka
połączeń VC naraz, co pozwala karcie sieciowej obsługiwać wywołania równocześnie. Każde
połączenie może być połączeniem z różnymi węzłami końcowymi na różnych komputerach.
Połączenia VC w sieci różnią się pod względem typu usługi, jakiej dostarczają klientom. Na
przykład dane połączenie VC może dostarczać usługi jednokierunkowej lub dwukierunkowej.
Parametry QoS dla każdego kierunku mogą zagwarantować określone progi wydajności, takie jak
przepustowość czy zwłoka.
Połączenie VC w sieci może być połączeniem SVC, albo stałym połączeniem VC (PVC).
Połączenie SVC tworzone jest, według potrzeby, dla określonego wywołania. Połączenie PVC
tworzone jest ręcznie i zostaje ostatecznie usunięte przez operatora za pomocą konfiguracyjnego
programu usługowego. Jakość usługi dla połączenia PVC konfigurowana jest przez operatora i nie
jest negocjowalna poprzez sieć.
W NDIS5 VC składa się z zasobów przydzielanych przez miniport w celu utrzymania informacji o
stanie połączenia w sieci. W skład tych zasobów wchodzą bufory pamięci, zdarzenia oraz
struktury danych. Żądanie utworzenia kontekstu dla VC wyrażane jest przez klienta
zorientowanego połączeniowo w przypadku wywołania wychodzącego lub przez menedżera
wywołań w przypadku wywołania przychodzącego.
Zanim utworzone połączenie VC może zostać wykorzystane do transmisji danych, musi ono
zostać uaktywnione przez menedżera wywołań (MCM). W celu uaktywnienia danego połączenia
VC, miniport lub MCM przygotowuje zasoby dla połączenia VC i, stosownie do potrzeb,
komunikuje się ze swoją kartą sieciową, aby przygotować ją do otrzymywania lub transmisji
danych przez połączenie VC. W momencie zakończenia (lub rozmontowania) wywołania,
menedżer wywołań lub MCM dezaktywuje VC użyte do wywołania. Po rozmontowaniu
wywołania twórca połączenia VC może albo zainicjować jego usuwanie, albo wykorzystać
połączenie VC do kolejnego wywołania.
Obsługa sterowników pośrednich
NDIS5 zapewnia obsługę sterowników pośrednich. Sterowniki pośrednie są wymagane w
przypadku Broadcast PC, LAN-ów wirtualnych, emulacji LAN-a poprzez ATM oraz telewizji
emitowanej drogą satelitarną.
Sterownik klasy to sterownik pośredni, który zapewnia uproszczony interfejs pomiędzy systemem
operacyjnym a sterownikiem specyficznym dla sprzętu. W skład NDIS5 wchodzi sterownik klasy
służący do przesyłania strumieniowego jądra, stream.sys, który uwalnia programistę sterowników
od większości zawiłości związanych z pisaniem sterownika WDM w pełni obejmującego rozmaite
platformy.
Większość klas urządzeń, takich jak urządzenia do przechwytywania obrazu oraz zewnętrzne
urządzenia dz
więkowe, jest obsługiwanych przez sterownik klasy przesyłu strumieniowego.
Wyjątkiem są wewnętrzne karty dz
więkowe, dla których Microsoft zapewnia oddzielną
architekturę.
Sterowniki klas i filtrów dla peryferyjnych urządzeń pamięci masowej systemu Windows 2000
zapewniają interfejs pomiędzy sterownikami poziomu pośredniego lub wysokiego a sterownikami
portu dostarczanymi przez system. Żądania wejścia-wyjścia (I/O) wychodzące od aplikacji
użytkownika, lub składnika jądra, docierają do sterowników klasy pamięci masowej poprzez
usługi systemowe I/O systemu Windows 2000 oraz poprzez jeden lub więcej sterownik poziomu
pośredniego lub wysokiego, jak sterownik systemu plików. Przed przesłaniem każdego z pakietów
IRP do sterownika niższego poziomu, sterowniki klasy pamięci masowej tłumaczą standardowe
pakiety IRP na takie IRP-y, które posiadają definiowane przez system bloki żądań (SRB)
interfejsu niewielkich systemów komputerowych (SCSI), zawierające bloki deskryptora poleceń
(CDB) interfejsu SCSI-2. Sterownik portu pamięci masowej tłumaczy SRB ze sterowników klas
na polecenia specyficzne dla magistrali, które następnie wysyła do sterownika magistrali I/O,
zazwyczaj poprzez jeden lub więcej sterownik filtra.
Dodatkowe funkcje NDIS5
Pomimo że niniejszy podrozdział obejmuje istotne funkcje NDIS5, nie jest tutaj możliwe (ani
wskazane) relacjonowanie każdej z funkcji. W skład funkcji dodatkowych wchodzi obsługa IEEE
1394, obsługa ponownego wiązania protokołu kiedy zmienia się typ nośnika karty sieciowej oraz
mechanizmy zapewniające bezpośredni dostęp do nośników dla przesyłu strumieniowego trybu
jądra. Pełny opis wszystkich funkcji NDIS5 zawarty jest w dokumentacji zestawu Windows 2000
DDK, wraz ze szczegółami dotyczącymi tego, jak implementować owe funkcje w procedurach
sterowników.
Funkcje warstwy łącza danych
Sterowniki NDIS działają w warstwie łącza danych otwartego połączenia systemów (OSI). Na tej
warstwie spoczywa odpowiedzialność za wysyłanie ramek z warstwy sieciowej do warstwy
fizycznej. Ponadto warstwa łącza danych otrzymuje dane surowe od warstwy fizycznej i pakuje je
w ramki danych. Rysunek 1.3 przedstawia prostą ramkę danych. Miejsce docelowe i miejsce
z
ródłowe identyfikują komputery odbierające i komputery wysyłające (lub dokładniej, karty
sieciowe) przeważnie po ich adresach MAC. Dane kontrolne wykorzystywane są w informacjach
na temat typu ramki, wyboru trasy oraz segmentacji. Cykliczna kontrola redundancji (CRC)
wykorzystywana jest do weryfikacji danych oraz do korekcji błędów. Warstwa łącza danych
odpowiedzialna jest za zapewnianie wolnego od błędów przesyłu ramek poprzez warstwę
fizyczną. Kiedy warstwa sieciowa otrzymuje dane z warstwy łącza danych, to przyjmuje, że są one
wolne od błędów.
Identyfikator z
ródła Dane
Identyfikator celu Kontrola CRC
Rysunek 1.3. Prosta ramka danych
Funkcje warstwy łącza danych są implementowane przez sprzęt karty sieciowej, sterownik karty
oraz przez sterownik stosu protokołu niskiego poziomu. Filtry połączenia sprzęt karty sieciowej 
sterownik oparte są na docelowym adresie MAC każdej ramki. Normalnie sprzęt odfiltrowuje
wszystkie przychodzące ramki, oprócz tych, które zawierają jeden z następujących adresów
docelowych:
" adres MAC karty sieciowej hosta;
" adres emisji typu  same jedynki (FF-FF-FF-FF-FF-FF);
" adresy multiemisji, zainteresowanie którymi zgłosił sterownik protokołu w hoście.
Ponieważ pierwsza decyzja o filtrowaniu podejmowana jest przez sprzęt, karta sieciowa odrzuca
wszelkie ramki, które nie spełniają kryteriów filtra  bez żadnej potrzeby przetwarzania przy
użyciu procesora. Wszystkie ramki (łącznie z emisjami), które przechodzą przez filtr sprzętowy są
przekazywane do sterownika karty sieciowej poprzez przerwanie sprzętowe. Sterownik karty
sieciowej sprowadza ramkę do pamięci systemu z karty sieciowej. Póz
niej ramce zostają wskazane
odpowiednie powiązane sterowniki transportu (zostaje do nich przekazana). Ramki są
przekazywane do wszystkich powiązanych sterowników transportu w kolejności, w jakiej są
powiązane. Wszelkie ramki, które przechodzą przez początkowy filtr sprzętowy wymagają
przetwarzania przy użyciu procesora.
Wskazówka: Pełna wersja (lub wersja serwera zarządzania systemami) Monitora sieci, jak
również agenta Monitora sieci, domyślnie ustawia kartę sieciową na tryb ogólny. Hamuje to
początkowe filtrowanie sprzętowe, aby każda z ramek, które host wykryje w sieci była
sygnalizowana. W ten sposób Monitor sieci może przechwytywać cały ruch w danej podsieci,
lecz odbywa się to dużym kosztem czasu przetwarzania za pomocą procesora. NDIS zapewnia
filtr wszystkich pakietów lokalnych, aby zagwarantować, że Monitor sieci nie zdobędzie
wyłączności w korzystaniu z procesora.
Kiedy dany pakiet przemierza sieć, lub szereg sieci, adres z
ródłowy MAC jest zawsze adresem tej
karty sieciowej, która umieściła go na nośniku sieciowym, a adres docelowy MAC jest adresem tej
karty sieciowej, która zdejmie go z nośnika. Stąd też w sieci routowanej z
ródłowe i docelowe
adresy MAC zmieniają się przy każdym przeskoku przez router.
Maksymalna jednostka transmisyjna (MTU)
Każdy typ nośnika posiada maksymalny rozmiar ramki, albo MTU, którego nie wolno
przekraczać. Warstwa łącza danych jest odpowiedzialna za odkrywanie jednostki MTU i
zgłaszanie jej do protokołów. Stos protokołu może sprawdzać sterowniki NDIS, aby uzyskać
lokalną jednostkę MTU. Protokoły warstwy górnej, takie jak TCP, wykorzystują informacje MTU
do automatycznej optymalizacji rozmiarów pakietu dla każdego z nośników. Odkrywanie
maksymalnej jednostki transmisyjnej ścieżki TCP (PMTU) jest omówione w rozdziale 8.
Jeżeli dany sterownik karty sieciowej korzysta z trybu emulacji sieci LAN, to może zgłaszać
jednostkę MTU wyższą od spodziewanej dla emulowanego typu nośnika. Na przykład sterownik
ATM może emulować Ethernet, a zgłaszać MTU ATM wynoszącą 9 180 bajtów. System
Windows 2000 przyjmuje i wykorzystuje rozmiar MTU zgłoszony przez kartę, nawet jeśli jest on
większy od spodziewanego dla zgłoszonego typu nośnika.
Czasami jednostka MTU zgłaszana do stosu protokołu jest mniejsza niż ta, jakiej można by się
spodziewać dla danego typu nośnika. Na przykład zastosowanie standardu 802.1p zmniejsza
zgłaszany rozmiar MTU o 4 bajty, z powodu wzrostu rozmiaru nagłówków warstwy łącza danych.
Rozwiązania natychmiastowe
Instalowanie protokołów sieciowych
Instalacja domyślna systemu Windows 2000 instaluje jako protokół połączeń lokalnych protokół
TCP/IP. Jeżeli chcesz używać innych protokołów oraz zoptymalizować kolejność powiązań,
musisz najpierw zainstalować te protokoły.
Aby zainstalować dodatkowe protokoły sieciowe:
1. Zaloguj się jako administrator.
2. Wejdz
do Start|Ustawienia|Połączenia sieciowe i telefoniczne, prawym przyciskiem
myszy kliknij Połączenie z siecią lokalną i wybierz Właściwości.
3. Kliknij Zainstaluj.
4. Wybierz Protokół i kliknij Dodaj.
5. Wybierz protokół, który chcesz zainstalować. Jeżeli instalujesz z CD-ROM Windows
2000, możesz kliknąć OK. Jeżeli instalujesz ze wspólnego obszaru sieciowego lub z
innego z
ródła (takiego jak dyskietka), kliknij Przeglądaj, podaj ścieżkę dostępu do
plików instalacyjnych i kliknij OK.
6. W zależności od protokołu, który zainstalowałeś, możesz zostać poproszony o
przeładowanie komputera. Jeżeli chcesz zainstalować dodatkowe protokoły, kliknij Nie
na tym etapie i powtórz procedurę. Po zainstalowaniu wszystkich protokołów, których
potrzebujesz, przeładuj komputer.
Uwaga! Świeżo zainstalowany protokół zostanie umieszczony na samej górze listy powiązań
zarówno dla kart sieciowych, jak i dla usług. Zazwyczaj nie jest to sytuacja pożądana  dlatego
zawsze sprawdzaj i rekonfiguruj swoją kolejność powiązań po zainstalowaniu protokołu
sieciowego.
Konfigurowanie powiązań
Powiązania pomiędzy protokołami a kartami sieciowymi (a także pomiędzy protokołami a
usługami) mogą być włączane lub wyłączane, a kolejność powiązań może być zmieniana. Jeżeli,
przykładowo, większość ruchu w Twojej podsieci to ruch lokalny o bardzo małej ilości pakietów
wysyłanych do routera w celu dalszej transmisji, to możesz chcieć, żeby NetBEUI, a nie TCP/IP,
był wykorzystywany jako protokół pierwszej kolejności. Jeżeli większość klientów w twojej
podsieci to hosty systemu Netware korzystające z protokołu wymiany pakietów w sieciach
internetowych/sekwencyjnej wymiany danych (IPX/SPX), to możesz zechcieć przesunąć NWLink
w górę w kolejności powiązań na swoich serwerach.
Uwaga: Zmiana kolejności powiązań może radykalnie poprawić wydajność. Zatem wybranie
niewłaściwej kolejności powiązań może spowodować równie radykalny spadek wydajności.
Uważaj podczas rekonfigurowania powiązań TCP/IP; zawsze najpierw przeprowadzaj analizę
ruchu za pomocą Monitora sieci.
Aby skonfigurować powiązania TCP/IP podejmij następujące działania:
1. Zaloguj się jako administrator.
2. Wejdz
do Start|Ustawienia, prawym przyciskiem myszy kliknij Połączenia sieciowe i
telefoniczne i wybierz Otwórz.
3. Wybierz połączenie, które chcesz skonfigurować.
4. W menu rozwijanym Zaawansowane wybierz Ustawienia zaawansowane.
5. Wybierz protokół powiązany z kartą lub usługą i użyj strzałki w górę lub w dół, aby
zmienić jego kolejność powiązań. Anulowanie zaznaczenia w polu wyboru na lewo od
protokołu wyłączy powiązanie. Rysunek 1.4 przedstawia okno dialogowe Ustawienia
zaawansowane.
Rysunek 1.4. Konfigurowanie powiązań
Konfigurowanie oszczędzania energii
Właściwości oszczędzania energii dla danego urządzenia mogą być skonfigurowane w jego
sterowniku. Jednak w przypadku ogólnych urządzeń systemowych, takich jak monitor, dysk
twardy, itd., możliwe jest dokonywanie konfiguracji przez użytkownika za pomocą panelu
sterowania.
Aby skonfigurować oszczędzanie energii z panelu sterowania, podejmij następujące kroki:
1. Wejdz
do Start|Ustawienia i wybierz Panel sterowania.
2. Otwórz okno dialogowe Właściwości: Opcje zasilania.
3. Do listy dostępnych schematów zasilania można dotrzeć za pomocą listy rozwijanej
Schematy zasilania, przedstawionej na rysunku 1.5. Opcja Zawsze włączony stosowana
jest na serwerach, chociaż niektóre przedsiębiorstwa wykorzystują ją do wszystkich
komputerów PC. Wybierz Zawsze włączony i zwróć uwagę na ustawienia domyślne.
4. Wejdz
do listy rozwijanej Wyłącz dyski twarde, przedstawionej na rysunku 1.6. Jeżeli
konfigurujesz serwer, to prawdopodobnie zachowasz ustawienie Nigdy, ponieważ w
przeciwnym wypadku czasy dostępu mogłyby się stać nie do przyjęcia.
5. Podobne opcje dostępne są na liście rozwijanej Wyłącz monitor. Jeżeli konfigurujesz
serwer, to prawdopodobnie będziesz chciał wyłączyć monitor (przy założeniu że jest
podłączony).
6. Wybierz zakładkę Zaawansowane. Zaznaczenie pola wyboru spowoduje wyświetlanie
ikony Zarządzania zasilaniem na pasku zadań. Jest to przydatne jeżeli często zmieniasz
ustawienia zasilania.
Rysunek 1.5. Wybieranie schematu zasilania
Rysunek 1.6. Opcje listy Wyłącz dyski twarde
7. Wybierz zakładkę Hibernacja. Zwróć uwagę, że uruchomienie hibernacji wymaga
znacznej ilości wolnej przestrzeni dyskowej, zazwyczaj 128MB. Hibernacji zwykle nie
uruchamia się na serwerze.
8. Wybierz zakładkę UPS (zasilacz awaryjny). Możesz wybrać i/lub skonfigurować UPS z
tego okna dialogowego.
9. Na zakładce Schematy zasilania wybierz i zastosuj wszystkie schematy po kolei i zwróć
uwagę na ustawienia domyślne. Opcje ustawień są takie same jak dla opcji Zawsze
włączony.
10. Ustaw zarządzanie zasilaniem komputera według swoich potrzeb. Kliknij Zapisz jako i
podaj nazwę dla swojego schematu zasilania. Nazwa ta powinna być dostępna na liście
rozwijanej Schematy zasilania, kiedy tylko ją zapiszesz.
Korzystanie z zestawu do rozbudowy sterowników
systemu Windows 2000 (DDK)
Ilość konfiguracji ustawień NDIS5, dostępnych poprzez narzędzia administracyjne oraz poprzez
panel sterowania jest ograniczona. Pozostała część tego rozdziału jest w związku z tym
interesująca tylko jeżeli aktualnie piszesz albo zamierzasz pisać sterowniki miniportu. To nie jest
książka o kodowaniu C++, ale też nie udaje, że nią jest. Jest wiele doskonałych publikacji na ten
temat. Dlatego też pozostała część tego rozdziału obejmuje instalację zestawu DDK,
wykorzystywanie makropoleceń uprzednio zdefiniowanych do budowy sterowników, korzystanie
z narzędzia weryfikatora sterowników oraz korzystanie z narzędzi do usuwania błędów, takich jak
punkty kontrolne.
Celem procedur w tej części jest przedstawienie zarysu narzędzi i urządzeń dostępnych w zestawie
DDK oraz omówienie metodologii dostarczonej do wytwarzania kodów z
ródłowych sterowników.
Nie jest to ani potrzebne, ani wskazane, aby podejmować tutaj próby dogłębnego potraktowania
tych tematów. Szczegółową dokumentację, jak również próbkę kodu, można pobrać wraz z DDK.
Wskazówka: Jeżeli nie jesteś doświadczonym programistą C++ i nie masz doświadczenia na
polu rozbudowy sterowników, to najlepiej zacząć od próbek dostarczonych wraz z DDK.
Przestudiuj sposób, w jaki te programy są zbudowane, skorzystaj z narzędzia weryfikatora
sterowników i implementuj punkty kontrolne.
Instalowanie zestawu do rozbudowy sterowników (DDK)
Aby rozbudowywać i usuwać błędy sterowników miniportu będą Ci potrzebne co najmniej dwa
komputery: jeden jako PC do rozbudowy sterowników, a drugi jako komputer do testowania
sterowników. Jeżeli masz zamiar pisać sterowniki, które obsługują działanie miniportu
zdeserializowanego, to twój komputer do testowania sterowników musi być komputerem SMP.
Powinien mieć zainstalowany system operacyjny Windows 2000 i przynajmniej 128MB pamięci
RAM. (Chociaż Microsoft twierdzi, że możesz korzystać z komputera wyposażonego w 64MB, ja
bym tego nie polecał.)
Komputer do rozbudowy sterowników wymaga:
" Windows 2000.
Wskazówka: Możliwe jest rozbudowywanie sterowników Windows 2000 na komputerze z
systemem Windows NT4 albo Windows 98 i testowanie ich w systemie z Windows 2000. Nie
jest to jednak całkowicie zadowalająca strategia rozbudowy. W niektórych okolicznościach, na
przykład kiedy przeprowadzasz usuwanie błędów jądra na sterowniku, który jest w rozbudowie,
potrzebne są dwa komputery z systemem Windows 2000.
" Microsoft Visual C++ v 5 lub póz
niejszy (najlepiej póz
niejszy). Potrzebna Ci będzie
edycja Professional, lub Enterprise. Edycje Academic i Standard nie są obsługiwane.
" Najnowszy pakiet usługowy Visual C++ dla wersji, której używasz.
" Napęd CD-ROM albo dostęp do Internetu.
" Co najmniej 128MB pamięci RAM. Tutaj znowu Microsoft określa minimum wynoszące
64MB. Mój komputer do rozbudowy ma 256MB, a mimo to czasem się męczy.
" 1GB wolnej przestrzeni na dysku twardym. Możesz zainstalować DDK na 200MB, ale
będziesz potrzebować 750MB, jeżeli masz zamiar kompilować wszystkie próbki. Wtedy
będzie Ci, oczywiście, potrzebne trochę przestrzeni na swoje własne procedury.
Wskazówka: Upewnij się, że wszystkie urządzenia w obu komputerach są w pełni zgodne z
systemem Windows 2000. Sprawdz
specyfikację swojego komputera porównując ją z listą
zgodności sprzętowej, dostępną pod adresem www.microsoft.com/hcl.
Do instalacji potrzebujesz praw administratora. Potrzebny jest również czysty komputer, który nie
ma już zainstalowanej poprzedniej wersji DDK (jeżeli tak jest, to ją odinstaluj).
Uwaga! Nie instaluj zestawu Windows 2000 DDK na poprzednich zestawach Windows 2000
DDK, ani na zestawach DDK dla innych systemów operacyjnych.
Aby zainstalować zestaw Windows 2000 DDK:
1. Jeżeli posiadasz CD-ROM z sieci programistów firmy Microsoft (MSDN&trade),
uruchom setup.exe z CD-ROM. W przeciwnym razie, wejdz
do witryny WWW zestawu
do rozbudowy sterowników firmy Microsoft, znajdującej się pod adresem
www.microsoft.com/ddk i pobierz oraz uruchom X86DDK.exe (dla systemów x86). Plik
ten ma 42MB i pobranie go zabiera trochę czasu.
Zasoby dla programistów
Dostęp do MDSN&Trade, sieci programistów firmy Microsoft, można uzyskać pod adresem
http://msdn.microsoft.com. Sieć ta dostarcza narzędzi i informacji wspomagających pisanie
oprogramowania. W skład tych informacji wchodzą elementy do pobierania dla pakietów service
pack czy też programy korygujące do narzędzi programowania firmy Microsoft; wydania
platformowe SDK; dostęp do grup użytkowników, forum dyskusyjne i informacje o zmianie
stanu; oraz biblioteka MSDN online.
Witryna WWW zestawu do rozbudowy sterowników firmy Microsoft, znajdująca się pod
adresem www.microsoft.com/ddk, zapewnia zasoby do rozbudowy sterowników, łącznie z
najnowszą wersją Windows 2000 DDK do pobrania, najnowszą dokumentacją DDK,
nowościami na temat ulepszeń DDK, formularzem zwrotnym, stroną najczęściej zadawanych
pytań (FAQ) oraz rozszerzonymi informacjami na temat wersji.
2. Kliknij Dalej.
3. Przeczytaj i zaakceptuj warunki umowy licencyjnej.
4. Wybierz składniki, które chcesz zainstalować. Radzę Ci zainstalować wszystkie, chyba że
jesteś doświadczonym programistą sterowników.
5. Zdecyduj czy chcesz środowisko o budowie dowolnej, czy środowisko usuwania błędów.
Na początku będziesz prawie na pewno potrzebować tego ostatniego. Istnieją następujące
środowiska:
" Budowa dowolna  wersja użytkownika systemu operacyjnego. System oraz
sterowniki zbudowane są z pełną optymalizacją, a usuwanie błędów jest wyłączone.
System i sterownik o budowie dowolnej jest mniejszy, szybszy i wykorzystuje mniej
pamięci niż budowa kontrolowana. Budowa dowolna jest czasem określana jako
budowa detaliczna.
" Budowa kontrolowana  wykorzystywana przy testowaniu i usuwaniu błędów
sterowników. Budowa kontrolowana zawiera wykrywanie błędów, weryfikację
argumentów oraz informacje dotyczące usuwania błędów, które nie są dostępne w
przypadku budowy dowolnej. System lub sterownik kontrolowany może pomóc przy
izolowaniu i wykrywaniu problemów, mogących powodować nieprzewidywalne
zachowanie, wycieki pamięci, albo niewłaściwą konfigurację urządzeń. Budowa
kontrolowana zużywa więcej pamięci oraz przestrzeni dyskowej, a wydajność
systemu i sterowników jest niższa.
6. Spod Programy|Development Kits|Windows 2000 DDK wybierz albo okno konsoli
dowolnej, albo kontrolowanej.
7. Spod konsoli wiersza poleceń uruchom setenv.bat. Zwróć uwagę, że zamknie to
wszystkie programy systemu Windows. Ponadto plik wsadowy nie będzie działał, jeżeli
nie został zainstalowany program Visual C++.
8. Spod konsoli wiersza poleceń wpisz build -cZ. Kompiluje to i łączy wszystkie
sterowniki w drzewie z
ródłowym bieżącego katalogu. Zwróć uwagę, że każdy katalog, w
którym uruchamiasz build -cZ musi zawierać plik o nazwie z
ródła. Jeżeli ten plik nie
występuje w katalogu, to katalog ten nie zawiera żadnych plików z
ródłowych
sterowników.
Wskazówka: możesz sprawdzić swoją instalację uruchamiając build -cZ z podkatalogu
\destination\src. Buduje to pełny zestaw zainstalowanych sterowników. Proces ten może
potrwać około 30 minut.
Budowanie sterowników
Zestaw DDK zapewnia zestaw makropoleceń, które są rozpoznawane przez program usługowy
służący do budowania. Te makropolecenia są podzielone na makropolecenia pliku z
ródła, które
wyszczególniają elementy produktu lub produktów danej budowy, oraz na makropolecenia pliku
kartoteki, które pozwalają, programowi usługowemu do budowania, na stworzenie całego drzewa
z
ródłowego z kilku plików z
ródła w katalogach, które są podkatalogami podkatalogu pliku
kartoteki. Ponadto, zapewniony jest zestaw zmiennych środowiska budowy. Próbka kodu dostępna
jest w zestawie DDK.
Format definicji makropoleceń to:
MACRONAME=Value
Gdzie Value jest ciągiem tekstowym. Na przykład:
TARGETNAME=mylibrary
Aby wyszczególnić składniki dla produktu build:
1. Utwórz drzewo katalogowe. Katalogi z
ródłowe powinny być podkatalogami drzewa kodu
z
ródłowego, którego katalog macierzysty będzie zawierał plik kartoteki.
2. W każdym katalogu z
ródłowym utwórz plik o nazwie z
ródła. Do utworzenia tego pliku
można użyć edytora tekstu, a sam plik nie powinien mieć rozszerzenia typu pliku.
3. Umieść swój kod z
ródłowy w pliku z
ródła. Dostępne makropolecenia zostały
przedstawione w tabeli 1.2.
4. Odwołaj się do zmiennych środowiskowych w miarę potrzeb, przy użyciu składni
$(NazwaZmiennej). Dostępne zmienne środowiskowe przedstawione zostały w tabeli
1.3.
5. Utwórz plik kartoteki w katalogu macierzystym drzewa kodu z
ródłowego. Podobnie jak
plik z
ródła, plik ten można utworzyć za pomocą edytora tekstu i nie powinien on mieć
rozszerzenia typu pliku. Makropolecenia przedstawione w tabeli 1.4 mogą być
definiowane w pliku kartoteki.
6. Uruchom program usługowy do budowania. Jeżeli, przykładowo, katalog1 i katalog2
zostały wyszczególnione w makropoleceniu OPTIONAL_DIRS, to polecenie brzmi
build -cZ directory1directory2.
Tabela 1.2. Makropolecenia użyte w pliku z
ródła
Makropolecenie Funkcja
TARGETNAME
Określa nazwę budowanej biblioteki.
TARGETPATH
Określa nazwę katalogu docelowego dla wszystkich produktów
build (plików EXE, DLL, LIB, itd.). Polecenie build tworzy
podkatalogi wyłączne dla platformy w tym katalogu. Zauważ, że
polecenie build zawsze tworzy podkatalog typu \obj (objfre lub
\onbjchk) w katalogu, który zawiera plik z
ródła.
TARGETPATHLIB
Określa ścieżkę pliku oraz katalog docelowy dla bibliotek importu
utworzonych przez operację build. Jeżeli ścieżka pliku nie jest
określona, to biblioteki importu umieszczane są w tym samym
podkatalogu, co inne pliki produktów build.
TARGETTYPE
Określa typ budowanego produktu. Jest to zazwyczaj LIBRARY lub
DYNLINK (dla DLL-i).
TARGETEXT
Określa rozszerzenie nazwy pliku dla DLL-i (na przykład CPL).
Domyślne rozszerzenie nazwy pliku dla DLL-i to DLL.
TARGETLIBS
Określa zestaw bibliotek importu, z którymi musi być połączony
twój sterownik.
INCLUDES
Zawiera listę ścieżek, które mają zostać przeszukane na okoliczność
występowania plików nagłówkowych podczas kompilacji. Build
szuka również plików nagłówkowych na domyślnej liście
katalogów. Ścieżki określone przez INCLUDES są przeszukiwane
przed ścieżkami domyślnymi.
SOURCES
Zawiera listę nazw plików z
ródłowych z rozszerzeniami. Pliki te
muszą rezydować w tym katalogu, w którym rezyduje plik z
ródła.
Listę plików z
ródłowych, które zawierają funkcję główną można
uzyskać za pomocą UMAPPL lub UMTEST, a nie za pomocą SOURCES.
UMTYPE
Określa typ budowanego produktu. Opcje to: Win32 (tryb
użytkownika), tryb jądra oraz konsola Win32.
UMAPPL
Zawiera listę plików z
ródłowych, które zawierają funkcję główną.
Jeżeli użyjesz UMAPPL, to build automatycznie utworzy pliki
wykonywalne.
UMTEST
Zawiera listę plików z
ródłowych, które zawierają funkcję główną.
Jeżeli użyjesz UMTEST, musisz zidentyfikować pliki, które chcesz,
aby zostały zbudowane, poprzez spisanie ich w wierszu polecenia
build.
UMAPPLEXT
Określa rozszerzenie nazwy pliku dla plików wykonywalnych (na
przykład COM). Domyślne rozszerzenie nazwy pliku dla plików
wykonywalnych to EXE.
UMLIBS
Zawiera listę nazw ścieżek bibliotek, które mają zostać połączone z
plikami określonymi przez UMTEST, lub UMAPPL. Tutaj powinna być
zawarta biblioteka określona przez SOURCES. Nazwy ścieżek muszą
być bezwzględne.
NTPROFILEINPUT
Umożliwia korzystanie z pliku, który podaje listę kolejności, w
jakiej program łączący powinien zyskiwać dostęp do funkcji. Plik
ten powinien być w tym samym katalogu, co plik z
ródła i powinien
się nazywać TargetName.prf, gdzie TargetName jest nazwą pliku
określoną przez makropolecenie TARGETNAME. NTPROFILEINPUT
jest ustawione na jeden (binarne), jeżeli ma być użyty plik PRF.
DLLORDER
Umożliwia określenie pliku, który podaje listę kolejności, w jakiej
program łączący powinien uzyskiwać dostęp do funkcji.
Makropolecenie musi być ustawione na nazwę pliku, który zawiera
listę kolejności. Możesz używać tego makropolecenia zamiast
NTPROFILEINPUT.
386_WARNING_LEVEL
Określa poziom ostrzegawczy kompilatora.
Tabela 1.3. Zmienne środowiskowe
Zmienna środowiskowa Funkcja
BASEDIR
Zawiera podstawę drzewa z
ródłowego produktu build (tzn.
katalog, który zawiera plik kartoteki).
BUILD_ALT_DIR
Dołącza wyszczególnione znaki do nazwy podkatalogu \obj.
Środowiska budowy kontrolowanej i budowy dowolnej
wykorzystują tę zmienną do tworzenia podkatalogów \objfre i
\objchk.
BUILD_DEFAULT
Zawiera listę domyślnych parametrów, które mają być przekazane
do programu usługowego build.
BUILD_DEFAULT_TARGETS
Zawiera listę domyślnych przełączników docelowych.
BUILD_MAKE_PROGRAM
Zawiera nazwę programu usługowego make wykorzystywanego
przez build. Ta zmienna musi przybrać wartość nmake.exe.
CRT_INC_PATH
Zawiera ścieżkę do katalogu, w którym zawarte są pliki
nagłówkowe systemu Windows 2000.
CRT_LIB_PATH
Zawiera ścieżkę do katalogu, w którym zawarte są biblioteki
importu C dostarczone przez Microsoft.
DDK_INC_PATH
Zawiera ścieżkę do katalogu, w którym zawarte są specyficzne dla
DDK pliki nagłówkowe dostarczone przez Microsoft.
DDK_LIB_PATH
Zawiera ścieżkę do katalogu, w którym zawarte są specyficzne dla
DDK biblioteki importu C dostarczone przez Microsoft.
DDK_LIB_DEST
Zawiera ścieżkę do katalogu docelowego dla specyficznej dla DDK
biblioteki importu będącej produktem build.
OAK_INC_PATH
Zawiera ścieżkę do katalogu, w którym zawarte są pliki
nagłówkowe dostarczone przez Microsoft.
SDK_LIB_DEST
Zawiera ścieżkę do katalogu docelowego dla biblioteki importu
będącej produktem build.
SDK_LIB_PATH
Zawiera ścieżkę do katalogu, w którym zawarte są biblioteki
importu C dostarczone przez Microsoft.
WDM_INC_PATH
Zawiera ścieżkę do katalogu, w którym zawarte są specyficzne dla
WDM pliki nagłówkowe dostarczone przez Microsoft.
C_DEFINES
Definiuje przełączniki, które są przekazywane do kompilatorów.
O
Identyfikuje podkatalog, w którym zostaną umieszczone pliki
produktu build.
NTDEBUG
Ustawiane na ntsd w środowisku kontrolowanym. Sprawia, że
kompilator tworzy informacje dotyczące debugowania
symbolicznego.
BUILD_OPTIONS
Może być inicjalizowane przez użytkownika. Ta zmienna zawiera
listę dodatkowych podkatalogów, które powinny zostać
przeszukane podczas operacji build. These are ...
Tabela 1.4. Makropolecenia wykorzystywane w pliku kartoteki
Makropolecenie Opis
DIRS
Zawiera listę podkatalogów, które mają być budowane domyślnie.
OPTIONAL_DIRS
Zawiera listę podkatalogów, które mają być budowane tylko jeżeli
zostały wyszczególnione w poleceniu build.
Weryfikowanie sterowników
Weryfikator sterowników sprawdzi, czy dany sterownik należycie się rozładowuje i czy
przepuszcza jakąkolwiek ilość pamięci, którą zużył (tzn. czy nie jest  nieszczelny ). Sprawdzi
przepełnienia pamięci, ujawni naruszenia stronicowania, przetestuje reakcję sterownika na niski
stan pamięci oraz skontroluje obsługę I/O. Z programu usługowego verifier.exe można korzystać z
wiersza polecenia za pomocą przełączników wiersza poleceń, ale bardziej wygodne jest
zastosowanie dostarczonego graficznego interfejsu użytkownika (GUI) menedżera weryfikatora
sterowników.
Aby użyć menedżera weryfikatora sterowników w celu sprawdzenia sterownika, podejmij
następujące działania:
1. Uruchom menedżera weryfikatora sterowników z menu Start|Programy|Development
Kits|Windows 2000 DDK, lub uruchom verifier.exe z wiersza poleceń bez
wyszczególniania przełączników. Plik verifier.exe zlokalizowany jest w podkatalogu
Ntddk\tools.
Wskazówka: Jeżeli DDK nie został w pełni zainstalowany, a środowisko budowy przygotowane
(odwołaj się do poprzedniej procedury), to ani ten plik nie zadziała, ani też menedżer
weryfikatora sterowników nie pojawi się we właściwym menu.
2. Zakładka Stan sterownika pojawia się domyślnie. Podaje on listę sterowników, które są
załadowane i sprawdzane, oraz wskazuje które opcje weryfikatora sterowników są
aktywne. Część Znaczniki globalne pokazuje, które opcje weryfikatora sterowników są
włączone. W części Sprawdzane sterowniki podana jest lista wszystkich sterowników,
które kazano sprawdzić weryfikatorowi sterowników oraz bieżący stan ich weryfikacji.
Częstotliwość odświeżania tego ekranu można ustawiać za pomocą przycisków opcji.
Wybranie opcji Ręczna wyłącza uaktualnienia automatyczne. Przycisk Odświeżaj teraz
powoduje natychmiastowe odświeżenie Kolumny stanu. Rysunek 1.7 przedstawia
zakładkę Stan sterownika.
3. Wybierz zakładkę Liczniki globalne. Ten ekran wyświetla statystyki, które monitorują
działania weryfikatora sterowników. Liczniki alokacji monitorują wykorzystanie puli
pamięci przez sterowniki standardowe trybu jądra. Rysunek 1.8 przedstawia zakładkę
Liczniki globalne.
Rysunek 1.7. Weryfikacja stanu sterownika
Rysunek 1.8. Liczniki globalne wykorzystywane przez weryfikator sterowników
4. Wybierz zakładkę Śledzenie puli. Ten ekran wyświetla informacje dotyczące alokacji pul
pamięci stronicowanej i niestronicowanej. Część Liczniki indywidualne wyświetla
statystyki dla jednego sterownika naraz, określone na liście rozwijanej u góry tej części.
W części Liczniki globalne licznik alokacji nieśledzonych wyświetla liczbę nieśledzonych
alokacji spośród wszystkich sterowników weryfikowanych w danej chwili. Rysunek 1.9
przedstawia zakładkę Śledzenie puli.
Rysunek 1.9.
5. Wybierz zakładkę Ustawienia. Ten ekran umożliwia wybór sterowników, które mają
zostać zweryfikowane. Możesz ustawić typ weryfikacji oraz poziom weryfikacji I/O.
Kliknięcie prawym przyciskiem myszy na danym sterowniku pozwala na kontrolowanie
weryfikacji z menu wyskakującego. Okno Zweryfikuj te dodatkowe sterowniki po
następnym przeładowaniu pozwala wpisywać nazwy sterowników, które nie są aktualnie
zainstalowane w systemie. Jeżeli wybrane zostanie Zweryfikuj wszystkie sterowniki, to
weryfikator sterowników zweryfikuje wszystkie sterowniki po przeładowaniu. Gdy
zostanie wybrany ten przycisk opcji, to lista sterowników oraz przyciski Weryfikuj i Nie
weryfikuj będą zaznaczone na szaro. Przycisk Ustawienia preferowane to szybki sposób
włączenia najczęściej używanych opcji. Kiedy dokonujesz ustawień za pomocą tego
ekranu, kliknij Zastosuj, wyjdz
z menedżera weryfikatora sterowników i przeładuj
komputer. Zmienione ustawienia nie zaczną działać, dopóki system nie zostanie
przeładowany.
6. Wybierz zakładkę Ustawienia zmienne. Ten ekran umożliwia dokonywanie zmian w
ustawieniach weryfikatora sterowników w trybie natychmiastowym (a nie po
przeładowaniu). Pula specjalna, sprawdzanie wymuszania IRQL oraz symulacja niskiego
stanu zasobów mogą być włączane i wyłączane dla wszystkich weryfikowanych
sterowników. Nowe ustawienia wchodzą w życie natychmiast po kliknięciu przycisku
Zastosuj. Rysunek 1.11 przedstawia zakładkę Ustawienia zmienne.
7. Dokonaj takich zmian, jakich potrzebujesz na wszystkich opisanych ekranach i zamknij
menedżera weryfikatora sterowników. Jeśli trzeba, przeładuj system.
Rysunek 1.10. Wybieranie sterowników, które mają zostać zweryfikowane oraz ustawianie typu i
poziomu weryfikacji
Rysunek 1.11. Ustawienia zmienne
Usuwanie błędów sterowników
Świeżo napisane sterowniki (lub wszelkiego innego typu programy) rzadko działają za pierwszym
razem. Zestaw Windows 2000 DDK zapewnia szczegółowe programy usługowe do usuwania
błędów, łącznie z takimi procedurami, jak OutputDebugString i DebugBreak dla sterowników
trybu użytkownika, oraz DbgPrint, KdPrint, DbgBreakPoint, DbgBreakPointWithStatus,
KdBreakPoint, KdBreakPointWithStatus, ASSERT, i ASSERTMSG dla sterowników trybu jądra.
Procedury te można, dla potrzeb usuwania błędów, umieścić w kodzie z
ródłowym. Szczegóły
składni oraz próbki dostępne są w zestawie DDK.
Jest jednak dostępne narzędzie bardziej przyjazne użytkownikowi  Windows Debugger
(WinDbg). Poniższa procedura rzuca światło na urządzenia dostępne z tego interfejsu graficznego.
Aby wejść do programu Windows Debugger i z niego korzystać, podejmij następujące kroki:
1. Wejdz
do Start|Programy|Zestawy do rozbudowy|Windows 2000 DDK|Narzędzia
debugowania i wybierz WinDbg. Pojawi się interfejs graficzny programu Windows
Debugger, jak na rysunku 1.12.
2. Menu Plik pozwala otworzyć plik z
ródłowy, plik wykonywalny, lub zrzut awaryjny.
Możesz także zarządzać swoją przestrzenią roboczą z tego menu.
3. W menu Edycja wybierz Punkty kontrolne. Lista rozwijana Punkty kontrolne oferuje
dostępne opcje punktów kontrolnych, jak na rysunku 1.13. Dokonaj potrzebnego wyboru
i kliknij OK.
Rysunek 1.12. Windows Debugger
Rysunek 1.13. Wybieranie opcji punktów kontrolnych
4. W menu Widok masz wybór elementów widoku takich jak: rejestry, pamięć oraz stos
wywołań. Rysunek 1.14 przedstawia dostępne opcje widoku pamięci.
5. W menu Debuguj możesz rozpoczynać lub zatrzymywać debugowanie, wkraczać w
procedurę albo pomijać punkt kontrolny, włączać albo wyłączać tryb z
ródłowy
(wyłączenie trybu z
ródłowego uruchamia dezasemblera) oraz ustawiać wyjątki, jak na
rysunku 1.15.
Rysunek 1.14. Opcje formatu wyświetlania widoku pamięci
Rysunek 1.15. Ustawianie wyjątków
6. Narzędzie posiada również pewną liczbę przycisków, które zapewniają skróty do pozycji
menu. Przycisk Opcje na przykład, zapewnia ten sam zestaw funkcji, co Widok|Opcje.
Zbadaj wszystkie zakładki w tym oknie dialogowym. Rysunek 1.16 (na przykład)
przedstawia zakładkę Debugger.
Jak zostało wcześniej stwierdzone, celem opisywania procedur związanych z zestawem DDK w
tym rozdziale jest zbadanie dostępnych urządzeń do generowania, weryfikowania i usuwania
błędów programów sterujących. Pełne ujęcie tego, jak pisać kod z
ródłowy C++ oraz korzystać ze
wszystkich urządzeń DDK, wymagałoby książki co najmniej tak dużej jak niniejsza. Na szczęście
szczegółowa dokumentacja dostępna jest wraz z zestawem DDK (jeżeli zdecydujesz się go
pobrać), podobnie jak próbki programów.
Rysunek 1.16. Okno dialogowe Opcje programu Windows Debugger