Thema: Inhalte für nächstes Magazin

[bscreator]

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

[neq]

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.

[neq]

haha ich guck mir grad die aktuelle ausgabe an... da wird kernelentwicklung auf deutsch behandelt

[bscreator]

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

[TeeJay]

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.

[mastermesh]

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

[TeeJay]

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.

[neq]

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 )

[TeeJay]

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?

[neq]

Okay ich bin überzeugt

[kleiner]

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?

[TeeJay]

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.

[kleiner]

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.

[mwoidt]

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.

[TeeJay]

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?

[Bassai]

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

[neq]

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)

[TeeJay]

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

[neq]

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

[TeeJay]

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.