Windows 2000 dla programistów - problemy i nowe możliwości

W Windows 2000 Microsoft wprowadził wiele nowych funkcji API, zmienił też sposób działania niektórych mechanizmów. Nowe aplikacje muszą być dokładnie przetestowane w tym systemie, może się bowiem zdarzyć, że nie będą działać poprawnie.

W Windows 2000 Microsoft wprowadził wiele nowych funkcji API, zmienił też sposób działania niektórych mechanizmów. Nowe aplikacje muszą być dokładnie przetestowane w tym systemie, może się bowiem zdarzyć, że nie będą działać poprawnie.

W Windows 2000 wprowadzono zupełnie nowy mechanizm zarządzający instalacją aplikacji. System operacyjny "pilnuje", aby podczas instalowania aplikacji pewne krytyczne elementy systemu nie zostały podmienione. Co ważniejsze, podmienić komponent systemowy może tylko poprawka do Windows lub mechanizm Windows Update.

Windows 2000 dopuszcza, by w systemie istniała więcej niż jedna wersja określonej biblioteki DLL. W ten sposób program, korzystający z konkretnego komponentu, ma możliwość zainstalowania go we własnym podkatalogu i korzystania z niego. Zmieniło się działanie funkcji wczytujących biblioteki, które najpierw sprawdzają lokalne wersje DLL. Na pewno zapobiega to często spotykanej sytuacji, gdy po zainstalowaniu jednego programu, inny program przerywał pracę.

Windows 2000 zawiera wersję 1.1 Windows Installer (wersja 1.0 jest rozprowadzana razem z Office 2000). Korzystając bezpośrednio z możliwości systemu, programista może tak utworzyć pakiet instalacyjny, by np. komponent dowolnej aplikacji był wgrywany dopiero w momencie, gdy użytkownik chce z niego skorzystać.

Równocześnie w Windows 2000 został zmieniony sposób instalowania większości sterowników - dzięki mechanizmom wbudowanym w API WDM nie jest konieczne tak częste restartowanie komputera.

Nowy wygląd okna

Microsoft w Windows 2000 wprowadził nowy obiekt graficzny - okno "warstwowe". Możliwe jest tworzenie okien o fantazyjnych kształtach, nadawanie pewnym fragmentom atrybutu "przezroczystości" czy precyzyjne kontrolowanie kolejności odrysowywania ekranu, tak by efekt dokładnie odpowiadał zamierzeniom programisty.

Wprowadzono także pewnego rodzaju automatyczną "pamięć podręczną", w której jest przechowywany wygląd okien. Dzięki temu w wielu sytuacjach okno nie otrzymuje komunikatu żądającego "odrysowania się", ale to system decyduje o samodzielnym odtworzeniu wyglądu okna.

Zmiany w wielozadaniowości

W Windows 2000 rozszerzono możliwości synchronizacji i zarządzania wątkami. Po pierwsze, system pozwala bardzo precyzyjnie sterować tzw. minimalnym czasem procesora przyznawanym wątkowi, czyli czasem, po którym następuje przełączenie zadań w systemie. W NT 4.0 Workstation można zmieniać tę długość, wybierając jedną z predefiniowanych wartości (w rzeczywistości NT Ser-ver 4.0 ma równy czas time-slice bez względu na preferencje przypisane aplikacji pierwszoplanowej). Windows 2000 pozwala na bardziej precyzyjne sterowanie podziałem czasu procesora. Można stosować zmienne długości time-slice, co pozwala dostosowywać obciążenie procesora, wynikające z operacji pierwszoplanowych, do operacji drugoplanowych. W ten sposób można dokładnie dostroić serwer do wykonywanych zadań.

W Windows 2000 wprowadzono nowy obiekt, pozwalający synchronizować zdarzenia przy przetwarzaniu wielowątkowym/wieloprocesowym. Załóżmy, że zachodzi konieczność wykonania pewnych operacji w ściśle zdefiniowanej kolejności. Windows 2000 pozwala, by dla każdej synchronizowanej operacji umieścić w specjalnej kolejce licznik czasu, dla którego jest zdefiniowana funkcja zwrotna (callback), wywoływana w ściśle określonym momencie. System operacyjny realizuje taką kolejkę korzystając (niemal) z jednego fragmentu kodu obsługi zegara, co powoduje niskie zużycie zasobów systemowych. Co ważniejsze, obok takiej kolejki liczników można zdefiniować tzw. pulę wątków. Podczas zajścia zdarzenia, funkcja zwrotna jest wywoływana w kontekście jednego z wolnych wątków przydzielonego z ogólnodostępnej puli.

