• Keine Ergebnisse gefunden

1 E in le itu n g

6.1 Berechnung der effektiven Macht (Effective State Power)

Diese Funktion liefert die "Effective State Power" des Staates stnr zurück. Bei der Berechnung spielt es eine Rolle, ob Bürgerkriege in diesem Lauf zugelassen sind. Sind Bürgerkriege nicht zugelassen, so liefert dieFunktion lediglich die "Real State Power" des jeweiligen Staates zurück.

Sind Bürgerkriege allerdings zugelassen, so liefert die Funktion nur den W ert zurück, der den Staaten nach Begleichung der Unterhaltskosten für ihr Imperium zur Verfügung steht. In diesem Falle wird von der "Real State Power" noch die "Maintenance Cost" des jeweiligen Staates abgezogen.

Sollte die Berechnung zufälligerweise einen negativen W ert ergeben, z.B. wenn die Macht des Staates nicht ausreicht, die "Maintenance Cost" zu begleichen, wird als effektive Macht des Staates Null zurückgeliefert.

6.2 Berechnung der ’’Assumed State Power”

Da die "Assumed State Power" im Modell sehr häufig verwendet wird, soll hier kurz auf ihre Bestimmung eingegangen werden. Die Berechnung findet in der Funktion apOl_Assumed_State_Power statt. Über die beiden Parameter wird das Verhalten der Funktion

W ichtige Funktionen und 22 Prozeduren

gesteuert. Die Funktion verlangt zwei Parameter als Eingabe: actor un dstnr. Die Funktion liefert eine Schätzung der Macht des Staates stnr durch den Staat actor. Sind die beiden gleich, liefert die Funktion folglich eine Selbsteinschätzung von actor.

W esentlichen Einfluß auf das Verhalten der Funktion hat der Parameter "Error Range" aus der Parameterdatei, der durch die Funktion rp04 Error Range zurückgeliefert wird. Ist der hier angegebene Parameter gleich Null, so bedeutet das, daß die Staaten bei der Einschätzung von M acht keine Fehler machen, andernfalls wird die "Effective State Power" mit einem Fehler belastet zurückgeliefert. Die Berechnung der "Effective State Power" findet in epOl-Effective State_Power statt (s.a. 6.1).

6.3 Berechnung der Siegeswahrscheinlichkeit in einem Krieg

Die Berechnung der Siegeswahrscheinlichkeit ("Likelihood o f Victory") in einem Krieg findet in der Funktion mf07_Likelihood_Of_Victory statt. Die Funktion erwartet als Eingabeparameter den Quotienten der M acht der Kontrahenten. Die Berechnung der "Likelihood of V ictory" findet unter Benutzung des Fehlerintegrals statt (mf51_C351).

6.4 Berechnung der Wahrscheinlichkeit eines Unentschieden in einem Krieg

Die Berechnung der W ahrscheinlichkeit eines Unentschieden in einem Krieg findet in der Funktion mfö9_LikeUhood_Of_Tie statt. Als Parameter wird ein bereits vorher ermittelter

"Likelihood of Victory" Wert verlangt. Die Wahrscheinlichkeit eines Unentschieden in einem Krieg (Likelihood of Tie) wird über folgende Gleichung berechnet:

I L V -0 .5 | 1

-L T =

0.5

L T ist die W ahrscheinlichkeit eines Unentschieden, L V ist der gegebene "Likelihood o f Victory"

W ert und LTP AR ist der "Tie Exponent" Wert aus der Parameterdatei.

6.5 Berechnung der Expected Utility

Die Berechnung der "Expected Utility" für Staaten und Koalitionen findet im Modul decision.c statt. Die "Expected Utility" ist ein wichtiges Entscheidungskriterium bei Modelläufen mit

"rationalen Staaten". Sie wird nur von diesen benutzt und ist Grundlage aller Entscheidungen der "rationalen Staaten".

W ichtige Funktionen und Prozeduren

23

Die "rationalen Staaten" treffen ihre Entscheidungen aufgrund des zu erwartenden Nutzens.

Bevor sie sich entscheiden ob sie einen K rieg entfachen oder sich einer Koalition anschließen, versuchen sie erst die zu erwartenden Gewinne und Verluste abzuschätzen.

6.5.1 Expected Utility Berechnung für Staaten (dr01_Exp_Util_States)

