T
Thomas 'Tom' Malkus
Guest
MaWin meinte:
Flat Memory ist die einfachste Möglichkeit für die Entwicklung
aber nicht immer die die beste. Segmentierung ist aber auch
nicht immer schön. Es hat halt alles seine Vor- und Nachteile.
73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Im Grunde stimmt es, weil es schon in die Hardware gegossen ist.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.
Flat Memory ist die einfachste Möglichkeit für die Entwicklung
aber nicht immer die die beste. Segmentierung ist aber auch
nicht immer schön. Es hat halt alles seine Vor- und Nachteile.
73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19