Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: bscreator am 14. March 2011, 10:31
-
Hallo,
möcht mich nach jahrelangem Kampf mit Assembler mal wieder mit C rumschlagen und meinen ASM-Kernel durch einen C-Kernel ersetzen.
Das Tutorial über "Einen C-Kernel starten hab ich schon gelesen, allerdings will ich es selbst machen und so verstehen.
Was ich bisher weiß über die einzelnen Schritte, um einen C-Kernel zu starten:
1. ASM-Bootloader
2. Sprung in den Protected Mode
3. Laden des C-Kernels
4. Anspringen der C-Kerneladresse
Und momentan bin ich beim Übergang von 1 zu 2.
Viele sagen, dass man den Bootloader nicht selbst sondern mit GRUB machen soll -> Sorry, dem kann ich nicht zustimmen. Ich schreib lieber alles selbst.
Stimmen die obigen 4 Schritte überhaupt.?
Viele Grüße,
bsc
-
Viele sagen, dass man den Bootloader nicht selbst sondern mit GRUB machen soll -> Sorry, dem kann ich nicht zustimmen. Ich schreib lieber alles selbst.
Sorry, aber wenn du oft gesagte und noch öfter gepredigte gute Ratschläge nicht beachtest wirst du auch wenig Hilfe finden. Ohne jetzt erneut die uralte Diskussion zu öffnen sei dir folgendes gesagt:
Ein eigener Bootloader ist ein Projekt für sich, selbst wenn dieser noch so popelig sein soll und lediglich deinen Kernel laden soll. Aber wieso damit die Mühe machen? GRUB erledigt das und vieles weiteres für dich.
Und da du selber sagst, dass die Arbeit mit Assembler ein Kampf war, warum dann Zeit investieren und einen Bootloader schreiben?
-
Dein eigener Bootloader wird den Kernel vielleicht von Diskette oder Festplatte (mit BIOS-Funktionen) starten können, sogar mit Dateisystem. Aber Dinge wie Netzwerkboot und ähnliches gehen dann halt nicht. Wenn du GRUB nicht magst, nimm etwas anderes - es gibt noch andere Urlader auf dieser Welt.
Um den C-Kernel starten zu können, springst du einfach die Funktion "main" an. Der Kernel setzt eine bestimmte Umgebung voraus (das kann Protected Mode mit aktivem Paging sein, das kann aber auch Real Mode mit Segmentierung sein), die muss der Bootloader erzeugen. Deine Liste ist eine mögliche Herangehensweise, wenn auch unpraktisch.
Ansonsten bist du in der Wahl der Waffen frei.
Gruß,
Svenska
-
Und da du selber sagst, dass die Arbeit mit Assembler ein Kampf war, warum dann Zeit investieren und einen Bootloader schreiben?
Ja, irgendwie hast du recht.
m den C-Kernel starten zu können, springst du einfach die Funktion "main" an. ... das kann aber auch Real Mode mit Segmentierung sein
Netzwerkboot usw. interressiert mich noch nicht.
OK, wenn meine Umgebung Real-Mode mit Segmentierung ist, kann ich dann einen C-Kernel durch einen einfachen JMP-Befehl (wie einen in ASM geschriebenen Kernel) einfach anspringen und so starten ?
Gruss,
bsc
-
OK, wenn meine Umgebung Real-Mode mit Segmentierung ist, kann ich dann einen C-Kernel durch einen einfachen JMP-Befehl (wie einen in ASM geschriebenen Kernel) einfach anspringen und so starten ?
Ich halte es zwar für nicht so gute Idee einen Bootloader selbst zu schreiben....
Wenn du schon im Protected Mode bist, kannst du JMP benutzten.
Wenn nicht: Lies http://www.fh-zwickau.de/doc/prmo/pmtutor/text/index.htm (http://www.fh-zwickau.de/doc/prmo/pmtutor/text/index.htm)!
Sfan
-
Hallo,
OK, wenn meine Umgebung Real-Mode mit Segmentierung ist, kann ich dann einen C-Kernel durch einen einfachen JMP-Befehl (wie einen in ASM geschriebenen Kernel) einfach anspringen und so starten?
Grundsätzlich Ja. Das ist weitgehend unabhängig vom CPU-Mode. Du solltest aber noch die Aufrufkonvention bei der Übergabe von Parametern berücksichtigen falls die C-Funktion Parameter erwartet oder Werte zurück gibt. Falls Deine C-Funktion zurückkehren möchte wäre es aber geschickter im Assembler-Teil ein CALL anstelle eines JMP zu benutzen.
Ansonsten bist du in der Wahl der Waffen frei.
Das war Don Quichotte auch! Und was hat es ihm gebracht? ;)
Grüße
Erik
-
OK,
wenn ich einen einfachen C-Kernel starten möchte, der lediglich einen Text ausgibt, muss ich zuerst eine
Binärdatei (*.bin) aus dem Kernel machen.
Brauche ich dazu sowas wie einen Cross-Compiler ?
Und einen speziellen Linker ?
Gruss,
bsc
-
Nein.
-
OK, wenn meine Umgebung Real-Mode mit Segmentierung ist, kann ich dann einen C-Kernel durch einen einfachen JMP-Befehl (wie einen in ASM geschriebenen Kernel) einfach anspringen und so starten?
Grundsätzlich Ja. Das ist weitgehend unabhängig vom CPU-Mode. Du solltest aber noch die Aufrufkonvention bei der Übergabe von Parametern berücksichtigen falls die C-Funktion Parameter erwartet oder Werte zurück gibt. Falls Deine C-Funktion zurückkehren möchte wäre es aber geschickter im Assembler-Teil ein CALL anstelle eines JMP zu benutzen.
Das ist aber nicht unabhängig vom Compiler. Der gcc erzeugt 32Bit Code und das kann/sollte man nicht einfach so anspringen, sondern man muss vorher in den Protected-Mode.
-
Hallo,
Das ist aber nicht unabhängig vom Compiler. Der gcc erzeugt 32Bit Code und das kann/sollte man nicht einfach so anspringen, sondern man muss vorher in den Protected-Mode.
Ich meinte dass das Anspringen des C-Codes aus dem Assembler-Code heraus immer nach ungefähr dem selben Grundprinzip abläuft, das man dabei natürlich die Gegebenheiten vom Compiler (Aufrufkonventionen usw.) und die Bedürfnisse des vom Compiler generierten Binär-Codes (CPU-Mode usw.) beachten muss hab ich einfach mal so stillschweigend vorausgesetzt.
@bscreator:
Es muss halt einfach alles zusammen passen, also der vom Compiler generierte Code erwartete CPU-Mode, Aufrufkonventionen usw. müssen von Deinem Assembler-Code passend vorbereitet werden. In was für einem Datei-Format der C-Kernel vorliegt ist auch eher nebensächlich solange Dein Assembler-Code oder der benutzte Boot-Loader das korrekt verarbeiten kann, hierfür wird aus vielen praktischen Gründen ELF und Grub empfohlen (was ich Dir hiermit ebenfalls ans Herz legen möchte) aber damit fällt natürlich Real-Mode und Segmentierung (auch im PM) aus.
Grüße
Erik
-
So, jetzt gehts langsam los mit nem C-Kernel.
Kennt ihr nen guten Windows C-Compiler, der auch 16 Bit Code erzeugen kann?
Im Internet gibts soviel ich weiß nur 32 Bit Code-Compiler. Da bin ich mir aber nicht sicher, ob die auch 16-Bit Code erzeugen können (für Real Mode).
Vielen Dank,
bscreator (der nix mit GRUB und Protected Mode anfangen will)
-
http://forum.lowlevel.eu/index.php?topic=2352.0
-
http://forum.lowlevel.eu/index.php?topic=2352.0
Vielen Dank, hilft mir aber überhaupt nicht, da es diesen nicht zum Download gibt.
Gibts auch nen anderen 16-Bit-C-Compiler ?
Wenn ich dann nen 16-Bit-C-Compiler hab, wie kann ich dann die OBJ-Datei, die vom Compiler erstellt wird, in eine Binary umwandeln, bzw. welchen Linker sollte ich dann verwenden ?
Vielen Dank,
bscreator
-
Hast du das überhaupt gelesen?
Den BCC gibt es für Linux (mit dem wurde ELKS entwickelt) und Turbo C 2.01 (1989) ist von Borland freigegeben worden. Die Originalseite gibt es nicht mehr, aber die Datei TC201.ZIP findet man trotzdem, z.B. unter ftp://ftp.univ-paris5.fr/Windows/TurboC/tc201.zip.
Gibt es einen Grund für "ich will Real Mode und keinen GRUB" oder ist das einfach nur ein "aber ich will das so und damit fertig"?
Mit MS-DOS wurde (wimre auf der Supplement-Disk) das Tool EXE2BIN geliefert. Was das tut, weiß ich nicht genau. Ansonsten kannst du natürlich auch COM-Dateien erstellen, das sind an 100h gelinkte Binaries. Der Linker von Turbo C heißt TLINK. Ein Debugger deiner Wahl dürfte DEBUG sein (gehört ebenfalls zu MS-DOS).
Ansonsten setzt du gerade auf Technologien, die ungefähr 20 Jahre alt sind. Damit bin ich kaum älter als dein C-Compiler und das trifft wohl für die meisten hier zu. Erwarte also keine Hilfe.
Gruß,
Svenska
-
Hallo bscreator,
wie schon in dem verlinkten Thread möchte ich Dir noch mal den Open-Watcom-Compiler ans Herz legen, der kann 16-Programme für den Real-Mode erstellen (auch 32Bit-Programme die dann natürlich einen >=386 erfordern aber trotzdem den selben Real-Mode-Beschränkungen unterliegen) und es gibt eine recht hübsche und komfortable Windows-IDE dazu (hab ich ein paar Jahre lang mit gearbeitet). Die ganzen Tools (Compiler, Linker usw. , ein MAKE-Verschnitt ist wimre auch dabei) sollten alle auch unter reinem DOS laufen so das man komplett unter DOS entwickeln kann (falls Du einen brauchbaren Editor für DOS hast).
Das EXE2BIN kann nur die MZ-Executables in ein Simples Binär-Datei umwandeln die auch so schon ziemlich simpel sind (also nur ein Segment enthalten und keine Relozierung beim Laden benötigen) was defacto auf keine EXE zutrifft die aus einem normalen Compiler rauspurzelt. DEBUG ist zwar extrem spartanisch aber trotzdem nicht zu verachten. Empfehlen würde ich aber eher eine DOS-Version von codeview von MS (auch damit hab ich einige Zeit gearbeitet, zumindest mit Programmen die mit einem DOS-Extender im PM liefen).
Auf reine Binär-Dateien würde ich aber trotzdem nicht zurück greifen, das MZ-EXE-Format ist eigentlich recht simpel.
Erklärt hatte ich das schon mal: http://forum.lowlevel.eu/index.php?topic=2631.msg29953#msg29953 (http://forum.lowlevel.eu/index.php?topic=2631.msg29953#msg29953).
Wo ich gerade so die alten Threads von Dir durchgegangen bin, um das eben zu finden, ist mir aufgefallen das Du nicht wirklich vorwärts zu kommen scheinst. Ich will Dir ja nicht in Dein Projekt rein reden aber vielleicht solltest Du erst mal einen der großzügig ausgetrampelten Standard-Wege (32Bit-PM / ELF / GRUB) benutzen um überhaupt mal zu etwas zu kommen und dabei auch den richtigen Umgang mit den nötigen Tools zu lernen. Wenn Du danach dann richtig Ahnung hast kannst Du Dich immer noch mal auf den Real-Mode stürzen. Ich kann ja nachvollziehen das der Real-Mode durchaus eine gewisse Anziehungskraft hat aber aufgrund seiner speziellen Komplexität und der Tatsache das er seit 20 Jahren nicht mehr ernsthaft benutzt wird ist dieses Unterfangen nicht gerade einfach.
Ich bin zwar alt genug um von dem was Du tun möchtest noch einigermaßen Ahnung zu haben (in den gut 10 Jahren die ich Programme für DOS entwickelt habe war auch einiges Real-Mode-Zeugs dabei) aber wirklich helfen kann auch ich Dir kaum da es Dir meiner persönlichen subjektiven Meinung nach einfach noch am nötigen Basiswissen fehlt. Daher kann ich Dir nur raten Dich erst einmal mit normaler SW-Entwicklung zu beschäftigen bis Du mit Compiler/Assembler/Linker/Objekt-Formaten/.... sicher und unfallfrei umgehen kannst und dann noch mal einen Anlauf in Richtung OS-Entwicklung zu nehmen.
Grüße
Erik
-
Hallo
Mit
ftp://ftp.univ-paris5.fr/Windows/TurboC/tc201.zip (ftp://ftp.univ-paris5.fr/Windows/TurboC/tc201.zip)
klappts besser aber vielen Dank svenska.
Gibt es einen Grund für "ich will Real Mode und keinen GRUB" oder ist das einfach nur ein "aber ich will das so und damit fertig"?
Momentan noch "damit fertig".
Naja, wenn es so schwer ist, kann ich dann im Real-Mode auch 32-Bit-C-Code ausführen ?
Oder gibts da dann Probleme damit ?
PS: Mir ist egal, ob der Code 16 oder 32-Bit groß ist. Hauptsache er funktioniert im 1 MB grossen
Real-Mode.
Gruss,
bsc
-
Du übergehst alle Hinweise wissentlich und willentlich. Dann weißt du es also besser. :roll:
Nein, du kannst im Real-Mode ohne weiteres keinen 32-Bit-Code ausführen. Wenn du es unbedingt möchtest, dann hast du die gleichen Probleme wie bei 16-Bit-Code im Real-Mode. Wenn du die gelöst kriegst: Ja, es geht.
-
Deine ganzen Threads scheinen so, als ob du Anfänger wärst, der gar nicht erst irgendetwas lernen will sondern schnell und einfach irgendwas hinfrickeln will, das irgendwie funktioniert.
Lern' doch einfach mal die Basics (damit meine ich nicht einen Bootloader schreiben oder Real-Mode, sondern einen Bootloader benutzen und Protected Mode), dann fällt vieles leichter, die Fragen werden (hoffentlich) besser und deine Reputation ebenso.
-
OK, dann werd ich mal mein Herz ausschütten :
Klar will ich was lernen. Aber all die leider viel zu theoretischen Betriebssystemvorlesungen hab mir nicht besonders viel gebracht. Mein Wunsch ist es nur, ein Betriebssystem zu programmieren. Das mit Assembler klappt schon ganz gut und mir wurde gesagt, dass zu einem Betriebssystem auch ein Bootloader gehört, den man ebenfalls selber programmieren sollte.
dann fällt vieles leichter, die Fragen werden (hoffentlich) besser und deine Reputation ebenso.
Dann fällt mir vieles leichter, wenn ich bereits vorgefertigte Programme nehm, die mir das abnehmen ?
Über die ganzen Bootloader, die es gibt (qemu,...) weiss ich nicht viel, außer dass diese Booten und in den Protected Mode schalten. Und mein OS sollte eben auf sovielen Rechnern wie möglich funktionieren, dazu gehören evtl. auch Rechner<386, d.h. nix mit Protected Mode.
-
PS:
das OS das ich schreiben will, sollte eigentlich nur so wenig Arbeitsspeicher wie möglich brauchen und auch auf älteren Rechnern noch funktionieren. Und im Protected Mode verbraucht man soviel ich weiß, wesentlich mehr RAM als im Real-Mode.
Aber wenn dann vieles leichter fällt mit z.B. QEMU, dann lernt man doch nicht, was hinter QEMU abläuft, oder ?
PS: Und ich will eigentlich nur SOVIEL ÜBER BETRIEBSSYSTEME LERNEN WIE MÖGLICH.
-
All das was du da gerade sagst zeugt von beänstigender Unwissenheit.
Nimm dir doch bitte einfach die Zeit und lies' dich ein wenig durch unser Wiki.
1. Wenn du so viele Rechner wie möglich unterstützen willst willst du eher x86, 32-Bit und 64-Bit sowie in Zukunft ARM-Prozessoren unterstützen, denn die wenigstens haben noch einen 286er zu Hause stehen (geschweige denn produktiv) - was aber nicht heißt, dass das keine Nische sein könnte
2. qemu ist ein Emulator, kein Bootloader
3. Wenn dein OS so wenig RAM wie möglich verbrauchen soll ist Real Mode keine Lösung sondern vielmehr geschicktes Programmieren. Lies dich doch mal in Embedded Systeme ein, hier heißt es "Sparen am RAM so viel es geht"
Wie gesagt: Lies dich bitte durch das Wiki. Dir fehlen scheinbar viele Grundlagen zur x86-er Architektur und zu Betriebssystemen generell. Wenn dir eine Vorlesung nichts bringt dann vielleicht das selber lesen oder das nachfrage bei uns im IRC: #lost auf irc.euirc.net.
-
SOVIEL ÜBER BETRIEBSSYSTEME LERNEN WIE MÖGLICH
Tu das, aber sei dir bewusst das RealMode mit halbwegs aktuellen Betriebssystemen nichts tun hat. Du lernst also nur historische Dinge.
-
Moin
Qemu ist ein Emulator und kein Bootloader.
Das man im PMode mehr RAM verbaucht stimmt ein bisschen, denn da man im PMode über viel mehr RAM verfügen kann, achtet man da eben nicht auf jedes Byte sonden nimmt halt mal ne 32 Bit Variable anstatt einer 8Bit Variable, man muss aber nicht mehr RAM verbauchen, man kann genauso auf jedes Byte achten, aber dort sollte man die goldene Mitte nehmen, nicht zu verschwenderisch umgehen aber auch nicht zu kleinlich sein.
Das zu einem OS ein Bootloader gehört ist falsch, klar jedes OS braucht einen, aber man muss trotzdem nicht zu jedem OS ein eigenen Bootlaoder programmieren. Das ist im endeffekt Geschmackssache, falsch ist es auf jedenfall nicht sein OS Multiboot kompatibel zu schreiben, da dann der Bootloader gut austauschbar ist, so könnte man dann syslinux, GRUB usw. nehmen, oder wenn man dann doch irgendwann einen eigenen Bootlaoder schreiben will, den eigenen nehmen, der dann antürlich auch multibootkompatibel sein sollte.
Meine Persönliche Meinung ist, das man im PMode mehr lernt, weil man dort selber Treiber schreiben muss, im RM übernimmt das BIOS diese Aufgabe.
Der Realmode wird dich auch im PMode nicht in Ruhe lassen, zumindest wenn du mal VESA nutzen möchtest ;).
Fukano, der allen einen schönen Tag wünscht
EDIT: Hab die zweite Seite gesehen, daher stehen in meinem Post ein paar Sachen drin, die andere eben schon geschrieben haben.
-
Das zu einem OS ein Bootloader gehört ist falsch, klar jedes OS braucht einen, aber man muss trotzdem nicht zu jedem OS ein eigenen Bootlaoder programmieren.
Um das nochmal zu verdeutlichen: Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben. Dasselbe gilt übrigens auch für das Verhältnis zwischen Bootloader und BIOS.
Wenn du speichersparend programmieren willst, ist Real Mode übrigens nicht so toll: Von im Moment vielleicht 4096 MB Speicher, die ein Rechner hat, wirft dein OS allein durch die Einschränkungen des RM 4095 MB gleich mal weg.
-
Das zu einem OS ein Bootloader gehört ist falsch, klar jedes OS braucht einen, aber man muss trotzdem nicht zu jedem OS ein eigenen Bootlaoder programmieren.
Um das nochmal zu verdeutlichen: Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben. Dasselbe gilt übrigens auch für das Verhältnis zwischen Bootloader und BIOS.
Du meinst sicher "Verhältnis zwischen Bootloader und OS", oder meinst du tatsächlich BIOS?
Fukano
-
Ja, ich meine das BIOS. Wer einen Bootloader schreibt, braucht das BIOS, aber er kommt in der Regel nicht auf die Idee, sich sein BIOS deswegen selber zu schreiben.
-
Ah ok ich konnte mir nur irgend wie nicht denken das du tatsächlich das BIOS meinst, weil das sehr Mainboard abhängig ist, aber ok so gesehen hast du natürlich recht.
-
Es geht ja darum, ob man auf die Arbeit anderer aufsetzen darf oder ob man alles selber machen muss. ("Ein OS ohne Bootloader ist kein ganzes OS")
Du kannst das Spiel mindestens bis zur Kupferförderung weitertreiben, aber meistens merken die Leute schon früher, dass das absurd ist und versuchen sich damit rauszureden, dass der Vergleich aus irgendeinem Grund hinke. ;)
-
("Ein OS ohne Bootloader ist kein ganzes OS")
Das ist eindeutig Geschmackssache, ich sehe das so, das ein OS auch dann ein OS ist wenn es keinen eigenen Bootloader hat, deinen Aussagen nach zu Urteilen siehst du das ähnlich.
Fukano
-
Klar will ich was lernen. Aber all die leider viel zu theoretischen Betriebssystemvorlesungen hab mir nicht besonders viel gebracht.
Das hat vielleicht sogar Gründe.
Mein Wunsch ist es nur, ein Betriebssystem zu programmieren. Das mit Assembler klappt schon ganz gut und mir wurde gesagt, dass zu einem Betriebssystem auch ein Bootloader gehört, den man ebenfalls selber programmieren sollte.
Naja. "Klappt schon ganz gut" klingt jetzt nicht besonders vertrauenswürdig und dass zu einem Betriebssystem auch ein Bootloader gehört, halte ich für Blödsinn. Gegenbeispiele findest du bei Mikrocontrollern.
Dann fällt mir vieles leichter, wenn ich bereits vorgefertigte Programme nehm, die mir das abnehmen ?
Wenn du die Hilfen und Erfahrungen annimmst, die andere bereits vor dir gemacht haben, ja, dann wird es einfacher. Du darfst Erfahrungen und Hinweise auch ignorieren, du solltest dann aber wenigstens wissen, warum!
Über die ganzen Bootloader, die es gibt (qemu,...) weiss ich nicht viel, außer dass diese Booten und in den Protected Mode schalten. Und mein OS sollte eben auf sovielen Rechnern wie möglich funktionieren, dazu gehören evtl. auch Rechner<386, d.h. nix mit Protected Mode.
Auch das zeugt von wenig Wissen: Die Hardware um einen 8086 (PC/XT) herum ist äußerst verschieden von der Hardware um einen 80386+ (AT) herum (weniger IRQs, weniger DRQs, andere Hardwarekomponenten, andere Adressen, kein Probing, beschränktes BIOS, kein Booten von HDD, ...) und im Real Mode hast du eh keinen Platz für spezialisierte Hardwaretreiber, geschweige denn für beide Varianten. Die CPU-Architektur ist kompatibel, die Plattform nicht. Außerdem sind die BIOS-Treiber für moderne Hardware nur begrenzt einsatzfähig (z.B. können nicht mit großen Festplatten und modernen Grafikkarten umgehen).
Vielleicht solltest du dich erstmal mit Emulatoren (wie Qemu) und mit Bootloadern (wie GRUB oder Syslinux) befassen, ehe du sie ablehnst. Oder zumindest, was sie normalerweise tun sollten.
das OS das ich schreiben will, sollte eigentlich nur so wenig Arbeitsspeicher wie möglich brauchen und auch auf älteren Rechnern noch funktionieren. Und im Protected Mode verbraucht man soviel ich weiß, wesentlich mehr RAM als im Real-Mode.
Ein vernünftiges Betriebssystem braucht wesentlich mehr RAM als 640 KB (der Rest ist ROM - kein RAM!). Jeder beschissene 386er, den du auf dem Schrott findest - wenn du ihn überhaupt noch findest - hat mindestens 4 MB RAM. Und nein, DOS ist nicht vernünftig.
Was die "älteren Rechner" angeht: Vor ziemlich genau 15 Jahren (mitte 1996) wurde der Pentium 200 angekündigt, vor 20 Jahren (1991) gab es bereits 486er (der 386er erschien 1985, der 486er 1989). Wie alt bist du?
Aber wenn dann vieles leichter fällt mit z.B. QEMU, dann lernt man doch nicht, was hinter QEMU abläuft, oder ?
Wenn es dir um das Verstehen geht, dann beschäftige dich mit Mikrocontrollern. Die sind noch überschaubar, weil recht einfach gestrickt. Da hast du auch nur wenig RAM (meist im KB-Bereich).
PS: Und ich will eigentlich nur SOVIEL ÜBER BETRIEBSSYSTEME LERNEN WIE MÖGLICH.
Das lernst du nicht durch rumschreien.
Und auch nicht, wenn du nicht auf die Leute hörst. Die meisten Tips hier sind wirklich gut begründet.
Gruß,
Svenska
-
Vielen Dank, ihr haubt mich überzeugt.
Meine anderen Fragen sind in "Softwareentwicklung", hauptsächlich fragen zu GRUB.
Vielen Dank,
bsc
-
Hallo,
Mein Wunsch ist es nur, ein Betriebssystem zu programmieren.
Dann beschränke Dich auch darauf, ein OS alleine ist komplex genug. Flat-Memory ist ein recht simples und überschaubares Konzept, dagegen hat der x86-Real-Mode ziemlich viele exotische Stolperfallen zu bieten und mit dem segmentierten x86-Protected-Mode möchtest Du Dich ja auch gar nicht beschäftigen.
und mir wurde gesagt, dass zu einem Betriebssystem auch ein Bootloader gehört, den man ebenfalls selber programmieren sollte.
Dann solltest Du mal anfangen die Aussagen anderer kritisch zu hinterfragen. Zu einem OS gehört auch der Computer auf dem es läuft aber das hat taljeth ja schon ausreichend verdeutlicht.
Dann fällt mir vieles leichter, wenn ich bereits vorgefertigte Programme nehm, die mir das abnehmen?
Ja. Die Kunst besteht darin sich auf sein eigentliches Problem zu beschränken. Es ist gut wenn man auch nach links und rechts schaut aber wenn Du Dir zu viele Nebenschauplätze aufhalst verlierst Du mit hoher Wahrscheinlichkeit Dein eigentliches Ziel aus den Augen.
Und mein OS sollte eben auf sovielen Rechnern wie möglich funktionieren
Gerade deswegen solltest Du den x86-Real-Mode konsequent ignorieren, etwas derartiges gibt es aktuell (also in den letzten 10 Jahren) bei keiner anderen Plattform. Alle CPUs der letzten >20 Jahre konzentrieren sich auf Flat-Memory (selbst bei den Micro-Controllern kenne ich nur eine einzige Familie die sowas ähnliches wie die Segmentierung des x86-Real-Mode bietet und die ist auch schon vor einigen Jahren ausgelaufen) und das solltest Du auch tun. Davon abzuweichen bedeutet das Du extrem viel mehr Arbeit vor Dir hast und dafür auch extrem viel mehr an Wissen und Erfahrung benötigst (nebst dessen das Du extrem weniger an Hilfe bekommen kannst).
auch Rechner<386, d.h. nix mit Protected Mode.
Auch der 286 hat einen Protected-Mode, sogar einen der vom Speicherschutz her besser ist als das was heutige CPUs im Flat-Memory zu bieten haben, trotzdem wurde Segmentierung vom Mainstream abgelehnt und daher von keinen Tools/OSen usw. unterstützt.
Grüße
Erik
-
.....Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben....
Wie jetzt, einen einfachen Texteditor kann man gar nicht ohne ein OS zur Ausführung bringen, wie kommst du denn auf diese Idee?
Wenn du speichersparend programmieren willst, ist Real Mode übrigens nicht so toll: Von im Moment vielleicht 4096 MB Speicher, die ein Rechner hat, wirft dein OS allein durch die Einschränkungen des RM 4095 MB gleich mal weg.
Wer wirft denn im RM 4095 MByte Speicher weg?
Bereits seit MS-DOS 6.22 konnte HIMEM.SYS 64 MByte Speicher für den RM verwalten. Mit MS-DOS 7.0 (Windows 95) bereits 256 MByte und ab der Version 3.0 von Himem.sys (MS-DOS 7.1/Windows98) 4 GByte verwalten: http://de.wikipedia.org/wiki/Himem.sys
Dirk
-
Ich bleibe lieber im eigenen Wiki: http://www.lowlevel.eu/wiki/MS-DOS#Zugriff_auf_hohen_Speicher
Extended Memory Blocks beginnen nach dem Ende der HMA. Die API erlaubt es, im erweiterten Speicher Blöcke zu reservieren, freizugeben und zu kopieren (die Speicherverwaltung schaltet dazu kurzzeitig in den Protected Mode).
Also nichts mit Real Mode.
-
Ich bleibe lieber im eigenen Wiki: http://www.lowlevel.eu/wiki/MS-DOS#Zugriff_auf_hohen_Speicher
Extended Memory Blocks beginnen nach dem Ende der HMA. Die API erlaubt es, im erweiterten Speicher Blöcke zu reservieren, freizugeben und zu kopieren (die Speicherverwaltung schaltet dazu kurzzeitig in den Protected Mode).
Also nichts mit Real Mode.
Aber sicher doch mit dem Real Mode! Himem.sys verwalten den Speicher für den Real Mode und nicht für den Protect Mode und so kann man im RM sehr wohl mehr als die untersten 640 KByte an Speicher verwenden. Jedes Realmode OS welches einen vergleichbaren XMS-Extender verwendet, kann auch den gesamten verfügbaren oberen Speicherbereich für den RM verwalten. Das man den oberen Speicher vom RM aus nicht direkt adressieren kann ist hierbei völlig irrelevant. Auch wird hierbei ja nur kurzzeitig in den PM dafür geschaltet und dann wieder zurück in den Real Mode.
Dirk
-
Hallo,
Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben.
Was wollte Herr Torvalds eigentlich entwickeln als Linux entstand?
SCNR ;)
Jedes Realmode OS welches einen vergleichbaren XMS-Extender verwendet, kann auch den gesamten verfügbaren oberen Speicherbereich für den RM verwalten.
DOS verwendet den XMS aber nicht, auch die Verwaltung des XMS wird von himem.sys und nicht von DOS erledigt. Für DOS ist himem.sys einfach nur ein Treiber/TSR der irgendeinen Service anbietet. Das es Speicher hinter der HMA gibt weiß DOS (also der Kernel msdos.sys) noch nicht einmal. Es gibt aber im Lieferumfang von DOS (als OS-Distribution) einige Tools die XMS benutzen können (z.B. smartdrv.exe).
Das man den oberen Speicher vom RM aus nicht direkt adressieren kann ist hierbei völlig irrelevant.
Das ist sehr wohl relevant! Speicher der nicht direkt nutzbar ist läst sich weder für Code noch für statische Daten oder Heap oder Stack nutzen. Der XMS kann von reinen Real-Mode-Programmen/OSen nur als große externe Datenablage (wie z.B. eine Datei) benutzt werden aber nicht als aktiven Teil des Programms. Mit EMS ist das etwas anders aber auch ziemlich umständlich.
Auch wird hierbei ja nur kurzzeitig in den PM dafür geschaltet und dann wieder zurück in den Real Mode.
Egal ob kurz oder lang, wenn das OS auch auf Systemen ohne Protected-Mode laufen können soll dann ist der einfach nicht verfügbar und fertig.
Grüße
Erik
-
Was wollte Herr Torvalds eigentlich entwickeln als Linux entstand?
SCNR ;)
Keinen Texteditor. :-P
Ich habe noch daran gedacht und mir überlegt, ob ich irgendwas einschränkendes dazuschreiben soll. Hätte ich wohl doch besser gemacht, so viele Haarspalter wie hier inzwischen rumlaufen. ;)
-
Hallo,
Keinen Texteditor. :-P
Stimmt.
Wenn Du möchtest das ich zur nächsten Präzisionshaarspaltung ansetze wüste ich aber schon gerne was Du mit "irgendwas einschränkendes" meinst. ;)
Grüße
Erik
-
Hallo,
Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben.
Was wollte Herr Torvalds eigentlich entwickeln als Linux entstand?
SCNR ;)
Jedes Realmode OS welches einen vergleichbaren XMS-Extender verwendet, kann auch den gesamten verfügbaren oberen Speicherbereich für den RM verwalten.
DOS verwendet den XMS aber nicht, auch die Verwaltung des XMS wird von himem.sys und nicht von DOS erledigt. Für DOS ist himem.sys einfach nur ein Treiber/TSR der irgendeinen Service anbietet. Das es Speicher hinter der HMA gibt weiß DOS (also der Kernel msdos.sys) noch nicht einmal. Es gibt aber im Lieferumfang von DOS (als OS-Distribution) einige Tools die XMS benutzen können (z.B. smartdrv.exe).
Jedes Realmode-OS das einen vergleichbaren XMS-Extender direkt in seinen Kernel implementiert kann aber den Speicher selber verwalten und auch selber nutzen. Es muss ja nicht ein Treiber werden und ausgehend von Thema (selber ein OS zu entwickeln) ist es doch eher unwichtig ob DOS es hier mit einem Treiber macht, oder auch nicht. Die Möglichkeit für den Realmode den gesamten XMS-Speicher zu benutzen zeigt ja nur das es eben möglich ist weit aus mehr Speicher zu verwenden, als nur die erwähnten 640 KByte.
Das man den oberen Speicher vom RM aus nicht direkt adressieren kann ist hierbei völlig irrelevant.
Das ist sehr wohl relevant! Speicher der nicht direkt nutzbar ist läst sich weder für Code noch für statische Daten oder Heap oder Stack nutzen. Der XMS kann von reinen Real-Mode-Programmen/OSen nur als große externe Datenablage (wie z.B. eine Datei) benutzt werden aber nicht als aktiven Teil des Programms.
Für den Benutzer eines verwendenten Realmode-OS ist es irrelevant wie nun auf den XMS-Speicher zugegriffen werden kann. Auch kann ein beliebiger RM-Opcode von einem langsameren Datenträger in den XMS-Speicher zunächst als Daten eingelagert werden und bei Bedarf heruntergeholt und dann ausgeführt werden, ganz ohne sich dabei um Privilege levels und möglichen Schutzverletzungen zu kümmern, wenn im Datenbereich nun ein Opcode zur Ausführung kommt.
Mit EMS ist das etwas anders aber auch ziemlich umständlich.
Auch wird hierbei ja nur kurzzeitig in den PM dafür geschaltet und dann wieder zurück in den Real Mode.
Egal ob kurz oder lang, wenn das OS auch auf Systemen ohne Protected-Mode laufen können soll dann ist der einfach nicht verfügbar und fertig.
Grüße
Erik
LOL. Was möchtest du uns damit eigentlich sagen, dass ein Rechner ohne PM nicht in den PM schalten kann und es somit besser wäre, ein RM-OS zu entwickeln für den Fall, das man gelegentlich auch mal solche exotische Retro-Hardware verwendet?
Dirk
-
Was wollte Herr Torvalds eigentlich entwickeln als Linux entstand?
SCNR ;)
Keinen Texteditor. :-P
Ich habe noch daran gedacht und mir überlegt, ob ich irgendwas einschränkendes dazuschreiben soll. Hätte ich wohl doch besser gemacht, so viele Haarspalter wie hier inzwischen rumlaufen. ;)
Ja ich verstehe was du meinst, du hast dich etwas unglücklich ausgedrückt, aber du kannst doch jederzeit erneut darauf Antworten und deine Sichtweise hierbei vertiefen, bzw. entstandene Missverständnisse aufklären.
Um eine kleine Anwendung(wie einen schlichten Texteditor) zur Ausführung zu bringen braucht man nicht unbedingt ein OS!!!
Deine Aussage das jeder Texteditor auch immer ein OS benötigt ist somit falsch und auch im verwendeten Beispiel daher irreführend. Ein OS kann nun mal ohne ein Booteintrag auf einem Datenträger nicht gestartet werden, wobei ein schlichter Texteditor auch ohne ein OS zur Ausführung gebracht werden kann. Mir geht es hierbei darum solche Fehlinformationen rund um den Realmode richtig zu stellen, damit eine Entscheidung des zu verwendenden Betriebsmodes für ein OS auch mit allen relevanten Fakten vollzogen werden kann und nicht nur einem Teil davon, der alleine ein doch eher schiefes Bild auf diesen Teilbereich wirft. Also das mit den nur verfügbaren 640 KB die man angeblich bei der Verwendung eines RM-OS nur zur Verfügung stehen hat wird hierbei völlig ausser acht gelassen, dass man vom einem RM-OS jederzeit ebenfalls in den PM schalten kann und trotzdem können wir diese OS als ein RM-OS bezeichnen.
Ich finde es daher besser alle Möglichkeiten auszuloten, um eine Entscheidung des zu verwendenden Betriebsmodes machen zu können. Hierbei wären dann auch die Möglichkeiten des PM anzugeben, dessen Fähighkeiten weit über den des RM hinausgehen, als nur den RM mit unzulänglichen Fehlinformationen schlechter dastehen zu lassen als er in Wirklichkeit ist.
Dirk
-
Hallo,
Keinen Texteditor. :-P
Stimmt.
Wenn Du möchtest das ich zur nächsten Präzisionshaarspaltung ansetze wüste ich aber schon gerne was Du mit "irgendwas einschränkendes" meinst. ;)
Grüße
Erik
Ich vermute das damit die Möglichkeit eines RM-OS jederzeit auch in den PM schalten zu können gemeint ist und das dieser Punkt bei der Betrachtung, dass man vom RM nur ein MByte adressieren kann, dadurch eingeschränkt wird. So habe ich es verstanden.
Dirk
-
Meines Erachtens ist ein OS, das in den PM schaltet, kein RM-OS mehr.
Aber selbst wenn man es so sieht, dass alles ein RM-OS ist, in dem die Anwendungen (aber nicht zwingend der Kernel oder Treiber) im RM laufen, welchen Vorteil hat der RM denn bitte gegenüber dem PM? Ich sehe keinen anständigen Grund, das zu tun. Außer vielleicht Nostalgie.
Die Möglichkeit für den Realmode den gesamten XMS-Speicher zu benutzen zeigt ja nur das es eben möglich ist weit aus mehr Speicher zu verwenden, als nur die erwähnten 640 KByte.
Der RM-Code kann den gesamten XMS-Speicher eben nicht direkt nutzen. Er kann PM-Code aufrufen, der die Daten für ihn im Speicher herumschiebt. Das ist aus Sicht des RM-Programmieres maximal eine Art schneller Swapspeicher, aber kein direkt nutzbarer RAM.
EMS kommt dem direkt nutzen schon näher, aber das ist dann endgültig PM.
LOL. Was möchtest du uns damit eigentlich sagen, dass ein Rechner ohne PM nicht in den PM schalten kann und es somit besser wäre, ein RM-OS zu entwickeln für den Fall, das man gelegentlich auch mal solche exotische Retro-Hardware verwendet
Gibt es denn andere Gründe, sich den RM anzutun als "exotische Retro-Hardware"?
-
LOL. Was möchtest du uns damit eigentlich sagen, dass ein Rechner ohne PM nicht in den PM schalten kann und es somit besser wäre, ein RM-OS zu entwickeln für den Fall, das man gelegentlich auch mal solche exotische Retro-Hardware verwendet
Gibt es denn andere Gründe, sich den RM anzutun als "exotische Retro-Hardware"?
Eventuell langeweile. :wink:
Das ist zumindest bei mir immer mal wieder ein Grund, warum ich teilweise ziemlich bescheuerte Projekte starte. :-D
-
LOL. Was möchtest du uns damit eigentlich sagen, dass ein Rechner ohne PM nicht in den PM schalten kann und es somit besser wäre, ein RM-OS zu entwickeln für den Fall, das man gelegentlich auch mal solche exotische Retro-Hardware verwendet
Gibt es denn andere Gründe, sich den RM anzutun als "exotische Retro-Hardware"?
Eventuell langeweile. :wink:
Was ist das, kann man das auch essen :? Die Worte kommen mir zwar bekannt vor, aber dessen Bedeutung habe ich bis heute immer noch nicht begriffen.
Ich selber habe so viele verschiedene Interessen, die ich zu meiner Lebzeit wohl niemals alle auch nur Ansatzweise nachgehen könnte.
So fällt es mir auch sehr schwer eine Langeweile zu verstehen was damit überhaupt gemeint ist.
Das ist zumindest bei mir immer mal wieder ein Grund, warum ich teilweise ziemlich bescheuerte Projekte starte. :-D
Ich würde ein Projekt dessen ich mich widme niemals als bescheuert bezeichnen. Auch wenn man sich damit quasei auf einem Holzweg begibt ist es doch zumindestens dafür nützlich zu erkennen, dass es nicht der richtige Weg war und um dieses erkennen zu können, dafür muss man halt auch mal solche Wege einschlagen.
Dirk
-
EMS kommt dem direkt nutzen schon näher, aber das ist dann endgültig PM.
EMS ist gerade garkein PM. Höchstens Offtopic. ;-)
Ich würde ein Projekt dessen ich mich widme niemals als bescheuert bezeichnen. Auch wenn man sich damit quasei auf einem Holzweg begibt ist es doch zumindestens dafür nützlich zu erkennen, dass es nicht der richtige Weg war und um dieses erkennen zu können, dafür muss man halt auch mal solche Wege einschlagen.
Aber wie nennst du es, wenn man schon vorher weiß, dass es ein Holzweg sein wird und es trotzdem tut?
Gruß,
Svenska
-
Meines Erachtens ist ein OS, das in den PM schaltet, kein RM-OS mehr.
Ein OS das nur kurzzeitig in den PM schaltet, um den XMS-Speicher zu verwalten und unmittelbar danach wieder zurück in den RM schaltet, um alles Andere im RM zu erledigen, wie z.B. Bios-Interrupts zu benutzen, um darüber Geräte zu steuern, das würde ich nicht als PM-OS bezeichnen. DOS wird aus diesem Grund als ein RM-OS bezeichnet, auch dann wenn es Treiber zur Verfügung stellt die kurzzeitig in den PM und wieder zurück in den RM schalten.
Wenn du allerdings DOS, oder eine anderes OS das ebenfalls nur kurzzeitig in den PM und dann gleich wieder zurück in den RM wechselt als PM-OS bezeichnest, dann weicht deine Definition aber erheblich von der allgemeinen Definition hierbei ab.
Aber selbst wenn man es so sieht, dass alles ein RM-OS ist, in dem die Anwendungen (aber nicht zwingend der Kernel oder Treiber) im RM laufen, welchen Vorteil hat der RM denn bitte gegenüber dem PM? Ich sehe keinen anständigen Grund, das zu tun. Außer vielleicht Nostalgie.
Einen Vorteil sehe ich darin das es im RM keine Protection gibt und man sich daher mit solchen Begebenheiten wie Zugriffsrechte und deren Verletzung überhaupt nicht kümmern muss. So ist es vergleichsweise einfacher für einen noch relativ unerfahrenen Entwickler eines OS mit dem RM zu beginnen, als mit dem PM. Dann kann man im RM auch diverse Bios-Funktionen benutzen, die einem im PM nicht zur Verfügung stehen. So muss man sich um solche Dinge im PM selber kümmern, womit der gesamte Aufwand ein OS zu entwickleln erheblich ansteigt.
Die Möglichkeit für den Realmode den gesamten XMS-Speicher zu benutzen zeigt ja nur das es eben möglich ist weit aus mehr Speicher zu verwenden, als nur die erwähnten 640 KByte.
Der RM-Code kann den gesamten XMS-Speicher eben nicht direkt nutzen. Er kann PM-Code aufrufen, der die Daten für ihn im Speicher herumschiebt. Das ist aus Sicht des RM-Programmieres maximal eine Art schneller Swapspeicher, aber kein direkt nutzbarer RAM.
Ja genau, der nutzbare XMS-Speicher kann nur indirekt dem RM zur Verfügung gestellt werden. Trotzdem bleibt damit DOS ein RM-OS laut allgemeiner Definition. Ob das nun über einen Treiber erledigt wird, oder bereits im Kernel eines RM-OS selber integriert wurde ist dabei nicht von Bedeutung, sondern nur ob die meisten Funktionen des Kernels auf dem RM basieren, oder eben nicht.
EMS kommt dem direkt nutzen schon näher, aber das ist dann endgültig PM.
Auch EMS-Speicher wird von DOS über einen entsprechenden Treiber zur Verfügung gestellt. Trotzdem wird DOS auch weiterhin als ein RM-OS bezeichnet, weil der V86-Mode sich eben ähnlich wie der RM verhält.
LOL. Was möchtest du uns damit eigentlich sagen, dass ein Rechner ohne PM nicht in den PM schalten kann und es somit besser wäre, ein RM-OS zu entwickeln für den Fall, das man gelegentlich auch mal solche exotische Retro-Hardware verwendet
Gibt es denn andere Gründe, sich den RM anzutun als "exotische Retro-Hardware"?
Ich verwende den RM mit Vorliebe auch auf moderner Rechnern, wie z.B. auf meinen Asus Striker 2-Rechner mit Intel Core2quad @2.8Ghz und einer Nvidia GTX 295 mit VBE3 Bios und einen daran angeschlossenen 28"LCD in 1920x1200x32. Ist dir diese Hardware modern genug?
Gerne könnte die CPU für mich und meine RM-Anwendungen noch 1000 fach schneller sein, solange der RM auch weiterhin zur Verfügung steht. Der wichtigste Grund für mich ist es Spaß damit zu haben etwas Eigenes zu entwickeln, ohne mich mit den Einschränkungen und Richtlinien eines bereits vorhandenenes OS und deren in Stein gemeisselten Funktionsweise herumplagen zu müssen. Hierbei kann man doch bei der Verwendung von Closed-Source-Treiber es nur lernen wie man, im übertragenen Sinne, einen Lichtschalter an und aus schaltet, nicht jedoch wie man einen solchen Schalter sich selber baut. Für mich ist das einfach zu unbefriedigend etwas für Windows, oder Linux (+Derivate) zu programmieren.
Ich hatte auch noch nie das Bedürfniss mir eine eigenes OS zu entwickeln, mir genügt es wenn meine Anwendungen auch ohne ein PM-OS funktionstüchtig zum laufen zu bringen sind.
Aber wie nennst du es, wenn man schon vorher weiß, dass es ein Holzweg sein wird und es trotzdem tut?
Entweder ist es dann noch keine Holzweg und/oder man erhofft sich noch andere Merkmale daran zu finden die einen wichtig erscheinen.
Dirk
-
Hallo,
meinen Asus Striker 2-Rechner mit Intel Core2quad @2.8Ghz und einer Nvidia GTX 295 mit VBE3 Bios und einen daran angeschlossenen 28"LCD in 1920x1200x32.
Angeber! :-P
Ganz offensichtlich könnte ich noch etliche male darauf hinweisen das der Speicher oberhalb der 1 MB-Grenze zwar vom Real-Mode aus verwaltet werden kann (wenn die nötigen Verwaltungsstrukturen unterhalb der 1 MB-Grenze liegen) aber eben nicht direkt benutzt werden kann. Klar kann man Teile des Programms per XMS oder EMS Auslagern und nur temporär ins untere MB holen (per Overlay-Techniken u.ä.) aber schön ist das nicht und von Compilern wird das auch nicht unterstützt so das man hier einiges an Assembler-Kram bauen müsste. Ein dickes Office-Programm das mehr als 1 MB Code hat wird man nicht so einfach als reines x86-Real-Mode-Programm realisieren können.
Das DOS selber immer noch ein reines RM-OS ist liegt daran das es auch ohne himem.sys und emm386.exe voll funktionsfähig und nutzbar ist, auch wenn dann die 640kB deutlich enger werden.
Wenn UEFI sich weiter verbreitet und zukünftige OSe/Bootloader nicht mal mehr beim Starten mit dem Real-Mode in Berührung kommen fällt auch die Notwendigkeit für diesen weg so das Intel und AMD sicher bald auf die Idee kommen werden den Real-Mode komplett aus der CPU zu entfernen (ernsthafte Nutzer gibt es schon lange nicht mehr). Dabei wird dann hoffentlich auch endlich das A20-Gäte und ein paar andere Altlasten (wie z.B. der ISA-DMA-Controller) gleich mit entfernt. Sollte dieser Schritt tatsächlich passieren wäre das auf jeden Fall ein echter Fortschritt für die x86-Plattform.
Grüße
Erik
-
Wenn UEFI sich weiter verbreitet ...
Grüße
Erik
Ich habe allerdings die Befürchtung das mit UEFI auch Digital Rights Management(DRM) immer weiter verbreitet wird und so alle User zukünftig für jeden Mouseklick beim Klickibunti zigfach zahlen müssen. Ob diese feindliche Übernahme unserer PCs dann noch zu stoppen ist bleibt abzuwarten. So sehe ich die Entwicklung mit gemischten Gefühlen entgegen und ich frage mich, ob so ein Hobby mir dann überhaupt noch Spaß macht, denn Fernsehen sehe ich auch, wegen nur noch 24 Stunden Teletubie-Folter auf allen Kanälen, schon seit einigen Jahren überhaupt gar nicht mehr. Das ganze erinnert mich immer mehr an den Begriff einer Kathodenstrahl-Marionette, denn es ist ja auch noch gar nicht so lange her, da hat man sich noch zur Tageschau einen Anzug angezogen und den Nachrichtensprechen ebenfalls mit einem "guten Abend" vor der Glotze begrüßt, so als wenn man im Fernsehstudio die Zuschauer ebenfalls sehen und hören könnte. Nun haben wir ja schon freiwillig unsere Radio-Hypnotic Intracereberal Mindcontrol-Transmitter-Handicaps akzeptiert. Morgen gibt es dann wohl gleich nach der Geburt den Gutmenschen-Chip implantiert.
Dirk
-
Mit Projekten wie coreboot wird die Freiheit unserer Computersysteme auch weiterhin gewährleistet bleiben.
Mit coreboot ist es u.a. möglich, eine BIOS- (SeaBIOS) als auch eine UEFI-Schnittstelle (TianoCore) bereitzustellen, außerdem gibt es noch verschiedenste andere Payloads (z.B. direkt einen Linux-Kernel im BIOS-Flash). AMD unterstützt coreboot mit Dokumentation und Code und ein GSoC-Projekt möchte coreboot auf ARM portieren.
Also wenn schon vieles schwarz ist, so ist es doch nicht alles. (Und selbst wenn, Development-Boards und Mikrocontroller bleiben uns auch enthalten - und in den kleineren ist kaum Platz für DRM.)
-
http://de.wikipedia.org/wiki/Extensible_Firmware_Interface
EFI wurde dafür kritisiert, mehr Komplexität ins System zu bringen, ohne nennenswerte Vorteile zu bieten[13] und das vollständige Ersetzen mit einem Open-Source-BIOS wie OpenBIOS und Coreboot unmöglich zu machen[14]. Es löse nicht eines der langjährigen Probleme des BIOS - nämlich, dass die meiste Hardware zwei unterschiedliche Treiber benötigt.[15] Es sei nicht klar, warum es nützlich sein soll, zwei komplett unterschiedliche Betriebssysteme gleichzeitig in Betrieb zu haben, die im Grunde die selben Aufgaben erledigen, oder warum ein neues Betriebssystem von Grund auf neu geschrieben werden müsste.[15] EFI gilt einem Entwickler von Coreboot zufolge in sicherheitskritischen Einsatzumgebungen - wie etwa in Banken - als ein mögliches Sicherheitsrisiko, da etwa mit dem implementierten Netzwerkstack die theoretische Möglichkeit bestünde, Daten unbemerkt vom Betriebssystem an eine beliebige Adresse zu senden. Auch für DRM-Zwecke könnte EFI benutzt werden, um etwa den I/O-Datenstrom auf digitale Wasserzeichen hin zu überwachen. Aus diesen Gründen plädieren einige Anwender eher für ein quelloffenes System wie Coreboot (ehemals LinuxBIOS).
Ich denke das es nur sehr wenige PC-Benutzer geben wird die ihr neu eworbenes UEFI-Bios gegen ein Coreboot-Bios austauschen werden und so werden wohl die Nachteile dieser Entwicklung sich am Markt durchsetzen, so das die meisten Kunden hierbei durch restriktive Gängelungen von Seiten der Konzerne bei der Frage der individuellen Selbstbestimmung, sich über den Tisch ziehen lassen werden und nur ein bedeutungsloser Anteil an kritikfähigen Individualisten sich dieser Sache entziehen werden.
Im weitem Umfeld sieht man ja auch schon am Vertrag von Maastricht deutlich genug in welche Richtung es nach dem Willen unser führenden Entscheidungsträger geht. (Kontroverse Kritik darüber findet man u.A. in Beiträgen von Karl Albrecht Schachtschneider. http://www.kaschachtschneider.de/)
Dirk