Selbstmodifizierender Code - Versionsgeschichte

Skranon am 27. September 2024 um 18:00 Uhr

2024-09-27T18:00:02Z

← Nächstältere Version		Version vom 27. September 2024, 20:00 Uhr
Zeile 3:		Zeile 3:
	Mit der Bezeichnung '''Selbstmodifizierender Code''' ({{enS\|Self Modifying Code}}) wird ein Abschnitt eines [[Computerprogramm]]s bezeichnet, das zur Lösung der Programmaufgabe Teile des eigenen Programmcodes während der Ausführung gezielt verändert. Unter der Bezeichnung „freier Rechenplan“ hatte schon [[Konrad Zuse]] selbstmodifizierenden Code als Möglichkeit in die von ihm entworfene Programmiersprache [[Plankalkül]] aufgenommen.		Mit der Bezeichnung '''Selbstmodifizierender Code''' ({{enS\|Self Modifying Code}}) wird ein Abschnitt eines [[Computerprogramm]]s bezeichnet, das zur Lösung der Programmaufgabe Teile des eigenen Programmcodes während der Ausführung gezielt verändert. Unter der Bezeichnung „freier Rechenplan“ hatte schon [[Konrad Zuse]] selbstmodifizierenden Code als Möglichkeit in die von ihm entworfene Programmiersprache [[Plankalkül]] aufgenommen.

	Das Programm muss dabei in der Lage sein, im [[Maschinensprache\|Maschinencode]] bestimmte Befehle durch sinnvolle andere Maschinenbefehle zu ersetzen. Bei höheren [[Programmiersprache]]n (z. B. [[APL (Programmiersprache)\|APL]]) manipuliert das Programm meist den [[Quellcode]] als [[Zeichenkette]].		Das Programm muss dabei in der Lage sein, im [[Maschinensprache\|Maschinencode]] bestimmte Befehle durch sinnvolle andere Maschinenbefehle zu ersetzen. Bei höheren [[Programmiersprache]]n (z. B. [[APL (Programmiersprache)\|APL]]) manipuliert das Programm meist den [[Quelltext\|Quellcode]] als [[Zeichenkette]].

	Selbstmodifizierender Code kann unter anderem da verwendet werden, wo es möglich ist, mehrere, nur an wenigen Stellen unterschiedliche Programmteile zu einem einzigen zusammenzufassen.		Selbstmodifizierender Code kann unter anderem da verwendet werden, wo es möglich ist, mehrere, nur an wenigen Stellen unterschiedliche Programmteile zu einem einzigen zusammenzufassen.
Zeile 32:		Zeile 32:
	== Beispiele ==		== Beispiele ==
	=== Videospiel ===		=== Videospiel ===
	In einem [[Pong\|Videotennis]]-Spiel kann im Programmteil, das den Ball steuert, ein [[Inkrement]]-Befehl durch einen [[Inkrement und Dekrement\|Dekrement]]-Befehl ersetzt werden, wenn er an die Wand prallt, dadurch wird die Bewegungsrichtung umgekehrt.		In einem [[Pong\|Videotennis]]-Spiel kann im Programmteil, das den Ball steuert, ein [[Inkrement und Dekrement\|Inkrement]]-Befehl durch einen [[Inkrement und Dekrement\|Dekrement]]-Befehl ersetzt werden, wenn er an die Wand prallt, dadurch wird die Bewegungsrichtung umgekehrt.

	Die [[Byte]]s, die die Koordinaten des Balles beinhalten, können so im Speicher abgelegt werden, dass sie gleichzeitig als direkte Parameter eines Kommandos interpretiert werden. Man stelle sich beispielsweise einen Befehl vor, der dazu führt, dass der Ball an einer bestimmten Stelle angezeigt wird. Statt nun die beiden Argumente „X-Position“ und „Y-Position“ indirekt als Variablen anzusprechen, können sie direkt so im Speicher abgelegt sein, dass sie Teil des Befehls „Stelle Ball dar“ sind.		Die [[Byte]]s, die die Koordinaten des Balles beinhalten, können so im Speicher abgelegt werden, dass sie gleichzeitig als direkte Parameter eines Kommandos interpretiert werden. Man stelle sich beispielsweise einen Befehl vor, der dazu führt, dass der Ball an einer bestimmten Stelle angezeigt wird. Statt nun die beiden Argumente „X-Position“ und „Y-Position“ indirekt als Variablen anzusprechen, können sie direkt so im Speicher abgelegt sein, dass sie Teil des Befehls „Stelle Ball dar“ sind.
Zeile 48:		Zeile 48:

	=== Mathematikprogramm ===		=== Mathematikprogramm ===
	In Microsoft [[BASIC]] auf Commodore Computern (z. B. PET, VC 20, [[C64]]) war es über ein kurzzeitiges Anhalten eines Programms effektiv möglich, eine über den INPUT-Befehl im Programm abgefragte Benutzerfunktion (z. B. „SIN(X)“) an den Programmeditor zu übergeben, der eine Zeile im BASIC-Programm entsprechend veränderte, worauf das Programm ohne Verlust der Variableninformation (mittels [[Sprunganweisung\|GOTO-Befehl]]) wieder fortgesetzt wurde		In Microsoft [[BASIC]] auf Commodore Computern (z. B. PET, VC 20, [[Commodore 64\|C64]]) war es über ein kurzzeitiges Anhalten eines Programms effektiv möglich, eine über den INPUT-Befehl im Programm abgefragte Benutzerfunktion (z. B. „SIN(X)“) an den Programmeditor zu übergeben, der eine Zeile im BASIC-Programm entsprechend veränderte, worauf das Programm ohne Verlust der Variableninformation (mittels [[Sprunganweisung\|GOTO-Befehl]]) wieder fortgesetzt wurde und die neue Zeile für Berechnungen nutzen konnte. Dies geschah durch Ausdruck der gewünschten neuen Programmzeile in der obersten Bildschirmzeile (unter Benutzung des Microsoft-BASIC-Ausdrucks „DEF FN“) und Ausgabe des Befehls „GOTO xxx“ zum Rücksprung ins Programm in der zweiten Bildschirmzeile. Füllen des Tastaturpuffers mit den Zeichen HOME und mehreren Steuerzeichen für [[Wagenrücklauf]] sorgte dafür, dass nach dem STOP-Befehl der systemeigene Programmeditor die zuvor ausgegebene Programmzeile bearbeitete und bei Erreichen des GOTO-Befehls (ausgelöst durch die Wagenrücklauf-Zeichen) das BASIC-Programm wieder ausführte.
	und die neue Zeile für Berechnungen nutzen konnte.
	Dies geschah durch Ausdruck der gewünschten neuen Programmzeile in der obersten Bildschirmzeile (unter Benutzung des Microsoft-BASIC-Ausdrucks „[[DEF FN]]“) und Ausgabe des Befehls „GOTO xxx“ zum Rücksprung ins Programm in der zweiten Bildschirmzeile.
	Füllen des Tastaturpuffers mit den Zeichen [[HOME]] und mehreren Steuerzeichen für [[Wagenrücklauf]] sorgte dafür, dass nach dem STOP-Befehl der systemeigene Programmeditor die zuvor ausgegebene Programmzeile bearbeitete und bei Erreichen des GOTO-Befehls (ausgelöst durch die Wagenrücklauf-Zeichen) das BASIC-Programm wieder ausführte.

	=== Kopierroutinen (6502-CPU) ===		=== Kopierroutinen (6502-CPU) ===

