Autor Thema: Kleine Vorstellung  (Gelesen 9179 mal)

NoeTrimm

  • Beiträge: 36
    • Profil anzeigen
Gespeichert
« am: 17. April 2008, 20:00 »
Buenas noches alle Miteinander,

ich dachte mir, da ich neu hier bin, möchte ich mich einmal kurz vorstellen. Ich habe einfach die Erfahrung gemacht, dass es wesentlich schöner ist zu wissen was für Forumnewbies hier rumgeistern, daher:

Ich bin kanasaru und OS-Entwickler.

In diesem Satz sind schon mal zwei unwahrheiten. naja toller einstieg  :roll:
Ich würde mich gerne mal OS-Entwickler nennen dürfen, aber derzeit bin ich wohl eher noch nicht soweit.
Ich programmiere seit insgesamt 10 Jahren. Angefangen hab ich damals mit C und C++. Sozusagen meine Muttersprache, denn ich komme einfach nciht davon weg. Später habe ich noch Pascal gelernt und bin dann vor 3,5 Jahren in die Webentwicklung gegangen. Habe meine html kenntnisse um PHP, SQL, Javascript und CSS erweitert. Dies hat mich lange Zeit ausgefüllt und mir schöne Projekte gebracht, sowie einige erfahrung auf dem gebiet. Aber vor einem Monat ungefähr wollte ich das nicht mehr. Meine resourcen waren fast ausgeschöpft. Ich habe oft nur alte projekte und datein wiederholt und das bin nunmal nicht ich. Ich entwickle lieber lösungen und verwende sie nicht nur.
Daher bin ich zum Urschleim zurück und hab begonnen Assembler zu lernen. Mittlerweile bin ich soweit, dass ich die grundstrukturen und Befehle verstanden habe, aber die Praxis fehlte noch. Deshalb entschloss ich mich eine alte Idee aufzugreifen. Wie man ja überall in foren oft dümmlich liest: "Ich will ein betriebssystem schreiben, welche progs brauch ich dafür".

Aber ich hab mich erstmal informiert und bin zu eurem forum gelangt. An dieser stelle ein dickes Lob für die Tolle deutschsprachige referenz.
Sofort hab ich mich an die Tutorials von Tee-Jay gemacht. Die meisten habe ich schon durchgearbeitet, aber ganz ehrlich, aufs erste lesen nicht viel verstanden. Aufbau der CPU und Co waren mir zwar kalr aber als ich bei Protected Mode und Kernel in C angelangt war, merkte ich das Grundlegende Fragen einfach geklärt werden müssen. Außerdem will ich verstehen was ich da hinschreibe und nicht nur ein blödes Scriptkiddie sein.

Deshalb bin ich auch hier. Sicherlich um meine Wissenslücken zu füllen, aber auch um das Forum soweit es mir möglich ist zu bereichern.

Ich hoffe ich hab nicht zuviel geschrieben, aber ich dachte das es euch interessiert.

Hasta luego,
Kanasaru

blitzmaster

  • Beiträge: 77
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 17. April 2008, 20:23 »
Herzlich Wilkommen!  :-)
Es freut mich, wenn unsere Community hin und wieder doch mal neue Mitglieder bekommt, die auch ernsthaft was machen wollen  :-)
A / OS PM - THE operating system of the future

NoeTrimm

  • Beiträge: 36
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 17. April 2008, 20:28 »
Vielen Dank.

Ich hatte mich schon etwas früher hier registriert aber nie einen registrierungslink bekommen. Daher musste ich auch ne weile warten.

Aber nun ist es ja möglich (also der login)

Genau, ernsthaft was machen wollen. daher kämpfe ich mich nun schon zum siebten mal durch das Protected Mode Tutorial durch. Aber mit jedem Lesen verstehe ich mehr. Zumindest den Bootloader von Tee-Jay habe ich verstanden und auch den aufbau von FAT 12 und wie man das händelt. Aber GDT, IDT und Co bringen mich noch in den wahnsinn.
Aber ich will nunmal nicht im realmode sondern gleich im protected mode starten  :x

Mein Kopf raucht  :?

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #3 am: 17. April 2008, 20:59 »
Herzlich Willkommen!

Ich nehme mal an, du hast diese Seite schon gefunden, oder?

Hast du denn schon mit Programmieren angefangen? Für einen ersten Anlauf ist es grundsätzlich nicht schlecht, die Theorie gleich auszuprobieren und mal ein paar Erfolgserlebnisse zu sammeln. ;-)

Weiter möchte ich hier einmal mehr die Empfehlung abgeben, für den Anfang GRUB als Bootloader zu benutzen.

Falls du kleinere Fragen schnell klären Möchtest, wäre der IRC-Kanal eine gute Anlaufstelle.