In dieser Funktion findet die Berechnung der "Expected Utility" für Staaten statt. Am Anfang steht die Berechnung der "Assumed State Power" für den Akteur selbst und für den Gegner in der Einschätzung durch den Akteur. Dann wird der "Kriegskostenfaktor" aus dem Quotienten dieser beiden W erte berechnet. Im nächsten Schritt versucht der Akteur die möglichen Gewinne aus dem Konflikt zu berechnen. D iese möglichen Gewinne bestehen aus zu empfangenden Territorien und aus möglicherweise zu erhaltenden Reparationen. Territoriengewinne sind nur möglich, wenn der gegnerische Staat der gerade betrachtet wird, der Führer der gegnerischen Koalition ist. Ist der gegnerische Staat nur weiteres Mitglied einer Koalition, so ist es nur möglich, von ihm Reparationen zu erhalten. Bei den möglichen Territoriengewinnen wird zwischen gegnerischen Staaten m it einem und gegnerischen Staaten m it mehreren Territorien unterschieden. Bei gegnerischen Staaten mit nur einem einzigen Territorium findet die Berechnung der Gewinne auf folgende Art statt:

gains = oppaspow ■ (l.O — warcostf)

Hierin bedeutet gains die möglichen Gewinne, oppaspow die "Assumed State Power" des Gegners und w arcostf den "War Cost Factor". In diesem Falle bestehen die Gewinne also aus der M acht die das gegnerische Territorium beinhaltet abzüglich der zu erwartenden Kriegskosten.

Besteht der gegnerische Staat aus mehreren Territorien, hängt die Höhe des möglichen Gewinns des Akteurs auch davon ab, wie groß der Anteil an Territorien des Gegners ist, der ihm zugeteilt würde:

asrecter

gains = asindrec + * {oppaspow • (1.0 - warcostf) - asindrec)

Hierbei bedeutet asindrec die möglichen Reparationen (Indemnities), die der Staat erhält,oppterisasrecter ist der Quotient aus erhaltenen Territorien und der Gesamtanzahl der gegnerischen Territorien.

Sind Territoriengewinne unmöglich, so bestehen die möglichen Gewinne nur aus empfangenen Reparationen.

Wichtige Funktionen und Prozeduren

24

Für die weitere Berechnung der "Expected Utility" ist die Berechnung der möglichen Kosten notwendig. Die möglichen Kosten für den Akteur bestehen aus eventuell zu zahlenden Reparationen sowie aus möglichen Territorienverlusten. Territorienverluste sind für den hier betrachteten Akteur nur möglich, wenn er der Anführer seiner Koalition ist. Besteht der Akteur nur aus einem Territorium so berechnen sich seine Kosten wie folgt:

losses = actaspow - actorcost

losses sind die möglichen Verluste des Staates, actaspow ist die "Assumed State Power" des Akteurs und actorcost sind die vermutlichen Kosten des Akteurs, wobei die Kosten des Akteurs aus den zu zahlenden Kriegskosten bestehen.

Besteht der Akteur aus mehreren Territorien, so berechnen sich die Kosten wie folgt:

losses = asindlos + ■ (actaspow -a sin d lo s — actorcost) actteris

asindlos sind die vermutlich zu zahlenden Reparationen ("assumed indemnities lost"), aslostte sind die wahrscheinlich verlorenen Territorien des Akteurs und actteris ist die Gesamtanzahl der Territorien des Akteurs. Die Anzahl der vermutlich verloren gehenden Territorien wird von te08_Number_Lost^Terries berechnet.

Ist der Akteur nicht Führer seiner Koalition, so berechnen sich seine Kosten nur aus den zu zahlenden Reparationen.

Für die Berechnung ist es noch notwendig, die W ahrscheinlichkeit des Sieges der Seite des Akteurs zu berechnen. Hierfür wurde in den bisherigen Simulationen lediglich die Funktion m fl)7 L ik e lih o o d O fV ic to r y benutzt, der Aufruf der Funktion dr50 IndividualJJkelihoodJJf_V ictory sollte an dieser Stelle eher als Ansatzpunkt betrachtet werden, um später eine andere Bestimmung der "Expected Utility" zu ermöglichen.

Nach Feststellung der Grundelemente der "Expected Utility" erfolgt die Berechnung:

exputil = Iv ■ gains - (1.0 - Iv) • losses — actorcost

Hierin ist exputil der "Expected Utility" Wert, der von der Funktion zurückgeliefert wird und Iv der "Likelihood of Victory" Wert.

