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 ź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 ultradź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 wyraź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óź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óź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óź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óź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 dź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 ź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 znaleźć 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 Sprawdź (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, znajdź 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óź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 dźwiękowe, jest obsługiwanych przez sterownik klasy przesyłu strumieniowego. Wyjątkiem są wewnętrzne karty dź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 ź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 ź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óź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 ź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 ź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. Wejdź 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 ź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. Wejdź 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. Wejdź 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. Wejdź 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 ź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óźniejszy (najlepiej póź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. Sprawdź 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, wejdź 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 źródłowym bieżącego katalogu. Zwróć uwagę, że każdy katalog, w którym uruchamiasz build -cZ musi zawierać plik o nazwie źródła. Jeżeli ten plik nie występuje w katalogu, to katalog ten nie zawiera żadnych plików ź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 ź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 źródłowego z kilku plików ź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 źródłowe powinny być podkatalogami drzewa kodu źródłowego, którego katalog macierzysty będzie zawierał plik kartoteki.

2. W każdym katalogu źródłowym utwórz plik o nazwie ź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 źródłowy w pliku ź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 źródłowego. Podobnie jak plik ź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 ź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 ź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 źródłowych z rozszerzeniami. Pliki te muszą rezydować w tym katalogu, w którym rezyduje plik źródła. Listę plików ź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 ź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 ź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 ź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 ź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, wyjdź 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 ź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. Wejdź 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 ź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 źródłowy (wyłączenie trybu ź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 ź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