Eigenes OS?
-
Ich habe mal dieses "halbfertige" Tool att2intl.exe eingesetzt:
man gibt z.B. asmcode.s (ATT) ein und erhält asmcode.asm.Beispiel:
"outb %%al,%%dx"::"d" (port), "a" (value)
==>
"out BYTE ["a" +value], BYTE %dx":[:"d" +port], %al
allerdings funktioniert
inline void outportb(unsigned int port,unsigned char value) { asm volatile ("out BYTE ["a" +value], BYTE %dx":[:"d" +port], %al); };
mit gcc -c ckernel.c -o ckernel.o -masm=intel nicht.
ckernel.c: In function `outportb':
ckernel.c:39: parse error before "a"Kann da jemand bitte etwas nachhelfen? Ansonsten bleibt es eben bei der AT&T-Sysntax.
-
@abc.w: Konntest Du das Problem lösen? Möchte niemanden verlieren.
The other main snag concerns object-file formats. There are two variants of the 32-bit COFF format: one used by Microsoft Win32 tools, and one by the rest of the world. They are only subtly different, and linkers which expect one format will happily link the other. The difference comes in the relocations: if you write code in, say, NASM, and link it using the Microsoft linker along with some modules compiled using Visual C++, the addresses in the final output will come out wrongly. Thereâ€s no real workaround for this, but luckily most tools that work with the PE format will allow you to emit files in the Win32 format: NASM has its -f win32 option, and Cygwin has the pei-i386 output format.
For LD (the linker that is most often used with DJGPP and gcc) use the option --oformat binary.
EDIT: delete (gelöst): del (anstelle delete; einer meiner Uraltfehler) u. -o beim Linker
-
@+fricky:
generische 'driver' struktur definieren, die bestandteil spezialisierter strukturen ist
hast du einen Link oder ein beispiel-OS vor Augen. würde mir das gerne mal an einem konkreten beispiel anschauen. thema passt momentan genau, bin da dran.
-
Erhard Henkes schrieb:
Was nimmt man da bei Win XP? delete ging nicht. Oder kann man bei rename einen Parameter angeben, der bestehende files überschreibt.
Nimm
copy /Y rename a.out ckernel.bin
.cheers, Swordfish
PS: toller Thread!
-
Erhard Henkes schrieb:
@+fricky:
generische 'driver' struktur definieren, die bestandteil spezialisierter strukturen ist
hast du einen Link oder ein beispiel-OS vor Augen. würde mir das gerne mal an einem konkreten beispiel anschauen. thema passt momentan genau, bin da dran.
was konkretes wüsste ich jetzt auch nicht. such mal im internet nach 'i/o model' oder so ähnlich. z.b. in der linux doku müsste sowas zu finden sein und in irgendwelchen büchern über betriebssysteme natürlich auch.
ach, vielleicht hilft das:
http://cespc1.kumoh.ac.kr/~juyoon/lecture/osd/2006/osd08.pdf
-
Nimm copy /Y rename a.out ckernel.bin.
Komischerweise wird das /Y im makefile nicht akzeptiert (unter MS-DOS sollte es gehen). Ich habe mich nun an die -o Option beim Linker erinnert. Die macht alles platt.
So geht es, zumindest bei mir mit gcc 3.1:
all: nasmw -O32 -f bin boot.asm -o boot.bin nasmw -O32 -f aout kernel.asm -o kernel.o gcc -c ckernel.c -o ckernel.o ld -T kernel.ld kernel.o ckernel.o -o ckernel.bin cmd /c copy /b boot.bin + ckernel.bin MyOS.bin partcopy MyOS.bin 0 800 -f0 del kernel.o del ckernel.o del ckernel.bin del boot.bin
Ich habe versucht, den Prozess auch grafisch (inzwischen mit video.c) darzustellen: http://www.henkessoft.de/OS_Dev/Bilder/make_process.PNG
Linker \1:
OUTPUT_FORMAT("binary") ENTRY(RealMode) SECTIONS { .text 0x8000 : { *(.text) } .data : { *(.data) } .bss : { *(.bss) } }
In einem anderen Thread hier habe ich brauchbare Mischung aus Hexeditor+Disassembler+Rechner gefunden:
http://members.inode.at/anton.zechner/az/Disassembler.htm
Echt interessantes Teil.
-
@+fricky: Danke für den Link. Hier ist auch eine interessante Architekturübersicht (kompakt): http://www.samueldotj.com/Ace/Architecture.asp
-
hier haste noch'n paar interessante slides zu dem thema
http://www.minix3.ru/docs/slides/Ch3.pdf
-
@+Fricky: danke für die Links, aber teilweise schon etwas weit in den Details, dafür aber wieder zu komplex und gleichzeitg theoretisch. Das verwirrt momentan mehr als es beim Design hilft.
Zur Zielsetzung ist eine abstrakte theoretische Diskussion auf der Meta-Ebene notwendig. Die Herausforderung besteht darin, dass es keine Übereinstimmung darin gibt, wie man ein OS optimal aufsetzt (cf. Tanenbaum, Modern Operating Systems, 2nd Ed., Chap. 12: Operating System Design). Das finde ich nach diesen vielen Jahren schon interessant.
Einige Dinge weiß man aber inzwischen:
Monolithische Kernel (Windows, Linux) sind erfolgreicher als Micro Kernels. Das hat aber lediglich Effizienzgründe und keine strukturelle Basis, kann uns also egal sein.
Präemptives Multitasking (Modernes Windows) ist aus Sicht eines Prozesses besser als kooperatives (klassisches Windows).Tanenbaum sieht vor allem vier Aufgabenfelder eines OS:
- Abstraktion schaffen (schwierigste Aufgabe)
- Primitive Operationen bereit stellen
- Isolation sicher stellen
- Hardware Management
Files, Prozesse, Synchronisation, Speichermodelle, I/O System, System calls, Fehlerseparation durch voneinander unabhängige Systeme, ... da stehen wir ja praktisch nicht mehr am Anfang, aber ob wir bereits im Optimum sind, das ist noch offen. Die Kontrolle der Hardware ist eher eine Fleissaufgabe.
Ein OS ist ein gigantisches Software-Paket. Unix hat mehr als 1 Mio., Linux 2.6 ca. 5,7 Mio., Win 2000 ca. 29 Mio., Win XP ca. 35 Mio. und MS Vista ca. 50 Mio. Zeilen Sourcecode. So etwas kann also keinesfalls in der Zielgeraden liegen. Daher muss man sich von diesen Systemen als Zielbild lösen.
Das Entscheidende dabei ist, dass niemand in wenigen Monaten ein neues OS schreiben kann. Diese Illusion sollte man rasch aufgeben. Bei einem Hobby-/Lehr-Projekt geht es also vor allem darum - didaktisch möglichst klar dargestellt - ein Verständnis für die Zusammenhänge und Möglichkeiten auf der untersten Ebene zu schaffen.
Es macht m.E. mehr Sinn, zunächst in der Historie anzuknüpfen und von dort aus neue Wege zu suchen. Das Original MS-DOS 1.0 (1981) besteht z.B. aus rund 4.000 Zeilen Assembler-Code (nicht offen gelegt). Die grundlegenden Funktionen dieses Systems lassen sich leicht nachvollziehen und verstehen. Es gibt inzwischen freie Clones.
MS DOS hatte vier Bereiche und arbeitete nur im RM:
- Bootcode
- io.sys = Geräteroutinen (Monitor, Tastatur, Festplatte, Schnittstellen)
- command.com = Befehlsinterpreter
- Ausführung von Programmen (COM, EXE)
Befehle:
"intern":
del, erase - Dateien löschen
rd, rmdir - Verzeichnis löschen
dir - Verzeichnisinhalt anzeigen
cd, chdir - Verzeichnis wechseln
cls - löscht den Bildschirminhalt
md, mkdir - Verzeichnis erstellen
copy - Kopieren einer oder mehrerer Dateien
ren, rename - Umbenennen von Dateien oder Verzeichnissen
type - Anzeigen von Textdateien
set - zeigt DOS Umgebungsvariablen oder legt eine neue fest
ver - zeigt die DOS Versionsnummer
vol - zeigt die Datenträgerbezeichnung an"extern":
attrib - Zeigt Attribute von Dateien oder legt diese fest
fdisk - Partitionierung der Festplatte erstellen oder verändern
move - Verschieben von Dateien
mem - Anzeigen der Belegung des Arbeitsspeicher
tree - Zeigt die Verzeichnisstruktur an
format - Formatieren eines DatenträgerEDIT: MS-DOS hatte auch einige Systemaufrufe wie den berühmten int 21h... (Anmerkung von abc.w)
http://www.operating-system.org/betriebssystem/bsgfx/microsoft/msdos_211-scr-.gif
Tanenbaum empfiehlt folgende drei Punkte für das Design:
Einfachheit, Vollständigkeit und Effizienz.
-
Erhard Henkes schrieb:
Es macht m.E. mehr Sinn, zunächst in der Historie anzuknüpfen und von dort aus neue Wege zu suchen.
Meine Rede! Man muß sich nur trennen von der Ansicht, daß im RM nur 1 MB RAM adressierbar sind. Dann müssten die Ideen eigentlich nur so hervorsprudeln. Vorausgesetzt natürlich, das Ziel ist nicht, DOS einfach nur zu kopieren.
-
Man muß sich nur trennen von der Ansicht, daß im RM nur 1 MB RAM adressierbar sind.
Gibt es hierzu bereits ein stabiles Hobby-/Lehr-OS, das man sich mal anschauen könnte?
Ich denke nicht, dass der Protected Mode das zentrale Problem ist, eher was daraus gemacht wurde. Die Adressierung ist beherrschbar (eine Zeigerebene mehr und Paging, dafür hat man flat Speicher-Adr.). Multitasking mit allen Problemen muss ja z.B. nicht sein. Es geht doch eher darum, die enorme Leistung eines heutigen PC, die unter Windows (und inzwischen auch Linux) verschüttet wird, frei zu legen und Programmen bereit zu stellen.
perfection is reached not when there is no longer anything to add, but when there is no longer anything to take away.
Antoine de St. Exupéry.
Protected Mode has several advantages over Real Mode:
1. Protected Mode has Protection, the ability to keep programs from messing around and crashing each other(this is how Proctected Mode got its name).
2. You may only have several tasks (like Windows and Linux).
3. You have 4GB of address space (A20-Gate enabled).
4. You can use paging to access memory.http://www.osdever.net/tutorials/gettingstarted.php
Wichtig ist nach Tanenbaum eine Abstraktionsidee, Beispiele:
alles ist ein Tape (Fortran)
alles ist ein File (Unix)
alles ist ein Objekt (W2K)
alles ist ein Dokument (www)A.S.Tanenbaum ist ja immer einer der Verfechter des aus seiner Sicht "eleganten" Microkernel-Prinzips gewesen, das er im OS Minix umsetzte.
-
Erhard Henkes schrieb:
MS DOS hatte vier Bereiche und arbeitete nur im RM:
...
Befehle:
...
"intern":
...
"extern":
...Vorsicht... vorsicht... MS-DOS hatte auch einige Systemaufrufe wie den berühmten int 21h...
-
@abc.w: ja, das ist richtig. Hat das mit dem Compilieren/Linken nun geklappt, oder gibt es da noch ein Grundsatzproblem?
-
Erhard Henkes schrieb:
@abc.w: ja, das ist richtig. Hat das mit dem Compilieren/Linken nun geklappt, oder gibt es da noch ein Grundsatzproblem?
Das habe ich noch nicht hingekriegt...
-
@abc.w: Schade, dass wir nicht wissen, woran es exakt liegt. Probiere doch mal parallel den DJGPP: http://www.osdever.net/downloads/compilers/DJGPP-Installer-nocpp.exe
Vielleicht erkennst Du dann, woran es genau liegt. Wenn ich es richtig verstanden habe, macht der Linker Probleme.
http://www.henkessoft.de/OS_Dev/Bilder/make_process.PNG (gelb)Ich hatte hier noch einiges zusammen getragen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-236354-and-postdays-is-0-and-postorder-is-asc-and-start-is-130.htmlNASM has its -f win32 option,
and Cygwin has the pei-i386 output format.For LD use the option --oformat=binary.
http://lists.zerezo.com/mingw-users/msg00383.htmlKeine Ahnung, ob das die richtige Spur ist.
Zur Erinnerung:
bei abc.w: i386pe
bei mir: i386go32Vielleicht kann jemand anderes hier zielgenau helfen.
-
Erhard Henkes schrieb:
@+Fricky: danke für die Links, aber teilweise schon etwas weit in den Details, dafür aber wieder zu komplex und gleichzeitg theoretisch. Das verwirrt momentan mehr als es beim Design hilft.
schau es dir einfach in ruhe an und lass dich davon inspirieren. du musst ja kein OS strikt nach lehrbuchmeinung basteln (das wäre auch langweilig), aber z.b. in den tanenbaum-slides sind prinzipien erwähnt, von denen man als os-designer mal was gehört haben sollte. was du davon verwertest und was nicht, bleibt dir überlassen. ich würde zumindest leichte erweiterbarkeit und austauschbarkeit von komponenten von vorn herein einplanen. nicht dass du später mal alles umbauen musst, wenn ausgaben statt auf dem bildschirm, in einer datei landen sollen.
-
ich würde zumindest leichte erweiterbarkeit und austauschbarkeit von komponenten von vorn herein einplanen. nicht dass du später mal alles umbauen musst, wenn ausgaben statt auf dem bildschirm, in einer datei landen sollen.
Das ist richtig. Abstraktion ist der entscheidende Punkt.
..
Folgende Punkte sehe ich bisher für mein "PrettyOS" (Deckname):
- Common affordable hardware platform (Standard PC ab 80386)
- Flat 32-Bit Virtual Memory Model (das bedeutet PM bei x86)
- Easy programming
- Simplicity (KISS Prinzip gilt in einer komplexen Welt immer mehr)
-
Habe mit mingw-Linker & Co ein wenig rumexperimentiert. Es funktioniert immer noch nicht und ich glaube nicht, dass es funktionieren wird...
Der mingw-Linker unterstützt folgende Formate:C:\BochsMyOS\20090327_eh_os>ld --help Usage: ld [options] file... ... ld: supported targets: pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec symbolsrec tekhex binary ihex ld: supported emulations: i386pe ...
Der nasm Assembler unterstützt folgende Formate:
C:\BochsMyOS\20090327_eh_os>c:\nasm-2.06rc6\nasm -hf ... valid output formats for -f are (`*' denotes default): * bin flat-form binary files (e.g. DOS .COM, .SYS) aout Linux a.out object files aoutb NetBSD/FreeBSD a.out object files coff COFF (i386) object files (e.g. DJGPP for DOS) elf32 ELF32 (i386) object files (e.g. Linux) elf ELF (short name for ELF32) elf64 ELF64 (x86_64) object files (e.g. Linux) as86 Linux as86 (bin86 version 0.3) object files obj MS-DOS 16-bit/32-bit OMF object files win32 Microsoft Win32 (i386) object files win64 Microsoft Win64 (x86-64) object files rdf Relocatable Dynamic Object File Format v2.0 ieee IEEE-695 (LADsoft variant) object file format macho NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X object files
D.h. der nasm Assembler kann Objektdateien erzeugen, die der mingw-Linker nicht kennt. Ausserdem scheint es problematisch zu sein, dass die Datei kernel.asm 16-Bit und 32-Bit Code enthält. Wenn man mit nasm versucht, z.B. win32 Format zu generieren, bekommt man zahlreiche Fehlermeldungen:
C:\nasm-2.06rc6\nasm -O32 -f win32 kernel.asm -o kernel.o kernel.asm:21: error: COFF format does not support non-32-bit relocations kernel.asm:27: error: COFF format does not support non-32-bit relocations kernel.asm:35: error: COFF format does not support non-32-bit relocations kernel.asm:40: error: COFF format does not support non-32-bit relocations kernel.asm:45: error: COFF format does not support non-32-bit relocations kernel.asm:50: error: COFF format does not support non-32-bit relocations kernel.asm:55: error: COFF format does not support non-32-bit relocations kernel.asm:59: error: COFF format does not support non-32-bit relocations kernel.asm:64: error: COFF format does not support non-32-bit relocations kernel.asm:69: error: COFF format does not support non-32-bit relocations kernel.asm:74: error: COFF format does not support non-32-bit relocations kernel.asm:82: error: COFF format does not support non-32-bit relocations kernel.asm:88: error: COFF format does not support non-32-bit relocations kernel.asm:117: error: COFF format does not support non-32-bit relocations make: *** [all] Error 1
Was COFF mit win32 Format zu tun hat, weiss ich jetzt nicht...
Dann habe ich mit ELF Format ausprobiert (scheint der kleinste gemeinsame Nenner zu sein, mingw-Linker und nasm können es beide und man kann die ckernel.o mit objcopy nach ELF konvertieren). Es kommt ungefähr folgende Fehlermeldung:C:\BochsMyOS\20090327_eh_os>ld -T kernel.ld kernel32.o ckernel_elf.o ld: cannot perform PE operations on non PE output file 'a.exe'.
Mit kernel32.o habe ich versucht, 16-Bit Code von 32-Bit Code zu trennen und die Datei ckernel_elf.o ist die ckernel.o konvertiert nach ELF.
Wie es aussieht, es geht mit mingw Tools nicht. Oder ich mache irgendwas falsch.Werde mir wohl den weisshaarigen DJGPP runterladen...
-
Werde mir wohl den weisshaarigen DJGPP runterladen...
DJGPP (gcc 3.1, ld 2.13):
ld.exe: supported targets: coff-go32 coff-go32-exe a.out-i386 srec symbolsrec tekhex binary ihex
ld.exe: supported emulations: i386go32mingw (ld 2.17.50 20060824 )
ld: supported targets: pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec symbolsrec tekhex binary ihex
ld: supported emulations: i386peHat da jemand die Lösung für den ASM-Kernel (16 u. 32 Bit) bezüglich Kopplung von NASM output file und Linker (ld 2.17) input file?
-
Erhard Henkes schrieb:
Momentan schmökere ich gerade im Buch von Richard A. Burgess "Developing Your Own 32 Bit Computer Operating System" (MMURTL V1.0). Er hatte sich bei seinem Operating System folgende Ziele gesetzt:
ah, ich glaub' das hatte ich mal in den fingern. ist schon ziemlich alt und er hat sein OS komplett in asm programmiert, ne?
Erhard Henkes schrieb:
The name is an acronym for Message based MUltitasking, Real-Time, kerneL."
'message based' bedeutet, dass kein timer-gesteuerter scheduler drin ist, sondern context-switches werden durch versenden von messages herbeigeführt, oder? finde ich gut. präemptives, gewaltsames multitasking nach zeitscheiben ist manchmal gar nicht so toll.
Erhard Henkes schrieb:
Folgende Punkte sehe ich bisher für mein "PrettyOS" (Deckname):
- Flat 32-Bit Virtual Memory Model (das bedeutet PM bei x86)
- Easy programming
- Simplicity (KISS Prinzip gilt in einer komplexen Welt immer mehr)ja, pretty-OS hört sich auch besser an, als der bisherige name.
flat memory model: was denn sonst? segment/offset-gedöns ist einfach nur übel.
easy programming: muss schon sein. keine übertriebenen schutzmechanismen, vertrau dem programmierer, denn er weiss, was er tut.
KISS: sehr vernünftig.