System Windows Embedded CE 6.0 cechuje się zupełnie zreorganizowanym jądrem systemu wprowadzającym zestaw nowych, istotnych elementów takich jak dwa tryby pracy sterowników urządzeń (Tryb Jądra i Tryb Użytkownika), funkcje systemowego API (ang. Application Programming Interface) przesunięte (z ich własnych procesów w trybie użytkownika) do bibliotek pracujących w trybie jądra czy też nowa architektura pamięci operacyjnej usuwająca dotychczasowe ograniczenia (teraz możliwa jest równoczesna obsługa do 32 tysięcy procesów z przestrzenią adresową 2 GB pamięci wirtualnej dla każdego procesu).
Dodatkowo kod warstwy OAL (nk.exe) i kod jądra systemu operacyjnego (kernel.dll) są teraz rozdzielone i mogą komunikować się ze sobą tylko poprzez ściśle zdefiniowane interfejsy.
Cechy szczególne:
Przeniesienie BSP dla „RMI Alchemy
- RMI Alchemy
- Au1550
- nowe BSP bazujące na:
- jednym z istniejących BSP dla Win CE 6.0 dla procesora MIPSII
- istniejącym BSP dla „RMI Alchemy
- proces migracji z CE 5.0 do CE 6.0 i do nowego IDE (Microsoft Visual Studio 2005 z dodatkami Platform Builder dla CE 6.0)
- rozdzielenie kodu warstwy OAL i jądra systemu operacyjnego
- zweryfikowanie programu rozruchowego i sterowników urządzeń względem nowych wymagań CE 6.0.
Zmiany w Głównych Modułach
- Kod warstwy OAL (nk.exe) i kod jądra systemu operacyjnego (kernel.dll) są rozdzielone.
- Aby zwiększyć wydajność funkcje API systemowego zostały wyjęte z ich własnych procesów w trybie użytkownika i umieszczone w bibliotekach pracujących w trybie jądra:
- filesys.dll – Rejestr, system plików i bazy danych
- gwes.dll – Interfejs graficzny, obsługa zdarzeń
- device.dll – Zarządzanie sterownikami urządzeń w trybie jądra.
- Menedżer usług składa się z procesu hosta usług systemowych (servicesd.exe) i interfejsu wiersza poleceń do konfigurowania usług (services.exe).
- Nowy, oddzielny proces zarządzający sterownikami urządzeń w trybie użytkownika (udevice.exe).
Nowa Architektura Pamięci Operacyjnej
Nowa Architektura Pamięci Operacyjnej usuwająca dotychczasowe ograniczenia
- każdy proces otrzymuje własną, naprawdę prywatną przestrzeń adresową (żaden proces aplikacji nie może „zaglądnąć” do przestrzeni adresowej żadnego innego procesu aplikacji)
- teoretyczne maximum 32K procesów obsługiwanych równocześnie (zamiast 32)
- większa przestrzeń adresowa – 2 GB pamięci wirtualnej dla każdego procesu (zamiast 32 MB).
Działanie w Trybie Jądra
- Procesor musi wspierać dwa poziomy uprzywilejowania:
- Tryb Jądra (wyższy)
- Tryb Użytkownika (niższy)
- Tylko mieszany tryb działania jest wspierany. Wszystkie aplikacje są ładowane do przestrzeni adresowej użytkownika, a wszystkie komponenty systemu operacyjnego do przestrzeni adresowej jądra (jest to wolniejsze niż uruchomienie całego systemu w trybie jądra ale dzięki temu całe środowisko działa stabilniej i bezpieczniej).
- Niektóre biblioteki systemowe istnieją w obu wersjach (dla trybu użytkownika i dla trybu jądra) aby zminimalizować koszt wywoływania funkcji poprzez granicę poziomów uprzywilejowania (np. systemowa biblioteka Core – coredll.dll oraz k.coredll.dll).
Dwa Tryby Pracy Sterowników Urządzeń
- sterowniki Trybu Jądra – funkcjonalność starego device.exe została przesunięta do jądra aby zwiększyć wydajność systemu. Sterowniki te muszą być bardzo dobrze przetestowane i stabilne aby nie spowodowały awarii jądra i całego systemu
- sterowniki Trybu Użytkownika – nowy, lepiej chroniony proces dla urządzeń użytkownika (udevice.exe) zwiększający stabilność i bezpieczeństwo – odpowiedni dla niezaufanych sterowników firm trzecich albo niestabilnych sterowników wymagających testów w trybie użytkownika przed umieszczeniem ich w trybie jądra. Każdy pojedynczy sterownik trybu użytkownika (lub ich grupa) może być uruchomiony na osobnej instancji udevice.exe.
Ograniczenia nowego API
- funkcje już nie wspierane – SetKMode, SetProcPermissions / GetCurrentPermissions, MapCallerPtr, MapPtrToProcess
- funkcja VirtualCopy – w przypadku wywoływania VirtualCopy w sterownikach trybu użytkownika, sprawdzane będą adresy aby upewnić się że sterownik ma prawo dostępu do żądanego adresu fizycznego
- warstwa OAL może korzystać tylko z tych funkcji jądra systemu które zostały wyeksportowane.
Wpływ nowego CE 6.0
Wpływ nowego CE 6.0 na istniejące sterowniki i oprogramowanie
- Kompatybilność Binarna dla aplikacji, czyli dobrze napisane aplikacje powinny działać po małych / żadnych przeróbkach (pamięć jest alokowana tymi samymi funkcjami API, a dane są wciąż przechowywane z użyciem 32-bitowych wskaźników pamięci wirtualnej). Duże bloki danych alokowane funkcją VirtualAlloc zamiast funkcjami alokowania pamięci współdzielonej (np. MapViewOfFile) z wcześniejszych wersji CE.
- Kompatybilność zachowana poprzez CoreDLL ze zminimalizowanym wpływem na API Win32 i zmianami ukrytymi w bibliotekach API.
- Aplikacje korzystające z nieudokumentowanych technik (takich jak przekazywanie uchwytów albo wskaźników pomiędzy procesami) będą najprawdopodobniej musiały zostać zmodyfikowane.
- Zmiany dotkną głównie sterowniki i serwisy:
- w większości przypadków sterowniki będą przeniesione małym nakładem pracy
- w przypadku niestandardowych rozwiązań programistycznych albo w przypadku użycia nieudokumentowanych funkcji może okazać się konieczne przebudowanie wewnętrznej struktury lub interfejsu sterownika
- sterowniki które potrzebują dostępu (odczyt/zapis) do danych w przestrzeni adresowej aplikacji muszą być uruchamiane w trybie jądra (ponieważ funkcja SetKMode i ustawianie dla procesu praw dostępu do innych procesów nie są już wspierane)
- sterownik urządzenia może być uruchamiany w trybie użytkownika przy pomocy procesu menedżera sterowników w trybie użytkownika – udevice.exe.
Nowe BSP bazuje na jednym z istniejących BSP dla procesora MIPSII dostarczanego przez Microsoft razem z dodatkami Platform Builder dla CE 6.0 do Microsoft Visual Studio 2005 oraz na istniejącym BSP dla „RMI Alchemy
Przeniesienie warstwy OAL
- skopiowanie istniejącego BSP dla „RMI Alchemy
- zmodyfikowanie struktury katalogów warstwy OAL aby odzwierciedlała podział na moduły OAL, KITL i Jądra Systemu
- użycie nowych nazw dla budowanych plików wykonywalnych (np. nk.exe, kitl.dll)
- rozdzielenie nk.exe (OAL z KITL + Jądro) z CE 5.0 na osobne moduły:
- nk.exe – kod startowy i implementacja warstwy OAL
- kernel.dll – implementacja jądra systemu niezależna od warstwy OAL dostarczona przez Microsoft
- kitl.dll – wsparcie do KITL zależne od platformy sprzętowej
- zmiana / dodanie kilku funkcji w warstwie OAL i KITL które są wymagane przez jądro (struktura OEMGLOBAL definiuje wszystkie funkcje i zmienne które warstwa OAL musi implementować)
- interfejs pomiędzy warstwą OAL a jądrem jest dobrze zdefiniowany we współdzielonych strukturach, a bezpośrednie odwołania do wewnętrznych funkcji z jądra, OAL i KITL nie są już możliwe – należy użyć dedykowany interfejs z NKStub.lib (biblioteka przykrywająca interfejs jądra, czyli wyeksportowane funkcje i zmienne zdefiniowane w strukturze NKGLOBAL) i funkcji KITLIoctl(), OEMIoControl().
Przeniesienie warstwy sterowników
Następujące sterowniki OEM i specyficzne dla platformy rozwojowej (development board) zostały zweryfikowane i dopasowane do wymagań CE 6.0:
- Au1550 PSC AC97 Audio, PSC I2S Audio – sterowniki dźwięku
- Alchemy ATI Rage XL, Silicon Motion Voyager – sterowniki wyświetlaczy
- Alchemy Ethernet, Alchemy PCMCIA, Alchemy Serial, Alchemy USB (OHCD) host controller, Alchemy USB Function, Au1550 PSC SPI Controller – grupa sterowników obsługujących magistrale komunikacyjne i interfejsy używane do komunikacji z innymi urządzeniami
- Highpoint HPT371/372 IDE Controller, Au1550 NAND FLASH Controller – sterowniki nośników danych
Projekt
- środowisko programistyczne: Platform Development Tools zintegrowane z Visual Studio® 2005 (zastępuje wcześniejsze osobne środowisko Platform Builder)
- język programowania: C, C++ (dla niektórych sterowników)
- wielkość: 5 osobo-miesięcy
Jeden z naszych zespołów w czasie pracy nad projektem:
