"Niestabilność" MiNT-a wynika z dwóch TOS-owych zaszłości, które przekładają się na dwie wielkie dziury w ochronie pamięci:
1) ochronie nie podlega pamięć BIOS-u, sterownika twardego dysku i wszystkich programów załadowanych z AUTO przed MiNT-em. Każda (przypadkowa) ingerencja w ten obszar może się skończyć tragicznie.
2) jeden proces - konkretnie AES - ma specjalny przywilej bezkarnego zapisu danych do pamięci aplikacji, nawet jeśli ta pamięć jest chroniona. AES natomiast nie jest stuprocentowo odporny na nieprawidłowe parametry zawarte w global array w chwili jego wywołania - z czego wynika, że przy odrobinie szczęścia (pecha) można skłonić AES do zapisu danych w chroniony obszar i uwalić system.
To drugie można rozwiązać na dwa sposoby:
1) przenosząc AES całkowicie do userspace i likwidując jego odrębność od wywołującej go aplikacji. AES działałby wtedy jako zwykła biblioteka (dzielona) a wszystkie jego operacje wykonywane byłyby "w imieniu" procesu użytkownika (czyli w imieniu aplikacji GEM). W przypadku naruszenia ochrony pamięci uwaleniu ulegałaby aplikacja, a system pozostawałby nienaruszony.
To był mój pomysł, którego Frank chyba nawet nie był w stanie zrozumieć (nie znał się zupełnie na GEM-ie).
2) przenosząc AES całkowicie do kernelspace i likwidując jego odrębność od kernela. AES działa "w imieniu" procesu użytkownika (w imieniu aplikacji GEM). W przypadku naruszenia ochrony pamięci uwalana jest aplikacja, a system pozostaje nienaruszony - niestety, AES w tym przypadku działa z prawami kernela (nie wiadomo, po co), więc śmiecie w global array ciągle mogą spowodować zniszczenie całego systemu.
To jest to, co zostało zrobione w postaci modułu kernela XaAES.
MagiC natomiast jest niestabilny sam z siebie, przypuszczalnie z powodu błędów w kernelu i spółce, i jest sobie w stanie sam tak namieszać w swoim własnym wnętrzu, że się wywróci po zadaniu mu np. kopiowania pliku jego własnym desktopem.