Was ist M2POSIX ? ================= Diese Modulsammlung soll die POSIX-Systemaufrufe, die bisher nur fr ``C'' (und Ada) definiert sind, auch unter Modula-2 verfgbar machen. Insbesondere unter GEMDOS werden ja manche Dinge v”llig unterschiedlich zu *IX-Systemen, und damit auch POSIX, gehandhabt. Ich denke da nur an das Suchen von Dateien: Unter GEMDOS werden dazu die Betriebssystemaufrufe "Fsfirst()" und "Fsnext()" benutzt, unter POSIX wird ein Verzeichnis mit "opendir()" ge”ffnet, jeweils der Name der n„chsten im Verzeichnis enthaltenen Datei mit "readdir()" ermittelt, mit "fnmatch()" wird berprft, ob der Name mit der oder den gesuchten bereinstimmt (dabei k”nnen die ``Wildcards'' *, ? und [...] benutzt werden) und schliežlich werden mit "stat()" alle weiteren Informationen ber die Datei eingeholt (unter GEMDOS stehen die vorhandenen Informationen in der DTA). Ein Beispiel fr die Ermittlung von Dateien nach diesem Muster ist in LISTDIR.MPP enthalten, das ein sehr vereinfachtes ``ls'' darstellt. Aužerdem k”nnen Pfadnamen nach *IX-Konvention angegeben werden (z.B. / statt \ oder /usr statt e:\usr); diese werden, soweit m”glich, in DOS-Žquivalente berfhrt. Fr die L„nge von Pfadnamen gibt es trotz der *IX <--> DOS-Wandlung keine Begrenzung (aužer der Stackgr”že, diese muž gegebenenfalls h”her als die blichen 8kB gew„hlt werden). Soweit von POSIX gefordert, sind die Funktionen reentrant und k”nnen in Signalhandlern verwendet werden. Fr die Erkl„rungen der einzelnen Funktionen mssen die Definitionsmodule herangezogen werden. I.allg. ist fr jede Funktion erstmal ein Text ber die allg. Funktionsweise unter *IX bzw. POSIX vorhanden, und dann unter den Stichworten GEMDOS bzw. MiNT evtl. Abweichungen davon, die durch die Implementierung oder das unterliegende Betriebssystem bedingt sind. Ohne MiNT (oder einer anderen Erweiterung, die die gleichen Funktionen zur Verfgung stellt) sind die Einschr„nkungen naturgem„ž (erheblich) gr”žer. Als Grundlage dieser Modulsammlung diente die ``C''-Bibliothek MiNTLib von Eric R. Smith, dem Autor von MiNT; die neueren Versionen (ab pl26) wurden und werden von mehreren anderen Leuten (auch in Richtung POSIX) weiterentwickelt, n„heres dazu ist den entsprechenden Texten der MiNTLib zu entnehmen. Diese Bibliothek macht die speziellen Eigenschaften von MiNT, dem GEMDOS-Multitasking-Ersatz bzw. der MultiTOS-Grundlage, auch innerhalb der (*IX)-Standardbibliothek den g„ngigen Atari-C-Compilern, speziell dem GNU-C-Compiler, zug„nglich. Abgesehen vom reinen šbertragen ``C'' --> Modula-2 sind einige Funktionen gleichgeblieben, aber bei den meisten habe ich erweitert, verkrzt, ver„ndert, Fehler beseitigt, Fehler hinzugefgt oder sonst irgendwas. Bei der Modulaufteilung und der Namensgebung war ich manchmal etwas ratlos, aber zumindest die Funktionsnamen sind, bis auf wenige Ausnahmen, gleichgeblieben. Wer einen Compiler hat, der Unterstriche in Bezeichnern erlaubt, und lieber die Originalnamen verwenden m”chte, kann die Module mit dem Pr„prozessor und der Datei POSIX_ID.M2H bearbeiten, die die entsprechenden Namens„nderungen enth„lt. Zeitweise war fr die Moduleinteilung auch ein einzelnes Modul im Gespr„ch, z.B. 'SYS' oder 'POSIX', aber das w„re wohl ein ziemliches Monster an Umfang geworden; auch die Struktur der POSIX-C-Header zu bernehmen schien mir nicht so geeignet, da hier die Verteilung der Funktionen schlecht geregelt w„re (in 'UNISTD' st„nde dann fast alles und in den anderen Modulen, wie 'STAT', 'DIRENT' u.„. jeweils nur ein paar wenige Funktionen). Zusammengeh”rende Funktionen sind zwar in den jeweiligen Modulen zusammengefažt, es ist aber ein Modul POSIX1 vorhanden, in dem alle POSIX-Funktionen, -Typen und -Konstanten als Reexport bzw. Prozedurvariable deklariert sind, sodaž der Import aus einem einzigen Modul ausreicht, ohne daž ein Riesenmodul entsteht oder zus„tzlicher Verwaltungsaufwand zur Laufzeit. Auf die gleiche Weise gibt es ein Modul ANSIC, in dem Funktionen reexportiert werden, die dem ANSI-C- Standard zuzuordnen sind und zumindest teilweise ebenfalls POSIX-1- Funktionen sind. Das Modul POSIX2 enth„lt bisher nur eine einzige Funktion aus POSIX.2 ("fnmatch()"), und das Modul BSD reexportiert Funktionen, Typen und Konstanten, die nicht zu POSIX geh”ren, aber im BSD-Unix und anderen *IX-Varianten anzutreffen sind. Die Funktionen machen, soweit m”glich, von MiNT Gebrauch, falls dieses aktiv ist. Es sollte aber mindestens die Version 0.96 benutzt werden, da nur berprft wird, ob MiNT vorhanden ist, und nicht, welche Version benutzt wird -- mit Version 0.95 oder kleiner laufen einige Funktionen nicht! Dies ist eine Žnderung gegenber den vorigen Versionen von M2POSIX, aber ich gehe davon aus, daž jemand, der MiNT einsetzt, entweder MultiTOS besitzt, oder sich selbst eine lauff„hige Version von MiNT aus den frei verfgbaren Quelltexten erzeugen kann, oder jemanden kennt, der dies kann. Die Verfgbarkeit vieler (aber nicht aller) neuer GEMDOS-Funktionen, die es unter MiNT gibt, wird nun nicht mehr vom Vorhandensein von MiNT abh„ngig gemacht, sondern es wird durch einen Aufruf dieser Funktionen geprft ob sie untersttzt werden (Returncode ungleich -32 = EINVFN). Damit ist die Nutzung dieser Funktionen auch unter anderen Betriebssystemerweiterungen m”glich, wenn sie die neuen GEMDOS-Aufrufe implementieren. Die Module bestehen nicht aus reinem Modula-2-Quellcode, sondern enthalten noch Kommandos eines ``C''-Pr„prozessors, der die šbersetzbarkeit der Module unter verschiedenen Compilern erleichtern soll. N„here Informationen zum Pr„prozessor geben die folgenden Abschnitte. Fr wen ist M2POSIX geeignet ? ============================== Diese Modulsammlung ist nichts fr Anf„nger! Wer sich mit den Modulen befassen will, sollte schon mit einem Kommandointerpreter umgehen k”nnen, und wissen wie ein Pr„prozessor zu benutzen ist. Weiterhin sollte man bereit sein, sich auf ein bižchen Experimentieren einzulassen. Wer Žnderungen vornehmen will, muž vor allem aufmerksam die Implementationsmodule und die Header-Dateien durchsehen. Also nochmal: DIESE MODULE SIND NUR ETWAS FšR LEUTE, DIE BEREIT SIND, SICH MEHR ODER WENIGER INTENSIV DAMIT AUSEINANDERZUSETZEN!!! An zus„tzlichen Programmen, neben einem M2-Compiler, werden ben”tigt: o Ein Kommandointerpreter, vorzugsweise GULŽM.PRG. o Ein ``C''-Pr„prozessor, vorzugsweise GCC-CPP.TTP bzw. CPP.TTP (Der GNU-C-Pr„prozessor wird im Verzeichnis 'cpp' mitgeliefert). Diese Programme findet man bestimmt auf jedem FTP-Server (z.B. ftp.uni-muenster.de, ftp.uni-paderborn.de, ftp.cs.tu-berlin.de). Der Pr„prozessor drfte meistens zusammen mit dem GNU-C-Compiler in einem gemeinsamen Archiv zu finden sein. Aužerdem gibt es beide Programme auch noch auf (teuren) PD-Disketten. Bedingungen, unter denen M2POSIX verwendet werden darf ====================================================== Die Verwendung von M2POSIX unterliegt keiner Einschr„nkung, aužer daž bei der Weitergabe alle Dateien unver„ndert enthalten sein mssen (abgesehen von einer Komprimierung). Natrlich drfen fr die Weitergabe auch keine Gebhren zus„tzlich zu Diskettenkosten, Kopierkosten o.„. verlangt werden! Ich bernehme keinerlei Verantwortung fr die Korrektheit und Verwendbarkeit der Funktionen. Wer M2POSIX benutzt, ist selber fr alle evtl. Folgen verantwortlich. Warum ein Pr„prozessor ? ======================== Leider verstehen nicht alle Modula-2-Compiler einen gemeinsamen ``Dialekt''. Sicher -- die Sprache ist in einer Sprachbeschreibung definiert worden, aber zum einen gibt es mehrere Versionen dieser Beschreibung (PIM1..PIM4), zum anderen ist lediglich die Syntax formal definiert (BNF), die Semantik aber in Form natrlichsprachlicher Texte, sodaž einige Dinge nicht eindeutig festgelegt sind (werden k”nnen). Aužerdem haben die Compiler-Hersteller auch eigene Restriktionen und/oder Erweiterungen hinzugefgt. Diese Situation wird sich erst „ndern, wenn sich die Hersteller an die ISO-Norm fr Modula-2 halten, hier wird n„mlich auch die Semantik bis ins kleinste formal definiert. Die Unterschiede bestehen vor allem in folgenden Bereichen: o standardm„žige Gr”žen von INTEGER und CARDINAL (16 oder 32 Bit) o Typtransfer: das Žndern des Typs eines Ausdrucks, ohne daž dafr Code generiert wird; d.h. das betreffende Bitmuster wird nur anders interpretiert, bzw. die Typprfung des Compilers umdirigiert. o Typkonvertierung: das Žndern des Typs eines Ausdrucks, wobei evtl. Code generiert wird, z.B. bei der Wandlung zwischen SHORT- und LONG-Typen. o Adressarithmetik o Setzen und Lesen von Prozessorregistern. o Kennzeichnung von LONG-Konstanten Um diese Unterschiede m”glichst aus dem Weg zu r„umen, werden die Module mit Pr„prozessormakros versehen, die z.T. von der Syntax her wie ISO-M2-Code aussehen (z.B. CAST, VAL, ADDADR, SUBADR, DIFADR, INT usw.). In der Datei PORTAB.M2H, die die Definitionen enth„lt, werden die Makros dann auf die compilerspezifischen Konstruktionen abgebildet. Eine weitere Datei mit Makros ist OSCALLS.M2H; sie enth„lt die Definitionen fr die Aufrufe der Betriebssystemfunktionen. Durch das Konzept der Makros k”nnen die Module also einheitlich fr unterschiedliche Compiler programmiert werden; die Unterschiede werden dann erst beim Bearbeiten mit dem Pr„prozessor bercksichtigt, das am besten als erster Pass des šbersetzungsvorganges betrachtet wird. (Bei ``C''-Compilern ist dieses Vorgehen ja bereits integriert, es hindert einen aber niemand daran, dies auch fr andere Sprachen, wie Modula-2, zu benutzen.) Um Module mit und ohne Makros leicht auseinanderhalten zu k”nnen, verwende ich folgende Extensionen fr M2-Dateien mit Pr„prozessorkommandos: .DPP fr Definitionsmodule, .IPP fr Implementationsmodule und .MPP fr Programmodule Diese Kennzeichnung ist natrlich nur ein Vorschlag. Die Benutzung eines ``C''-Pr„prozessors hat natrlich(?) auch Nachteile: o Die Modula-2-Kommentarklammern sind keine ``C''-Kommentarklammern -- deshalb werden Zeichenketten, die mit definierten Makros bereinstimmen, auch innerhalb von Modula-2-Kommentaren durch den Pr„prozessor ersetzt. Als Behelf kann man die entsprechenden Schlsselworte innerhalb der Modula-2-Kommentare in doppelte Anfhrungszeichen (") setzen, da der Pr„prozessor, zumindest der GNU-C-Pr„prozessor, keine Makros in C-Strings ersetzt. o Der Backslash '\' hat fr den Pr„prozessor eine Spezialbedeutung; je nach dem (oder den) nachfolgenden Zeichen wird fr die Kombination der Zeichen nachher durch den Compiler ein Spezial (meistens Control)-Zeichen eingesetzt. Obwohl nicht der Pr„prozessor fr die Ersetzung verantwortlich ist, meldet er jedoch einen Fehler (-> "unterminated string constant"), wenn hinter dem Backslash in einer Zeichen- oder Stringkonstante kein Zeichen mehr folgt. (Das gilt zumindest fr den GNU-C-Pr„prozessor.) Pr„prozessieren der Module ========================== Im folgenden wird davon ausgegangen, daž ``Gul„m'' als CLI zusammen mit den vorgefertigten Batch-Dateien benutzt, und als Pr„prozessor der GNU-C-Pr„prozessor verwendet wird. Wer einen anderen CLI (z.B. Mupfel) benutzt, oder gar einen anderen Pr„prozessor, muž entsprechende Žnderungen vornehmen. Der Aufbau der Batch-Dateien ist als Kommentar in den Dateien selbst enthalten, es sollte also keine gr”žeren Schwierigkeiten geben, diese an andere Gegebenheiten anzupassen. Beim Pr„prozessieren wird am besten folgende Reihenfolge eingehalten: 1) Erstellen einer Datei X.G, die die Batch-Datei X_M2.G mit den n”tigen Parametern aufruft, d.h. Name des Compilers, Zielverzeichnis, Endungen von Definitions- und Implementationsmodulen. Meine Datei fr LPR-Modula sieht so aus: Name: XLPR.G Inhalt: x_m2 LPRM2 m: def mod Die pr„prozessierten Module landen bei mir auf der RAM-Disk M:. Eine „hnliche Datei muž auch fr das Pr„prozessieren der Testmodule erstellt werden, wobei hier nur die Endung fr Programmodule ben”tigt wird: Name: TLPR.G Inhalt: t_m2 LPRM2 m: mod 2) In der Datei PORTAB.M2H werden gleich zu Anfang die Makros #if 0 #define __RES_ON_STACK__ #endif #if 1 #define __LONG_WHOLE__ #endif #if 1 #define __LONG_REAL__ #endif #if 1 #define __REG_VARS__ #endif #if 0 #define __RANGE_CODE__ #endif #if 0 #define __STACK_CODE__ #endif #if 0 #define __DEBUG_CODE__ #endif definiert. Die Einstellung dieser Makros kann auf Wunsch ver„ndert werden. Falls die Bedingung im umgebenden #if gleich 0 ist, ist das Makro undefiniert und damit ausgeschaltet, sonst ist es eingeschaltet. Falls die entsprechende Option bei einem Compiler nicht einstellbar ist, hat das Makro keine Bedeutung. Falls die Option nur beim Start des Compilers aber nicht im Quelltext einstellbar ist, MUž(!) dieses Makro mit der globalen Compilereinstellung bereinstimmen. Falls die Option dagegen im Quelltext gesetzt werden kann, wird sie automatisch, zusammen mit anderen Grundeinstellungen, abh„ngig von diesem Makro gesetzt. Die Bedeutung der Makros ist wie folgt: __RES_ON_STACK__: Die Ergebnisse von Funktionen werden auf dem Stack bergeben, sonst in Registern (D0/D1). __LONG_WHOLE__: Die Typen CARDINAL und INTEGER sind identisch mit LONGCARD und LONGINT, also den gr”žten Ganzzahltypen, entsprechend ISO, sonst mit SHORTCARD und SHORTINT. __LONG_REAL__: Der Typ REAL ist identisch mit LONGREAL, sonst mit SHORTREAL. __REG_VARS__: Lokale Variablen, die mit dem Attribut __REG__ versehen sind, werden als Registervariablen deklariert, sonst nicht. __RANGE_CODE__: Wenn im Quelltext das Makro __DEBUG__ auftaucht, werden die Compileroptionen zur Erzeugung von Index- und Bereichstests und „hnlichem ein- bzw. ausgeschaltet. __STACK_CODE__: Wie oben, es betrifft jedoch die Erzeugung von Stacktests. __DEBUG_CODE__: Wie oben, betrifft jedoch die Erzeugung zus„tzlichen Codes fr die Untersttzung von Debuggern. 3) Eintragen des vollst„ndigen Pfades der Datei PORTAB.M2H in die Batch-Datei M2PPX.G. PORTAB.M2H kann in einem beliebigen Verzeichnis stehen, da nur an dieser einen Stelle auf sie zugegriffen wird. Sinnvoll ist es jedoch, sie in dem Verzeichnis unterzubringen, wo auch die anderen Header-Dateien stehen, falls solche existieren (z.B. vom ``C''-Compiler). 4) Die Batch-Dateien (bei mir M2PPX.G, X_M2.G, XLPR.G, T_M2.G und TLPR.G), der Pr„prozessor CPP.TTP bzw. GCC-CPP.TTP und das kleine Programm X2D1.TOS werden in ein Verzeichnis kopiert, wo der Kommandointerpreter sie als ausfhrbare Dateien finden kann; das Verzeichnis muž also in der Environmentvariablen PATH erw„hnt sein. Bei mir steht deshalb in GULAM.G folgende Definition (die ab- schlieženden Punkte sollen weitere Pfade andeuten): set path '.,e:\usr\bin,e:\bin,...' , wobei die Batch-Dateien und X2D1.TOS im ersten Verzeichnis stehen und der Pr„prozessor im zweiten. Bemerkung: Nach einem 'set path' wird bei Gul„m automatisch die Environmentvariable PATH gesetzt. 5) Alle Dateien mit den Endungen .DPP, .IPP und .MPP und die Datei OSCALLS.M2H in ein Verzeichnis kopieren. OSCALLS.M2H kann alternativ ebenfalls in das Verzeichnis kopiert werden, wo die anderen Header-Dateien stehen, dann muž jedoch der Pr„prozessor wissen, wo er zu suchen hat; in meinem GULAM.G steht deswegen folgende Zeile: setenv GNUINC e:\usr\include\m2,e:\usr\include Im ersten Verzeichnis stehen dabei alle Modula-2-Header, im zweiten die ``C''-Header. 6) Gul„m starten und in das Verzeichnis mit den M2-Dateien wechseln. 7) Einfach die in Punkt 1) erstellten Batch-Dateien aufrufen, z.B. mit: XLPR und wenn kein Fehler aufgetreten ist: TLPR Dann sollten im Zielverzeichnis die Module in reinem M2-Quellcode stehen. Die Module k”nnen dann mit dem Modula-2-Compiler bersetzt werden. Da die Module teilweise voneinander abh„ngig sind, muž beim šbersetzen natrlich eine bestimmte Reihenfolge eingehalten werden, hierfr kann aber einfach die gleiche Reihenfolge benutzt werden, wie sie in der Batch-Datei X_M2.G fr das Pr„prozessieren verwendet wurde. Installation ============ Die Installation der POSIX-Bibliothek geschieht einfach dadurch, daž die bersetzten Module in ein (neues) Verzeichnis kopiert werden (z.B. ...\POSIX\), und dieses Verzeichnis dem M2-System als zus„tzlicher Suchpfad bekannt gemacht wird. Wie das Einstellen der Suchpfade geschieht, ist den jeweiligen Systemunterlagen zu entnehmen. Bei HM2 k”nnen die Module auch zu einem Archiv zusammengefažt werden, um Platz zu sparen und die šbersicht zu erh”hen. Verwendung unterschiedlicher Compiler ===================================== Folgende Compiler werden nicht untersttzt: o ana-systems m2 (ANAM2): Ein Shareware-Compiler, der sich an PIM2 orientiert; der Hauptnachteil ist aber, daž er keine arithmetischen 16-Bit-Typen kennt. o Modular Systems (MSM2): orientiert sich auch irgendwo zwischen PIM2 und PIM3, hat aber viel zuviele Eigenheiten. o FTL-Modula (FTLM2): hat einige Compilerfehler, die einem das Leben schwer, wenn nicht gar unm”glich machen, zumindest in der Version 1.18 (z.B. fehlerhafte Mengenoperationen, Probleme beim Reexport, Fehler beim Lesen und Setzen von Prozessorregistern, Fehler beim Casten). Ich behaupte nicht, daž diese Compiler schlecht w„ren (na ja, gut sind sie allerdings auch nicht...), es ist mir aber zu viel Arbeit, auf die Eigenheiten dieser Systeme Rcksicht zu nehmen. Momentan werden (nur) die folgenden Compiler untersttzt: o LPR (PD-Compiler der TU-Mnchen), Version 1.4 (LPRM2): Fr diesen Compiler gibt es die Batchdateien MAKELIB.CM und MAKETEST.CM, mit deren Hilfe der Compiler alle pr„prozessierten Module in einem Rutsch bersetzt. Beim LPR-Compiler mssen per Hand alle Tests in der Shell ein- oder ausgeschaltet werden, da es keine im Quelltext aktivierbaren Compileroptionen gibt. Leider werden die entstehenden Programme, im Gegensatz zu den anderen Compilern, ziemlich grož, da der Linker nicht optimiert, aber dieses Problem ist ja nicht M2POSIX-spezifisch. Fr diesen Compiler gibt es von mir das Archiv 'LPR_UTL2.ZOO', das u.a. Fehlerkorrekturen und ein ge„ndertes Startup-Modul fr ACC-Programmierung enth„lt. Das Archiv sollte dort erh„ltlich sein, wo es M2POSIX gibt. Fr die Lauff„higkeit von M2POSIX sind die Korrekturen allerdings nicht notwendig. o SPC, Version 2.0 (SPCM2): Es ist keine spezielle Anpassung vorhanden; da dieser Compiler (nur der Compiler, nicht etwa das ganze System) aber fast identisch zum LPR-Compiler ist, drfte es auch mit SPC-Modula keine Probleme geben (Die Pr„prozessormakros bercksichtigen immer LPRM2 und SPCM2 gemeinsam). Žhnliches drfte auch fr andere Compiler gelten, die vom Original-ETH-Compiler abstammen. o TDI, Version 3.01 (TDIM2): Ebenso wie fr LPR gibt es Batchdateien, mit denen alle Module auf einmal bersetzt werden k”nnen; sie lauten MAKELIB.BAT und MAKETEST.BAT. Fr diesen Compiler gibt es in 'M2GEM*.LZH' von Ulrich Kaiser einen umfangreichen Bug-Report von Rolf Schrader. Die darin beschriebenen Fehler beeintr„chtigen jedoch nicht die Lauff„higkeit von M2POSIX mit TDI. 'M2GEM*.LZH' sollte ebenfalls am gleichen Ort erh„ltlich sein wie M2POSIX. Mit diesem Compiler sollten allerdings die ber __RANGE_CODE__, __STACK_CODE__ und __DEBUG_CODE__ erreichbaren Laufzeitberprfungen abgeschaltet werden, da der Compiler z.T. falschen Debug-Code erzeugt, der Bereichsberschreitungen meldet wo gar keine vorhanden sind; dies ist z.B. bei den Programmen 'ListDir' und 'tlib' der Fall. o Megamax, Version >= 4.2 (MM2): Bei diesem Compiler funktioniert die Prozedur "proc.vfork()" nicht; d.h. eigentlich funktioniert sie schon, blož die Beendigung des neuen Prozežes mittels 'Pterm' funktioniert nicht. Das liegt vermutlich am Laufzeitsystem und den Bibliotheken, die sich in den 'etv_term'-Vektor einh„ngen und beim 'Pterm' bzw. 'Exit' des Kindprozesses s„mtliche Resourcen freigeben, die der Elternprozež noch braucht. Wird der Kindprozež unter MiNT mittels 'exec*' mit einem neuen Prozež berlagert, funktionierts wieder, der 'exec*'-Aufruf darf nur nicht fehlschlagen, da dann der Kindprozež wieder mit 'Pterm' beendet werden muž. Unter TOS funktionierts auch mit 'exec*' nicht, da es keine šberlagerung gibt, sondern nur eine Emulation mittels dem normalen 'Pexec' und einem anschlieženden 'Pterm'. Die obige Text stimmt nicht mehr ganz, ich habe ihn aber zur Erkl„rung des Problems stehen lassen. Falls die 'Pvfork'-Funktion existiert, wie bei MiNT, ist es nun doch m”glich "vfork()" zu verwenden (Dank an Thomas Tempelmann), die TOS-Emulation von "vfork()" funktioniert allerdings immer noch nicht (muž wohl andere Grnde haben...). Um alle Module auf einmal bersetzen zu k”nnen, kann dem Make-Generator (ModRef, F3) das Modul MAKELIB.M bergeben werden, das alle Module aužer den Testmodulen importiert. Ebenso wie bei TDI sollten die Laufzeitberprfungen abgeschaltet werden, da teilweise falscher Debug-Code erzeugt wird. o H„nisch, Version >= 5.1 (HM2): Auch hier kann MAKELIB.M verwendet werden, um alle Module in das integrierte Make zu bernehmen. Je nach Compilerversion sind bereits die Bezeichner BYTESET und LONGSET vordefiniert, sodaž es bei der šbersetzung von PORTAB, auch wieder je nach Version, zu Warnungen oder Fehlermeldungen kommen kann. Wenn Fehlermeldungen auftreten, mssen die Bezeichner in der HM-Programmdatei mit einem Dateimonitor durch gleichlange anderslautende Bezeichner ersetzt werden (z.B. ByteSet und LongSet). Frher waren BYTESET und LONGSET in PORTAB einfach auskommentiert, da sie in M2POSIX nicht verwendet werden, damit war dieses PORTAB allerdings nicht mehr kompatibel zum Original-PORTAB aus 'crystal' (Wer 'crystal' nicht verwendet, kann ja die Bezeichner in PORTAB auch wieder auskommentieren, anstatt den Compiler zu patchen). Wer Signalhandler programmiert, sollte beachten, daž z.Zt. die Bibliotheksmodule GEMDOS, BIOS und XBIOS nicht reentrant sind (Rcksprungadresse und Register werden global gesichert). Da viele weitere Bibliotheksmodule auf diese Betriebssystemmodule zugreifen -- insbesondere 'Terminal' und 'InOut' --, sollten/mssen Aufrufe dieser Module innerhalb von Signalhandlern vermieden werden. Der HM-Compiler wird st„ndig in Richtung ISO weiterentwickelt, sodaž je nach Version schon Features untersttzt werden, die in PORTAB.M2H fr HM2 nicht definiert sind; dies betrifft alle Makros, die mit ``ISO_'' beginnen. Testweise, oder wenn sicher ist, daž der Compiler gewisse Dinge (fehlerfrei!!!) untersttzt, kann bei diesen Makros also ein ``(defined HM2)'' hinzugefgt werden. Wer die Module an sein System anpassen will, muž auf jeden Fall die Header-Datei PORTAB.M2H anpassen, wahrscheinlich auch OSCALLS.M2H, da dort die Betriebssystemaufrufe definiert werden. Aužerdem muž im Modul 'cmdline' die systemspezifische Prozedur zur Ermittlung der 'Basepage' verwendet werden, vielleicht ist die 'Basepage' auch als Variable in irgendeinem Systemmodul deklariert. Die Module 'MEMBLK' und 'jump' enthalten Assemblerprozeduren, die angepasst werden mssen; die Routinen selber sind allgemein gehalten, sodaž hier keine Anpassung n”tig sein drfte, evtl. mssen aber andere Register gerettet werden, dazu steht aber ein Kommentar im Quelltext. Weiterhin muž noch die (teilweise) Assemblerprozedur "proc.vfork()" angepasst werden. Es kann auch sein, daž im Quellcode spezielle Abfragen auf das System n”tig werden, z.B in der Form: ... #if (defined M2) ... #else ... #endif ... Es sollte jedoch versucht werden, s„mtliche Compiler-Abh„ngigkeiten in die Header-Dateien zu verlegen -- soweit m”glich. Am besten ist es, mal die Testmodule (mit der Endung .MPP) zu bersetzen, und sowohl unter GEMDOS als auch unter MiNT laufen zu lassen -- vorausgesetzt natrlich, daž der Compiler dazu berredet werden kann, die Module zu bersetzen. Falls der Compiler fr INTEGER und CARDINAL per Option 16 oder 32 Bit benutzen kann, sollten auch beide Einstellungen ausprobiert werden. Die ``Test''-Module sind allerdings keine vollst„ndigen Tests, vielmehr werden einfach nur einige der Funktionen mit unterschiedlichen Parametern aufgerufen, und geprft, ob das Erwartete passiert. Z.T. ist auch die šberprfung durch den Benutzer erforderlich, oder es werden einfach nur Systemeinstellungen abgefragt. Fr weitere Informationen ber die Anwendung der Testmodule sollte der Quellcode durchgesehen werden. Zu Demonstrationszwecken wurden einige der Testmodule auch bersetzt. Da bei solchen Anpassungen einiges schief gehen kann, sollte vielleicht eine RAM-Disk benutzt werden, auf der dann Dateien ohne Auswirkungen zerst”rt werden k”nnen... Auf jeden Fall bernehme ich keine Verantwortung fr zerschossene Festplatten oder „hnliches... Eine Anpassung an MSDOS- oder gar *IX-Systeme ben”tigt sicherlich einiges an Arbeit, ich will aber niemanden davon abhalten... Generell: Ich wrde mich freuen, wenn mir jemand, der eine Anpassung vorgenommen hat, eine Kopie zukommen l„žt. Das gilt natrlich auch fr Anregungen, Fehlermeldungen u. „. Meine Adresse: Holger Kleinschmidt Promenadenstr. 11 B 12207 Berlin Literatur ========= Zlotnick, F. "The POSIX.1 Standard: A Programmer's Guide." The Benjamin/Cummings Publishing Company, Redwood City, California, 1991 POSIX.2-Standard. IEEE P1003.2 Draft 11.2, ISO/IEC CD 9945-2.2 Diverse *IX-man-pages Quelltexte der MiNTLib, GNULib und glibc (die ``echte'' GNULib)