home *** CD-ROM | disk | FTP | other *** search
/ Amiga ISO Collection / AmigaDemoCD2.iso / ASCII / TEXTE / SCENE / FAQ-LISTS / cfaq_3.txt < prev    next >
Encoding:
Text File  |  1995-01-03  |  23.7 KB  |  520 lines
  1. _______________          _____      _____   _________       ___________________
  2. \.            /________ |.   /_____:o    | /.        \/|___/_       \         /
  3.  \___   _____/|.   /   \||  /|.    |:    |//   ______/·|.   / ______ \    ___/
  4.    /.   /_/·  ||  /     \:  \||    |·    |/   /   \ \/ ||  /_______ \/+    /
  5.   //  ____/   ||  \   \  \   \:   ¯¯¯    |   /    / /  ||  \ /·\  /  \  __/_
  6.  //   / //    |+   \   \      \  \___/   |   \___/ /   |·   \/  \/   /      /
  7. /·   /  \\         /    \     /    |:    |        /         /       /      /
  8. \___/    \________/_____|\___/:    |_____|_______/\________/_______/______/
  9.                              l_____|·MBB·
  10.  
  11.  
  12. _ ___                  \ _
  13.   ___|__________/\______\//\________________________________________________ _
  14.   \___   /  ___/  \_____\//\______________      /\   ______/  _______/  ___ _
  15.      | _/   \ _    \_   \/     |   ___)_/_  ___/_/_  ___)_\______   \______
  16.      | \     \/     /   ||     |   \      | \      | \          /    /    /
  17.  _ __|  \__________/____||     |____      |__      |__         _____/    ___ _
  18.      `----'              `-----'   `------' `------' `---------'  `------'
  19.                                                                          
  20.                               [hOMELESS÷bBS!]
  21.  
  22.     [bIRDHOUSE^pROJECTS eUROPEAN hQ][mYTH! gERMAN hQ][aRT-cORE! fUN hQ]
  23.  
  24.             [sYSdOODE: -sLIME!^bIRDHOUSE÷pROJECTS-lEADER^mYTH!]
  25.                [cOdOODES: mOGUe!/sCX^aC! pRIMUS!/bP!-lEADER]
  26.                      [MR.VAiN/bNZ^aC! wHIRLWIND/mYTH!]
  27.  
  28.             [uPLOADER:GeNeRaTioN      ][oF:[+] PRODIGY '95 [+]]
  29.                [uPLOAD tIME:13:52:39][uPLOAD dATE:03-Jan-95]
  30.  
  31. _ ___                  \ _
  32.   ___|__________/\______\//\________________________________________________ _
  33.   \___   /  ___/  \_____\//\______________      /\   ______/  _______/  ___ _
  34.      | _/   \ _    \_   \/     |   ___)_/_  ___/_/_  ___)_\______   \______
  35.      | \     \/     /   ||     |   \      | \      | \          /    /    /
  36.  _ __|  \__________/____||     |____      |__      |__         _____/    ___ _
  37.      `----'              `-----'   `------' `------' `---------'  `------'
  38.  
  39.  
  40.  
  41.  
  42.   «------------------[ eLITE gUYS wILL gET iNVITED hERE ]------------------»
  43.         .         .        .            .    :   ·    .
  44.    ____/¦__   ___/¦____ __/¦___________/¦__  ¦   ¦___/¦__         !
  45.    _ ____  \__\____  _//  _____\_________  \ |   | ____  \__     _:/\__
  46.     /·  |____//·  |   \\_____ ·\|   |   |  \\|   |/·  |____/     \ Oo /
  47.    //   |    \    |    \   l   \\   |   |   ·\_  //   |    \     /_--_\
  48.    \__________\________/________/___j___j     /  \__________\     :\/
  49.    -------------------------------------l____/   :-----------     ¡
  50.                                              ·   ·
  51.                     .     :   ·    .           .         .        .
  52.     !        _ ____/¦__   ¦   ¦____¦\____ ____/¦__   ___/¦____ __/¦_____ __
  53.    _:/\__    _ _ ____  \__|   |______   \ _ ____  \__\_  |  _//  _____ __ _
  54.    \ Oo /       /·  |____/|   |/· __  __/  /·  |____//·  |   \\_____ ·\
  55.    /_--_\      //   |    \|   //   |    \_//   |    \    l    \   l   \\
  56.     :\/        \__________\   \____j     /\__________\________/________/
  57.     ¡          -----------·   :----l____/-------------------------------
  58.                           ·   ·
  59.      <*> pRODIGY gHQ <*> nEUTRON wHQ <*> iLLUSION eHQ <*> dYNAMIX gHQ <*>
  60.  
  61.               Upload Date: [01-03-95] «» Upload Time: [07:18:11]
  62.  
  63.   «-------------------[ aSK eLITE fOR SYS-PW & NUMBA ! ]-------------------»
  64.  
  65.                     .__ _                                            r      
  66.                     :   __tHIS fILE wAS D/L fROM                     I      
  67.                  _ _02-Jan-95_________________________:              N      
  68.                    _|   \/                            |              G      
  69.                    \/       T¾R¾S¾I LEADER H¾Q     \\ ²  tRISTAR & rED      
  70.                     ­                               \ ­          sECTOR     
  71.     ö   .           |_/\________/\__.___   _/\_______ |              W      
  72.      /\             |\    ._    \   ­   \  \     ____)²             iNC.    
  73.    . \/\------------|/    |/____/        \ /     __)__!---------------.     
  74.      |\/            /     ²   /     |     \           \   4nODEZ      |     
  75.      |              \_____|   \_____²_____/___________/               !_    
  76.      |ö             |                                 |              /_/\   
  77.      |  _/\__.___   !/\_._/\________/\________/\______!  _/\______   \_\/   
  78.      |  \    ­   \  \___!\    ._    \   ._    \    ____) \    .   \   |     
  79.      00:12:49     \ /   |/    |/    /   |/    /    __)__ /    |    \_/¹     
  80.        /     |     \    |     /    /    /    /          \     |     \       
  81.        \_____²_____/____²_________/_________/___________/_____²_____/ö2Fö   
  82.                     ²                                 ²                     
  83.                    _!/\__                             |__                   
  84.                    \ Oo /   +49  p¾R¾I¾V¾A¾T¾E¾!   ___| /                   
  85.    eLITE gUYS      /_--_\                          \  //                    
  86.     wILL gET        ²\/      tHE hOLY mASTER iS     \/|                     
  87.   iNVITED hERE      !              mClOUD             ²                     
  88.                     ²  aND hIS hELPING hAND iS mARIO  :                     
  89.                     :                                                       
  90.                     ¾   aSK fOR nUMBER aND sYSPW/nUP
  91.  
  92.  
  93. @BEGIN_FILE_ID.DIZFREQUENTLY ASKED QUESTIONS ABOUT `C`
  94. -German Edition-
  95. 3-10
  96. @END_FILE_ID.DIZ
  97. /Teil 3
  98.  
  99.           Q1.12  Was bedeutet portabel?
  100.  
  101.  
  102.           Ein Programm  ist  portabel,  wenn  es  sich  auf verschiedenen
  103.           Rechnern,  Betriebssystemen  und  Compilern ohne Änderung über-
  104.           setzen läßt (und funktioniert).  C ist  eine  portable Program-
  105.           miersprache, d.h. sie ermöglicht es  durch  ihre  präzise Defi-
  106.           nition, Programme zu schreiben, die auf den unterschiedlichsten
  107.           Rechnern ohne  Änderungen  laufen.  Allerdings  ist  es  ebenso
  108.           möglich,  unportable  Programme,  die möglicherweise schon nach
  109.           einem Compiler-Update auf  demselben Rechner nicht mehr laufen,
  110.           zu schreiben.
  111.                                      Begriffe                          11
  112.           ---------------------------------------------------------------
  113.  
  114.           Es  gibt verschiedene Kriterien, anhand derer die  Portabilität
  115.           eines Programms bestimmt werden kann.  Das  stärkste  davon ist
  116.           die strikte Konformität ("strictly conforming"),  die bedeutet,
  117.           daß ein Programm sich garantiert  auf  allen  denkbaren ANSI-C-
  118.           Systemen ohne Probleme übersetzen läßt und  auf  dieselbe Weise
  119.           funktioniert. Allerdings lassen sich  in  der  Praxis  nur sehr
  120.           wenige Programme strikt konform halten, da sie keine Funktionen
  121.           des Betriebssystems verwenden dürfen.
  122.  
  123.           Portable Programme in der Praxis sind  daher  normalerweise nur
  124.           in einem  gewissen Umfeld portabel, z.B. auf Systeme, auf denen
  125.           die  portable  Betriebssystemschnittstelle  POSIX zur Verfügung
  126.           steht (u.a.  viele Unix-Systeme) oder die ein und dieselbe gra-
  127.           fische Benutzeroberfläche verwenden.
  128.  
  129.           Der  Preprozessor  kann  oft  verwendet  werden,  um  Programme
  130.           portabel  zu  machen,  obwohl einzelne Programmteile unportabel
  131.           formuliert werden müssen:
  132.  
  133.                #if UNIX
  134.                #  if SYSV
  135.                     /* Code fuer Unix System 5 */
  136.                #  elif BSD
  137.                     /* Code fuer BSD-Unix */
  138.                #  else
  139.                #    error "Unbekanntes Unix"
  140.                #  endif
  141.                #elif TOS
  142.                     /* Code fuer Atari TOS */
  143.                #elif MSDOS
  144.                     /* Code fuer MSDOS */
  145.                #else
  146.                #  error "Unbekanntes Betriebssystem"
  147.                #endif
  148.  
  149.           Für die portable Programmierung ist es von größter Wichtigkeit,
  150.           genau  zu  wissen,  was in C definiert, was undefiniert und was
  151.           implementierungsdefiniert ist, um  abschätzen zu können, ob das
  152.           Programm, wenn es auf einem  Rechner  läuft,  auch  auf anderen
  153.           laufen  wird. Normalerweise werden Programme nämlich auf  einem
  154.           Rechner entwickelt und getestet und erst  hinterher  auf andere
  155.           Rechner portiert.
  156.  
  157.           Die  bei  einer  Portierung  auftretenden Probleme können viel-
  158.           fältig sein,  und  häufig  werden  Fehler  erst  beim Portieren
  159.           bemerkt. So kann z.B. bei
  160.  
  161.                int a;
  162.                int x[3];
  163.                int b;
  164.  
  165.                a = 1;
  166.                b = 2;
  167.                x[3] = 0;
  168.  
  169.           durch die fehlerhafte Zuweisung x[3]=0 auf einem Rechner a, auf
  170.           einem  anderen  Rechner  b und auf einem  dritten  Rechner  gar
  171.           nichts überschrieben werden.                               (wr)
  172.           12                           Begriffe
  173.           ---------------------------------------------------------------
  174.  
  175.           Q1.13  Was bedeutet portierbar?
  176.  
  177.  
  178.           Eigentlich gar nichts; die  Definition  von  "portierbar" daher
  179.           aus istProgramm wird als portierbar  bezeichnet,  wenn  es sich
  180.           auf andere Rechner portieren läßt.  Z.B. ist es für die meisten
  181.           Unix-Programme  möglich,  sie   (unter   Verwendung  spezieller
  182.           Libraries) auf einem  Atari  ans laufen zu kriegen, nachdem man
  183.           sie entsprechend angepaßt  hat. Der Aufwand solcher Anpassungen
  184.           kann  durchaus beträchtlich sein und gehört  zu  den  unter  C-
  185.           Programmierern am meisten verabscheuten Tätigkeiten.
  186.  
  187.           Zum Beispiel müssen Programme, die  davon  ausgehen,  mit einem
  188.           Aufruf von malloc() mehr als 64 KB anfordern zu können, bei der
  189.           Portierung auf MS-DOS (wo  size_t  nur  16  Bits groß ist, also
  190.           maximal  64 KB ansprechen kann) in weiten Teilen  umgeschrieben
  191.           werden.
  192.  
  193.           Da man mit hinreichender Anstrengung jedes C-Programm  auf fast
  194.           jedem System ans laufen  kriegen  kann, ist so gut wie jedes C-
  195.           Programm portierbar. Natürlich gibt es Ausnahmen; Programme mit
  196.           grafischer Benutzeroberfläche sind  nicht  auf Microcontroller,
  197.           die  interaktionslos  arbeiten,  portierbar, und Programme, die
  198.           mehr als 64 KB an statischen Variablen brauchen, sind nicht auf
  199.           MS-DOS portierbar.                                         (wr)
  200.  
  201.  
  202.           Q1.14  Was ist robuste Programmierung?
  203.  
  204.  
  205.           Robuste  Programmierung  bedeutet, ein Programm  so  zu  formu-
  206.           lieren, daß es möglichst viele Änderungen toleriert,  ohne auf-
  207.           zuhören zu funktionieren. Beispiel:
  208.  
  209.                int *ptr;
  210.                ptr = calloc(sizeof(int),10);
  211.  
  212.           Wird irgendwann das Programm geändert,  so  daß  ptr vielleicht
  213.           kein int*, sondern ein double* ist, dann wird (falls ein double
  214.           größer als ein int  ist)  das  calloc() zuwenig Speicher anfor-
  215.           dern, falls es nicht mitgeändert wurde.  Die  einfache Änderung
  216.           des Typen von  ptr  würde  also  in  diesem  Fall  das Programm
  217.           kaputtmachen. Schreibt man stattdessen
  218.  
  219.                ptr = calloc(sizeof(*ptr),10);
  220.  
  221.           so kann das Programm durch die einfache Änderung  des  Typs von
  222.           ptr nicht beschädigt werden. Das Programm ist dann also robust-
  223.           er gegen die Änderung.
  224.  
  225.           Robuste Programmierung ist von großer Wichtigkeit, da  außer in
  226.           der ersten Entwicklungsphase kaum jemand eine  Änderung  an dem
  227.           Programm vornimmt,  der das gesamte Programm gelesen hat und so
  228.           alle Abhängigkeiten und Auswirkungen von  Änderungen beurteilen
  229.           kann.
  230.  
  231.           Weitere Beispiele:
  232.                                      Begriffe                          13
  233.           ---------------------------------------------------------------
  234.  
  235.               -  Folgendes
  236.  
  237.                       struct {
  238.                            char string[100];
  239.                            /* ... */
  240.                       } s;
  241.                       char t[100];
  242.                       /* ... */
  243.                       strcpy(s.string,t);
  244.  
  245.                  kann schiefgehen, sobald die  Größe  von  s.string, aber
  246.                  nicht die von t geändert wird. Besser:
  247.  
  248.                       char t[sizeof(s.string)];
  249.  
  250.               -  Folgendes
  251.  
  252.                       for(i=0;i!=10;i++)
  253.  
  254.                  geht schief, sobald die Schleife so geändert wird, daß i
  255.                  einen Wert > 10 annehmen kann. Besser:
  256.  
  257.                       for(i=0;i<10;i++)
  258.  
  259.           Zur robusten Programmierung gehört natürlich auch, daß man kein
  260.           undefiniertes   oder    implementierungsdefiniertes   Verhalten
  261.           ausnutzt,  die  Funktionsweise  des  Programms   von  Compiler-
  262.           Einstellungen abhängig macht o.ä.
  263.  
  264.           Um  sicherzustellen,  daß  Bedingungen,  von  denen  das  Funk-
  265.           tionieren eines Programms  abhängt, nicht geändert werden, kann
  266.           man auch den Preprozessor verwenden.
  267.  
  268.                #define MINSIZE 10
  269.                #define MAXSIZE 100
  270.                /* ... */
  271.                #if ! (MINSIZE < MAXSIZE)
  272.                #error "MINSIZE muss immer kleiner als MAXSIZE sein"
  273.                #endif
  274.  
  275.           Obiges   setzt   selbstverständlich   einen   ANSI-Preprozessor
  276.           voraus.                                                    (wr)
  277.  
  278.  
  279.           Q1.15  Was ist defensive Programmierung?
  280.  
  281.  
  282.           Defensive  Programmierung ist eine Vorgehensweise bei der  Pro-
  283.           grammierung, die schon beim  Entwurf  eines  Programms beginnt.
  284.           Ziel ist es, in instabilen Umgebungen brauchbare  Ergebnisse zu
  285.           erzielen. Mit instabilen Umgebungen sind  Verhältnisse gemeint,
  286.           in denen man z.B. das fertige Programm nur schwer bis gar nicht
  287.           und/oder nur sehr  umständlich  testen kann, wo man mit fehler-
  288.           haften Compilern arbeiten muß, wo der ECLG-Zyklus (siehe Q1.17)
  289.           sehr aufwendig ist, wo das Betriebssystem jeglichen Schwachsinn
  290.           produziert usw.
  291.           14                           Begriffe
  292.           ---------------------------------------------------------------
  293.  
  294.           Zum  Instrumentarium der defensiven Programmierung gehört  u.a.
  295.           robuste Programmierung, der Verzicht auf exotische C-Konstrukte
  296.           (und natürlich auf alle  mit  undefiniertem  Verhalten), exzes-
  297.           sives Testen aller an Funktionen übergebenen Werte  (z.B. auch,
  298.           ob Pointer  in  gewissen  Bereichen  liegen), Plausiblitätstest
  299.           aller  Rückgabewerte von Betriebssystem-Aufrufen usw. Kurz  und
  300.           gut, man vermeidet  alles,  was nur im Entferntesten nach Ärger
  301.           riechen könnte.  Das ganze wird häufig noch mit größeren Mengen
  302.           Debugging-Code verziert, der so geschrieben  ist,  daß  er fein
  303.           granuliert  zur   Laufzeit   ein-   und   ausgeschaltet  werden
  304.           kann.                                                      (tw)
  305.  
  306.  
  307.           Q1.16  Was ist ein "String-Literal"?
  308.  
  309.  
  310.           Einfach ein konstanter String. Beispiel:
  311.  
  312.                puts("Hallo Welt");
  313.  
  314.           In diesem Fall ist  "Hallo  Welt"  das  String-Literal. String-
  315.           Literale werden als '\0'-terminierte Arrays von chars abgelegt,
  316.           d.h. das String-Literal "xyz" entspricht dem Array
  317.  
  318.                char array[4] = { 'x', 'y', 'z', '\0' };
  319.  
  320.           Anders als  bei einem solchen Array darf ein String-Literal al-
  321.           lerdings nicht verändert werden. Folgendes
  322.  
  323.                "abc"[0] = 'x';
  324.  
  325.           oder
  326.  
  327.                char *p = "hallo";
  328.                *p = 'H';
  329.  
  330.           oder
  331.  
  332.                strcpy("Hallo","Welt");
  333.  
  334.           ist also verboten und  führt  zu  undefiniertem  Verhalten. Der
  335.           Grund  dafür  ist,   daß   es  dem  Compiler  so  möglich  ist,
  336.           Stringliterale  in  einem   schreibgeschützten  Speicherbereich
  337.           (vielleicht  im ROM) abzulegen, oder in einem  Speicherbereich,
  338.           der von mehreren Prozessen (gleichzeitig  laufenden Programmen)
  339.           gemeinsam benutzt ("shared") wird.  Ein  Schreibversuch  in ein
  340.           solches String-Literal kann zum Abbruch des  Programms  oder zu
  341.           einem Signal  führen. Außerdem ist es dem Compiler erlaubt, das
  342.           sogenannte "String Merging" durchzuführen: bei
  343.  
  344.                char *p = "Hallo";
  345.                puts("Hallo");
  346.  
  347.           braucht das  String-Literal  "Hallo"  nur  einmal  im  Speicher
  348.           abgelegt zu werden, bei
  349.  
  350.                char *p = "abcd";
  351.                char *q = "bcd";
  352.                                      Begriffe                          15
  353.           ---------------------------------------------------------------
  354.  
  355.           kann  q==p+1 gelten. Schreibversuche in String-Literale  können
  356.           in  diesem  Fall zu unvorhersehbaren  Ergebnissen  führen,  zum
  357.           Beispiel könnte mit
  358.  
  359.                FILE *fp;
  360.                char *p = "r";
  361.                p[0] = 'w';
  362.                fp = fopen(very_important_file,"r");
  363.  
  364.           die Datei überschrieben statt gelesen  werden  (weil  durch die
  365.           Änderung  des  String-Literals,  auf  das  p  zeigt,  auch  das
  366.           String-Literal  geändert  wird, das als  zweiter  Parameter  an
  367.           fopen() übergeben wird).                                   (wr)
  368.  
  369.  
  370.           Q1.17  Was ist der ECLG-Zyklus?
  371.  
  372.  
  373.           Edit, Compile, Link, Get pissed...                         (wr)
  374.  
  375.           Edit, Compile, Link, Go.                                   (tw)
  376.           16                           Begriffe
  377.           ---------------------------------------------------------------
  378.                                    Preprozessor                        17
  379.           ---------------------------------------------------------------
  380.  
  381.  
  382.                                      Kapitel 2
  383.  
  384.                                    Preprozessor
  385.  
  386.  
  387.           Q2.1  Wie unterscheidet sich ein K&R- von einem ANSI-
  388.                 Preprozessor?
  389.  
  390.  
  391.           Der Vergleich zwischen den beiden Preprozessoren ist  gar nicht
  392.           so einfach. Eigentlich sind nur  alle  Eigenschaften  des ANSI-
  393.           Preprozessors  definiert.  K&R-Preprozessoren sind  im  Prinzip
  394.           Reiser-Preprozessoren (dessen Eigenschaften eh nirgendwo 100%ig
  395.           definiert  sind), jedoch  spendiert  fast  jeder  Compilerbauer
  396.           seinem K&R-Preprozessor ein paar Erweiterungen.
  397.  
  398.           Ein ANSI-Preprozessor arbeitet  prinzipiell anders als ein K&R-
  399.           Preprozessor.  Meist ist ein ANSI-Preprozessor gar kein  eigen-
  400.           ständiges  Programm/Compilermodul (muß es auch nicht sein),  da
  401.           bei ANSI C schon während des Preprocessings  der  Sourcecode in
  402.           Tokens zerlegt werden  muß. Ein K&R-Preprozessor hingegen macht
  403.           praktisch einen 1:1 Textersatz.
  404.  
  405.           Neben Änderungen im Details leistet der ANSI-Preprozessor (bzw.
  406.           die ANSI Preprocessing-Phase) mehr als ein K&R-Preprozessor. Im
  407.           folgenden sind die  wichtigsten Unterschied zwischen den beiden
  408.           Preprozessor-Arten aufgeführt:
  409.  
  410.              1.  Token-Pasting
  411.  
  412.                  ANSI C  führt  für  Token-Pasting den '##'-Operator ein.
  413.                  Damit wird eine undokumentierte (aber  durchaus häufiger
  414.                  verwendete) Eigenschaft des Reiser-Preprozessors endlich
  415.                  standardisiert.
  416.  
  417.                  Bei einem Reiser-Preprozessor schreibt und verwendet man
  418.                  ein Makro,  das  z.B.  einen  Funktionsnamen  mit  einem
  419.                  Prefix 'fkt_' erzeugen soll, wie folgt:
  420.  
  421.                       #define MK_NAME(p)  fkt_/**/p()    /* K&R */
  422.  
  423.                       int MK_NAME(a);     /* wird zu "int fkt_a();" */
  424.                       int MK_NAME(b);     /* wird zu "int fkt_b();" */
  425.  
  426.                  Dies funktioniert deshalb, da ein Reiser-Preprozessor
  427.  
  428.                     a.  zuerst die Makro-Argumente ersetzt und  dann erst
  429.                         Kommentare beseitigt und
  430.  
  431.                     b.  einen Kommentar der  Form '/**/' nicht (wie jeden
  432.                         anderen Kommentar) durch ein White-Space, sondern
  433.           18                         Preprozessor
  434.           ---------------------------------------------------------------
  435.  
  436.                         - entgegen  der  K&R-Sprachdefinition(!) -  durch
  437.                         nichts ersetzt.
  438.  
  439.                  Die Verwendung von '/**/' ist eine ziemlich wilde Sache.
  440.                  Bei einigen K&R-Preprozessoren kann man '/**/' wie folgt
  441.                  umgehen:
  442.  
  443.                       #define IDENT(x)    x
  444.                       #define MK_NAME(p)  IDENT(fkt_)p()
  445.  
  446.                  Da man mit beide Lösungen nicht gerade einen Schönheits-
  447.                  preis gewinnen kann, wurde  für  ANSI  C ein anderer Weg
  448.                  gewählt. Ein ANSI-Preprozessor besitzt den wohldefinier-
  449.                  ten Operator '##':
  450.  
  451.                       #define MK_NAME(p)  fkt_##p() /* ANSI */
  452.  
  453.                       int MK_NAME(a);     /* wird zu "int fkt_a();" */
  454.                       int MK_NAME(b);     /* wird zu "int fkt_b();" */
  455.  
  456. /Ende von Teil 3/
  457.  
  458. Keep hacking
  459. Wolfram
  460.  
  461.  
  462.  
  463.  
  464.   «------------------[ eLITE gUYS wILL gET iNVITED hERE ]------------------»
  465.         .         .        .            .    :   ·    .
  466.    ____/¦__   ___/¦____ __/¦___________/¦__  ¦   ¦___/¦__         !
  467.    _ ____  \__\____  _//  _____\_________  \ |   | ____  \__     _:/\__
  468.     /·  |____//·  |   \\_____ ·\|   |   |  \\|   |/·  |____/     \ Oo /
  469.    //   |    \    |    \   l   \\   |   |   ·\_  //   |    \     /_--_\
  470.    \__________\________/________/___j___j     /  \__________\     :\/
  471.    -------------------------------------l____/   :-----------     ¡
  472.                                              ·   ·
  473.                     .     :   ·    .           .         .        .
  474.     !        _ ____/¦__   ¦   ¦____¦\____ ____/¦__   ___/¦____ __/¦_____ __
  475.    _:/\__    _ _ ____  \__|   |______   \ _ ____  \__\_  |  _//  _____ __ _
  476.    \ Oo /       /·  |____/|   |/· __  __/  /·  |____//·  |   \\_____ ·\
  477.    /_--_\      //   |    \|   //   |    \_//   |    \    l    \   l   \\
  478.     :\/        \__________\   \____j     /\__________\________/________/
  479.     ¡          -----------·   :----l____/-------------------------------
  480.                           ·   ·
  481.      <*> pRODIGY gHQ <*> nEUTRON wHQ <*> iLLUSION eHQ <*> dYNAMIX gHQ <*>
  482.  
  483.               Upload Date: [01-03-95] «» Upload Time: [07:18:11]
  484.  
  485.   «-------------------[ aSK eLITE fOR SYS-PW & NUMBA ! ]-------------------»
  486.  
  487.                                                           [-AquaAdder v1.0-]
  488.  
  489.  
  490.  
  491.  
  492.  
  493.    
  494.                             -sLiME!^bP·LEADER^mTH!
  495.                          mOGUe!^aC! pRIMUS!/bP·lEADER
  496.                       wHIRLWIND/mTH! MR.VAIN/BNZ^sXi^aC!
  497.  
  498. -- --- ---- pHUKKIN' fAST aMIGA ^ wORLD'S lARGEST cHIPTUNE aREA ---- --- --
  499.       ____
  500.   ___|    |_____________  __________________   ____________________________
  501. _/  _|    |   ._________\/__________  \   _/___\______  \   _____/   _____/
  502. \   \.    |   l/    /   \/    |  _____/_  l     /  _____/\____  _/\____  \_
  503.  \___|    |________/____||-Mo!|________________/_______\ _______\ ________/
  504.      l____|              l____|                         \/       \/
  505.  
  506.     -- --- ---- aMI-eX fREE-lEECH ^ bIG aSCII bASE © bY aC! ---- --- --
  507.  
  508.    -- mYTH! gHQ - -÷- - bIRDHOUSE pROJECTS! eHQ - -÷- - aRT-cORE! eHQ --
  509.  
  510. _______________          _____      _____   _________       ___________________
  511. \.            /________ |.   /_____:o    | /.        \/|___/_       \         /
  512.  \___   _____/|.   /   \||  /|.    |:    |//   ______/·|.   / ______ \    ___/
  513.    /.   /_/·  ||  /     \:  \||    |·    |/   /   \ \/ ||  /_______ \/+    /
  514.   //  ____/   ||  \   \  \   \:   ¯¯¯    |   /    / /  ||  \ /·\  /  \  __/_
  515.  //   / //    |+   \   \      \  \___/   |   \___/ /   |·   \/  \/   /      /
  516. /·   /  \\         /    \     /    |:    |        /         /       /      /
  517. \___/    \________/_____|\___/:    |_____|_______/\________/_______/______/
  518.                              l_____|·MBB·
  519.  
  520.