Paloxena

Aus Lowlevel
Wechseln zu:Navigation,
Paloxena
Paloxena.png
Entwickler: XanClic
Akt. Version: 0.001-o
Lizenz: GPL
OS-Eigenschaften
Plattform: i386
Kernelart: Monolith
Sprache: C
API: POSIX-ähnlich
Binärformat: ELF
IPC-Methode: -
Homepage
Gitorious
Forum


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.

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. 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

Akt. Release

Die aktuelle Freigabe ist 0.001-o (zur Benennung der Versionen, siehe hier).

Screenshot

Hier passend zum Namen ein Bild von einem Pink Screen Of Death (Dank an Hartmut für die Inspiration): Paloxena-PSOD.png

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)