84.158.120.82: /* Architektur- und Sprachabhängigkeit */ Autor Charles Petzold hinzugefügt

2024-08-11T00:45:54Z

Architektur- und Sprachabhängigkeit: Autor Charles Petzold hinzugefügt

← Nächstältere Version		Version vom 11. August 2024, 02:45 Uhr
Zeile 15:		Zeile 15:
	Die In-Memory-Veränderung eines Maschinensprachen-Programmcodes ist in einer [[Von-Neumann-Architektur]] einfach möglich, da Programmteile zeitweise als Daten betrachtet werden können, später dann wieder als Programmteile; bei der Von-Neumann-Architektur besitzen Programm und Daten denselben Adressraum. In Prozessoren mit [[Harvard-Architektur]] ist das Modifizieren von Maschinencode während der [[Laufzeit (Informatik)\|Laufzeit]] nicht vorgesehen, Programm und Daten haben getrennte Adressräume. Evtl. stehen spezielle Befehle für das Übertragen von Informationen zwischen den Adressräumen zur Verfügung, oder es müssen Umwege außerhalb des Arbeitsspeichers beschritten werden.		Die In-Memory-Veränderung eines Maschinensprachen-Programmcodes ist in einer [[Von-Neumann-Architektur]] einfach möglich, da Programmteile zeitweise als Daten betrachtet werden können, später dann wieder als Programmteile; bei der Von-Neumann-Architektur besitzen Programm und Daten denselben Adressraum. In Prozessoren mit [[Harvard-Architektur]] ist das Modifizieren von Maschinencode während der [[Laufzeit (Informatik)\|Laufzeit]] nicht vorgesehen, Programm und Daten haben getrennte Adressräume. Evtl. stehen spezielle Befehle für das Übertragen von Informationen zwischen den Adressräumen zur Verfügung, oder es müssen Umwege außerhalb des Arbeitsspeichers beschritten werden.

	Höhere Programmiersprachen können in das „normale Programm“ einen [[Compiler]] einbetten, dann müssen die Modifikation ggf. nicht direkt in [[Maschinensprache]] ausgeführt werden. Hilfreich ist, wenn die Sprache [[Homoikonizität]] besitzt (Selbst-Abbildbarkeit: die Eigenschaft einer Programmiersprache, dass Programme gleichzeitig Datenstrukturen derselben Sprache sind/sein können; in solchen Sprachen ist es einfach, Programme zu schreiben, die Programme schreiben). Die [[Portierung (Software)\|Portierung]] von selbstmodifizierendem Maschinencode auf einen beliebigen [[Prozessor]] ist fast nicht möglich. Mittlerweile verfügen viele [[Prozessorarchitektur]]en, die eigentlich Von-Neumann-artig aufgebaut sind, über Methoden, das Schreiben in (Maschinen-)Codebereiche sowie das Ausführen von Datenbereichen zu verhindern (z. B. [[NX-Bit]], [[Protected Mode]] des [[Intel 80286]]<ref>https://books.google.de/books?id=pDGnxFyejN4C&lpg=PP1&hl=de&pg=PA170#v=onepage&q&f=false Obstracles to a grown-up operating system, PC Mag 10.Juni 1986 (englisch)</ref>), als Schutzmaßnahme gegen [[Pufferüberlauf]]-Angriffe. Bei höheren Programmiersprachen sind für selbstmodifizierenden Code in der Regel [[Interpreter\|interpretierende]] (also nicht kompilierende) Systeme notwendig.		Höhere Programmiersprachen können in das „normale Programm“ einen [[Compiler]] einbetten, dann müssen die Modifikation ggf. nicht direkt in [[Maschinensprache]] ausgeführt werden. Hilfreich ist, wenn die Sprache [[Homoikonizität]] besitzt (Selbst-Abbildbarkeit: die Eigenschaft einer Programmiersprache, dass Programme gleichzeitig Datenstrukturen derselben Sprache sind/sein können; in solchen Sprachen ist es einfach, Programme zu schreiben, die Programme schreiben). Die [[Portierung (Software)\|Portierung]] von selbstmodifizierendem Maschinencode auf einen beliebigen [[Prozessor]] ist fast nicht möglich. Mittlerweile verfügen viele [[Prozessorarchitektur]]en, die eigentlich Von-Neumann-artig aufgebaut sind, über Methoden, das Schreiben in (Maschinen-)Codebereiche sowie das Ausführen von Datenbereichen zu verhindern (z. B. [[NX-Bit]], [[Protected Mode]] des [[Intel 80286]]<ref>https://books.google.de/books?id=pDGnxFyejN4C&lpg=PP1&hl=de&pg=PA170#v=onepage&q&f=false Obstracles to a grown-up operating system, Charles Petzold PC Mag 10.Juni 1986 (englisch)</ref>), als Schutzmaßnahme gegen [[Pufferüberlauf]]-Angriffe. Bei höheren Programmiersprachen sind für selbstmodifizierenden Code in der Regel [[Interpreter\|interpretierende]] (also nicht kompilierende) Systeme notwendig.

	== Vorteile ==		== Vorteile ==

84.158.120.82: /* Architektur- und Sprachabhängigkeit */ Verlinkung

2024-08-11T00:37:24Z

Architektur- und Sprachabhängigkeit: Verlinkung

← Nächstältere Version		Version vom 11. August 2024, 02:37 Uhr
Zeile 15:		Zeile 15:
	Die In-Memory-Veränderung eines Maschinensprachen-Programmcodes ist in einer [[Von-Neumann-Architektur]] einfach möglich, da Programmteile zeitweise als Daten betrachtet werden können, später dann wieder als Programmteile; bei der Von-Neumann-Architektur besitzen Programm und Daten denselben Adressraum. In Prozessoren mit [[Harvard-Architektur]] ist das Modifizieren von Maschinencode während der [[Laufzeit (Informatik)\|Laufzeit]] nicht vorgesehen, Programm und Daten haben getrennte Adressräume. Evtl. stehen spezielle Befehle für das Übertragen von Informationen zwischen den Adressräumen zur Verfügung, oder es müssen Umwege außerhalb des Arbeitsspeichers beschritten werden.		Die In-Memory-Veränderung eines Maschinensprachen-Programmcodes ist in einer [[Von-Neumann-Architektur]] einfach möglich, da Programmteile zeitweise als Daten betrachtet werden können, später dann wieder als Programmteile; bei der Von-Neumann-Architektur besitzen Programm und Daten denselben Adressraum. In Prozessoren mit [[Harvard-Architektur]] ist das Modifizieren von Maschinencode während der [[Laufzeit (Informatik)\|Laufzeit]] nicht vorgesehen, Programm und Daten haben getrennte Adressräume. Evtl. stehen spezielle Befehle für das Übertragen von Informationen zwischen den Adressräumen zur Verfügung, oder es müssen Umwege außerhalb des Arbeitsspeichers beschritten werden.

	Höhere Programmiersprachen können in das „normale Programm“ einen [[Compiler]] einbetten, dann müssen die Modifikation ggf. nicht direkt in [[Maschinensprache]] ausgeführt werden. Hilfreich ist, wenn die Sprache [[Homoikonizität]] besitzt (Selbst-Abbildbarkeit: die Eigenschaft einer Programmiersprache, dass Programme gleichzeitig Datenstrukturen derselben Sprache sind/sein können; in solchen Sprachen ist es einfach, Programme zu schreiben, die Programme schreiben). Die [[Portierung (Software)\|Portierung]] von selbstmodifizierendem Maschinencode auf einen beliebigen [[Prozessor]] ist fast nicht möglich. Mittlerweile verfügen viele [[Prozessorarchitektur]]en, die eigentlich Von-Neumann-artig aufgebaut sind, über Methoden, das Schreiben in (Maschinen-)Codebereiche sowie das Ausführen von Datenbereichen zu verhindern (z. B. [[NX-Bit]], [[Protected Mode]] des Intel 80286<ref>https://books.google.de/books?id=pDGnxFyejN4C&lpg=PP1&hl=de&pg=PA170#v=onepage&q&f=false Obstracles to a grown-up operating system, PC Mag 10.Juni 1986 (englisch)</ref>), als Schutzmaßnahme gegen [[Pufferüberlauf]]-Angriffe. Bei höheren Programmiersprachen sind für selbstmodifizierenden Code in der Regel [[Interpreter\|interpretierende]] (also nicht kompilierende) Systeme notwendig.		Höhere Programmiersprachen können in das „normale Programm“ einen [[Compiler]] einbetten, dann müssen die Modifikation ggf. nicht direkt in [[Maschinensprache]] ausgeführt werden. Hilfreich ist, wenn die Sprache [[Homoikonizität]] besitzt (Selbst-Abbildbarkeit: die Eigenschaft einer Programmiersprache, dass Programme gleichzeitig Datenstrukturen derselben Sprache sind/sein können; in solchen Sprachen ist es einfach, Programme zu schreiben, die Programme schreiben). Die [[Portierung (Software)\|Portierung]] von selbstmodifizierendem Maschinencode auf einen beliebigen [[Prozessor]] ist fast nicht möglich. Mittlerweile verfügen viele [[Prozessorarchitektur]]en, die eigentlich Von-Neumann-artig aufgebaut sind, über Methoden, das Schreiben in (Maschinen-)Codebereiche sowie das Ausführen von Datenbereichen zu verhindern (z. B. [[NX-Bit]], [[Protected Mode]] des [[Intel 80286]]<ref>https://books.google.de/books?id=pDGnxFyejN4C&lpg=PP1&hl=de&pg=PA170#v=onepage&q&f=false Obstracles to a grown-up operating system, PC Mag 10.Juni 1986 (englisch)</ref>), als Schutzmaßnahme gegen [[Pufferüberlauf]]-Angriffe. Bei höheren Programmiersprachen sind für selbstmodifizierenden Code in der Regel [[Interpreter\|interpretierende]] (also nicht kompilierende) Systeme notwendig.

	== Vorteile ==		== Vorteile ==

84.158.120.82: /* Architektur- und Sprachabhängigkeit */ Nur i80286, der 386 musste es für DOS zumindest im VM86 Modus erlauben.

2024-08-11T00:36:49Z

Architektur- und Sprachabhängigkeit: Nur i80286, der 386 musste es für DOS zumindest im VM86 Modus erlauben.

← Nächstältere Version		Version vom 11. August 2024, 02:36 Uhr
Zeile 15:		Zeile 15:
	Die In-Memory-Veränderung eines Maschinensprachen-Programmcodes ist in einer [[Von-Neumann-Architektur]] einfach möglich, da Programmteile zeitweise als Daten betrachtet werden können, später dann wieder als Programmteile; bei der Von-Neumann-Architektur besitzen Programm und Daten denselben Adressraum. In Prozessoren mit [[Harvard-Architektur]] ist das Modifizieren von Maschinencode während der [[Laufzeit (Informatik)\|Laufzeit]] nicht vorgesehen, Programm und Daten haben getrennte Adressräume. Evtl. stehen spezielle Befehle für das Übertragen von Informationen zwischen den Adressräumen zur Verfügung, oder es müssen Umwege außerhalb des Arbeitsspeichers beschritten werden.		Die In-Memory-Veränderung eines Maschinensprachen-Programmcodes ist in einer [[Von-Neumann-Architektur]] einfach möglich, da Programmteile zeitweise als Daten betrachtet werden können, später dann wieder als Programmteile; bei der Von-Neumann-Architektur besitzen Programm und Daten denselben Adressraum. In Prozessoren mit [[Harvard-Architektur]] ist das Modifizieren von Maschinencode während der [[Laufzeit (Informatik)\|Laufzeit]] nicht vorgesehen, Programm und Daten haben getrennte Adressräume. Evtl. stehen spezielle Befehle für das Übertragen von Informationen zwischen den Adressräumen zur Verfügung, oder es müssen Umwege außerhalb des Arbeitsspeichers beschritten werden.

	Höhere Programmiersprachen können in das „normale Programm“ einen [[Compiler]] einbetten, dann müssen die Modifikation ggf. nicht direkt in [[Maschinensprache]] ausgeführt werden. Hilfreich ist, wenn die Sprache [[Homoikonizität]] besitzt (Selbst-Abbildbarkeit: die Eigenschaft einer Programmiersprache, dass Programme gleichzeitig Datenstrukturen derselben Sprache sind/sein können; in solchen Sprachen ist es einfach, Programme zu schreiben, die Programme schreiben). Die [[Portierung (Software)\|Portierung]] von selbstmodifizierendem Maschinencode auf einen beliebigen [[Prozessor]] ist fast nicht möglich. Mittlerweile verfügen viele [[Prozessorarchitektur]]en, die eigentlich Von-Neumann-artig aufgebaut sind, über Methoden, das Schreiben in (Maschinen-)Codebereiche sowie das Ausführen von Datenbereichen zu verhindern (z. B. [[NX-Bit]], [[Protected Mode]] des 80286 ~~und späteren Prozessoren~~<ref>https://books.google.de/books?id=pDGnxFyejN4C&lpg=PP1&hl=de&pg=PA170#v=onepage&q&f=false Obstracles to a grown-up operating system, PC Mag 10.Juni 1986 (englisch)</ref>), als Schutzmaßnahme gegen [[Pufferüberlauf]]-Angriffe. Bei höheren Programmiersprachen sind für selbstmodifizierenden Code in der Regel [[Interpreter\|interpretierende]] (also nicht kompilierende) Systeme notwendig.		Höhere Programmiersprachen können in das „normale Programm“ einen [[Compiler]] einbetten, dann müssen die Modifikation ggf. nicht direkt in [[Maschinensprache]] ausgeführt werden. Hilfreich ist, wenn die Sprache [[Homoikonizität]] besitzt (Selbst-Abbildbarkeit: die Eigenschaft einer Programmiersprache, dass Programme gleichzeitig Datenstrukturen derselben Sprache sind/sein können; in solchen Sprachen ist es einfach, Programme zu schreiben, die Programme schreiben). Die [[Portierung (Software)\|Portierung]] von selbstmodifizierendem Maschinencode auf einen beliebigen [[Prozessor]] ist fast nicht möglich. Mittlerweile verfügen viele [[Prozessorarchitektur]]en, die eigentlich Von-Neumann-artig aufgebaut sind, über Methoden, das Schreiben in (Maschinen-)Codebereiche sowie das Ausführen von Datenbereichen zu verhindern (z. B. [[NX-Bit]], [[Protected Mode]] des Intel 80286<ref>https://books.google.de/books?id=pDGnxFyejN4C&lpg=PP1&hl=de&pg=PA170#v=onepage&q&f=false Obstracles to a grown-up operating system, PC Mag 10.Juni 1986 (englisch)</ref>), als Schutzmaßnahme gegen [[Pufferüberlauf]]-Angriffe. Bei höheren Programmiersprachen sind für selbstmodifizierenden Code in der Regel [[Interpreter\|interpretierende]] (also nicht kompilierende) Systeme notwendig.

	== Vorteile ==		== Vorteile ==

84.158.120.82: /* Architektur- und Sprachabhängigkeit */ Bereits der Protected Mode des 286er verhinderte selbstmodifizierenden Code. Quelle liegt bei.

2024-08-11T00:33:04Z

Architektur- und Sprachabhängigkeit: Bereits der Protected Mode des 286er verhinderte selbstmodifizierenden Code. Quelle liegt bei.

← Nächstältere Version		Version vom 11. August 2024, 02:33 Uhr
Zeile 15:		Zeile 15:
	Die In-Memory-Veränderung eines Maschinensprachen-Programmcodes ist in einer [[Von-Neumann-Architektur]] einfach möglich, da Programmteile zeitweise als Daten betrachtet werden können, später dann wieder als Programmteile; bei der Von-Neumann-Architektur besitzen Programm und Daten denselben Adressraum. In Prozessoren mit [[Harvard-Architektur]] ist das Modifizieren von Maschinencode während der [[Laufzeit (Informatik)\|Laufzeit]] nicht vorgesehen, Programm und Daten haben getrennte Adressräume. Evtl. stehen spezielle Befehle für das Übertragen von Informationen zwischen den Adressräumen zur Verfügung, oder es müssen Umwege außerhalb des Arbeitsspeichers beschritten werden.		Die In-Memory-Veränderung eines Maschinensprachen-Programmcodes ist in einer [[Von-Neumann-Architektur]] einfach möglich, da Programmteile zeitweise als Daten betrachtet werden können, später dann wieder als Programmteile; bei der Von-Neumann-Architektur besitzen Programm und Daten denselben Adressraum. In Prozessoren mit [[Harvard-Architektur]] ist das Modifizieren von Maschinencode während der [[Laufzeit (Informatik)\|Laufzeit]] nicht vorgesehen, Programm und Daten haben getrennte Adressräume. Evtl. stehen spezielle Befehle für das Übertragen von Informationen zwischen den Adressräumen zur Verfügung, oder es müssen Umwege außerhalb des Arbeitsspeichers beschritten werden.

	Höhere Programmiersprachen können in das „normale Programm“ einen [[Compiler]] einbetten, dann müssen die Modifikation ggf. nicht direkt in [[Maschinensprache]] ausgeführt werden. Hilfreich ist, wenn die Sprache [[Homoikonizität]] besitzt (Selbst-Abbildbarkeit: die Eigenschaft einer Programmiersprache, dass Programme gleichzeitig Datenstrukturen derselben Sprache sind/sein können; in solchen Sprachen ist es einfach, Programme zu schreiben, die Programme schreiben). Die [[Portierung (Software)\|Portierung]] von selbstmodifizierendem Maschinencode auf einen beliebigen [[Prozessor]] ist fast nicht möglich. Mittlerweile verfügen viele [[Prozessorarchitektur]]en, die eigentlich Von-Neumann-artig aufgebaut sind, über Methoden, das Schreiben in (Maschinen-)Codebereiche sowie das Ausführen von Datenbereichen zu verhindern (z. B. [[NX-Bit]]), als Schutzmaßnahme gegen [[Pufferüberlauf]]-Angriffe. Bei höheren Programmiersprachen sind für selbstmodifizierenden Code in der Regel [[Interpreter\|interpretierende]] (also nicht kompilierende) Systeme notwendig.		Höhere Programmiersprachen können in das „normale Programm“ einen [[Compiler]] einbetten, dann müssen die Modifikation ggf. nicht direkt in [[Maschinensprache]] ausgeführt werden. Hilfreich ist, wenn die Sprache [[Homoikonizität]] besitzt (Selbst-Abbildbarkeit: die Eigenschaft einer Programmiersprache, dass Programme gleichzeitig Datenstrukturen derselben Sprache sind/sein können; in solchen Sprachen ist es einfach, Programme zu schreiben, die Programme schreiben). Die [[Portierung (Software)\|Portierung]] von selbstmodifizierendem Maschinencode auf einen beliebigen [[Prozessor]] ist fast nicht möglich. Mittlerweile verfügen viele [[Prozessorarchitektur]]en, die eigentlich Von-Neumann-artig aufgebaut sind, über Methoden, das Schreiben in (Maschinen-)Codebereiche sowie das Ausführen von Datenbereichen zu verhindern (z. B. [[NX-Bit]], [[Protected Mode]] des 80286 und späteren Prozessoren<ref>https://books.google.de/books?id=pDGnxFyejN4C&lpg=PP1&hl=de&pg=PA170#v=onepage&q&f=false Obstracles to a grown-up operating system, PC Mag 10.Juni 1986 (englisch)</ref>), als Schutzmaßnahme gegen [[Pufferüberlauf]]-Angriffe. Bei höheren Programmiersprachen sind für selbstmodifizierenden Code in der Regel [[Interpreter\|interpretierende]] (also nicht kompilierende) Systeme notwendig.

	== Vorteile ==		== Vorteile ==

84.158.113.105: /* Nachteile */

2024-06-11T13:45:36Z

Nachteile

← Nächstältere Version		Version vom 11. Juni 2024, 15:45 Uhr
Zeile 28:		Zeile 28:
	#Der CPU-Entwurf wird deutlich komplizierter; mitunter kommt es bei anderen CPU-Versionen zu Fehlern.<ref group="Anmerkung">Selbstmodifizierender Code wurde z. B. verwendet, um den Intel 8088 vom Intel 8086 zu unterscheiden, da einer eine längere Befehlspipeline besaß: Der Prozessor mit der kurzen Pipeline folgte der Änderung, der Prozessor mit der längeren Pipeline führte jedoch weiterhin den „alten“ Befehl aus, da dieser bereits in der Pipeline gespeichert war.</ref>		#Der CPU-Entwurf wird deutlich komplizierter; mitunter kommt es bei anderen CPU-Versionen zu Fehlern.<ref group="Anmerkung">Selbstmodifizierender Code wurde z. B. verwendet, um den Intel 8088 vom Intel 8086 zu unterscheiden, da einer eine längere Befehlspipeline besaß: Der Prozessor mit der kurzen Pipeline folgte der Änderung, der Prozessor mit der längeren Pipeline führte jedoch weiterhin den „alten“ Befehl aus, da dieser bereits in der Pipeline gespeichert war.</ref>
	#Programmcode kann im Arbeitsspeicher nicht für mehrere Instanzen wiederverwendet werden, die erste Instanz würde den Code modifizieren, womit die spätere zweite Instanz nicht mehr korrekt funktionieren würde.<ref>https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/july/under-the-hood-happy-10th-anniversary-windows ''Under the Hood: Happy 10th Anniversary, Windows'' von Matt Pietrek, MSDN Magazin</ref>		#Programmcode kann im Arbeitsspeicher nicht für mehrere Instanzen wiederverwendet werden, die erste Instanz würde den Code modifizieren, womit die spätere zweite Instanz nicht mehr korrekt funktionieren würde.<ref>https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/july/under-the-hood-happy-10th-anniversary-windows ''Under the Hood: Happy 10th Anniversary, Windows'' von Matt Pietrek, MSDN Magazin</ref>
			#Kurzer Selbstmodifizierender Code ist auf modernen CPUs aufgrund von deren Cache- und Pipelineverhalten wenig effizient.

	== Beispiele ==		== Beispiele ==

84.158.113.105: /* Nachteile */

2024-06-11T13:42:09Z

Nachteile

← Nächstältere Version		Version vom 11. Juni 2024, 15:42 Uhr
Zeile 27:		Zeile 27:
	#Der Maschinencode ist schwierig nachzuvollziehen.		#Der Maschinencode ist schwierig nachzuvollziehen.
	#Der CPU-Entwurf wird deutlich komplizierter; mitunter kommt es bei anderen CPU-Versionen zu Fehlern.<ref group="Anmerkung">Selbstmodifizierender Code wurde z. B. verwendet, um den Intel 8088 vom Intel 8086 zu unterscheiden, da einer eine längere Befehlspipeline besaß: Der Prozessor mit der kurzen Pipeline folgte der Änderung, der Prozessor mit der längeren Pipeline führte jedoch weiterhin den „alten“ Befehl aus, da dieser bereits in der Pipeline gespeichert war.</ref>		#Der CPU-Entwurf wird deutlich komplizierter; mitunter kommt es bei anderen CPU-Versionen zu Fehlern.<ref group="Anmerkung">Selbstmodifizierender Code wurde z. B. verwendet, um den Intel 8088 vom Intel 8086 zu unterscheiden, da einer eine längere Befehlspipeline besaß: Der Prozessor mit der kurzen Pipeline folgte der Änderung, der Prozessor mit der längeren Pipeline führte jedoch weiterhin den „alten“ Befehl aus, da dieser bereits in der Pipeline gespeichert war.</ref>
			#Programmcode kann im Arbeitsspeicher nicht für mehrere Instanzen wiederverwendet werden, die erste Instanz würde den Code modifizieren, womit die spätere zweite Instanz nicht mehr korrekt funktionieren würde.<ref>https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/july/under-the-hood-happy-10th-anniversary-windows ''Under the Hood: Happy 10th Anniversary, Windows'' von Matt Pietrek, MSDN Magazin</ref>

	== Beispiele ==		== Beispiele ==

Aka: Tippfehler entfernt, typografische Anführungszeichen, Links normiert

2024-04-23T09:58:34Z

Tippfehler entfernt, typografische Anführungszeichen, Links normiert

← Nächstältere Version		Version vom 23. April 2024, 11:58 Uhr
Zeile 46:		Zeile 46:

	=== Mathematikprogramm ===		=== Mathematikprogramm ===
	In Microsoft [[BASIC]] auf Commodore Computern (z. B. PET, VC 20, [[C64]]) war es über ein kurzzeitiges Anhalten eines Programms effektiv möglich, eine über den INPUT-Befehl im Programm abgefragte Benutzerfunktion (z. B. ~~"SIN~~(X)") an den Programmeditor zu übergeben, der eine Zeile im BASIC-Programm entsprechend veränderte, worauf das Programm ohne Verlust der Variableninformation (mittels [[Sprunganweisung\|GOTO-Befehl]]) wieder fortgesetzt wurde		In Microsoft [[BASIC]] auf Commodore Computern (z. B. PET, VC 20, [[C64]]) war es über ein kurzzeitiges Anhalten eines Programms effektiv möglich, eine über den INPUT-Befehl im Programm abgefragte Benutzerfunktion (z. B. „SIN(X)“) an den Programmeditor zu übergeben, der eine Zeile im BASIC-Programm entsprechend veränderte, worauf das Programm ohne Verlust der Variableninformation (mittels [[Sprunganweisung\|GOTO-Befehl]]) wieder fortgesetzt wurde
	und die neue Zeile für Berechnungen nutzen konnte.		und die neue Zeile für Berechnungen nutzen konnte.
	Dies geschah durch Ausdruck der gewünschten neuen Programmzeile in der obersten Bildschirmzeile (unter Benutzung des Microsoft-BASIC-Ausdrucks "[[DEF FN]]") und Ausgabe des Befehls ~~"GOTO~~ ~~xxx"~~ zum Rücksprung ins Programm in der zweiten Bildschirmzeile.		Dies geschah durch Ausdruck der gewünschten neuen Programmzeile in der obersten Bildschirmzeile (unter Benutzung des Microsoft-BASIC-Ausdrucks „[[DEF FN]]“) und Ausgabe des Befehls „GOTO xxx“ zum Rücksprung ins Programm in der zweiten Bildschirmzeile.
	Füllen des Tastaturpuffers mit den Zeichen [[HOME]] und mehreren Steuerzeichen für [[Wagenrücklauf]] sorgte dafür, dass nach dem STOP-Befehl der systemeigene Programmeditor die zuvor ausgegebene Programmzeile bearbeitete und bei Erreichen des GOTO-Befehls (ausgelöst durch die Wagenrücklauf-Zeichen) das BASIC-Programm wieder ausführte.		Füllen des Tastaturpuffers mit den Zeichen [[HOME]] und mehreren Steuerzeichen für [[Wagenrücklauf]] sorgte dafür, dass nach dem STOP-Befehl der systemeigene Programmeditor die zuvor ausgegebene Programmzeile bearbeitete und bei Erreichen des GOTO-Befehls (ausgelöst durch die Wagenrücklauf-Zeichen) das BASIC-Programm wieder ausführte.

Zeile 54:		Zeile 54:
	Ein solches Unterprogramm bekam Startadresse, Zieladresse und Größe in Byte oder Speicherseiten (je 256 Byte) übergeben. Die normale Art und Weise zu kopieren bestand darin, die Adressen in zwei Zeigern innerhalb der Zeropage zu speichern, und dann indirekt-zeropage adressierbare Lade- und Speicherbefehle mit Indexzugriff zu verwenden. Diese brauchen aber auf der [[MOS Technology 6502\|6502]]-CPU zwei Taktzyklen mehr als die absolut adressierbaren. Der Trick zur Steigerung der Geschwindigkeit besteht darin, absolut adressierbare Befehle zu verwenden. Bei dieser Art des selbstmodifizierenden Codes werden nicht das Indexregister und die Zeigeradressen hochgezählt, sondern die Adressen im Programmcode hinter dem Opcode der absolut adressierbaren Lade- und Speicherbefehle. Damit lassen sich Kopierroutinen deutlich beschleunigen.		Ein solches Unterprogramm bekam Startadresse, Zieladresse und Größe in Byte oder Speicherseiten (je 256 Byte) übergeben. Die normale Art und Weise zu kopieren bestand darin, die Adressen in zwei Zeigern innerhalb der Zeropage zu speichern, und dann indirekt-zeropage adressierbare Lade- und Speicherbefehle mit Indexzugriff zu verwenden. Diese brauchen aber auf der [[MOS Technology 6502\|6502]]-CPU zwei Taktzyklen mehr als die absolut adressierbaren. Der Trick zur Steigerung der Geschwindigkeit besteht darin, absolut adressierbare Befehle zu verwenden. Bei dieser Art des selbstmodifizierenden Codes werden nicht das Indexregister und die Zeigeradressen hochgezählt, sondern die Adressen im Programmcode hinter dem Opcode der absolut adressierbaren Lade- und Speicherbefehle. Damit lassen sich Kopierroutinen deutlich beschleunigen.

	=== BitBlt der 16-Bit Windows Versionen ===		=== BitBlt der 16-Bit-Windows-Versionen ===
	Für die 16-Bit Versionen von [[Microsoft Windows]], einschließlich der 16-/32- Bit Hybride [[~~Windows_9x~~\|Windows 95/98/Me]] wurde für die [[Bit blit\|BitBlt]]-Funktion ein selbstmodifizierender Code verwendet.<ref>{{Internetquelle \|url=https://devblogs.microsoft.com/oldnewthing/20180209-00/?p=97995 \|autor=Raymond Chen \|titel=Optimizing BitBlt by generating code on the fly \|werk=The Old New Thing \|hrsg=Microsoft \|datum=2018-02-09 \|sprache=en \|abruf=2024-04-01}}</ref>		Für die 16-Bit Versionen von [[Microsoft Windows]], einschließlich der 16-/32-Bit-Hybride [[Windows 9x\|Windows 95/98/Me]] wurde für die [[Bit blit\|BitBlt]]-Funktion ein selbstmodifizierender Code verwendet.<ref>{{Internetquelle \|url=https://devblogs.microsoft.com/oldnewthing/20180209-00/?p=97995 \|autor=Raymond Chen \|titel=Optimizing BitBlt by generating code on the fly \|werk=The Old New Thing \|hrsg=Microsoft \|datum=2018-02-09 \|sprache=en \|abruf=2024-04-01}}</ref>

	== Anmerkungen ==		== Anmerkungen ==

Pentachlorphenol: Änderungen von Mathbueb (Diskussion) auf die letzte Version von Rolf acker zurückgesetzt

2024-04-09T13:13:06Z

Änderungen von Mathbueb (Diskussion) auf die letzte Version von Rolf acker zurückgesetzt

← Nächstältere Version		Version vom 9. April 2024, 15:13 Uhr
Zeile 1:		Zeile 1:
	{{Überarbeiten}}		{{Überarbeiten}}
	{{Belege fehlen\|2=Der gesamte Artikel\|1=<small>(Februar 2017)</small>}}		{{Belege fehlen\|2=Der gesamte Artikel\|1=<small>(Februar 2017)</small>}}
	Mit der Bezeichnung: '''Selbstmodifizierender Code''' ({{enS\|Self Modifying Code}}) wird ein Abschnitt eines [[Computerprogramm]]s bezeichnet, das zur Lösung der Programmaufgabe Teile des eigenen Programmcodes während der Ausführung gezielt verändert. Unter der Bezeichnung „freier Rechenplan“ hatte schon [[Konrad Zuse]] selbstmodifizierenden Code als Möglichkeit in die von ihm entworfene Programmiersprache [[Plankalkül]] aufgenommen.		Mit der Bezeichnung '''Selbstmodifizierender Code''' ({{enS\|Self Modifying Code}}) wird ein Abschnitt eines [[Computerprogramm]]s bezeichnet, das zur Lösung der Programmaufgabe Teile des eigenen Programmcodes während der Ausführung gezielt verändert. Unter der Bezeichnung „freier Rechenplan“ hatte schon [[Konrad Zuse]] selbstmodifizierenden Code als Möglichkeit in die von ihm entworfene Programmiersprache [[Plankalkül]] aufgenommen.

	Das Programm muss dabei in der Lage sein, im [[Maschinensprache\|Maschinencode]] bestimmte Befehle durch sinnvolle andere Maschinenbefehle zu ersetzen. Bei höheren [[Programmiersprache]]n (z. B. [[APL (Programmiersprache)\|APL]]) manipuliert das Programm meist den [[Quellcode]] als [[Zeichenkette]].		Das Programm muss dabei in der Lage sein, im [[Maschinensprache\|Maschinencode]] bestimmte Befehle durch sinnvolle andere Maschinenbefehle zu ersetzen. Bei höheren [[Programmiersprache]]n (z. B. [[APL (Programmiersprache)\|APL]]) manipuliert das Programm meist den [[Quellcode]] als [[Zeichenkette]].
Zeile 7:		Zeile 7:
	Selbstmodifizierender Code kann unter anderem da verwendet werden, wo es möglich ist, mehrere, nur an wenigen Stellen unterschiedliche Programmteile zu einem einzigen zusammenzufassen.		Selbstmodifizierender Code kann unter anderem da verwendet werden, wo es möglich ist, mehrere, nur an wenigen Stellen unterschiedliche Programmteile zu einem einzigen zusammenzufassen.

	Der selbstmodifizierende Code, eines Programms hat meist nichts mit [[Lernen]] oder der Verbesserung eines Programmes zu tun. Selbstmodifizierende Programme, die die Hochsprache des Programms modifizieren, sind in der Zukunft möglicherweise hilfreich, die [[Künstliche Intelligenz\|Maschinenintelligenz]] zu steigern.		Der selbstmodifizierende Code eines Programms hat meist nichts mit [[Lernen]] oder der Verbesserung eines Programmes zu tun. Selbstmodifizierende Programme, die die Hochsprache des Programms modifizieren, sind in der Zukunft möglicherweise hilfreich, die [[Künstliche Intelligenz\|Maschinenintelligenz]] zu steigern.

	== Motivation ==		== Motivation ==
	Die Methode, Code sich selbst modifizieren zu lassen, stammt hauptsächlich aus einer Zeit, in der Ressourcen (CPU-Zeit, Speicher) noch sehr knappe Güter waren – es wurde also oftmals, eine Optimierung des Laufzeitverhaltens oder Speicherverbrauchs angestrebt. Sogenannte [[Kompression ausführbarer Programmdateien\|Laufzeitpacker]] dekomprimieren mittels einer Hilfsroutine das eigentliche Programm, bevor sie es starten. Sowohl die Laufzeitoptimierung mittels Selbstmodifikation als auch die Speicherbedarfsreduktion sind mittlerweile nur noch äußerst selten notwendig (z. B. beim „Retro computing“, wenn also auf sehr alten Systemen programmiert wird). Ein anderer Grund zur Selbstmodifikation war der Schutz geistigen Eigentums, um die tatsächlichen Algorithmen zu verbergen. In Anbetracht der historischen Motivationen zum Schreiben von selbstmodifizierendem Code sollte das Vorhandensein von solchem Code nicht alleine nach modernen Maßstäben zur Bemessung von Codequalität bewertet werden, sondern auch immer die (historischen und/oder technischen) Umstände berücksichtigt werden.		Die Methode, Code sich selbst modifizieren zu lassen, stammt hauptsächlich aus einer Zeit, in der Ressourcen (CPU-Zeit, Speicher) noch sehr knappe Güter waren – es wurde also oftmals eine Optimierung des Laufzeitverhaltens oder Speicherverbrauchs angestrebt. Sogenannte [[Kompression ausführbarer Programmdateien\|Laufzeitpacker]] dekomprimieren mittels einer Hilfsroutine das eigentliche Programm, bevor sie es starten. Sowohl die Laufzeitoptimierung mittels Selbstmodifikation als auch die Speicherbedarfsreduktion sind mittlerweile nur noch äußerst selten notwendig (z. B. beim „Retro computing“, wenn also auf sehr alten Systemen programmiert wird). Ein anderer Grund zur Selbstmodifikation war der Schutz geistigen Eigentums, um die tatsächlichen Algorithmen zu verbergen. In Anbetracht der historischen Motivationen zum Schreiben von selbstmodifizierendem Code sollte das Vorhandensein von solchem Code nicht alleine nach modernen Maßstäben zur Bemessung von Codequalität bewertet werden, sondern auch immer die (historischen und/oder technischen) Umstände berücksichtigt werden.

	== Architektur- und Sprachabhängigkeit ==		== Architektur- und Sprachabhängigkeit ==

Mathbueb: Kommas gesetzt

2024-04-09T13:12:41Z

Kommas gesetzt

← Nächstältere Version		Version vom 9. April 2024, 15:12 Uhr
Zeile 1:		Zeile 1:
	{{Überarbeiten}}		{{Überarbeiten}}
	{{Belege fehlen\|2=Der gesamte Artikel\|1=<small>(Februar 2017)</small>}}		{{Belege fehlen\|2=Der gesamte Artikel\|1=<small>(Februar 2017)</small>}}
	Mit der Bezeichnung '''Selbstmodifizierender Code''' ({{enS\|Self Modifying Code}}) wird ein Abschnitt eines [[Computerprogramm]]s bezeichnet, das zur Lösung der Programmaufgabe Teile des eigenen Programmcodes während der Ausführung gezielt verändert. Unter der Bezeichnung „freier Rechenplan“ hatte schon [[Konrad Zuse]] selbstmodifizierenden Code als Möglichkeit in die von ihm entworfene Programmiersprache [[Plankalkül]] aufgenommen.		Mit der Bezeichnung: '''Selbstmodifizierender Code''' ({{enS\|Self Modifying Code}}) wird ein Abschnitt eines [[Computerprogramm]]s bezeichnet, das zur Lösung der Programmaufgabe Teile des eigenen Programmcodes während der Ausführung gezielt verändert. Unter der Bezeichnung „freier Rechenplan“ hatte schon [[Konrad Zuse]] selbstmodifizierenden Code als Möglichkeit in die von ihm entworfene Programmiersprache [[Plankalkül]] aufgenommen.

	Das Programm muss dabei in der Lage sein, im [[Maschinensprache\|Maschinencode]] bestimmte Befehle durch sinnvolle andere Maschinenbefehle zu ersetzen. Bei höheren [[Programmiersprache]]n (z. B. [[APL (Programmiersprache)\|APL]]) manipuliert das Programm meist den [[Quellcode]] als [[Zeichenkette]].		Das Programm muss dabei in der Lage sein, im [[Maschinensprache\|Maschinencode]] bestimmte Befehle durch sinnvolle andere Maschinenbefehle zu ersetzen. Bei höheren [[Programmiersprache]]n (z. B. [[APL (Programmiersprache)\|APL]]) manipuliert das Programm meist den [[Quellcode]] als [[Zeichenkette]].
Zeile 7:		Zeile 7:
	Selbstmodifizierender Code kann unter anderem da verwendet werden, wo es möglich ist, mehrere, nur an wenigen Stellen unterschiedliche Programmteile zu einem einzigen zusammenzufassen.		Selbstmodifizierender Code kann unter anderem da verwendet werden, wo es möglich ist, mehrere, nur an wenigen Stellen unterschiedliche Programmteile zu einem einzigen zusammenzufassen.

	Der selbstmodifizierende Code eines Programms hat meist nichts mit [[Lernen]] oder der Verbesserung eines Programmes zu tun. Selbstmodifizierende Programme, die die Hochsprache des Programms modifizieren, sind in der Zukunft möglicherweise hilfreich, die [[Künstliche Intelligenz\|Maschinenintelligenz]] zu steigern.		Der selbstmodifizierende Code, eines Programms hat meist nichts mit [[Lernen]] oder der Verbesserung eines Programmes zu tun. Selbstmodifizierende Programme, die die Hochsprache des Programms modifizieren, sind in der Zukunft möglicherweise hilfreich, die [[Künstliche Intelligenz\|Maschinenintelligenz]] zu steigern.

	== Motivation ==		== Motivation ==
	Die Methode, Code sich selbst modifizieren zu lassen, stammt hauptsächlich aus einer Zeit, in der Ressourcen (CPU-Zeit, Speicher) noch sehr knappe Güter waren – es wurde also oftmals eine Optimierung des Laufzeitverhaltens oder Speicherverbrauchs angestrebt. Sogenannte [[Kompression ausführbarer Programmdateien\|Laufzeitpacker]] dekomprimieren mittels einer Hilfsroutine das eigentliche Programm, bevor sie es starten. Sowohl die Laufzeitoptimierung mittels Selbstmodifikation als auch die Speicherbedarfsreduktion sind mittlerweile nur noch äußerst selten notwendig (z. B. beim „Retro computing“, wenn also auf sehr alten Systemen programmiert wird). Ein anderer Grund zur Selbstmodifikation war der Schutz geistigen Eigentums, um die tatsächlichen Algorithmen zu verbergen. In Anbetracht der historischen Motivationen zum Schreiben von selbstmodifizierendem Code sollte das Vorhandensein von solchem Code nicht alleine nach modernen Maßstäben zur Bemessung von Codequalität bewertet werden, sondern auch immer die (historischen und/oder technischen) Umstände berücksichtigt werden.		Die Methode, Code sich selbst modifizieren zu lassen, stammt hauptsächlich aus einer Zeit, in der Ressourcen (CPU-Zeit, Speicher) noch sehr knappe Güter waren – es wurde also oftmals, eine Optimierung des Laufzeitverhaltens oder Speicherverbrauchs angestrebt. Sogenannte [[Kompression ausführbarer Programmdateien\|Laufzeitpacker]] dekomprimieren mittels einer Hilfsroutine das eigentliche Programm, bevor sie es starten. Sowohl die Laufzeitoptimierung mittels Selbstmodifikation als auch die Speicherbedarfsreduktion sind mittlerweile nur noch äußerst selten notwendig (z. B. beim „Retro computing“, wenn also auf sehr alten Systemen programmiert wird). Ein anderer Grund zur Selbstmodifikation war der Schutz geistigen Eigentums, um die tatsächlichen Algorithmen zu verbergen. In Anbetracht der historischen Motivationen zum Schreiben von selbstmodifizierendem Code sollte das Vorhandensein von solchem Code nicht alleine nach modernen Maßstäben zur Bemessung von Codequalität bewertet werden, sondern auch immer die (historischen und/oder technischen) Umstände berücksichtigt werden.

	== Architektur- und Sprachabhängigkeit ==		== Architektur- und Sprachabhängigkeit ==