6.5.2 Für Koalitionen (dr02_Exp_Util_Coal)

W ährend drOl_Exp_Util_States die "Expected Utility" für Staaten berechnet, wird hier die Berechnung für Koalitionen ausgeführt. Prinzipiell erfolgt die Berechnung der

Wichtige Funktionen und Prozeduren

25

"Expected Utility" auf die gleiche Art, und beide Funktionen sollten auch für Koalitionen der Länge eins die gleichen Werte liefern. Bei umfangreicheren Koalitionen sind aber einige Zusatzanforderungen bei der Berechnung zu beachten. Folgende Fälle sind zu unterscheiden:

(1) Die Akteurskoalition besteht aus einem Staat. Die Gegnerkoalition besteht nur aus einem Staat.

Die Gewinne bestehen aus der Macht des gegnerischen Territoriums abzüglich der gegnerischen Kriegskosten.

(2) Die Akteurskoalition besteht aus mehreren Staaten. Die Gegnerkoalition besteht aus einem Staat. Der Akteur ist der stärkste Staat in seiner Koalition.

Der Akteur erhält das gegnerische Territorium abzüglich der vom Gegner zu zahlenden Reparationen.

(3) wie (2) aber der Akteur ist nicht der stärkste Staat seiner Koalition.

Die Gewinne bestehen nur aus den möglicherweise zu erhaltenden Reparationen.

(4) Die Akteurskoalition besteht aus mehreren Staaten. D er gegnerische Staat besteht aus mehr als einem Territorium.

Die Gewinne bestehen aus den Territorien, die der Gegner mutmaßlich verliert zuzüglich erhaltener Reparationen abzüglich der gegnerischen Reparationen und Kriegskosten.

(5) Die gegnerische Koalition enthält mehr als einen Staat. D er Führer der gegnerischen Koalition besitzt nur ein Territorium. Die Akteurskoalition besteht nur aus einem Staat.

Die Gewinne bestehen aus dem Territoriengewinn vom gegnerischen Koalitionsführer, sowie aus den Reparationen, die von allen Mitgliedern der gegnerischen Koalition zu erhalten sind, abzüglich der Kriegskosten der gegnerischen Koalition.

(6) Die gegnerische Koalition enthält mehr als einen Staat. D er Führer der gegnerischen Koalition besitzt nur ein Territorium. Die Akteurskoalition besteht aus mehreren Staaten und der Akteur ist der stärkste Staat seiner Koalition.

Die Gewinne bestehen aus dem Territorialgewinn vom gegnerischen Koalitionsführer abzüglich seiner Kriegskosten und den Reparationen die der gegnerische Staat an die anderen Mitglieder der Akteurskoalition zahlen müßte. Hinzu kommen die Reparationen, die der Akteur von den anderen Mitgliedern der gegnerischen Koalition abzüglich deren Kriegskosten erhält.

(7) Wie (6) aber der Akteur ist nicht der stärkste Staat seiner Koalition.

Die Gewinne bestehen lediglich aus den vermutlichen Reparationen.

Zusatzmodule m it nicht 26 modellspezifischen Funktionen

(8) Der Führer der gegnerischen Koalition besitzt mehr als ein Territorium.

Die Gewinne für den Akteur bestehen aus den empfangenen Reparationen, dem Anteil an Territorien des gegnerischen Koalitionsführers abzüglich der Kriegskosten und der vom Gegner gezahlten Reparationen.

Die Berechnung der potentiellen Kosten für den Akteur ist wesentlich einfacher. Diese Kosten bestehen aus den vermutlichen Kriegskosten und den anzunehmenden Territorialverlusten des Akteurs, falls der Akteur Führer seiner Koalition ist.

Die endgültige Berechnung der "Expected U tility” findet statt wie in Abschnitt 6.5.1 beschrieben.

7 Zusatzmodule mit nicht modellspezifischen Funktionen

Listenmodul und Bildschirmausgabemodul stellen nicht modellspezifische Funktionen zur Verfügung. Von beiden M odulen wird aber in vielen Teilen des Modells reger Gebrauch gemacht, deshalb werden sie hier kurz beschrieben.

Das Listenmodul soll eine von der speziellen Anwendung weitgehend unabhängige Listenverwaltung ermöglichen. Das Listenmodul stellt zur Verwaltung von Listen einige wesentliche Funktionen, wie z.B. das Erzeugen von Listen, das Vernichten, das Einfügen und Löschen von einzelnen Listenelementen und das Ausführen von Aktionen auf Listenelementen zur Verfügung.

