Paloxena
Der Name Paloxena stammt von der wissenschaftlichen Bezeichnung für die „Grüne Stinkwanze“ („Palomena“), ein „Bug“ also. Und das wird das OS wohl vermutlich ausmachen.
Inhaltsverzeichnis
paloxena1
paloxena1 ist das „ursprüngliche“ Paloxena, das geschrieben wurde, weil MyXomycota so ziemlich kaputt war. Dummerweise wurde es noch viel kaputter. Deshalb gibt es jetzt paloxena2 (Und paloxena3. Und paloxena3.5. Und paloxena4). Irgendwann muss man ja einen Glückstreffer landen.
Programme
- FASM 1.69.08: Ein Assembler mit Intelsyntax
- µsh 0.002: Die Shell (portiert von MyXomycota)
- Paloxoreutils:
- ls
- cat
- Paloxena nettools:
- dig
- ping
- mbr: Gibt 512 Bytes einer Datei von einer gegebenen Position an in Hex-Editor-Form aus
- maumau: Der Klassiker von MyXomycota
- brainfuck: Brainfuckcompiler
Screenshot
Hier passend zum Namen ein Bild von einem Pink Screen Of Death (Dank an Hartmut für die Inspiration):
paloxena2
Hast du nicht schon genug Betriebssysteme zu unterhalten?
paloxena1 war ein halbes Abkopieren von MyXomycota. In meinem „Wahn“, alles schön zu machen und gut zu designen, habe ich mich wohl übernommen. Es entstand ein hübsches einheitliches Treiberinterface, das sowohl für die Console als auch für Dateisystemtreiber verwendet werden konnte. Leider hatte die Console dann jede Menge Code zu liefern, der total unnötig war. Den gleichen Code habe ich dann auch z. B. für den PCI-Treiber verwendet. Deshalb soll paloxena2 darauf ausgerichtet sein, wieder ein differenzierteres und vor allem einfacheres Treiberinterface zu liefern. Es soll nicht mehr schön sein. Es soll einfach funktionieren. Außerdem soll es eigentlich so tolle Sachen wie SMP und Threading mitbringen, hoffen wir, dass ich irgendwas dazu rausfinde. ;-)
Syscalls
Erwähnenswert ist das geplante Syscallinterface. Nachdem ich in paloxena1 bereits versucht habe, die POSIX-Calls zu implementieren (ursprünglich, um die Newlib möglichst einfach portieren zu können – welche in meinen Augen aber kaputt ist), habe ich mich nun entschlossen, die Syscalls einfach umzunummerieren, sodass mein open-Syscall die gleiche Nummer wie der open-Syscall von Linux hat, und so weiter. Dadurch sollen für Linux kompilierte Programme nativ unter paloxena2 ausgeführt werden (ganz einfach, weil ich sowieso die gleichen Syscalls habe, da kann man auch die Nummern umlegen). Dies bringt voraussichtlich vor allem den Vorteil, dass ich keine libc wirklich portieren muss, da ich die von Linux nutzen kann. Bis jetzt klappt es mit der glibc noch nicht so richtig, die diet libc spielt aber schon gut mit.
ppp
Zum „Crosscompilieren“ (das ja dank der Syscalls eigentlich ein natives Compilieren für Linux ist) gibt es auch ein eigenes Repo, genannt „ppp“, kurz für „Paloxena's Patched Packages“ (ja, der Name klingt absichtlich so bescheuert). Es ist lbuilds von týndur nachempfunden. „Portiert“ wurden bisher folgende Programme (wenn auch mehr schlecht als recht):
- dash 0.5.5.1 (Version der Almquist Shell)
- FASM 1.69.11 (s. o.)
- maumau 0.5 (Was sonst)
- pdksh 5.2.14 (Public-Domain-Version der Korn Shell)
paloxena3
Oh, mein Gott.
Ja. Es ist schon wieder passiert. Auch paloxena2 war zu kaputt, also gibt es nun paloxena3. Im Großen und Ganzen verfolgt es die gleichen Ziele wie paloxena2 (SMP, Threads, einfacheres Treiberinterface). Bei paloxena2 gab es aber erstens das Problem, dass ich anfangs noch keine Ahnung von SMP hatte und ich das OS zweitens zu Beginn nur als Testplattform für meinen CDI-USB-Treiber verwendet habe – das soll bei paloxena3 von Anfang an besser laufen.
OSOD
Neu bei paloxena3 ist der OSOD, der Orange Screen Of Death. Die einen schwerwiegenden Fehler anzeigende Farbe ist also nicht mehr pink oder violett, sondern orange, meine Lieblingsfarbe (#FF4000, um genau zu sein). Hier ein entsprechender Screenshot:
paloxena4
Aus Spaß an der Freude habe ich mir noch einen Rewrite gegönnt, der allerdings das VFS von paloxena3.5 weiterverwendet. Dieser Rewrite ist zum ersten Mal einigermaßen portabel und wurde bisher auf den i586 sowie auf den Game Boy Advance mit einem ARM7TDMI als CPU (ohne MMU) portiert. Details zum VFS, den aktuellen Features und den Besonderheiten auf dem GBA befinden sich auf der Website.
Damit das nicht alles war, hier noch ein Screenshot von der GBA-Version direkt nach dem Booten (unter einem Emulator, da ich nicht mal einen GBA besitze):
Wie man evtl. erkennen kann, unterstützt paloxena4 wie auch seine Vorgänger CDI, bisher allerdings nur CDI.audio (Man beachte das kleine „cdi.audio“ in Zeile 9). Für den GBA existiert auch ein entsprechender Treiber.