NoeTrimm

  • Beiträge: 36
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 17. April 2008, 21:18 »
Thanks FreakyPenguin

Ja ich habe schon ein wenig rumprogrammiert. jedoch nur im RM. hab dafür die Tutorials 16-bit console und co durchgearbeitet und das hat auch alles ganz gut geklappt. auch mein "rumfuschen" im Quelltext hat auch nicht nur fehler verursacht. von daher super. Die Lowlevel ausgaben habe ich auch alle gelesen.

Also von daher hab ich schon ein wenig gemacht.

Aber ums mal auf den Punkt zu bringen was ich erreichen möchte mal hier meine Zielsetzung:

1.) Bootloader der von FAT 12 die Kernel.bin laden kann (dank Tee-Jay: abgehakt)
2.) ein Betriebsystem welches

a. im protected Mode läuft
b. Microkernel
c. Multitaksing
d. vorerst in VGA Textmodus 80 x 25, später mehr
e. Tastaturtreiber
f. konsole
g. ein zwei testprogramme
h. assembler wo es nötig ist, C wo es möglich ist
i. ...

Sicher könnte ich noch mehr aufzählen, aber dann wirds noch utopischer  :-D

Was mich interessieren würde, wäre zb. in welcher reihenfolge ich vorgehen sollte um das zu realisieren, denn ich habe schon oft in der c/C++ programmierung aber auch webentwicklung gemerkt, das gtue planung alles ist. denn wie oft baut man sich alles toll zusammen, nimmt das nächste ziel und man muss alles umbauen. kurz gesagt, vorausschauend programmieren.

Was ich nciht will ist ein eigenen Dateiformat oder Execute Format erfinden. FAT/ext2 und ELF/EXE reichen finde ich.

Also wer mir helfen kann einen Strukturplan aufzustellen, würde mir schonmal sehr helfen.ZB. lese ich gerade (mal wieder) im Protected Mode tutorial, dass in der GDT mindestens 3 Discriptoren stehen müssen (inkl. null discriptor. Aber da mir die bedeutung noch nciht ganz klar ist und mir auch noch das genaue spiel von zb. treibern und system schleierhaft ist, würde jede Struktur mir schonmal weiterhelfen. o hätte ich auch einen ungefähren Fahrplan wie ich am sinnvollsten die Tuts durcharbeite, ect...

*nach oben guck* Wow. ich hab nen hang zum langen texten  :roll:

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #5 am: 17. April 2008, 21:51 »
Gut, das ist ja schon mal was. ;-)

Okay, dann fangen wir mal an...
Ich würde dir, wie schon erwähnt, empfehlen für den Anfang Grub zu benutzen, damit kannst du schon mal eine Fehlerquelle auschliessen. Und wenn du später willst, kannst du den Bootloader ja problemlos ersetzen. (Ich zweifle aber daran, dass du das willst, sobald du Grub schätzen gelernt hast. ;-))

Hm hast du den ersten Link den ich dir angegeben habe schon durchgelesen? Denn die Frage nach dem Vorgehen am Anfang, wird dort eigentlich recht ausführlich erläutert. Falls dir etwas bestimmtes nicht klar ist, fragst du am Besten genauer.
OS-Dev für Einsteiger

NoeTrimm

  • Beiträge: 36
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 17. April 2008, 22:17 »
Ok. ich hab mich mal eben reingelesen udn werde es noch weiter lesen. Aber ich bin gleich auf eine sache gestoßen.

Da steht nachdem ich den PIC Programmiert habe kann ich ja ein wenig rumbasteln und mich an einen tastaturtreiber setzen. Jetzt meine Frage:

Das ist doch bis dahin kein treiber im eigentlichen sinne oder? ich biete doch lediglich einen funktionsblock der bei dem tastaturinterupt ausgeführt werden soll. wenn ich von einem treiber rede so muss dieser doch im hintergrund laufen (sprich multitasking) das ist da aber nicht noch ncith erklärt. Was mich widerum verwirrt. Oder hab ich ein völlig falsches verständnis von treibern???

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 17. April 2008, 22:31 »
Ein Treiber ist das Stück Code, das macht, daß Hardware tut. Wenn du das einfach reinbastelst ist das durchaus ein Tastaturtreiber. Du hast dann allerdings erstmal etwas, was eher nach einem monolithischen Kernel als einem Microkernel aussieht. Im Hintergrund läuft der Treiber ja schon allein dadurch, daß er nur durch den Interrupt gelegentlich aufgerufen wird (aber das würde ich sowieso nicht als Voraussetzung sehen, damit es sich Treiber nennen kann).
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

