System operacyjny bez systemu plików
Do efektywnej pracy, większość systemów operacyjnych potrzebuje pamięci masowej, w której może przechowywać dane. Dane te są najczęściej umieszczane w sposób określony i ustandaryzowany, dzięki czemu istnieje możliwość dostępu do nich z poziomu różnych komputerów pracujących często pod różnymi systemami operacyjnymi lub architekturami sprzętowymi. Aby zapewnić jak największą funkcjonalność systemy plików są często bardzo skomplikowane i złożone. Implementacja, choćby najprostszego z rodzajów systemu pliku łączy się wieloma tygodniami pracy. Systemy plików są też ściśle powiązane z mechanizmem obsługi urządzeń zewnętrznych, przede wszystkim z obsługą kontrolerów pamięci masowej czy sterownikami kart sieciowych, których implementacja również nie należy do czynności banalnych. Ponieważ wymienione wyżej zagadnienia znacznie wykraczają poza ramy tej strony, w implementowanym systemie mechanizmy te nie zostały zawarte.
W implementowanym systemie, zarówno procedury należące do jądra systemu, jak też procesy aplikacji znajdują się w jednym pliku obiektowym. Ponieważ mechanizm ochrony systemu wymaga, aby jądro systemu i aplikacje uruchamiane były z innym poziomem uprzywilejowania, istnieje potrzeba oddzielenia tych procedur od siebie. Zadanie te wykonuje konsolidator według odpowiedniego skryptu.
Załączony powyżej kod, jest fragmentem skryptu konsolidatora, dotyczącym sekcji kodu implementowanego systemu - (pozostałe sekcję są skonstruowane podobnie). Zastosowanie tego skryptu powoduje umieszczenie procedur aplikacji (pliki task*), oraz bibliotek (pliki lib/libc.o) w innej niż jądro systemu stronie pamięci (wymuszone poprzez polecenie ALIGN(0x1000)). Dzięki temu rozwiązaniu procedury aplikacji mają inny poziom uprzywilejowania niż jądro systemu, co wiąże się z jego ochroną i umożliwia implementację procedur z zachowaniem ochrony zasobów.
Niestety takie rozwiązanie ma też szereg wad. Przede wszystkim aplikację korzystają z tych samych bibliotek co procedury systemu operacyjnego, mają więc do nich pełen dostęp. Kolejną wadą jest to, że wszystkie aplikacje znajdują się na tej samej stronie, co wiąże się z możliwością niekorzystnego wpływania procesów na siebie w razie wystąpienia błędu. Następnym problemem jest nieokreślona wielkość poszczególnych procesów aplikacji, co uniemożliwia implementację procedur systemowych takich jak fork() czy też exec().
Istnieje oczywiście możliwość ograniczenia większości wyżej wymienionych wad, jednakże wiąże się to ze znacznym skomplikowaniem pliku skryptowego. Należy pamiętać, że rozwiązanie te ma charakter jedynie tymczasowy i powinno być zmienione, po implementacji systemu plików.