Die Bildschirmausgabe des Modells findet im wesentlichen in den M odulen ib m te rm .c und screenou.c statt. ibm_term.c ist das vom Modell unabhängige Modul, das einige Funktionen zur Full-Screen Ausgabe bereitstellt, während screenou.c modellspezifische Funktionen, wie z.B.

die Ausgabe der Karte des Modells (soOl_Write_Hexagon_Map), bereitstellt. Außerdem finden natürlich in vielen Teilen des Modells Aus- und Eingaben über normale "Read-" und "Write-"

Anweisungen statt. Diese Verteilung der Ein- und Ausgabe des Modells über verschiedene Module ist eine Designschwäche, die sich aus der evolutionären Entwicklung des Modells erklärt und noch aus den Ursprungszeiten stammt. Bei einer weiteren Überarbeitung würde man wohl die Ein- und Ausgabe und die dafür nötigen Hilfsfunktionen in weniger Modulen übersichtlicher zusammenfassen, wobei man versuchen würde, die rechnerspezifischen Teile zu extrahieren und in einem einzigen Modul zusammenzufassen. Auf diese Weise könnte man das Erscheinen von mehreren Prozeduren, die annähernd die gleichen Aufgaben erfüllen weitgehend vermeiden.

7.1 Das Listenmodul

Das Listenmodul stellte in der Modula-2 Fassung einen Abstrakten Datentyp dar, der mit generischen Listen umgehen konnte. Das bedeutet, daß das Modul die Verwaltung von Listen

Zusatzmodule m it nicht modellspezifischen Funktionen

27

übernahm und der Zugriff auf Listen nur noch über die in diesem Modul spezifizierten Funktionen und Prozeduren möglich war. Die Basis dieses Moduls war in [2] als Modula-2 Quelle angegeben. Die tatsächliche Implementation der Liste als doppelt verkettete Liste blieb diesem M odul überlassen. Für die Benutzung von Listen ist es daher nicht nötig, selbst Zeiger-Variablen zu definieren und zu verwalten.

Das Listenmodul kann Listen beliebigen Typs verwalten. Nachteil dieser Art von Verwaltung ist der Verlust jeglicher Typüberprüfung, Vorteil ist die leichte Benutzbarkeit und eine relativ effiziente Verwaltung des Speichers im Vergleich zu einer Realisierung von Listen über eine

"Union", denn dann würde für jedes Listenelement der Speicherbedarf des größten

"Uniori'-M itgliedes alloziert werden. Der versteckte Datentyp von Modula-2 wird in "C" über einen Zeiger des Typs "void" verwirklicht. Der Benutzer einer Liste hat keine Einsicht in die interne Verwaltung, denn der Aufbau des Elementes auf das der Zeiger weist ist ihm nicht bekannt. In der M odula-2 Version wurden Listenelemente als "Array o f Word" übergeben, das beinhaltet eine implizite Größeninformation. In "C" muß die Größe der Datenelemente den Bearbeitungsprozeduren und Funktionen mitgeteilt werden. Die Feststellung der Größe findet in "C" über den sizeo f() - Operator statt.

Für die Verwaltung von Listen definiert das Listenmodul einen Typ Node, der sowohl als Listenkopf als auch als Listenelement fungieren kann. Ist der Knoten ein Listenkopf, enthält er einige Verwaltungsinformationen, wie Länge der Liste und Größe der Listenelemente, ist der Knoten ein Listenelement, so enthält er einen Zeiger auf die Daten. Das Listenmodul verwaltet also nur die Knoten, die lediglich Verwaltungsinformationen und die Verzeigerung enthalten.

Das Listenmodul enthält folgende Prozeduren und Funktionen, die zur Benutzung des abstrakten Datentyps exportiert werden:

- glOl Define: Erzeugt eine leere Liste und trägt die notwendigen Verwaltungsinformationen in den Listenkopf ein.

- gl02 Delete Front: Löscht das erste Element einer Liste falls dieses vorhanden ist.

- gl03 Delete List: Löscht die gesamte Liste und gibt den allozierten Speicherplatz wieder frei.

- glO4_Empty: Überprüft, ob eine Liste leer ist.

- gl05 Erase: Löscht die Elemente einer Liste, die Liste bleibt aber definiert.

- gl06 P ro cessF o rw a rd JJn til: Führt auf den Listenelementen die Funktion pressend () aus, bis die Funktion TRUE zurückgibt.