NoeTrimm

  • Beiträge: 36
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 18. April 2008, 09:25 »
Soweit hab ich das verstanden. Also ist der, um bei der Tastatur zu bleiben, Tastaturtreiber nur ein Routine für den Interrupt.
Ich habe ja als ich meine ersten Schritte beim OS-Dev gemacht habe bzw noch mache im Real Mode gearbeitet und dort in einem Bsp. Kernel die Funktion get_char gehabt. Sozusagen also eine Routine für den Tastaturinterrupt.
Gehe ich richtig in der Annahme, dass ich diese Funktion einfach wieder verwende? Natürlich mit Einbeziehung der IDT usw. Aber generell.
Ich verstehe da aber noch nciht die Fkt. des Tastaturtreibers. Ich kann ja in meinem Kernel (nehmen wir mal an ich hätte Multitasking) nicht ständig auf ein zeichen warten, oder doch?
Oben wurde ja schon richtig gesagt: Eine Routine für den Interrupt. Das warten auf den Interrupt, mittels get_char() zb. ist nach meinem verständnis doch nur eine art haltepunkt im system...

Ich hoffe ihr versteht mich. Denn ich glaube ich denke vollkommen falsch...

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 18. April 2008, 11:44 »
get_char() ist aber nicht die Routine für den Interrupt, sondern die Routine, die auf einen Interrupt wartet. Ich denke, du wirfst hier zwei Sachen durcheinander: Den Treiber und die Anwendung. Der Treiber würde beispielsweise ein eingegebenes Zeichen in einen Tastaturpuffer speichern, nichts weiter. Dein getchar() ist dann die Anwendung, die wartet, bis in diesem Puffer etwas auftaucht.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

NoeTrimm

  • Beiträge: 36
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 18. April 2008, 12:05 »
Ahh. Ich glaub es klingelt  :roll:

Also nehmen wir an ich drücke eine Taste. Der Interrupt wird ausgelöst. Meine IDT verweißt dann auf die Routine die ich für diesen Interrupt im Kernel vorgesehen habe. Zb. das Zeichen in einen Puffer zu schreiben.

Und das ist mein Tastaturtreiber.

Wenn jetzt, sagen wir, mein Betriebsystem in Form einer Konsole auf die eingabe eines Befehls wartet, so macht es nichts anderes als im puffer nachzusehen ob was drin steht und es dann auszulesen, auszuwerten, auszugeben, ect. (Bsp. dei einem befehl der mit enter bestätigt werden soll, den puffer einlesen, gucken ob Puffer einen Wert hat -> nein, dann weiter puffer lesen, -> Ja, dann gucken ob die Enter-Taste im puffer steht -> Nein, dann zeichen ausgeben, Puffer leeren und weiter den Puffer lesen, bis wieder ein zeichen drin steht.)


So richtig vom Verständnis her???

Termite

  • Beiträge: 239
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 18. April 2008, 12:51 »


und wenn kein zeichen im puffer ist, wartet deine konsole so lange bis über dein Tastatur interrupt ein zeichen in den puffer geschrieben wird. Das kann man dann z.B. über Betriebsystem synchronisations mechanismen lösen. geht aber auch über eine volatile variable.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 18. April 2008, 13:07 »
So richtig vom Verständnis her???
Das haut so grob hin, ja. Zumindest vorerst. In Wirklichkeit hat natürlich z.B. kein OS die Shell im Kernel (hoffe ich jedenfalls), aber das kannst du ja alles noch über die Zeit anpassen, wenn du merkst, daß Änderungen nötig werden.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

NoeTrimm

  • Beiträge: 36
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 18. April 2008, 13:58 »
Das haut so grob hin, ja. Zumindest vorerst. In Wirklichkeit hat natürlich z.B. kein OS die Shell im Kernel (hoffe ich jedenfalls), aber das kannst du ja alles noch über die Zeit anpassen, wenn du merkst, daß Änderungen nötig werden.

 :-o Was kommt denn dann in den Kernel? Ich weiß ist jetzt ne sau dumme Frage, aber ich muss sie jetzt einfach stellen.
Ich weiß, anlegen der GDT, IDT, ne printk(), usw. aber wenn ich die Treiber später auslagere und all das erledigt ist, soll ja mein betriebssystem irgendetwas machen bzw mit dem benutzer aggieren. Und ob ich nun die shell als Programmdatei lade, oder diese direkt im kernel steht macht doch keinen unterschied, oder? Schließlich will ich ja dem benutzer ermöglichen Programme zu starten und das kann er ja nur indem er mitteilt welche die kernel laden soll...

Warum dann nicht die shell als Teil des Kernels?


EDIT: Ich glaube das fällt hier alles schon aus off-topic raus. daher werd ich mal dafür nen thread eröffnen, damit off-topic auch zurecht seinen Namen trägt.

Danke für die bisherigen Antworten
« Letzte Änderung: 18. April 2008, 14:16 von Kanasaru »

 

Einloggen