Wybór narzędzi do uruchomiania systemu
Implementacja jądra systemu operacyjnego jest z wielu powodów zajęciem bardzo skomplikowanym. Na fakt ten składa się przede wszystkim ograniczona liczba narzędzi, które mogły by taką pracę ułatwić. Projektanci zwykłych aplikacji dysponują szeregiem programów wspomagających, dzięki którym znalezienie błędu kodu jest wręcz trywialne. Do programów tych należą specjalne edytory wraz z opcją pracy krokowej (ang. trace mode), możliwością zakładania punktów kontrolnych (ang. breakpoints), czy też śledzenie wartości odpowiednich zmiennych - i to wszystko na poziomie języka wysokiego poziomu. Jednakże programista jądra systemu operacyjnego musi poradzić sobie z błędami kodu w inny sposób, gdyż na tworzony system takie aplikacje po prostu jeszcze nie istnieją.. Niezłym pomysłem może być tu pisanie i weryfikowanie procedur w innym systemie operacyjnym, lecz nie jest to rozwiązanie, które może być stosowane na dłuższą metę - nie gwarantuje bowiem pełnej zgodności z innymi procedurami.
Najlepszym pomysłem na rozwiązanie tego problemu jest zastosowanie dwóch środowisk uruchomieniowych przeznaczonych do testowania tworzonego systemu: komputera rzeczywistego, oraz programu emulatora.
Komputer fizyczny
Komputer fizyczny jest, oczywiście, niezbędnym narzędziem do pisania systemu operacyjnego. Umożliwia on uruchamianie systemu z pełną zgodnością sprzętową oraz pełną prędkością jaką może zaoferować sprzęt. Jednakże implementacja systemu operacyjnego na pojedynczym komputerze wiąże się z wieloma niedogodnościami. Przede wszystkim mocno utrudniony jest proces weryfikowania poprawności zmian dokonanych na systemie, gdyż wiąże się to z wielokrotnym restartowaniem całego systemu i długim czasem oczekiwania, aż system 'macierzysty' się załaduje. Problem ten można by było obejść korzystając z dwóch systemów komputerowych - jeden do implementacji, pracujący pod kontrolą systemu macierzystego wraz z uruchomionym środowiskiem programistycznym, drugi służący tylko do testowania implementowanego systemu. Jednakże te rozwiązanie ma dużą wadę - drugi system komputerowy nie zawsze jest dostępny. Jeśli implementacja systemu operacyjnego ma być prowadzona w ramach procesu szkolenia, to te rozwiązanie jest praktycznie niewykonalne - na jednego ucznia potrzeba by było dwóch oddzielnych komputerów.
Kolejną wadą środowiska uruchomieniowego opartego na fizycznym komputerze jest problem wykrywania błędów programistycznych. Najczęściej jakikolwiek błąd w implementowanym systemie powoduje całkowite zawieszenie komputera. W najlepszym przypadku, jeśli zostało wygenerowane przerwanie błędu, możemy dysponować danymi dotyczącymi zaistniałego błędu takimi jak: wypis rejestrów procesora, zrzut stosu programowego, czy zrzut określonego z góry fragmentu pamięci. Najczęściej jednak dane te niewiele mówią o sytuacji jaka wystąpiła i jedyne co możemy zrobić to restart systemu.
Następną istotną wadą takiego środowiska jest problematyczna zmiana konfiguracji sprzętowej takiego komputera, a więc trudność w przetestowaniu zachowania implementowanego systemu operacyjnego na różnych systemach komputerowych. Najczęściej zmiany konfiguracji wiążą się z wielokrotnym rozkręcaniem komputera.
Emulator programowy
Większość z powyżej wymienionych wad nie posiada emulator programowy systemu komputerowego. Emulator taki jest to najczęściej program uruchamiany z poziomu 'macierzystego' systemu operacyjnego. Program taki zachowuje się najczęściej jak zwykły proces, więc restart implementowanego systemu wiążę się, po prostu, z ponownym uruchomieniem programu (jedno kliknięcie myszą, czy też wpisanie jednej komendy w konsoli). Zazwyczaj również programy emulatora posiadają wbudowane mechanizmy ułatwiające wyszukiwanie błędów czy też śledzenie wykonywanych programów, co dla projektanta systemu operacyjnego ma wielkie znaczenie. Nie występuje też problem testowania systemu na wielu systemach komputerowych, gdyż zmiana konfiguracji emulowanego komputera wiąże się najczęściej ze zmianą wprowadzoną w pliku konfiguracyjnym emulatora i jego ponownym uruchomieniu.
Środowisko uruchomienowe oparte na emulatorze posiada jednak kilka podstawowych wad. Przede wszystkim emulowany komputer jest zdecydowanie wolniejszy od rzeczywistej maszyny. Spowolnienie pracy sięga rzędu wielkości, co może powodować pewne utrudnienie podczas implementowania systemu, a zwłaszcza procedur opartych na przerwaniach czy wywoływanych co określony interwał czasu. Kolejną istotną wadą jest niecałkowita zgodność emulowanego systemu z systemami rzeczywistymi. Stosunkowo często mogą zdarzać się sytuację, że komputer emulowany będzie się zachowywał inaczej w stosunku do jego rzeczywistego odpowiednika. Wiąże się to też z sytuacjami, w których implementowany system pracuje poprawnie na emulatorze, jednakże występują problemy na komputerze rzeczywistym.
Kolejnym problemem mogą być duże wymagania co do sprzętu, jakie posiada większość emulatorów programowych. Wynikiem tego będzie zajęcie dużej ilości zasobów komputera na którym pracuje emulator i znaczne spowolnienie jego pracy. Zjawisko to szczególnie jest łatwe do zaobserwowania na słabszych komputerach.
Ponieważ, podczas implementacji systemu, zależy nam na wszystkich pozytywnych cechach wymienionych środowisk, zalecane jest stosowanie ich obu w zależności od potrzeb i stopnia zaawansowania projektu.
W fazie implementacji oraz testowania jako środowisko uruchomieniowe z powodzeniem mogą służyć następujące narzędzia