Mechanizm thread pooling może być wykorzystywany także w innych sytuacjach. Aplikacja zamiast tworzyć wiele wątków oczekujących na zdarzenie (czyli tzw. śpiących wątków), może definiować ciąg operacji określających sposób oczekiwania i funkcje, jakie mają być wywołane przy użyciu mechanizmu callback. Wtedy wywołanie funkcji następuje w kontekście jednego z wątków pobranego z puli.

EAP i IAS

W Windows 2000 - oprócz wbudowanych mechanizmów autoryzacji - istnieje specjalny moduł pozwalający dołączyć do systemu autoryzację zarządzaną przez narzędzia innych firm. Dotychczas w NT 4.0 sprowadzało się to np. do podmiany biblioteki GINA, odpowiedzialnej za "okienko logowania" NT 4.0.

W Windows 2000 pojawił się interfejs Extensible Authentication Protocol (EAP), który pozwala na korzystanie z innych schematów autoryzacji np. przy dostępie przy użyciu RAS. Ponadto API IAS (Internet Authentication Service) pozwala programistom na tworzenie specjalnych dodatków, które mogą rejestrować fakt zalogowania się czy w inny sposób kontrolować zdalną sesję.

Precyzyjne śledzenie zdarzeń

W Windows 2000 pojawił się specjalny mechanizm pozwalający na bardzo dokładne monitorowanie operacji zachodzących w systemie.

Zbiór funkcji wchodzących w skład Event Tracing API umożliwia podglądanie każdej operacji, wykonywanej przez Windows 2000 (także operacji jądra systemu). Aplikacja może podłączyć się pod konkretne zdarzenie i rejestrować je w specjalnym buforze w pamięci, który okresowo będzie zapamiętywany na dysku. Co ciekawsze, Windows 2000 pozwala, by zewnętrzne aplikacje dostarczały własne źródła zdarzeń. Należy podkreślić, że jest to mechanizm zupełnie oddzielony od Monitora Wydajności znanego z NT 4.0. Event Tracing API jest bardziej dokładne. Ma być pomocne np. przy samoprofilowaniu się działającej aplikacji (dostosowywaniu działania do obciążenia) czy tworzeniu programów, jako narzędzie pomocnicze dla profilerów.

COM+

W roku 1997 Microsoft poinformował o planach rozszerzenia modelu COM, wprowadzając COM+. Rozszerzenie nowego standardu miało przynieść nowe możliwości dla programistów, ułatwić pracę, a co najważniejsze - ściśle zintegrować Microsoft Transaction Server i obiekty COM, by programista nie musiał nadmiernie dużo uwagi poświęcać na tworzenie obiektu, którego operacje byłyby wykonywane w środowisku transakcyjnym, z możliwością automatycznego wycofania w momencie awarii. W COM+ miało być także wprowadzone, znane z Javy, automatyczne zarządzanie przydzieloną pamięcią. Microsoft zamierzał także rozszerzyć możliwości COM o dziedziczenie, znane z języków programowania (w COM można dziedziczyć interfejsy, ale np. by odziedziczyć zachowanie, kod obiektu "potomnego" musi jawnie wywoływać odpowiednią metodę obiektu bazowego). Jednak ostatecznie niewiele z tych zapowiedzi pojawia się w Windows 2000.

Uproszczono tworzenie obiektów - w środowisku Windows 2000 to system operacyjny realizuje pewne standardowe operacje, jakie musi wykonywać każdy obiekt COM. Jako jedną z najważniejszych zmian należy wskazać wprowadzenie mechanizmu publish-subscribe, pozwalającego "zapisywać się" na określone zdarzenia. Usprawniono współpracę z MSMQ i MTS, jednak te zmiany nie są tak rewolucyjne, jak wynikałoby z zapowiedzi Microsoftu. Jednocześnie z COM+ wprowadzono wiele towarzyszących mechanizmów, które pozwalają efektywnie tworzyć aplikacje typu enterprise.

W Windows 2000 istnieje mechanizm tworzenia ściśle określonej puli obiektów COM+, z której na żądanie są przydzielane określone instancje. Specjalny komponent pozwala na wyrównywanie obciążenia pomiędzy różnymi serwerami. Wprowadzono także mechanizm pozwalający na tworzenie bardzo szybkich (transakcyjnych!) baz danych przechowywanych w pamięci serwera.

Asynchroniczne RPC