Zusatzmoduie mit nicht modellspezifischen Funktionen

28

- gl07_Remove: Entfernt aus der Liste das spezifizierte Element. Sollten mehrere Listenelemente der Spezifikation entsprechen, so wird das erste gefundene Element entfernt.

Um die Elemente zu identifizieren, muß der Prozedur eine Funktion übergeben werden, die die Gleichheit der Listenelemente bestimmt, dies geschieht über den Param eter eqpos.

- gl08 Insert Front: Fügt ein Element vor dem bisherigen ersten Element ein.

■ gl09 J n s e r t Rear: Fügt ein Element am Ende der Liste an.

■ gllO Length: Gibt die Länge der Liste zurück.

■ g lll_ P la ce: Fügt ein Element so in die Liste ein, daß die Liste als geordnete Liste aufgebaut wird. Das Ordnungskriterium wird durch die als Parameter übergebene Funktion orderpr angegeben.

- g ll2 Process: Die als Parameter übergebene Funktionprcssprc wird für alle Listenelemente ausgeführt.

- g l l 3 Process First: Führt die als Parameter übergebene Funktion Prozedur prcssprc für das erste Listenelement aus.

Außer diesen Prozeduren, die dem Zugriff auf die Liste von außen dienen, sind zwei interne Prozeduren implementiert. Die Funktion gl50 Free_Node gibt den von einem Listenelement belegten Speicherplatz frei; gl5l-G et_N ode alloziert den für ein Listenelement benötigten Speicherplatz.

7.2 Bildschirmausgabe

Hier erfolgt nur eine kurze Schilderung des weitgehend modellunspezifischen Moduls ibm_term.c. Dieses stellt die für Fullscreen-Ausgabe auf IBM-PC kompatiblen Rechnern unbedingt nötigen Funktionen zur Verfügung. Es existiert ebenfalls ein Modul, das diese Funktionen auf dem Atari-ST zur Verfügung stellt (ata_term.c). Die zur Verfügung gestellten Funktionen sind:

- tmOl Clear Home: Löschen des Bildschirms

- tm02-Cursor_XY: Positionieren des Cursors an die Stelle row,col - tm.03 Cursor_Save: Sichern der Cursorposition

- tm04_Cursor_Restore: Wiederherstellen der mit tm03 Cursor Save gesicherten Cursorposition.

- tm05 Clear_From_Cursor: In ib m te rm .c nicht implementiert.

- tmlO_Read_Char: Liefert das erste Zeichen eines eingelesenen Strings zurück.

Bedienungsanleitung 29

- tm l 1 _Write_Blank_Lines: Schreibt die in nr übergebene Zahl von leeren Zeilen auf den Bildschirm.

- tm l2JU ser_Stop: Liefert trotz des etwas verwirrenden Namens nur das von der Tastatur gelieferte Zeichen (falls eines vorhanden ist).

Bei der Übertragung des Modells auf eine andere Rechenanlage sind in diesem Modul wahrscheinlich einige Änderungen erforderlich. Z.B. wäre es bei der Übertragung auf einen UNIX-Rechner möglich hier termcap-Funktionen zu benutzen.

$ Bedienungsanleitung

Um das M odell laufen zu lassen, wird das ausführbare Programm cearth.exe und eine Parameterdatei (zum Aufbau der Parameterdatei s.a C .l) benötigt.

Nach A ufruf des Programms ohne Param eter beginnt der Startdialog. Als erstes wird der Name der Parameterdatei vom Benutzer abgefragt. Macht der Benutzer hierbei einen Fehler, hat er die M öglichkeit die Eingabe zu korrigieren oder das Programm zu beenden. Nach Eingabe eines gültigen Parameterdateinamens werden vom Benutzer die Nummern des ersten und des letzten Laufes abgefragt. Zur Eingabeerleichterung werden hier die niedrigste und die höchste Nummer, die in der Parameterdatei vorhanden sind, angezeigt. Am Ende des Dialoges wird vom Benutzer die Entscheidung verlangt, ob die umfassende und die kleine Statistikdatei erzeugt werden sollen.

Die im Dialog abgefragten Positionen können auch über Kommandozeilenparameter angegeben werden.

Das allgemeine Aufrufformat für EARTH lautet:

Cearth -[flgsStv] parfile

