"Gerrit Heitsch" schrieb im Newsbeitrag news:fogjst$uva$ snipped-for-privacy@news.bawue.net...
Tja, lern noch ein paar Jahre, vielleicht begreifst du dann.
Es ist normal, dass viele Nachplappernde die Segmentierung schlecht finden, schliesslich stand es so auch in allen damaligen Publikationen. Wenn du dir aber selbst mal ueber Betriebssysteme, Speicherverwaltung, Prozesse Gedanken gemacht haettest, und verglichen haettest, wuesstest du, dass Segmentierung genau die Hardware ist, die passt. Dass man bei 286 das dirty-bit vergessen hat, war Pech, und fuehrte dazu, dass man mit dem Prozessor nicht demonstrieren konnte, wie viel effektiver die Segmentierung ist, aber wer die B5500 nicht kennt, sollte lieber die Fuesse stillhalten.
Frank Wilberg:
Es ist die effizienteste Moeglichkeit, geladenen Code vor anderem Code zu schuetzen. Man kann nicht mitten reinspringen, man kann keine Daten manipulieren, und das funktioniert sogar, wenn verschiedene Prozesse den Code nutzen.
Wenn du Programm A (mit Daten und Code) und Programm B (mit Daten und Code) eine DLL C (mit Code, statischen Daten und prozessbezogenen Daten) betrachtest, zur Steigerung noch in Programm A ein Treiber D (mit Code, statischen Daten und prozessbezogenen Daten) und in Programm B ein Treiber E (mit Code, statischen Daten und prozessbezogenen Daten) dir vorstellst, wobei Treiber D von C verwendet wird wenn es durch A lief, nur mit den Zugriffsrechten von A erlaubt (nur A hat die Signatur die eine Verwendung von D erlaubt), und Treiber E von C verwendet wird bei Programm B nur mit den Zugriffsrechten von B, und das ganze nicht nur zufaellig (richtig programmiert), sondern systembedingt sicher sein soll, sind Segmente mit Abstand das rechenzeiteffektivste.
Nein, lernen musst du. Z.B. dass deine Vorurteile nicht angebracht sind.
Frank Brunner:
Macintosh, gilt aber auch fuer Amiga und Sun, war wohl A5 statt A13, richtig, halt das vorletzte Adressregister als Datensegmentzeiger, verwaltet ja der Compiler, da merkt man sich die Nummer nicht.