W Windows 2000 Microsoft zdecydował się rozszerzyć tradycyjny model RPC (zdalnego wywołania procedur), określony przez Open Software Foundation - Distributed Computing Environment (OSF-DCE), o wywołania asynchroniczne. W tradycyjnym przetwarzaniu, opartym na RPC, w momencie, gdy aplikacja kliencka wywołuje zdalną procedurę, musi czekać, aż serwer zwróci wynik. Co więcej, niemal jedynym sposobem na wykrywanie błędów transmisji jest ustalenie dostatecznie długiego czasu oczekiwania na reakcję serwera. Problemy pojawiają się także, gdy serwer ma przesłać dużą ilość danych - serwer może nie sprostać obsłudze kolejnych żądań. Asynchroniczne RPC rozwiązuje większość problemów. Było ono już dostępne na NT 4.0, jednak dopiero w Windows 2000 pojawiło się wiele funkcji pozwalających obsługiwać błędy czy upraszczających wykorzystanie tego mechanizmu.

Definicja asynchronicznych funkcji znajduje się poza plikiem definiującym postać funkcji (Interface Definition Language). Dzięki temu z tej samej funkcji może korzystać zarówno aplikacja wywołująca ją asynchronicznie, jak i program korzystający ze standardowego RPC.

ASDI

W związku z dołączeniem do Windows 2000 usług katalogowych, wprowadzono specjalne mechanizmy pozwalające tworzyć aplikacje, które mogą łatwo skorzystać z NDS. Usługi katalogowe mają 3 główne zestawy funkcji API, bo tradycyjny zestaw LDAP C API tak naprawdę jest standardem pozwalającym na pisanie aplikacji LDAP w "czystym" C.

Aby zachować zgodność z istniejącymi aplikacjami, Microsoft wprowadził interfejs rozszerzający MAPI, pozwalający, by aplikacje, które już korzystały z MAPI (np. współpracujące z Exchange Server), mogły działać z mechanizmem Active Directory.

Jednak zalecanym sposobem oprogramowywania usług katalogowych jest ADSI, oparty na obiektach COM, udostępniający zarówno Active Directory, jak i struktury NDS czy LDAP.

Istnieje specjalny provider OLE DB, pozwalający na wykorzystanie ADSI, i tym samym katalogi i pliki przekształcane są w "bazę danych", która może obsługiwać kwerendy itp.

Obiekty ADSI są przeznaczone dla trzech głównych grup odbiorców: programistów, którzy przy użyciu tego mechanizmu mogą tworzyć własne aplikacje, administratorów i końcowych użytkowników, mogących skorzystać z obiektów ADSI do tworzenia skryptów upraszczających codzienne zarządzanie plikami czy zadaniami wysyłanymi na drukarkę.

Dodatkowe elementy w NTFS

W Windows 2000 pojawił się nowy format plików NTFS 5.0. Jednym z ciekawszych rozszerzeń w NTFS 5.0 jest opcja dodawania "własnych informacji" przy tworzeniu niemal dowolnego pliku na dysku. Dane stowarzyszone z plikiem czy katalogiem są zrozumiałe albo dla filtrów instalowanych w systemie, albo dla aplikacji, która utworzyła te informacje. Mechanizm ten został zastosowany w Microsoft Remote Storage Server, który może przesuwać rzadko wykorzystywane pliki z dysków serwera na wolniejsze media, jak napędy taśmowe. Niestety, trochę to skomplikowało tworzenie kopii zapasowych, a także działanie skanerów antywirusowych.

VLM

Nie wiadomo jaki będzie ostatecznie los funkcji obsługujących dużą pamięć operacyjną (VLM). W SDK do Windows 2000 wprowadzono nowe, 64-bitowe typy danych, a w specyfikacji beta określonych jest wiele funkcji służących do obsługi pamięci o wielkości do 28 GB. Jednak ponieważ nie będzie wersji Windows 2000 na procesor Alpha, aby z tych funkcji skorzystać, trzeba czekać na 64-bitowy procesor Intela.

DirectX 7.0

W Windows 2000 będzie wbudowane DirectX 7.0. Dzięki temu większość aplikacji graficznych powinna działać pod Windows 2000, tak jak pod 95/98.

Problemy z kompatybilnością

Niestety, nie wszystkie programy będą działały pod Windows 2000 bez konieczności wprowadzenia zmian. Najwięcej kłopotów na pewno sprawi nowy instalator i mechanizmy chroniące pliki systemowe. Istniejące programy instalacyjne zakładają, że mogą podmienić plik systemowy czy bibliotekę DLL wykorzystywaną przez inną aplikację. Ponadto nie można przewidzieć, czy konkretny instalator poprawnie wykryje wersję Windows. Może więc się zdarzyć, że aplikacja wprawdzie będzie działać pod Windows 2000, ale nie będzie jej można w łatwy sposób zainstalować!

