Mal eine Frage an euch Spezialisten: Wie geht man sinnvoll vor, wenn man ein eigenes Betriebssystem auf einem PC/Notebook selbst erstellen und ausprobieren will?
Ich betrachte mich nicht als Spezialist auf diesem Gebiet, aber wie auch immer...
Wie gut kennst du den Assembler für deine Zielarchitektur? Mit einer Antwort welche unterhalb von "sehr gut" liegt, solltest du dich zuerst damit auseinandersetzen. Danach solltest du dasselbe mit der C-Programmiersprache tun, bis du sie gut im Griff hast. Das gilt auch, wenn du dein Betriebssystem nicht in C schreiben möchtest. Der grösste Teil der Tutorials und Erklärungen von allgemeinen Konzepten sind in C-Pseudocode formuliert.
Erst wenn du das Zeugs sehr gut kennst, kannst du anfangen, dich in die Materie einzuarbeiten. Das wird am Anfang sehr trocken sein. Für viele ist es zu trocken, auch für mich, den es eigentlich hochgradig interessiert. Wenn du nicht dranbleiben magst, wirst du es bald merken, und zwar nachdem du deinen Bootloader geschrieben hast und die Frage kommt, was es als nächstes zu tun gibt.
Hast du einen alten PC, den du nicht mehr brauchst? Arbeite auf deinem richtigen PC höchstens im Emulator, für alle richtigen Versuche gehst du auf den anderen PC.
Das gibt ein Gefühl von Sicherheit
MfG
_________________ MCPD, MCTS and more! | "It's 7:05am. I have not slept." | www.google.com
Ich beschäftige mich seit einiger Zeit mit Assembler für den x86.
Möchtest du wirklich ein OS wie DOS schreiben, oder nur ein kleines Programm was etwas Text nach dem Booten ausgibt?
Ersteres ist allein eigentlich nicht möglich, da du heutzutage selbst mit Assembler nur beschränkt auf die Hardware zugreifen kannst. Eine Bildschirmauflösung wie in Windows wirst du leider nicht realisieren können.
Ebenso müsstest du deinen eigenen CD-Rom Treiber schreiben, sodass für den Anfang nur das Starten von Diskette bleibt.
Eine Dokumentation für die Programmierung einer Netzwerkkarte ist nicht zu bekommen, da die Hersteller nicht die Funktionsweise ihrer Karten offen legen.
Dein OS hätte also nur Zugriff auf max. 640x480x16 Grafik, Tastatur, Maus, Diskette und die ersten MByte deiner Festplatte, sowie 1 MByte RAM.
Die Bücher "PC Hardware" von H.P. Messmer und die Buchreihe "PC Intern" von M.Tischer sollten dabei auf deinem Schreibtisch nicht fehlen. Sie beinhalten eigentlich alles was du wissen musst.
Leider nur noch gebraucht bei Amazon oder Ebay zu bekommen, wenn überhaupt.
Ersteres ist allein eigentlich nicht möglich, da du heutzutage selbst mit Assembler nur beschränkt auf die Hardware zugreifen kannst. Eine Bildschirmauflösung wie in Windows wirst du leider nicht realisieren können.
Ebenso müsstest du deinen eigenen CD-Rom Treiber schreiben, sodass für den Anfang nur das Starten von Diskette bleibt.
Eine Dokumentation für die Programmierung einer Netzwerkkarte ist nicht zu bekommen, da die Hersteller nicht die Funktionsweise ihrer Karten offen legen.
Dein OS hätte also nur Zugriff auf max. 640x480x16 Grafik, Tastatur, Maus, Diskette und die ersten MByte deiner Festplatte, sowie 1 MByte RAM.
Ich beschäftige mich seit einiger Zeit mit Assembler für den x86.
Möchtest du wirklich ein OS wie DOS schreiben, oder nur ein kleines Programm was etwas Text nach dem Booten ausgibt?
Ersteres ist allein eigentlich nicht möglich, da du heutzutage selbst mit Assembler nur beschränkt auf die Hardware zugreifen kannst. Eine Bildschirmauflösung wie in Windows wirst du leider nicht realisieren können.
Ebenso müsstest du deinen eigenen CD-Rom Treiber schreiben, sodass für den Anfang nur das Starten von Diskette bleibt.
Eine Dokumentation für die Programmierung einer Netzwerkkarte ist nicht zu bekommen, da die Hersteller nicht die Funktionsweise ihrer Karten offen legen.
Dein OS hätte also nur Zugriff auf max. 640x480x16 Grafik, Tastatur, Maus, Diskette und die ersten MByte deiner Festplatte, sowie 1 MByte RAM.
Die Bücher "PC Hardware" von H.P. Messmer und die Buchreihe "PC Intern" von M.Tischer sollten dabei auf deinem Schreibtisch nicht fehlen. Sie beinhalten eigentlich alles was du wissen musst.
Leider nur noch gebraucht bei Amazon oder Ebay zu bekommen, wenn überhaupt.
Dann schreibt man ein paar Programme, wie Commandointerpreter, Debugger, Texteditor, Dateiverwaltung, mehrere Interrupts, diverse Treiber für Tastatur (inklusive verschiedene Layouts) Bildschirm, Festplatten, Usb-Sticks, Disketten, SD-Karten, Joysticks, Soundkarten, Netzwerkkarten Prozessorverwaltung, Temperaturverwaltung, Internetbrowsing, Videogucken, Tetris spielen, Bildschirmschoner, Bildschirmhintergrund, diverse Verwaltungstools, verschiedene Sprachcompiler/interpreter, Entwicklungsumgebung, Tabellenkalkulation, Fotobearbeitung, Datenkompression, Festplattenpartitionierung, Defragmentierung, usw. usw.
Man muss nicht alles auf einmal schreiben, aber wenigstens einen Teil davon, um überhaupt programmiertechnisch dabei zu sein.
Wenn man dann die richtige Vision hat, die nötige Erfahrung, die richtigen Kontakte und einigermaßen Know How und Designvorstellungen, kann man z.B. erste Schritte mit einem Visionsgemäßen Kommandointerpreter wagen. Je besser das Konzept und das Programmierinterface, und je leistungsfähiger und innovativer im Sinne von Zukunftsweisend, desto eher wird man Freunde finden, die mitmachen, code tauschen und desto stärker wird das System sein, und sich weiterentwickeln.
Ersteres ist allein eigentlich nicht möglich, da du heutzutage selbst mit Assembler nur beschränkt auf die Hardware zugreifen kannst. Eine Bildschirmauflösung wie in Windows wirst du leider nicht realisieren können.
Ebenso müsstest du deinen eigenen CD-Rom Treiber schreiben, sodass für den Anfang nur das Starten von Diskette bleibt.
Eine Dokumentation für die Programmierung einer Netzwerkkarte ist nicht zu bekommen, da die Hersteller nicht die Funktionsweise ihrer Karten offen legen.
Dein OS hätte also nur Zugriff auf max. 640x480x16 Grafik, Tastatur, Maus, Diskette und die ersten MByte deiner Festplatte, sowie 1 MByte RAM.
Absoluter Blödsinn!
Kann man sehen wie man will. Man sollte aber realistisch bleiben.
Beim Programmieren im RealMode bleibt einem nunmal nicht mehr übrig. Das BIOS stellt einige zwar einige Routinen bereit für den Zugriff auf die Hardware, jedoch weiß jeder das diese sehr langsam sind.
Wenn es so einfach wäre, hätte jeder zweite Hobbyprogrammierer ein eigenes OS daheim. Dem ist aber nicht so. Selbst Assembler hilft einem nicht weiter wenn man nicht weiß wie die ganzen Register der einzelnen Controller angesprochen werden müssen. Von den Portadressen ganz zu schweigen.
Bis auf (S)VGA, Diskette/Festplatte und Tastatur ist sogut wie nichts dokumentiert oder heute noch gültig. Darum liefern die Hersteller nunmal Treiber mit ihrem Gerät mit.
Ich habe nicht gesagt das es unmöglich ist, aber viele OS-Entwickler werden schnell von der Realität eingeholt und brechen ihr Vorhaben sehr früh ab.
Ich habe nicht gesagt das es unmöglich ist, aber viele OS-Entwickler werden schnell von der Realität eingeholt und brechen ihr Vorhaben sehr früh ab.
Nicht die Tatsache, dass du das Vorhaben als unrealistisch einstufst wird belächelt, sondern die technischen Einschätzungen, die du gepostet hast. Die sind einfach nur Schwachsinn und darüber hinaus sehr amüsant. LOL, Alter!
Man kann auch mit Assembler Code vom Real Mode in den Protected Mode wechseln (den Code für den Wechsel muss man glaube sogar in Assembler schreiben...).
Danach schreiben die meisten in C weiter, weil es komfortabler ist,
aber selbst da kann man noch mit Assembler weiter arbeiten.
Prinzipiell gibt es nichts, was einen daran hindern würde, sich sein eigenes Windows zu implementieren... auch alleine.
Tatsächlich scheitern die meisten Projekte einfach am Aufwand...
@supernicky:
Tatsächlich scheitern die meisten Projekte einfach am Aufwand...
Hallo,
das hab ich doch gesagt :)
Ich habe immer das Gefühl das viele nicht wissen was für ein OS alles getan werden muss. Es arbeiten nicht umsonst immer mehrere Leute an einem Projekt. Einer allein kann das nicht alles wissen.
Eine Frage habe ich noch zum PM des x386.
In einem Buch von mir steht geschrieben, das man (mit entsprechender Vorarbeit)
die Segmentregister ES, FS mit den richtigen Werten lädt,in den PM und zurück in den RM springt und trotzdem auf den gesamten RAM über ES und FS zugreifen kann. Ist das wahr?
Von solchen Tricks steht bei Herr Messmer und Herr Tischer nämlich nichts geschrieben.
Wie erfahre ich wieviel RAM ich habe? Im RM erhalte ich vom BIOS nur 640KByte.
Ersteres ist allein eigentlich nicht möglich, da du heutzutage selbst mit Assembler nur beschränkt auf die Hardware zugreifen kannst. Eine Bildschirmauflösung wie in Windows wirst du leider nicht realisieren können.
Ohne Frage es ist aufwendig und erfordert viel Erfahrung, Kraft und Geduld. Aber es wird sicher nicht an der Auflösung eines Grafikmodus scheitern. Technisch sind auch hohe Auflösungen machbar. Am Anfang ist es aber sicher leichter erst einmal im Textmodus zu bleiben.
Zitat:
Ebenso müsstest du deinen eigenen CD-Rom Treiber schreiben, sodass für den Anfang nur das Starten von Diskette bleibt.
Das BIOS bietet keine direkte Unterstützung (Zugriff) für CD ROM. Allerdings kann es durchaus von CD ROM booten. Dafür gibt es den El Torito Standard.
Natürlich wird hier in Wirklichkeit auch nur ein Disketten Boot simuliert.
Zitat:
Eine Dokumentation für die Programmierung einer Netzwerkkarte ist nicht zu bekommen, da die Hersteller nicht die Funktionsweise ihrer Karten offen legen.
Dadurch das es Systeme wie Linux gibt, ist diese Aussage nicht richtig. Linux ist quelloffen, damit sind auch die Treiber für Netzwerkkarten quelloffen. Die Hersteller sind in diesem Punkt auch nicht mehr so stur wie vor 10 Jahren. Natürlich werden sie nicht jede kleine Anfrage von jedem bearbeiten. Aber die Informationen liegen in Form offener Treiber vor.
Zitat:
Dein OS hätte also nur Zugriff auf max. 640x480x16 Grafik, Tastatur, Maus, Diskette und die ersten MByte deiner Festplatte, sowie 1 MByte RAM.
Das ist nicht richtig. Spätestens wegen der Quelloffenheit verfügbarer Systeme ist das einfach nicht richtig. Mühsam das alles zusammen zu tragen ist es aber
trotzdem.
Zitat:
Die Bücher "PC Hardware" von H.P. Messmer und die Buchreihe "PC Intern" von M.Tischer sollten dabei auf deinem Schreibtisch nicht fehlen. Sie beinhalten eigentlich alles was du wissen musst.
Für die Grundlagen ist das ok. Aber alles in allem sind die veraltet. Nimmst Du diese Bücher als einzige Grundlage, dann hast Du mit Deinen Aussagen oben sogar Recht. Aber wir sind ja zum Glück im Zeitalter des Internet .
Zitat:
In einem Buch von mir steht geschrieben, das man (mit entsprechender Vorarbeit)
die Segmentregister ES, FS mit den richtigen Werten lädt,in den PM und zurück in den RM springt und trotzdem auf den gesamten RAM über ES und FS zugreifen kann. Ist das wahr?
Von solchen Tricks steht bei Herr Messmer und Herr Tischer nämlich nichts geschrieben.
Warum sollte man aus dem PM freiwillig zurückschalten wollen?
EMM386 erreicht so aus Softwaresicht den gleichen Effekt wie die ursprünglichen, für spezielle EMS-Steckkarten ausgelegten Expansionsspeicher-Treiber. Während diese allerdings eigene, für die CPU an sich gar nicht adressierbare Speicherbereiche mittels einer speziellen Bank-Switching-Hardware einblendeten, verwendet EMM386 ausschließlich "Bordmittel" der Intel i386 und höheren Prozessoren. Als Nebeneffekt wird der Prozessor dabei allerdings aus dem unter DOS üblichen Real-Modus in den sogenannten V86-Modus geschaltet, womit einige sehr hardwarenah arbeitende Programme und einige Programme, die spezielle Speicherverwaltungstricks verwenden, nicht kompatibel sind.
Zitat:
Wenn es so einfach wäre, hätte jeder zweite Hobbyprogrammierer ein eigenes OS daheim.
Unabhängig von Deinen falschen technische Einschätzungen ist es eben nicht einfach. Aber es sei Dir verziehen, Erfahrung erwirbt man nicht über Nacht. Und dieses Forum ist ja auch dazu da etwas dazu zu lernen. Das gilt für alle Seiten. Hoffe ich zumindest
Zuletzt bearbeitet von lupo1977 am 01:18:09 07.11.2011, insgesamt 3-mal bearbeitet
Warum sollte man aus dem PM freiwillig zurückschalten wollen?
Mir fallen da zwei Gründe ein:
1) Im RM kann man die Funktionen des BIOS ohne VM86 nutzen
2) Unreal Mode
Ja klar. Es ist sicher für den Anfang leichter ein System mit diesen Rahmenbedingungen zu schreiben. Geht es einfach nur darum mehr Speicher verwenden zu können, dann ist das mit dem Unreal Mode Trick ok.
Im Protected Mode gibt es keine Unterstützung vom BIOS, man ist also gezwungen wirklich alles selber zu machen. Das ist dann natürlich nochmal um Größenordnungen aufwendiger.
Dafür bietet der PM ausreichend RAM und eine vernünftige Adressierung.
Was meinst du genau mit vernünftig?
64bit ist ja auch gar nicht schlecht, noch mehr Ram, bessere(flexiblere) Addressierung wie z.B. Riprelativ.
Und man muß ja auch gar nicht Betriebsystem für Pentiums schreiben, ginge nicht auch für ARM oder für Grafikkarten, oder allgemein für mehrere Prozessoren, z.B. Mpi-basiert/OpenCl/funktional usw?
Oder gerade, weil es für den Einstieg ist, für einfachere Prozessoren ( http://www.mikrocontroller.net/articles/AVR-Tutorial#Welchen_Mikrocontroller_soll_ich_verwenden.3F ) allein oder im Verbund?
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können keine Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum nicht antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.
Twitter
Facebook
