Lowlevel
Lowlevel => Das Wiki => Thema gestartet von: bscreator am 01. March 2004, 12:09
-
Hallo Autoren,
könnt ihr in der nächsten Ausgabe die Kernelentwicklung in Assembler
als Thema behandeln ? Desweiteren wäre gut, wenn ihr das Entwickeln einer grafischen Oberfläche in Assembler ansprecht.
Tschüss
-
Also die Kernelentwicklung mit Assembler war schon Thema der ersten Ausgaben !
Du meinst wahrscheinlich tiefergehende entwicklungen.
Um eine GUI zu schreiben muss man erstmal sicher im Protected Mode sein, da der Real Mode durch seine begrenzte Speicherverwaltung nicht dafür zu gebrauchen ist.
Ich hab die aktuelle Ausgabe nur überflogen, aber ich glaub da gehts schon gut in richtung Protected Mode !
Ich würde mich auch freuen über informationen die in richtung auflösung ändern und grafikspeicher benutzen gehen. da gibts irgentwelche Standarts, deren namen ich aber vergessen hab.
Über dieses Thema ist im Internet nur recht wenig und nur schlecht sortiert und auf deutsch sowieso nichts vorhanden.
Vielleicht könnte man die Zeitschrift in 2 teile für einsteiger und für fortgeschrittene unterteilen. Dann könnte man eine noch grössere Zielgruppe abdecken.
-
haha ich guck mir grad die aktuelle ausgabe an... da wird kernelentwicklung auf deutsch behandelt
-
Hey neq,
das mit dem Unterteilen für Anfänger und Fortgeschrittene finde ich eine verdammt gute Idee. Für die Anfänger wäre wahrscheinlich das schrittweise Entwickeln eines einfachen Real-Time-OS interessant, das beispielsweise eine Diskette kopieren kann und einfache Dateiverwaltungen behandelt (glaube zwar, dass das mit der Dateiverwaltung auch nicht gerade einfach ist, die Autoren jedoch würden solche Themen den Anfängern sicherlich verständlich machen können).
Ich bin selber ein Anfänger und spreche deshalb aus Erfahrung
-
Alloa.
Ich denke es würde zu viel Aufwand machen gleich 2 Magazine zu entwickeln.
WIr bemühen uns ja extra die Artikel auch für Anfänger verständlich zu schreiben.
Zum Thema Protected Mode bin ich gerade am schreiben eines möglichst umfangreichen Tuts.
Allerdings kann das natürlich noch ein bisschen dauern.
Da werde ich dann auch Quelltexte und Zusatztools zum umschalten in den PMode beilegen.
Das mit der GUI denke ich hat noch ein bisschen Zeit.
Als erstes sollte man wohl mal eine einfache Shell bauen und ein Dateisystem sowie das lesen von Platte und Diskette integrieren.
GUI ist sehr aufwendig, da man dort wohl kaum um das Multitasking herumkommen wird, was auch nochmal ein großer Sprung sein wird.
Also habt bitte etwas nachsicht und fordert nicht gleich zu viel.
-
GUI???
Ne Leute, jetzt noch nicht. Bevor man ne GUI codet, muss man eine *sehr* gute Speicherverwaltung haben und außerdem ist das ganze VGA/SVGA/VESA-Zeug sehr kompliziert. Lieber erstmal nen stabilen Kernel hinkriegen und *dann* mit der GUI anfangen.
Und ne GUI in Assembler ist auch keine gute Idee. MenuetOS hat es zwar geschafft, aber ich sag euch, das ist verdammt kompliziert. Dagegen mit C++ (jawohl, C Plus Plus) ist es um einiges einfacher.
@TeeJay
Was wird dein Artikel genau behandeln? Ich muss schon mal ein bisschen planen...
-
Ich hab mir mal die Mühe gemacht und das Intel Manual bezüglich System Programming durchgelesen.
Und da wollte ich ein Tut schreiben, was es so im PMode alles zu beachten gibt. Was für Optionen es da gibt, wie diese Funktionieren und halt auch wie man in den PMode schaltet.
Dazu hab ich bis jetzt auch schonmal ein kleines Konsolen-App geschrieben mit dem man sich bequem die Deklarationen für Descriptoren erstellen lassen kann.
-
Ja genau VESA heisst der standart .. denke schon den ganzen tag nach wie der noch hies .. war aber zu faul zu suchen :)
ich meinte nich das man 2 magazine macht ... sondern eher folgendes:
ihr habt ja meist so 2 ausführliche artikel übers coden.
wie wärs wenn einer für anfänger (wat weiss ich Fat12 oda so)
und der andere für die dicken playas (z.b. VESA-Standart)
für ne GUI brauch man gar kein Multitasking (okay für ne sinnvolle GUI schon)
aber wenn wir im PM sind könnte man doch innen 800x600x32 schalten und irgentwas schönes malen (puh jez hätt ich fast maus gesagt aba dann hättet ihr nen krampf bekommen :) ).
Ist natürlich nur ne spielerei ... aber ne sehr lustige und ausserdem können leute die bereits ein Multitasking OS geschrieben haben auch sehr davon profitieren.
(Weiss nicht ob solche leute eure zeitschrift lesen, da sie momentan ja eher noch nicht die zielgruppe darstellen :( )
-
Naja ich stimme dir zu. Es ist immer ganz toll wenn man was schönes zu Gesicht bekommt auf dem Moni.
Aber darauf zielt es hier wohl nicht ab. Ich denke es sollte eher der Reihe nach gehen.
Erst wenn mal eine gescheite Konsole, das arbeiten mit Platte, Diskette und vielleicht ein paar anderen Hardwaresachen steht, kann man sich gedanken um eine GUI machen.
Weil man sollte das ganze schon etwas planen und nicht einfach drauf los hacken. Das führt zwar schnell zu Ergebnissen, jedoch sind diese meist sehr unausgereift und bieten kaum gute Erweiterungsmöglichkeiten.
Das ganze Gerüst (das man NICHT sehen kann) muss erstmal stimmen, bevor man darauf aufsetzt.
Wenn du dir mal angeschaut hast, wirst du sehen das das Handbuch zu VESA recht ordentlich ist.
Des weiteren kannst du aus dem PMode entweder garnicht oder nicht so einfach auf die VESA-Funktionen zugreifen, weil dieser über BIOS-Interrupts zu verfügung gestellt werden. Man müsste also entweder kurzzeitig in den Real-Mode zurückschalten oder einen Virtual86-Mode haben. Und dazu benötigt man schon wieder Multitasking.
Verstehst nun warum das nicht so einfach ist? :)
-
Okay ich bin überzeugt
-
Wenn ihr einen Anfängerteil haben wollt, wäre es doch ne Möglichkeit ein kleines Single-Tasking System mit Konsole zu schreiben, dass dann jede Ausgabe erweitert wird. Leute hier am Forum könnten dann Code einfließen lassen indem sie Tutorials verfassen und darin ihren Code erklären. Nur so als Idee. Weiß nicht in wie weit das umsetzbar ist?
-
Ich denke mal darauf wird es wohl hinauslaufen.
Es ist ja nicht verkehrt erst einmal nur ein SingleTask System zu haben.
Alleine an diesem läst sich dann viel weiteres realisieren.
So könnte man dieses als Ansatz nehmen um einzelne Interrupthandler zu veranschaulichen und dann auch eine Shell basteln über die man dann auf ein Dateisystem zugreifen kann.
Aber auch all das braucht eben so seine Zeit. Wir alle bemühen uns darum immer in so kurzen Abständen wie möglich etwas neues zu veröffentlichen.
Jedoch ist es so das wir? (ich zumindest) auch nicht so die Experten sind und uns ebenfalls erst in meist Englische Texte einlesen müssen. Und da wir nebenher auch noch Schule, Arbeit und Studium haben, ist auch unsere Zeit begrenzt. Somal mich meine Freundin auch ab und zu mal sehen möchte *G*.
Mastermesh hat ja schon ein Resource Center eingerichtet.
Jeder der dort gerne einen Beitrag posten möchte, der Verfasse einfach seinen Beitrag und schicke ihn mir oder mastermesh.
Wir schauen uns das dann an und posten es dann im Resource Center.
-
Das kleine Singel-Tasking OS das ich angesprochen hab, war auch mehr so gemeint, dass man vorher ne gewisse Struktur vorgibt innerhalb derer dann jeder entwickeln kann und seine Entwicklungen im Magazin vorstellt und Kommentiert.
-
Was über PM wäre wirklich hilfreich. Es gibt kaum vernünftige seiten über PM (wer interesse hat kann ja mal hier gucken. Sehr umfangreich leider auch etwas abstrakt und die Beispiele sind nicht immer grad hilfreich http://www.fh-zwickau.de/doc/prmo/pmtutor/text/) Mit hilfe dieser Seite hab ich meine ersten Erfahrungen mit dem PM gemacht und ich muss sagen ich stoße immer wieder auf neue Probleme. So ist es mir z.B. noch nicht gelungen den Code von den Daten zu trennen. Meine Strings gehen immer hoffnungslos verloren wenn ich ein eigenes DS anlege (bin ich vielleicht zu dumm dazu?). Dazu würd ich mir auch was wünschen.
-
Wie schon erwähnt bin ich gerade dabei ein PMode Tut zu schreiben.
Dabei gehe ich erstmal auf die Grundlegenden Dinge ein:
- Aufbau der Deskriptoren
- Beschreibung der unterschiedlichen Deskriptoren
- Beschreibung der GDT, IDT LDT
- Paging <- Weiß ich noch nicht.
Das Tut von der FH-Zwickau hab ich auch gelesen. Jedoch war es teilweise etwas unvollständig und der Code....naja
Ich hab mir daher das "englische" Manual von Intel reingefahren. Ist sehr komplex, aber auch sehr genau.
Im Tut versuche ich daher so viel davo wieder zu geben wie möglich.
Dazu kommen dann auch Codebeispiele, Zusatztools.
Des weiteren werde ich dann an Code zeigen wie man in den PMode schaltet und von da aus in einen C-Kernel springt.
Das anlegen von Interrupt-Handlern werde ich dann aber erst Schrittweise in folgenden Tuts beschreiben.
Sonst noch "konkrete" Wünsche für das PM-Tut?
-
Ich denke eine gute Idee wäre auch mal zu beschreiben,
wie man ein Diskettenlaufwerk benutzt ;)
Ich hab das nämlich mal versucht und ned richtig hinbekommen,
den Floppy Controller und DMA zu programmieren und wenn man
einen Kernel im P-Mode schreiben möchte, ist es doch sehr sinnvoll
wenn man seinen Kernel auch von der Diskette laden kann ;)
-
ja auf das pm-tut freu ich mich schon .. könntest du das vielleicht wenn es brauchbar ist in den resource center tun damit nicht auf die nächste ausgabe von lowlevel warten müssen?
das mit dem paging ist doch super kompliziert... so weit ich weiss.
glaub nicht dass das in das anfänger tut kommen sollte ... weiss aber nicht egnau (das letzte mal wo ich mich ausgiebig mit OSdevelopment beschäftigt hab is shon omnate her)
-
@Bassai
Um den Kernel zu laden muss ich das Diskettenlaufwerk noch nicht programmieren. Da befinde ich mich noch im Real-Mode und kann bequem über BIOS-Interrupts von der Diskette lesen.
Sobald aber der PMode läuft und der Kernel geladen ist, muss ich natürlich einen Treiber für das Diskettenlaufwerk schreiben, weil ich DANN nur noch über Ports Daten vom Laufwerk lesen kann. Das einbinden der DMA ist leider beim DIskettenlaufwerk (laut meinen Kenntnissen) notwendig.
@neq
Das Prinzip vom Paging ansich ist recht simpel. Jedoch ist es eine komplexe Sache, wenn es darum geht das man Pages auf Platte auslagern möchte.
Daher werde ich das Paging wohl in seiner Funktionsweise beschreiben. Jedoch werde ich keinen Beispielcode bereitstellen, der zeigt wie man Pages auf Platte auslagert *G*.
Das kommt vielleicht später.
Ob das Tut ins RC kommt, kann ich noch nicht sagen. Das müsste ich mit Mastermesh absprechen, da er die Planung in der Hand hat.
Ich bin zwar heute ein gutes Stück weitergekommen im Tut, aber es fehlt noch einiges.
Wahrscheinlich wird es auch so kommen, das ich im nachinein noch Ergänzungen vornehmen muss, sollte ich evtl ein Thema darin zu kurz oder unverständlich behandeln.
Der Umfang des Tuts beträgt zur Zeit (laut der Druckvorschau des IE) 11 Seiten.
-
krass, das is ja im gegensatz zu den anderen tuts bei lowlevel schon riesig !
wie wärs denn wenn ihr allgemein ale tuts wo viel code ist ind den resourcecenter packt, da man dann nicht immer alle lowlevelzeitschriften durchsuchen muss , wo denn jez genau der code war den man sucht. Momentan, da es erst 5 ausgaben gibt, ist das ja noch überschaubar. aber später wäre das echt eine grosse hilfe.
Also ein naschlagewerk für OSdevelopment
-
Ich werde es in Zukunft so handhaben, das ich von den Tuts (nachdem sie veröffentlicht wurden) den Code der darin vorkommt mit Erklärung und Kommentaren ins Resource Center stellen werde.
-
So. Das Protected mode Tutorial ist soweit fertig und muss "nur" noch für das Magazin aufbereitet werden.
Ich brauche mal Vorschläge für das nächste Tutorial.
Ich hätte selbst ein paar Vorschläge:
- Paging (Wurde im PMode Tut nicht so ausführlich behandelt)
- Multitasking
- Memorymanagment (Ohne Paging)
Kommt bitte nicht auf die Idee ein GUI Tut zu verlangen. Ohne Memory Managment, Multitasking und sonstigen Gerüstzeug macht das garkeinen Sinn.
Eine Konsole wäre zwar auch so möglich, jedoch sehr eingeschränkt.
-
Memorymanagment ist wohl eines der wichtigsten themen überhaupt, also wäre darüber ein tutorial ganz gut ;)
Ansonsten, Multitasking
Aber wo kann ich denn jetzt das Tutorial finden ???
-
Finden kannst du es noch garnicht *g*.
Du musst warten bis das neue Magazin von LowLevel rauskommt.
Speichermanagement hatte ich mir auch gedacht. Ohne das macht es kaum Sinn den Kernel in irgendeiner Form weiterzuentwickeln.
-
Was ich auch sehr interessant fände, wären die besonderen Möglichkeiten die mir ELF bietet. Irgendwie war da doch was mit dynamischen laden und so, oder?
Gut wird wohl erstmal auf Floppy-Zugriff warten müssen.
-
Nochmal ne Frage anbei. Jetzt wo ich endlich den beschissenen Fehler gefunden habe, kann ich auch die nächsten Tutorials zumindest teilweise in C schreiben. Frage ist halt ob das gewünscht wird?
Vorweg muss ich aber sagen das ich leider gezwungen bin GCC (DJGPP) zu benutzen. Ich persöhnlich mag das Ding nicht. Und was ich absolut daran hasse ist der häßliche Inline-Assemblersyntax. Daher werde ich alle Funktionen die auch NUR EINE ZEILE Assemblercode benötigen, komplett in ASM schreiben und mit dem C-Code verlinken.
Aber ansonsten kann ich gerne den Rest in C schreiben.
-
Also ich bin dafür, dass das was in C realisierbar ist, auch in C geschrieben wird.
Ist die Inline-Syntax so schlimm?
-
@TeeJay: Kann man denn nicht einen anderen Compiler als gcc benutzen.
Also ich hab bis jez immer den von digitalMars benutzt. Allerdings muss ich sagen, dass es möglicherweise an ihm liegt, das ich z.B. zu dumm bin in den ProtectedMode zu kommen ... naja keine Ahnung wie der so geeignet is.
Aber im RealMode hat der mir ganz gute Dienste geleistet
-
in den PMode schaltest du am besten eh über ASM. im Protected Mode tut hab ich ASM Code für das schalten mit reingeschrieben.
Ich hab auch schon versucht mit Borland zu arbeiten. Aber der realisiert InlineASm nur indem er erstmal den C Code in ASM umwandelt und dann TASM drüberlaufen lässt. Und TASM erzeugt komisch Objektdateien. Mit denen funktioniert das Linken nicht richtig.
-
So ich hab mich mal entschieden.
Ich werde das nächste Tutorial über Memorymanagment schreiben.
Sprich wie man die Funktionen malloc und free basteln kann.
Dabei werde ich am Anfang des Tutorials nochmal etwas ausführlicher Erklären, wie man einen C-Kernel zum laufen bekommt.
Und wie gewünscht wird diesmal auch C-Code zu finden sein.
-
neq postete
für ne GUI brauch man gar kein Multitasking (okay für ne sinnvolle GUI schon)
aber wenn wir im PM sind könnte man doch innen 800x600x32 schalten und irgentwas schönes malen (puh jez hätt ich fast maus gesagt aba dann hättet ihr nen krampf bekommen :) ).
Ist natürlich nur ne spielerei ... aber ne sehr lustige und ausserdem können leute die bereits ein Multitasking OS geschrieben haben auch sehr davon profitieren.
(Weiss nicht ob solche leute eure zeitschrift lesen, da sie momentan ja eher noch nicht die zielgruppe darstellen :( )
Ich glaub aber, dass mehrere unter den Lesern sind, die sich an einem bestehendem Projekt beteiligen(ich kenne mindestens einen). Und für die dürfte das schon interessant sein(auch wenn es bei dem, den ich kenne wohl noch etwas dauern dürfte bis man so weit ist)
-
Wie schon gesagt. Bevor es an GUI geht muß noch einiges an Vorarbeit geleistet werden. Da müssen Interrupt-Handler geschrieben werden, Memory Managment, Task-Management. Das kann also noch etwas dauern.
Zur Zeit hab ich grad ein eigenes Singeltask OS in Arbeit. Das dient aber nur zum testen von Code. Bei Gelegenheit werd ich das zur Verfügung stellen.
Ich denke es ist wichtig erstmal Grundlegende Dinge anhand eines SingleTask OS zu zeigen. Weil Multitasking ist nur wirklich sinnvoll, wenn man schon etwas Workaround hat und zudem auch noch virtuellen Speicher benutzt. Und das ist recht komplex.
-
Bitte macht weiter mit dem angefangenen OS in ASM... Dann ist das nicht in allem, in ASM und in C ein Anfang, sondern man hat ein fertiges und gutes System und ein Erfolg...
-
Hi Joachim.
Von vielen wurde gewünscht auch zu Zeigen wie man es in C macht. Ich halte es für keine schlechte Idee, da man damit schneller und bequemer vorran kommt. Zudem wird man vom Compiler unterstützt der evtl Fehler schon früh erkennt.
Aber keine Sorge. Es wird auch noch genug ASM Code kommen.
Sobald das PMode Tutorial in der neuen Ausgabe draussen ist, werde ich im Ressource-Center neue Threads eröffnen in denen ich dann C und Assemblerfunktionen für bestimmte Aufgaben poste.
-
Ok, meinet wegen auch in C oder sonstwas, aber bitte nicht immer nur irgendwelche Codefitzel und dann muss man damit eben selber fertig werden, sondern ein OS, woran an jeder Ausgabe weiter gemacht wird, bitte...
-
Ich glaube das is wohl nicht das ziel des Magazins einfach nur ein Betriebssystem Schritt für Schritt zusammen zu bauen bzw. fertigen quellcode zu posten und dann nimmts einer kopierts in seinen Editor compilierts und sagt :"Eh guck ma ich hab nen Os gecodet". Es sollte doch vielmehr um Konzepte gehen die gezeigt werden, die man dann aber selbst zu code verarbeitet Daraus entwickelt man wieder neue Konzepte usw. und plötzlich sieht man das es viel bessere Lösungen für ein Problem gibt. Experimentier Freudigkeit sollte halt gefragt sein. Und man sollte halt so viel Quellcode wie möglich selber schreiben und mit anderen austauschen damit man 1. selber Erfahrungen macht und 2. aus Erfahrungen anderer schöpfen kann. So ist z.B. Linux entstanden bzw. deshalb ist es heute so gut. Diese regeln sollten aber auch allgemein fürs Coding gelten. Wer kennt das nich man hat tausend Bücher über C, Assembler und was weiss ich alles gelesen und alles auch sehr gut verstanden und plant dann ein Mamut Projekt setzt sich hoch motiviert an seinen PC schreibt die ersten Zeilen Code und nix klappt, weil man einfach schon immer zu faul war selber Code zu schreiben und auszuprobieren.
Ich mein ich finds schon gut das man sozusagen mit der idee "alleine gelassen" wird, denn nur so lernt mans wirklich. Und immerhin hat man hier ja auch das glück das die autoren wirklich hilfsbereit und für Fragen offen sind. Schließlich gibts keine dumme Fragen nur dumme Antworten. In anderen Foren liest man nur zu hauf solche dumme Antworten wie:"Ein Os coden das kannst du sowieso nich lass es lieber."
Naja Jedenfalls is ein Os coden kein Zucker schlecken und um es auf den Punkt zu bringen bei fertigen Code lernt man halt weniger als bei Codeschnipseln
-
@lobmann
Einer der "leider" wenigen die das Prinzip vollends verstanden haben :)
Es spricht ja garnix dagegen, wenn man an einem Problem hängt und deshalb mal nachfragt oder sich Unterstützung holt.
Aber wie lobmann schon gesagt hat, sollen die Artikel von LowLevel viel mehr eine Anregung und Sprunghilfe sein.
Ich persöhnlich bin selbst hier als "Anfänger" eingestiegen. Ich hatte zwar schon einiges über PCs gelesen und auch Assembler mal in den Fingern gehabt. Aber aus mangelndem Anwendungsgebiet ist das schnell fallen gelassen worden.
LowLevel hat in mir wieder richtig Lust auf das Ganze geweckt.
PS: Sämtliche Tutorials die ich geschrieben habe oder noch schreiben werde habe ich mir auch vor kurzem erst selbst erarbeitet. Ist nicht so das ich aus Redmond komme und schon weiß wie das alles funktioniert :)
-
Ja, aber es bringt auch nichts, wenn man nur schnippsel hat und überhaupt keine ahnung, wie man die einbauen soll... Denn dann muss man so viele Möglichkeiten ausprobieren, das es frustrierend wird...
-
weiß man schon etwa, wann das neue magazin kommt?
-
Die kurze Antwort: Nein.
Die lange Antwort: Nein. Ich kann nie wissen, wann mir die Leute ihr Material schicken, wann ich Zeit habe, das Magazin zu "kompilieren", wann ich mal Zeit habe, Rechtschreibfehler zu korrigieren etc...
-
@joachim
Also ich weiß nicht. Aber ich finde in den Ausgaben steht es schon recht gut detailiert. Und ein bisschen Eigeninitiative sollte ja auch sein.
Aber wenn du so Probleme hast, dann sag doch mal genauer wo du nicht weiterkommst und wir helfen dir.
-
Ich habe garkeine Probleme, ich habe euer Beispiel bereits zu einer Shell ausgebaut, aber ich freue mich schon auf eure neue Ausgabe, weil es Spaß macht, endlich mal wieder was zu hören auf deutsch vom Programmieren von Betriebssystem...