Sporo problemów napotkają użytkownicy aplikacji korzystających z urządzeń pomiarowych i aplikacji pisanych pod Windows 95, które wykorzystują wirtualne urządzenia (pliki VxD). Takie programy nie będą działać pod Windows 2000. Natomiast programy i urządzenia, do których dostępne są sterowniki napisane przy wykorzystaniu interfejsu WDM, powinny pracować poprawnie.

Z uwagi na duże zmiany w organizacji systemu plików także większość programów antywirusowych czy narzędzia do "naprawy" dysków bądź defragmentacji nie będą działać poprawnie.

W Windows 2000 zmieniono niektóre wywołania funkcji API. Przykładowo, do TranslateMessage powinna być przekazywana nie zmieniona wartość parametru wparam, z tym że jeżeli aplikacja nie będzie tego wykonywać, to pewne usprawnienia dostępne w Windows 2000 nie będą z nią współpracować. Windows 2000 w przypadku standardowych okien dialogowych korzysta domyślnie z innej czcionki niż 95/NT.

Drugim punktem "niezgodności" w Windows 2000 może stać się "okno pierwszoplanowe". W Windows NT 4.0/98/95 aplikacja mogła bez większych trudności ustawić swoje okno jako pierwszoplanowe, co powodowało, że nie można było łatwo przełączyć się do innego zadania. W Windows 2000 aplikacja musi spełnić kilka warunków, by mogła stać się aplikacją pierwszoplanową. Co więcej, system może przekazać priorytet innemu programowi, gdy dana aplikacja nie będzie odpowiadać na komunikaty.

Windows 2000 inaczej traktuje atrybuty niż Windows 95/NT. Plik z ustawianymi równocześnie atrybutami System i Hidden nigdy nie będzie widoczny w Eksploratorze Windows (mimo że w aplikacjach DOS będzie go widać).

NetBIOS nie jest już "domyślną" częścią Windows 2000. Aplikacja nie może zakładać, że zawsze może wywołać np. NetServerEnum. Konieczne jest przeanalizowanie kodu aplikacji i sprawdzenie, czy każde wywołanie funkcji Net... działa poprawnie, gdy nie ma NetBIOS.

Zmieniło się także zarządzanie pamięcią. W Windows 2000 nie zmieniono API odpowiedzialnego za zarządzanie stosem. Zmienił się jednak sposób działania menedżera pamięci. Dotychczas, po zwolnieniu bloku pamięci, taki blok był przesuwany na koniec listy "wolnych obszarów", zwykle nie był więc od razu wykorzystywany ponownie. W Windows 2000 jest on umieszczany na początku listy. Dzięki tej organizacji system zarządzania pamięcią działa znacznie sprawniej, ponieważ nowo alokowany obszar może znajdować się od razu w odpowiedniej stronie pamięci RAM. Jednak w przypadku źle napisanej aplikacji, która próbuje odwołać się do pamięci po zwolnieniu obszaru, jest duże prawdopodobieństwo, że dane zostały już zmienione! I program zawiesi się! Podobny mechanizm został zastosowany w ServicePack 4.0 do NT 4.0, można więc wstępnie przetestować aplikację.

Windows 2000 jest bardziej "czuły" na nieprawidłowe konwencje wywoływania funkcji API. O ile w Windows 95 nie było to tak istotne, o tyle częstą przyczyną nieprawidłowego działania aplikacji w Windows 2000 może być niezdefiniowanie dla wywoływanej funkcji konwencji STDCALL.

W związku z pojawieniem się nowych sterowników do dysków twardych (zwłaszcza Ultra DMA 66) w Windows 2000 bardzo ważne jest poprawne wyrównywanie bufora dysku w pamięci (zwłaszcza gdy program samodzielnie buforuje operacje I/O).

Microsoft w Windows 2000 (w związku z wprowadzeniem nowych mechanizmów zarządzania wielozadaniowością itp.) zmienił kolejność wysyłania komunikatów. Aplikacja, która zakłada, że otrzyma komunikaty w ściśle określonej kolejności (dotyczy to zwłaszcza komunikatów wysyłanych przy zamykaniu aplikacji) prawdopodobnie nie będzie działać poprawnie w Windows 2000.

Ponieważ Windows 2000 (i Windows 98) może obsługiwać równocześnie wiele monitorów, należy sprawdzić, czy na pewno testowana aplikacja poprawnie będzie działała, jeżeli np. okno główne będzie miało ujemne współrzędne.

Microsoft twierdzi, że jeżeli aplikacja działa poprawnie pod Windows NT z wgraną ostatnią poprawką, powinna także działać poprawnie pod Windows 2000. Jednak warto to sprawdzić przed instalacją nowego systemu na komputerze!

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200