Lowlevel
Lowlevel => Das Wiki => Thema gestartet von: BigOlly am 08. April 2004, 02:29
-
Hi LowLevel-Gemeinde ! :-)
Ich hab ein bisschen im Forum gestöbert und mir die ganzen Beiträge reingezogen die sich um künftige Themen und Themen-Wünsche drehen.
Tja und dazu möcht ich nun auch meinen "Senf dazugenben" : :-)
Kurz zu mir:
Ich programmiere seit 18 Jahren als Hobby und seit 6 Jahren auch beruflich als Web-Programmierer für PHP, MySQL, HTML usw.
Damals hab ich mit Maschienencode auf dem Z80 angefangen (ich betone MASCHIENENCODE !!! Also nicht "mov ax,10h" sondern E5 46 C9 BF ... usw.) und später auch mit Assembler auf Motorola 68000 Prozessoren.
Weil ich der Zeit etwas nachweine (man hat ja sooo viel über die Hardware gelernt) und auch fast alles verlernt habe, hab ich mir nun vorgenommen wieder in Assembler einzusteigen. Und wie geht das besser als mit dem programmieren einen eigenen Betriebssystems !!! :-)
Aber nun zu meinen Vorschlägen:
1. Wenn ihr mich fragt dann bitte bleibt hauptsächlich in Assembler! Alles was vor der Entwicklung einer GUI liegt und mit dem Kernal zu tun hat sollte meiner Meinung nach so Hardware-nah wie möglich geproggt sein. Nichts gegen C, aber bitte Vernachlässigt nicht den Assembler dabei....
2. Wie ich aus vielen Beiträgen entnehmen konnte gibt es hier viele die am liebsten "fertigen Code" im Magazien finden würden. Mir persönlich sind lieber Code-Teile die bestimmte Sachen und Technicken erklären.
3. Viele schreiben z.b. "Zeigt uns wie man eine Shell proggt, wie man eine GUI schreibt ..." usw. Ja, das ist alles wichtig. Aber ich finde es ist noch viel wichtiger Grundlagen zu vermitteln.
Also z.B.:
- genaue Erläuterung von schreibweisen wie z.b. 0x07c00h usw. ("x" ???)
- Technicken wie man z.B. erkennen und prüfen kann ob eine Hardware (z.b. das Floppy-Laufwerk) existiert oder nicht (und zwar ohne BIOS, wichtig im PM)
- wie genau funtioniert das Paging und der Speicher-Schutz im PM
- das Arbeiten mit Ports wenn man einen Kernal baut der im PM ganz ohne Bios alleine seine Hardware-Treiber laden soll...
- gibt es immer den Bildschirm-Speicher ab B8000h, oder gibt es auch Fälle wo dieser wo anders liegt und wie stelle ich das fest....
- was muss ich tun damit mein Kernal ein im ELF-Format forliegendes Programm laden und ausführen kan...?
- ...usw.
Also: Das sind nur Vorschläge die mir jetzt so spontan eingefallen sind. Manches davon wurde schon behandelt und maches ist ja für die nächsten Ausgaben angekündigt.
Ich will nur zeigen was ich meine mit "Grundlagen vermitteln".
Nicht das wir nach einem Jahr feststellen das wir alle "das selbe" OS entwickelt haben weil jeder nur den Code kopiert und zusammengesetzt hat... :-))
Naja, das wollt ich mal als Anregung schreiben. Ist natürlich alles kein "muss" und nur als Vorschlag gemeint. Fertige Sachen in C sind ja auch interessant.
Euer Magazien ist spitze! Nur bleibt hatl auch Eurem Namen treu: "LowLevel" :-)
so viel für jetzt
Gruß BigOlly
-
Hehe danke für den Post.
Deinen Ansatz finde ich sehr gut. So ist auch das vermitteln der Dinge hier gedacht. Das diese mehr zur Theoretischen Aufklärung dient und man dann sein eigenes Zeug selbst draus bastelt.
Auch deine Vorschläge für die Grundlagen sind gut. Und ich denke das wir gerade dieses ja auch ganz gut vermitteln.
Allerdings denke ich wäre es Zeitverschwendung extra zu erklären was das "x" bei 0x7c00 bedeutet. Es soll ja kein Kurs über Assembler sein, sondern über Betriebssysteme. Und wenigstens ein bisschen sollten sich die Leute auch selbst mit den Dingen beschäftigen und Nachlesen. Trotzdem versuche ich immer möglichst viel Hintergrundwissen mit in die Tutorials zu packen.
Ob Assembler immer die erste Wahl ist ist so ne Sache. Ich persöhnlich finde Assembler recht cool und ich schreibe auch oft kleine Funktionen in Assembler die sich meiner Meinung nach damit einfach geschickter Lösen lassen.
Aber mit C kommt man einfach schneller vorran und es ist einfacher zu lesen.
Und gerade bei den Grundlegenden Dingen eines OS muß man auf Grund der Ports usw eh noch häufig genug auf Assembler zurückgreifen.
Vielleicht hast du ja selbst (wenn du sagst das du das eigentlich schon ein wenig kannst) ja Lust ebenfalls ein paar Artikel oder Tutorials hier beizutrager. Wir sind für jede helfende Kraft dankbar.
PS: Wie schon mehrfach erklärt steht LowLevel nicht umbedingt für Assemblerprogrammierung, sondern für das LowLevel zur Programmierung generell. Sprich programmieren eines OS :)
-
Vielleicht könnte man ja eine eigene Asm-Tut Reihe hier machen*g*, damit die ,die zu faul sind nach sowas zu suchen das auch lernen können und das was in asm hier an code kommen sollte besser verstehn. Denn ich glaube viele kapiern hier Zeilen wie mov ax,80h nicht mal. Und das sollte schon der fall sein, denn auch wenn es bei Lowlevel nicht um ständige programmierung in asm geht, kommt man auf keinen Fall drum herum. Um in den PM zu kommen muss mans machn, beim Bootloader... und für die Treiber im PM mal sowieso. Also auch wenns in C bequemer ist sollte man sich bei der OS-Programmierung schon in asm auskennen oder nich?
PS: Ich könnte die asm-tut's zur not auch selbst machen wenn sich keiner findet;)
__Roshl
-
Ja wenn du ASM Tuts machen möchtest dann gerne :)
Da würde ich dir aber raten das in mehrere Abschnitte zu packen, da ASM Coding doch recht umfangreich ist.
Und der Syntax sollte wenns geht auf NASM abgestimmt sein, da dieser wohl am meisten benutzt wird.
Kannst mich ja mal im ICQ anquatschen.
-
Ja klar, wenn ich was interessantes hab oder ergänzen kann schreib ich gern nen Artikel für euer Magazin.
Nur wird es vielleicht noch ein bisschen dauern da ich was den x86 Assembler betrifft wieder ganz von vorne anfange. Man glaubt ja garnicht wie sehr einen das Objektorientierte programmieren von den Grundlagen wegbringen kann... :-)
(Bei mir war das übrigens Delphi mit VCL und Konsorten)
Da ich keine Literatur über den x86 und seine Befehle habe bzw. deren Maschienen-Code, hab ich erstmal angefangen mir die entsprechende Literatur zu besorgen.
(Das würde ich übrigens jedem empfehlen der sich für "unsere" Materie interessiert und hier mitmchen will)
Da wären z.B. "PC-Intern" von Data Becker oder "Das Hardware-Buch" von ADW sowie Assembler-Literatur wie "Assembler" von Reiner Backer (rororo) und "Assembler Ge-Packt" von Joachim Rohde.
(Dies soll auch gleich eine Literatur-Empfehlung sein für alle anderen hier, die sich mit dem Thema beschäftigen)
Die PC-Intern-Reihe kenn' ich noch aus früheren Zeiten und die zwei Assembler-Bücher bin ich grad am lesen.
Übrigens nochmal zu dem "0x0C700h": Selbst ich weiss das nicht 100%-tig. Als die Assembler-Bücher noch nicht da waren hab ich mal in meinen alten Büchern und Aufzeichnungen über den M68000-Prozessor gestöbert.. dort ist so eine Schreibweise nicht bekannt. Auch beim Z80 nicht.
(Übrigens ist der Assembler-Code beim M860x0 viiieeell schöner und einfacher, aber das nur nebenbei :-) )
Das gibt's anscheinend nur beim x86. Auch in den Assembler-Büchern zum x86 hab ich es nicht gefunden. Ich hab mir das auch nur zusammenreimen können: Meiner Meinung nach ist das "nur" eine Schreibweise, das "0x" könnte man auch weglassen. Ich denke es verdeutlicht das man den "Segment-Adressraum" also eigentlich den Offset meint.
Aber vielleicht ist meine erste Erklährung hier im Forum ja auch gleich falsch! :-)
Ich wette die meissten hier könnten das nicht erklären.
Aber gut, das reicht fürs erste, sonst wird's wieder ein Roman.... Das heb ich mir auf für den ersten Artikel bei Euch... :-)
-
Also das 0x... heist lediglich das die Zahl dahinter im Hexadezimalssystem gemeint ist;) amn kann auch ein h hinter die zahl machn also 1234h is das selbe. Dient dazu das der assembler weiss ob es dezimal hexa octa oda binär is;)
-
@Roshl:
Hey, dann ist ja "0x0C700h" doppelt gemoppelt! :-)
Seht ihr, ich denk wieder viel zu kompliziert!
-
bei der sache mit den asm-tuts würd ich mich auch ganz gern beteiligen, da ich total auf asm abfahre! ich hab, als ich noch windows benutzte, alle meine progs in asm geschrieben. durch linux bin ich davon jetzt allerdings abgekommen
-
Ãääähm also ob der assembler 0x0C700h überhaupt aktzeptiert weiss ich garnich:P aber wenn du beides machst biste nich im Zahlensystem auf basis 32:P...schön wäres zwar und umrechnen is auch kein prob aber 1.brauch keiner 2.müssten wir da fast das ganze alphabet zu nehm und 3.könnte keiner lesn^^
ich denk aber für gewöhnlich auch kompliziert:P also you are not alone....
-
Also dann gleich ein Aufruf an alle die gerne etwas über Assembler schreiben möchten.
Meldet euch einfach bei mir im ICQ und wir koordinieren das ein wenig. Es kann ja jeder einen kleinen Beitrag über ein bestimmtest Thema schreiben und wir fügen das dann im Ressource Center zusammen.
Wie gesagt. Sollte NASM Syntax sein, da dies wohl der quasistandard ist :)
Mein UIN: 59868486
PS: Wenn doch so viele in ASM schreiben, dann lasst mir doch einfach mal ein paar nützliche ASM Routinen zukommen und ich stelle diese ebenfalls ins Ressource Center.
-
Hm...also ein deutschsprachiges ASM-Tutorial wäre super da ich Assembly gerade erst lerne. (habe mit C++ angefangen und bin dann für Maschinennähe mehr auf C umgestiegen.) Und bisher habe ich nur englisches Zeug gelesen, welches zwar sehr simpel war allerdings ist ein Deutscher Artikel zur vertiefung doch besser :)
Und Teejay, wo kann ich mir denn anschauen wie die Funktionen setmem und memcpy aufgebaut sind, die in deinem C++ im Kernel-Tutorial angegeben sind?
-
*wink*
ich würde auch ein thema über assembler beitragen
da ich diese sprache schon seit amiga programmiere
ich sie auf dem pc zwar nicht so gebräuchlich finde
aber ich mache mit ;) ich melde mich dann über ICQ
bei dir
greetz Saber
-
Also wenn wir hier schon soviele ASM-Coder sind sollten wir das irgendwie gemeinsam machen oder? Hat nicht viel Sinn wenn jeder für sich werkelt und nix übereinander passt. Ich hatte schon ein ASM Tut geschrieben und es TJ mal geschickt (zum überarbeiten bisher keine Zeit). Vielleicht machen wir alle zusammen ne Tut-Reihe stellvertretend für die LowLevel-Page hier. Da jeder hier ICQ zu haben scheint können wir das ja darüber koordinieren.
-
Jo sag ja. Meldet euch bei mir und wir besprechen das. Wir sollten dann erstmal grob einteilen welche Themen wir behandeln wollen und wie wir das in Kapitel aufteilen.
-
Also ich melde mich als Tester ;)
-
Jo, hurra! Ich hoffe euer Vorhaben gelingt. Denn ich suche auch schon lange ein Assembler-Tutorial! Und das in Deutsch und mit NASM. *sabber* Oh tschuldige mir läuft das Wasser schon aus dem Mund :). Wie sieht die Lage denn jetzt aus oder war es nur eine Schnapsidee?
MFG
Ivan Keen Lee
-
Das ganze ist in Arbeit;) (me is Mitautor also ich werds wissen;))
Also bischen Geduld noch wir ham die Zeit auch nicht im Lotto gewonnen^^
-
Hier mal die Übersicht über die Kapitel die wir so zusammengestellt haben:
1. Binäres/Hexadezimales Zahlensystem und Datentypen
2. Aufbau der CPU (Register und Co)
3. Aufbau des Speichers (Arbeiten mit Segment und Offset)
4. Arbeiten mit Variablen
5. Der Stack (Push und Pop)
6. Funktionen (Call und Ret)
7. Funktionsparameter und lokale Variablen
8. Ports
Die ersten drei sind in Arbeit.
Weitere Kapitel werden dann noch folgen. Diese werden sich dann mit den einzelnen Asm-Befehlen in Beispielen beschäftigen.
-
Also wenn das Asm-Tut so einfach bleibt, könnte ich auch ein Kapitel oder mehr schreiben. Also soll ich was schreiben???
-
Meld dich im ICQ.
59868486
-
Naja, also ich könnte das Zahlensystem schreiben und das sogar mit rechnen und so...aber das kann eh jeder oder?
-
Leider habe ich mich noch nie über ICQ verständigt und weiß auch nicht, wie das geht...
-
Es geht nicht nur um das Zahlensystem. Sondern auch wie die einzelnen Datentypen aufgebaut sind uns worin der Unterschied liegt ob ich signed oder unsignes nehme.
Die ersten 3 Kapitel sind schon vergeben.
Wer eines der anderen in Angriff nehmen möchte, der soll sich bei mir per ICQ oder wenn nicht per Mail an TeeJay@jay-code.de melden.
-
Hiho
@chr15:
ICQ ist recht leit zu bedienen. du gehst einfach zu www.icq.com und dort kannst du dann die gewünschte Version runterladen. wenn du nicht viel über ICQ machen willst, kannst du dir die Lite version laden (gibt's auch auf Deutsch). Ich persönlich bevorzuge die Pro Variante (gibt's nur auf Englisch), da man dort mehr machen kann (und ich die Funktionen aus alten zeiten kenne).
Nach der Installation, kannst du dann einen neuen Account anlegen. Sobald du das gemacht hast, kannst du via TeeJay's UIN (also die Komische Zahl) ihn in deine Liste aufnehmen.
MfG JensFZ
-
Ich persöhnlich nutze Trillian. ICQ hat sich irgendwann entschlossen bei mir jedesmal mit einem SPeicherfehler abzunudeln. Egal welche Version ich dann auch installiert habe. Seit dem mag ich ICQ nichmehr.
Trillian hat zwar nicht so viele Funktionen aber läuft stabiler als ICQ und man kann damit auch mit Leuten aus anderen Messengern (AOL, MSN usw) kommunizieren.
-
Jo, ich bekenne auch: Ich bin Trillian-Nutzer! :)
-
Hiho
Naja. Ich hatte auch mal Trillian drauf und ich kenne halt nur leute mit ICQ (bzw. die AOL haben, haben auch ICQ drauf). Bei Trillian gefällt mir eigentlich nur das Winamp Plugin (bekomme das bei nen Kumpel mit, wenn der Musik hört) aber ansonsten bin ich eigentlich mit den normalen ICQ zufrieden (hatte noch nie solche Probs).
MfG JensFZ
-
Unter Linux kann ich Licq sehr empfehlen!
Gibt Dir auch die Möglichkeit, s.g. Hilfsprogramme auf die IP des anderen anzusetzen.
Sind auch sinnvolle dabei, aben wenn Du z.B. BackOrifice installiert hast, kannst Du auch das drauf ansetzen oder auch VNC.
-
Unter Linux kann ich centericq empfehlen. Rennt zwar nur in der Konsole, aber ist schnel zu bedienen. Nutze ich bei mir in der Uni, da man da nur unter Linux ins Netz kann.
-
Werde ich mal ausprobieren!
@TeeJay: Kann aber dauern - die letzten Ferientage sind bei mir schrecklich... ;)
-
Macht ja nix. Es kann ja jeder mithelfen was zu schreiben. Nur sollte das vorher abgeklärt werden, wer was schreibt, damit es kein durcheinander gibt.
Daher wie gesagt einfach bei interesse bei mir melden.
-
So jetzt hab ich TeeJays nummer hinzugefügt und da steht TeeJay bei mir!
Wie bekomme ich das hin, dass bei mir chr15 steht??? (Licq)
-
Hiho
Also beim normalen ICQ wird das über deinen Nickname geregelt (Steht irgendwo im Profil) Nehme mal an, dass es bei Licq ähnlich ist.
MfG JensFZ
-
Hab's auch schon bei licq gefunden :)
Danke noch mal für die Hilfe!
-
ich würde alles der reihe nach nehmen, wie es in einem OS vorkommt und nicht plötzlich PM-Sachen schreiben, womit man nicht anfangen kann, weil man nicht weiß, wie man in den PM wechselt, alles schön der reihe nach... und ich würde immer ein Beispiel fortlaufen lassen und nicht immer lauter einzellne OSs machen, wo immer nur ein Thema erklärt wird... Und zu C: ich würde alles so "gemütlich" wie möglich machen, also nicht was in ASM schreiben, wo man mit einem C-Code das gleiche erreicht, der aber kürzer ist...
-
@joachim_neu.
Was genau meinst du jetzt?
Die ASM-Tuts? Oder das Mag generell?
-
Also das mit dem in Asm was in C das selbe wäre aber kürzer: Theoretisch, wenn man asm halbwegs kann dann is es ganz einfach in C umschreiben Beispielsweise die setmem-funktion für TJ's asm variante hab ich so gemacht für C:
void setmem(void *mem,unsigned char value,unsigned int iCount)
{
char *memory=(char*)mem;
for(;iCount>=0;--iCount)
{
*memory=value;
++memory;
}
return;
}
nur is die extrem viel langsamer da hier alles mit einzelnen bytes kopiert wird und nicht in doppelwords(kann man zwar umschreiben aber naja)
Ich wollt nur damit sagen dass man das leicht umwandeln könnte
und von PM war soweit ich weiss noch nie die rede, oder hab ich was verpasst?
-
Ãhhmmm... vielleicht lieg ich ja falsch, aber zum ProtectedMode wollen wir doch alle...!!!
Ich meine wollten hier nicht einige ein OS programmieren? :)
Ich fand das ein gutes Vorhaben. Und ein OS im RealMode... naja, ne wirkliche Kunst ist das nicht.
Also wenn schon OS dann richtig...! :) Und das geht nur im PM!
..Naja... meine Meinung!
-
Der Realmode sollte aber auch nicht vernachlässigt werden!
Vielleicht möchte jemand(hatte ich auch erst vor) sowas wie einen Bootmanager schreiben und da wäre der Protected Mode überdimensioniert!
-
Manche Funktionen lassen sich einfach geschickter in ASM umsetzen.
Und gerade so kleine Funktionen wie memcpy und setmem sollen zudem auch noch möglichst schnell laufen, weshalb auch da ASM zu bevorzugen ist.
-
Keine Frage! Bis zum laden des Kernels, und natürlich bis zu den Routienen die GDT, IDT usw. einrichten, ist natürlich der RealMode die Wahl (es bleibt einem ja auch garnichts anderes übrig).
Aber spätestens dann geht's ab in den PM. ;)
-
Ausserdem, wenn du C haben willst macht es keinen Sinn im Real-Mode zu bleiben, da funzt das nicht so recht wenn ich mich nicht täusch
-
Doch C geht auch im Real Mode!
Ich hab's sogar schon mal mit TP geschafft!
-
Naja auch wenns geht, es macht nicht viel Sinn aus meiner Sicht.
-
Ein Freund kann am besten pascal und wollte erst kein C lernen. Darum habe ich den Vorschlag gemacht, dass wir in TP programmieren (Haben wir auch im Info Unterricht). Jetzt wollen wir aber doch ein PMode-System in C und Assembler schreiben. (Also so was wie Linux :) )
-
ich meine, dass man nicht alle themen durcheinander mischen sollte, sondern z.B. erst erklären, wie man im PM Text ausgiebt, wenn der Leser weiß, wie man in den PM wechselt... Also nicht schon in der nächsten Ausgabe zeigen, wie man einen CD-Treiber für sein OS im PM proggt, sondern erstmal, wie man in den PM wechselt, weil dass ja wichtig ist und man sonst mit dem treiber nichts anfangen kann... ich finde, man sollte alle wichtigen FUnktionen in ASM schreiben aber das OS, wo man dann ja alle Funktionen der Reihe nach aufruft in C, weil es übersichtlicher ist... Und ich habe nichts gegen PM...
Was ich sagen will ist, dass Themen erst dann kommen sollen, wenn man alles das hat, was man dazu braucht und nicht dann, wenn man noch nichtmal die Vorraussetztungen dazu kennt...
-
War das bis jetzt nicht immer so???
Im Real-Mode sowieso und im Protected Mode:
1. C im Kernel
2. Ein C Image mit Grub booten (man ist im PMode)
3. Textausgabe im Pmode
Passt das nicht???
-
Also ich hab mich entschieden jetz erstma im realmode zu bleiben. Will nämlich erstma so ne mindest Unterstützung an Treibern haben. Sprich erstma werden sollen die Treiber im RealMode gecodet werden, und wenn ich dann jetz Disketten Grafikkarten Tastatur Treiber hab geh ich daran in den PMode zu wechseln. Im RealMode is es halt für mich einfacher nen Treiber zu testen da ich ja noch Bios Ints benutzen kann.
-
Du kannst auch Treiber ganz einfach im PMode testen.
Mein System wechselt bis jetzt in den PMode. Und dort kann ich bis jetzt Text ausgeben, den Bildschrim scrollen, den Cursor verschieben und hab mir auch FUnktionen geschrieben mit denen ich Zahlen ausgeben kann.
Von daher könnte ich nun ganz einfach Treiber für Treiber schreiben und diesen Testen und mir einfach entsprechende Ausgaben machen lassen um zu sehen obs geht.
Von daher brauchs du nicht umbedingt im Real-Mode bleiben.
-
Is mir schon klar nur im RMode is es wesentlich einfacher z.B. nen Int-Handler umzubiegen oder mit dem Speicher umzugehen usw.
-
Hallo allerseits!
Ich bins mal wieder :). Wollte fragen, wie weit ihr denn schon seit? Der letzte Eintrag ist ja auch schon wieder 2 Monate her. Ich hoffe ich bekomm nicht als antwort, dass das Vorhaben eingestellt wurde...
MFG
Ivan Keen Lee
-
Jo, dass würd mich auch mal interessieren...
btw, wann kommen eigentlich die "fortgeschrittenen" Themen wie Paging und Multitasking? Wenn ihr wollt, kann ich euch über solche Themen was schreiben. Ich weiß ja net, wie das ist wer alles Artikel schreiben darf ;).
Mein Code für o.g. Bereiche sind eigenlich recht gut, hoffe ich :) daher...
MfG GhostCoder
-
Naja, mir würde ehrlich gesagt auch interessieren wann das tutorial startet :)
-
Wenn jemand ein Tutorial schreiben will, dann soll er das tun. Am besten einfach Roshl bescheid sagen das ihr eins schreibt und worüber.
-
@GhostCoder
Nen Tut über Paging fänd ich richtig gut, würd mich freuen wenn dus schreibst
-
Hiho,
kein Problem, kann ich machen. Paging is in echt mälich garnicht so schwer wie viele sagen...
Wohin soll ich das dann posten?
MfG GhostCoder
-
ka musst du dann mit Roshl absprechen ich fänds halt einfach als Tut Idee gut.
Ich denk Roshl würds dankend annehmen;)
-
Was ich gut finden würde wäre nen Tut über MemoryManagement insgesamt mit vielen Beispielen