1994 begann die Entwicklung der BayCom-Mailbox Software. Die damalige Wahl des Betriebssystems DOS geschah nach folgenden Gesichtspunkten:
Bereits zum Zeitpunkt der Entwicklung waren natürlich auch die Schwächen von DOS schon bekannt. Diese sind in erster Linie:
Es war also im Prinzip bereits am Anfang bekannt, daß DOS nicht die ideale Wahl für den Betrieb einer Mailbox ist. Trotzdem wird es sich noch lange halten, weil das Gesetz der Trägheit und die Tatsache, daß jede Änderung mit Kosten verbunden ist, dies erzwingen.
Interessant ist die Tatsache, daß es kein anderes Betriebssystem mit ähnlich schlechten Eigenschaften wie DOS gibt. Das mag wohl daran liegen, daß DOS das erste und älteste PC-Betriebssystem ist.
Folgende Alternativen stehen potentiell zur Auswahl:
Andere UNIX-Derivate für PC wurden nicht betrachtet, da Preis meist hoch oder Beschaffung schwierig ist.
Allen obengenannten Systemen gemeinsam ist:
Es sollte hier nicht zur Diskussion angeregt werden, welches der genannten Systeme nun das Beste ist und welches nicht. Obige Auflistung stellt einen subjektiven Blickwinkel des Autors (DL8MBT) dar, es gibt natürlich bei jeder Behauptung Gegenargumente.
Wie auch immer die Vor- und Nachteile der einzelnen Systeme ausfallen mögen, die erste Portierung der BayCom-Mailbox wurde für Linux durchgeführt.
Die ersten Schritte dieser Portierung haben schon Mitte 1994 stattgefunden. Es war weniger die unbedingte Notwendigkeit, als vielmehr der technische Reiz, der zu diesem Schritt geführt hat. So ist es auch nicht verwunderlich, daß nach den ersten Erfolgserlebnissen dieser Zweck erfüllt war, und das Projekt wieder in die Ecke geworfen wurde.
Einige Leute haben sich mit der damaligen Version 1.35a ``vergnügt''. Diese war allerdings für den praktischen Einsatz vollkommen unbrauchbar und vermochte lediglich das Erlebnis ``es geht prinzipiell'' zu demonstrieren.
Im Dezember 1995 brach dann erneutes Interesse aus und das Projekt wurde aus der tiefen Versenkung ausgegraben. Da der Code größtenteils portabel ist, konnte auf die zwischenzeitliche Weiterentwicklung der DOS-Version problemlos aufgesetzt werden.
Die hohe Kunst der portablen Programmierung besteht nicht darin, möglichst verschiedene Versionen für verschiedene Betriebssysteme zu erzeugen, sondern möglichst eine einheitliche Software zu pflegen, die dann auf allen Plattformen übersetzbar und lauffähig ist.
Wird dieses Ziel gut verwirklicht, dann ist auch die Portierung auf weitere Plattformen ohne größere Schwierigkeiten möglich.
So erklärt sich auch, warum es stets nur eine Version gibt und zu einer bestimmten Versionsnummer auch eine bestimmte Funktionalität gehört, ohne daß für die jeweils andere Plattform zusätzliche Arbeit nötig ist.
Trotz dieser guten Vorsätze waren natürlich durchaus Änderungen erforderlich, um den Code portabel zu machen. Folgende Dinge müssen dabei beachtet werden:
So ergibt sich eine kleine Zahl von Modulen, in denen Abhängigkeiten vom Betriebssystem enthalten sind. Der gesamte Rest (>95% der Gesamtmenge) enthält weder Abhängigkeiten vom Betriebssystem noch von der Hardware.
Natürlich gibt es einige Programmteile, die sich partout nicht so anpassen lassen, daß sie für alle Plattformen gemeinsam nutzbar sind. Hier mußten echte ``Sonderlocken'' entwickelt werden, die auch bei zukünftigen Portierungen wieder neu gemacht werden müssen.
Bei DOS ist ein shell-Ausstieg durch Nachladen von COMMAND.COM möglich. Während eines solchen Ausstiegs steht das aufrufende Programm still. Um einen Ausstieg über Funk möglich zu machen, müssen vorher die Ein- und Ausgaben über die BIOS-Schnittstellen umgelenkt werden. Dies ist kritisch und erfordert sehr systemnahe Eingriffe. Unter Linux erfolgt ein Ausstieg ganz anders und vor allem sehr viel eleganter. Wichtigster Vorteil ist, daß wärend eines shell-Ausstiegs die Box ohne Behinderung weiterläuft. Die Kommunikation zwischen dem Boxprogramm und der shell (bzw. des ansonsten ausgeführten Programmes) erfolgt über ein Pseudo-TTY. Nach Beendigung des aufgerufenen Programmes müssen alle davon erzeugten Prozesse wieder sauber aufgeräumt werden.
DOS kann bekanntlich nur ein Programm gleichzeitig abarbeiten (von Interrupts abgesehen). Damit die Box viele Benutzer gleichzeitig bedienen kann wurde für die DOS-Version ein Multitasking-Kern entwickelt, der die Anwendung selbst von dieser Aufgabe befreit. Jeder eingelegte Benutzer erhält eine eigene Umgebung und muß sich zum eigenen Ablauf nicht um die Abläufe anderer Benutzer kümmern.
Dieses Subsystem wäre in dieser Art unter anderen Betriebssystemen nicht erforderlich, wenn sog. Threads, also verschiedene Tasks innerhalb einer Anwendung vom Betriebssystem zur Verfügung gestellt werden. Unter Linux wäre dies im Prinzip möglich. Um das Programm so gleich wie möglich zu halten, werden jedoch auch hier die Mechanismen der DOS-Version benutzt. Dies bedingt, neben vielen portabel realisierbaren Mechanismen, die Umschaltung des Stack-Kontextes. Zu diesem Zweck ist genau ein Assemblerbefehl notwendig, der ein Verbiegen des Stackpointers möglich macht. Dieser Befehl ist sowohl von der Hardware, als auch vom Compiler, als auch vom Betriebssystem abhängig und muß deshalb jedesmal überarbeitet werden.
Die DOS-Version kommuniziert über einen Software-Interrupt mit FlexNet. Dabei sind nur kompakte lnterfaceroutinen in der Box eingebaut, das gesamte AX.25-Handling wird im lnterrupt von einem TSR-Programm durchgeführt.
In der Linux-Version ist derzeit der AX.25-Teil mit in der Box enthalten. Dieser kommuniziert nach außen nur über vorhandene Standard-Schnittstellen. Konkret sind dies CRC-KISS-Mode über serielle Schnittstelle sowie AXIP über UDP für Ethernet-Kommunikation. Außerdem kann die Kommunikation nach außen über ein Linux-Kernel-AX.25-Interface erfolgen.
Bei DOS wird direkt in den Bildschirmspeicher geschrieben. Dies ist notwendig, um eine ansprechende Konsole zur Verfügung zu stellen. Es gibt nur diesen einen Bildschirm, er muß deshalb alle Erfordernisse zur Wartung der Box zur Verfügung stellen. Die Linux-Version wird ganz im Hintergrund betrieben, es findet also keinerlei Bildschirmzugriff statt. Dafür ist es bei Linux vom Betriebssystem möglich, gleichzeitig mehrere virtuelle Bildschirme zu betreiben und von dort über Interprozesskommunikation in die Box einzuloggen.
Bei DOS muß zu diesem Zweck ein Interrupt-Vektor auf das eigene Programm gelegt werden.
Bei Linux wird ein zyklisches ALARM-Signal erzeugt, das dann ebenfalls einen Interrupt im Anwendungsprogramm auslöst. Der Zyklus wurde hierbei auf die bei DOS üblichen 55ms festgelegt.
Komplexere Betriebssysteme haben zumeist die Eigenschaft, auf einer großzügig bemessenen Hardware sehr viel bessere Leistungseigenschaften zu besitzen als z.B. DOS. Das betrifft sowohl die Dateizugriffe als auch den Umgang mit Arbeitsspeicher. Ist der Rechner jedoch unangemessen klein, so brauchen die Mechanismen innerhalb des Betriebssystems einen großen Anteil der zur Verfügung stehenden Resourcen und bewirken daher keine Leistungssteigerung, sondern eher ein Ausbremsen der Anwendung.
Um zufriedenstellende Leistungsdaten zu erzielen, muß man hier also tiefer in die Tasche greifen als dies unter DOS der Fall ist. Es sollte möglichst ein 486er sein, und es sollten wenigstens 8 MB Speicher drinstecken. Unterhalb dieser Grenzen sollte nach wie vor DOS benutzt werden, da eher eine Verringerung der Leistung unter Linux zu erwarten ist.
Die ersten Gehversuche Anfang 1996 bei DB0AAB-8 sind erfreulich. Den Anforderungen bezüglich Rechnerleistung wurde dort Rechnung getragen. Dort läuft ein 486DX2/66 mit 16 MB RAM und insgesamt 4,5 GB Plattenspeicher. Es soll sich hier auch zeigen, wie sich die Box im Zusammenhang mit einer sehr hohen Datenmenge verhält. Aus diesem Grund ist auch derzeit und bis auf weiteres jegliches Löschen von Nachrichten bei DB0AAB abgestellt. Falls die vorhandenen Platten voll sind, läßt sich die Kapazität problemlos auf ca. 8 GB erweitern.
Die Linux-Version der Mailbox hat vor dem ersten Einsatz im ``rauhen'' Betrieb bei DB0AAB auf der Fachhochschule München viele Versuche im stillen Kämmerlein über sich ergehen lassen. Trotzdem war es natürlich nicht möglich, alle Eventualitäten des praktischen Betriebs auszutesten.
Vor allem die Fähigkeit, auch höhere Belastungen stabil durchzustehen, ist im Hausgebrauch nicht zu testen und auch durchaus nicht selbstverständlich. So ist es nicht verwunderlich, daß in den ersten Betriebszeiten gelegentlich ein Update der Software erforderlich war. Die meisten Benutzer werden davon jedoch nichts gemerkt haben, weil der größte Teil der Funktionalität von Anfang an stabil war.
Inzwischen hat sich der Betrieb normalisiert und es gibt auch kein auffallendes Feedback von den Benutzern. Dies ist ein typisches Merkmal bei jeder technischen Entwicklung, daß Rückmeldungen stets nur im Fehlerfall kommen. Das ist zwar für den Entwickler nicht besonders erfreulich, aber im Sinne der Fortentwicklung durchaus wünschenswert und notwendig.
Für den Benutzer ergeben sich kaum Unterschiede zwischen beiden Versionen. Eine wesentliche Zielsetzung bei der Entwicklung der BayCom-Mailbox war schon in der DOS-Version, daß für den Benutzer stets eine gewohnte Umgebung mit vorhersehbarem Verhalten existiert. Waren es bei der DOS-Version andere Mailboxsysteme, die als Vorbild dienten, so galt es bei der Linux-Portierung, möglichst viele der bisherigen Bedienungselemente exakt beizubehalten und nicht einzuschränken oder zu verändern.
Diese Zielvorgabe ist auch weitestgehend gelungen, so daß auf der Benutzerseite tatsächlich so gut wie keine Änderungen erkennbar sind. Dies gilt allerdings nur für den tatsächlichen ``Benutzer'' über Funk, Sysops haben mit sehr wesentlichen Unterschieden zu rechnen.
Soll eine bestehende BayCom-Mailbox unter Linux weiterbetrieben werden, so ist zunächst eine Vorbereitung der DOS-Dateien erforderlich, da dies nur unter DOS und nicht mehr unter Linux möglich ist. Der Grund liegt darin, daß unter Linux Strukturelemente nur an für den jeweiligen Typ ausgerichteten Adressen abgelegt werden, was unter DOS nicht der Fall ist. So ist bei allen Dateien, die direkt auf C-Strukturen aufsetzen, eine Konvertierung erforderlich. Dies erfolgt mit dem DOS-Hilfsprogramm BCM2LINU.EXE. Dieses Programm wird im BayCom-Mailbox-Verzeichnis aufgerufen und wird etwa 5-20 min laufen.
Folgende Dateien werden für die Anwendung unter Linux konvertiert:
USERS.BCM -> USERS3.BCM (HADR2.BCM -> HADR3.BCM)
Die Datei HADR3.BCM wurde in der Zwischenzeit durch HADR4.BCM ersetzt, diese Datei braucht nicht mehr konvertiert zu werden.
Die dazugehörigen Hashdateien bleiben dabei unverändert bzw. können ohnehin durch reorg neu erzeugt werden. Die BID-Datei ist nicht konvertierbar und muß unter Linux durch ``reorg f'' aus dem Datenbestand erzeugt werden.
Wichtig ist die Tatsache, daß die Dateien zur Umwandlung umkopiert werden und deshalb mindestens die Größe aller obengenannten Dateien als freier Plattenplatz zur Verfügung stehen muß.
Der nächste Schritt ist dann die Überführung aller vorhandenenen Daten (also komplettes BCM-Verzeichnis sowie USER und INFO-Verzeichnisbäume) von DOS nach Linux. Folgende Möglichkeiten sind denkbar:
Das BCM-Home Verzeichnis sollte unter /bcm angelegt werden. Hier werden alle Dateien der DOS-Version mit allen Unterverzeichnissen hineinkopiert. Selbstverständlich ist es sinnvoll, hierbei die rein DOS-spezifischen Dateien auszumisten. Die Verzeichnisse für die ``user''- und ``info''-Daten können in INIT.BCM frei gewählt werden. Werden mehrere Platten verwendet, so müssen hier sinnvolle Mountpunkte definiert werden. Es kann nicht im Rootverzeichnis von Platten oder Partitionen gearbeitet werden, da hier Linux das lost+found-Verzeichnis anlegt, was die Box durcheinander bringen kann. Es ist also notwendig, vom Mountpunkt stets ein Unterverzeichnis zu definieren. Die Pfade sollten jedoch nicht zu lang sein, da dies etwas die Performance mindert.
Sind alle Dateien umkopiert und die Pfade eingestellt, so kann die Box gestartet werden. Vor einem Zugriff über Funk sollten noch nacheinander ``reorg l'', ``reorg i'', ``reorg h'' und ``reorg f'' gemacht werden, um sicher zu sein daß alle Tabellen konsistent sind. Hinweis: Jeder Reorg muß abgewartet werden, ehe der nächste gestartet werden kann.
Die beiden Versionen unter DOS und Linux verhalten sich bezüglich Dateisystem so identisch wie nur möglich. Ein Fallstrick ist die Tatsache, daß bei UNIX Dateinamen üblicherweise kleingeschrieben werden, bei DOS ist GROSS-kleinschreibung egal und es wird dummerweise meist alles GROSS geschrieben. Das schafft Verwirrung und war auch in der Software nicht ganz einfach, zumal viele Dateinamen aus dem Zusammenhang automatisch erzeugt werden. Die Linux-BayCom-Mailbox verwendet ausschliesslich kleingeschriebene Dateinamen, egal wo sie auftauchen. Der Inhalt der Dateien ist jedoch stets identisch zur DOS-Version (auß bei BIDS3.BCM und USERS3.BCM), also sind dort Referenzen zu Dateinamen großgeschrieben.
Es darf (fast) überall die Folge CR-LF statt der UNIX-üblichen Folge LF in den Dateien vorkommen. Umgekehrt kommt auch die DOS-Version mit nur-LF aus. Ausnahme sind LIST und CHECK Dateien, diese müssen bei beiden Versionen stets mit CR-LF abgeschlossen sein. Diese werden jedoch üblicherweise nicht mit einem Editor bearbeitet und sind daher unproblematisch.
Wichtig ist, daß nach der Installation alle Dateien (auch das Verzeichnis selbst!) dem User ``bcm'' gehören müssen (siehe oben). Sicherheitshalber sollte also:
cd /bcm (Home-Verzeichnis der BCM)
cd ..
chown -R bcm:bcm bcm
chmod -R u+rw bcm
Für eine Anwendung wie eine PR-Mailbox ist Windows eigentlich kein allzu geeignetes Betriebssystem. Was die Vor- und Nachteile der einzelnen Systeme sind, sollte hier nicht diskutiert werden.
Tatsache ist, daß unter DOS nach wie vor nur die berühmten 640 kB Speicher vernünftig ansprechbar sind, und daß unter DOS kein besonders herausragendes Dateisystem zur Verfügung steht.
Windows NT hilft beiden Problemen ab. Es steht eine virtuelle Speicherverwaltung und ein neues Dateisystem NTFS zur Verfügung.
Es ist nicht zu verschweigen, daß technisch die Lösung für Linux die weitaus bessere ist. Linux ist ideal über Funk zu bedienen und hat insgesamt Eigenschaften, die geradezu ideal für einen Einsatz der BayCom-Mailbox sind. Linux hat eigentlich nur einen einzigen Nachteil. Wer sich nicht mit UNIX auskennt, braucht ein relativ grosses Grundwissen, um alle nötigen Kenntnisse zum Betrieb und zur Wartung eines Rechners zu haben. Windows ist hier ein wenig besser, vor allem ist das erforderliche Wissen etwas weiter gestreut. Dies ist die einzige Motivation, warum es die BayCom-Mailbox für Windows gibt. Es ist auch bei langem Nachdenken keine technische Begründung zu finden, warum Windows besser sein sollte als Linux, es ist eben nicht so. Da die Windows-NT Version der Mailbox nur wenig verbreitet ist, muß auch mit mehr bisher unentdeckten Fehlern als bei Linux gerechnet werden.
Klare Antwort: Nur Windows NT. BCM32.EXE läuft auch unter Windows 95/98/2000, wenn auch nicht besonders stabil. Das liegt mehr oder weniger daran, daß man ohne Aufwand eine für beide Systeme komptible EXE-Datei erzeugen kann. Zum Betrieb mit einer Mailbox scheidet Windows 95/98/2000 derzeit jedoch schon deshalb aus, weil es kein dem DOS überlegenes Dateisystem gibt. Solange dies noch so ist, ist kein wesentlicher Vorteil gegenüber DOS zu erwarten und es wird deshalb von der Anwendung abgeraten. Unter Windows NT ist ausschliesslich ein Betrieb mit NTFS-Dateisystem ratsam. Die BCM32 wurde unter Windows NT 4.0 mit Service Pack 5 entwickelt.
Die Windows NT-Version verhält sich sehr viel ähnlicher zur Linux- als zur DOS-Version. Das ist auch kein Wunder, da im 32 Bit-Mode vieles aus der DOS-Welt (z.B. Hardware- und BIOS-Zugriffe) nicht zur Verfügung steht, und auch z.B. die Speicherverwaltung eher vergleichbar mit Linux ist.
Im Unterschied zu DOS ist:
Alle Datenstrukturen sind kompatibel zur DOS-Version. Es muß nichts konvertiert werden.