wobei sowohl Optionen als auch "parfile" (der Name einer Parameterdatei) weggelassen werden können. In diesem Falle geht das M odell in den interaktiven Modus m it Abfrage der Kommandozeilenparameter über. Die Reihenfolge der Angabe der Optionen auf der Kommandozeile spielt keine Rolle, lediglich der Name der Parameterdatei muß das letzte Argument auf der Kommandozeile sein.

Folgende Kommandozeilenparameter sind erlaubt:

(1) -f Argument, Angabe der Nummer des ersten auszuführenden Laufes (2) -1 Argument, Angabe der Nummer des letzten auszuführenden Laufes

(3) -g Argument, Angabe der Zahl von Läufen, deren Resultate in eine Ergebnis-Datei geschrieben werden sollen

(4) -s, (kleines ’s’) bei Angabe dieser Option wird die kleine Statistikdatei ausgedruckt

Fehlermeldungen 30

(5) -S, (großes ’S ’), bei Angabe dieser Option wird die umfassende Statistikdatei ausgegeben (6) -t, die Parameterdatei wird gelesen und auf Fehlerif eiheit überprüft; das M odell wird nicht

gestartet.

(7) -v, die Daten der letzten Kompilation der einzelnen Module werden in die Log-Datei geschrieben.

(8) parfile,

D er Name einer Parameterdatei, wird der Name auf der Kommandozeile weggelassen, wird der interaktive Modus betreten.

W ar die Kommandozeile zum Start ausreichend oder ist der Dialog beendet, sind weitere Eingaben nicht nötig und die Modelläufe beginnen. Es werden alle Modelläufe durchgeführt, für die die Bedingung gilt, daß die Nummer des Laufes zwischen der kleineren eingegebenen Nummer und der größeren liegt. Die Laufnummer wird in der oberen linken Ecke des Bildschirms zusammen m it der aktuellen Iterationsnummer angezeigt. Hat der Benutzer in der Parameterdatei eine "Land"-Karte des Systems angefordert, so wird diese Karte zu den angeforderten Zeitpunkten dargestellt. Die Darstellung der Karte kann also auch einmal gegenüber dem aktuellen Zustand des Systems hinterherhinken.

Nach Beendigung der Läufe kehrt das Modell ohne weitere Anzeigen oder Eingaben wieder zurück zum Betriebssystem. Man sollte beachten, daß je nach angeforderten Ausgabedateien erheblicher Plattenplatz von den M odellergebnissen belegt werden kann. Der Lauf des Modells kann durch Drücken von C O N T R O L - B R E A K oder C ONTROL-C abgebrochen werden (in manchen Situationen reicht auch Drücken der ESCAPE-Taste).

9 Fehlermeldungen

Für gewisse Fehlerbedingungen sind Vorkehrungen für einen kontrollierten Abbruch des Modellaufs getroffen. Im Fehlerfall wird eine Fehlermeldung auf den Bildschirm und in die Protokolldatei (EARTH.log) ausgegeben. Im Normallfall hat eine solche M eldung folgendes Format:

Catastrophic error, program aborted

Status: Ausgabe eines Statuswertes ungleich 0

Where: Ausgabe der Prozedur, in der der Fehler auftrat Why: Angabe der Fehlerursache

Als Prozedum am e wird in den meisten Fällen lediglich die Abkürzung des definierenden Moduls und die Prozedumummer ausgegeben. Als Fehlerursache kommen folgende Meldungen in Betracht:

31 Gliederung des Programms

(*. *.c *.h *.typ - Dateien)

1 Out o f memory: D er zur Verfügung stehende Speicherplatz reicht nicht aus.

Mögliche Ursachen:

System zu groß: kleinere Systemgröße wählen

Speicher von anderen Programmen belegt: alle nicht unbedingt nötigen Hilfsprogramme und Gerätetreiber aus dem Speicher entfernen

2 Option error: Es wurde eine fehlerhafte Kommandozeilenoption angegeben

3 Null Pointer where it is not allowed: Eine Pointer-Variable hat den W ert NULL, obwohl dieser Wert an dieser Stelle im Programm nicht erlaubt ist. Diese Fehlermeldung läßt auf einen schweren Modellfehler schließen und sie sollte unter normalen Umständen nicht

3 Null Pointer where it is not allowed: Eine Pointer-Variable hat den W ert NULL, obwohl dieser Wert an dieser Stelle im Programm nicht erlaubt ist. Diese Fehlermeldung läßt auf einen schweren Modellfehler schließen und sie sollte unter normalen Umständen nicht