\documentclass[a4paper]{article}

\usepackage[utf-8]{inputenc}
\usepackage[german]{babel}
\usepackage{url}
\usepackage{alltt}
\usepackage{multicol}

\title{Bootmanager und FAT-Reparatur: Erste Fort(h)schritte}
\ifx\shorttitle\undefined\else
\shorttitle{Bootmanager und FAT-Reparatur}
\fi
\author{Fred Behringer}

\begin{document}
\maketitle

\begin{multicols}{2}

Sie haben ein paar unüberlegte Experimente mit dem unseligen FDISK aus DOS, Version sowieso, gemacht, vielleicht sogar mit dem vielgepriesenen Parameter FDISK /MBR, oder etwa sogar aus Windows heraus, und plötzlich sehen Sie nur noch die Meldung \emph{Betriebssystem fehlt} --- egal, ob über Diskette oder HD gebootet. Was machen Sie? Vielleicht können Ihnen meine Vorüberlegungen aus dem vorliegenden Artikel weiterhelfen? Erste amateurhafte Schritte zwar, aber immer noch besser als das vergebliche Herumjonglieren mit allen möglichen und unmöglichen \emph{Reparaturprogrammen}. (Man möchte gern wissen, was passiert.)

In diesem Artikel werden 23 Forth--Worte entwickelt, die zeigen sollen, wie man sich in Forth \emph{ganz leicht} einen Bootmanager für den PC nach eigenem Geschmack einrichten kann (könnte). Zunächst wird an fünf in sich geschlossenen Beispielen die grundsätzliche Vorgehensweise besprochen. Dann werden im Listing die 23 entwickelten Forth--Worte aufgezeigt. Sie sind mit vielen $\backslash$--Kommentaren versehen. An das Listing schließt sich zum schnellen Zurechtfinden ein knapp gehaltenes Glossar (23 Zeilen) an. Und schließlich wird im Hauptteil des Textes der Hintergrund beleuchtet. Nur soweit, wie für die hier geschilderten allerersten Schritte nötig.

Es kann hier die Partitionstabelle aus dem MBR (\emph{master boot record}\/) angezeigt werden. (Dabei handelt es sich natürlich um den MBR der im BIOS eingestellten Boot--Festplatte.) Damit können alle wesentlichen Festplatten--Informationen ermittelt werden. Somit kann (auch) der momentane Boot--Zustand eingesehen werden. Es können beliebige primäre oder logische Partitionen versteckt oder sichtbar gemacht werden. Es können beliebige primäre Partitionen aktiviert oder deaktiviert werden. Ein dem Forth--Geübten leicht von der Hand gehendes bisschen High--Level--Forth würde sicher genügen, um aus diesen Bestandteilen einen menügeführten Bootmanager zu machen. (Ich unterdrücke mein Verlangen, das im Vorliegenden schon zu versuchen.) Allerdings zunächst nur über zwei Stufen: Erst (ein normalerweise über DOS aufgerufenes) Forth (mit dem per \texttt{INCLUDE} eingebundenen Programm \texttt{BOOTMAST.FTH}) laden und den Bootmanager auf das gewünschte Betriebssystem einstellen, dann den PC mit diesen Einstellungen rebooten. Wer hierbei einen Schritt einsparen will, der vergleiche den interessanten Artikel von Carsten Strotmann im VD--Heft 2/2006 [CS] über den Aufruf eines DOS--freien Forth--Systems schon unmittelbar nach dem BIOS--Boot--Durchgang.

Es können aber mit den hier gezeigten Mitteln auch schon einige Dinge in einen Forth--Puffer gelesen, verändert und wieder zurückgeschrieben werden, nämlich: Der MBR (\emph{master boot record}\/), die Bootsektoren der einzelnen Partitionen (auch der logischen Laufwerke der erweiterten Partition) und vor allen Dingen auch die Partitionstabellen (auch die der logischen Laufwerke!) .

Dazu sind keine Kunststücke nötig: In Forth geht alles! Allerdings sollte man sich bei alldem vorher natürlich genau überlegen, was man zu tun vorhat --- wenn man keine Daten verlieren möchte.

In den folgenden Beispielen wird die Verwendung der hier zu entwickelnden Forth--Worte demonstriert. Diese Worte werden in dem dann anschließenden Listing einzeln näher besprochen.
\end{multicols}

Beispiel 1: Anzeige und Änderung des MBRs

\begin{verbatim}
getmbr             \ MBR von HD in den Forth-Puffer schreiben
showsectbuf        \ Pufferinhalt auf dem Bildschirm anzeigen
cc xx sectbuf + c! \ Byte-Offset xx auf Byte cc setzen
putmbr             \ Puffer in den MBR der HD zurueckschreiben
\end{verbatim}

Beispiel 2: Partitionstabellen der erweiterten Partition

\begin{verbatim}
n getpart          \ laedt Tabelle des logischen Laufwerks n in den Puffer,
showsectbuf        \ zeigt sie am Bildschirm an (ggf. aendern wie bei BS 1),
n putpart          \ speichert Tabelle wieder zurueck.
\end{verbatim}

Beispiel 3: Reparatur der Adresskette der erweiterten Partition
\begin{verbatim}
0f getpart         \ ergab bei mir im Reparaturfall ab Offset 1be (Achtung,
                   \ little endian):
                   \ 80 01 C1 FF 06 FE FF FF 9E 99 07 00 D1 EB 03 00
                   \ 00 00 C1 F0 05 FE FF FF 70 B7 D7 00 50 99 07 00

10 getpart         \ ergab ab Offset 1be:
                   \ 80 01 C1 FF 06 FE FF FF 8E AD 03 00 D1 EB 03 00
                   \ 00 00 C1 FF 05 FE FF FF 80 A3 DB 00 20 D8 07 00

                   \ Das war (offensichtlich) falsch (Laufwerk S: (= 10) ist
                   \ bei mir das letzte logische Laufwerk unterhalb der
                   \ DOS-Grenze von 8 GB). Repariert habe ich zu:

                   \ 80 01 C1 E0 06 FE FF EF 3F 00 00 00 D1 EB 03 00
                   \ 00 00 C1 F0 05 FE FF FF 70 B7 D7 00 10 EC 03 00
                   \ und:
                   \ 80 01 C1 F0 06 FE FF FF 3F 00 00 00 D1 EB 03 00
                   \ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

                   \ Beide Gruppen wurden nach dem Muster von Beispiel 1 ueber
                   \ das Forth-Wort c! in den Puffer geschrieben. Der neue
                   \ sectbuf-Inhalt wurde dann ueber:
E0C1 putpart       \ und:
F0C1 putpart       \ zurückgeschrieben. F0C1 entspricht bei mir der
                   \ "Sektoradresse" des letzte logischen Laufwerks (S:) vor
                   \ der DOS-8GB-Grenze. Die erweiterte Partition geht noch
                   \ weiter und enthaelt bei mir noch Linux, aber DOS (und 
                   \ Win 3.11 und Win 95/98/ME) hoeren bei F0C1 mit ihrer Suche
                   \ auf (2. Zeile lauter Nullen). Aeusserste Vorsicht vor dem
                   \ "Putten" mit falschen "Sektoradressen" !!!

                   \ C1 F0 usw. (wegen little endian zu lesen als F0C1) enthaelt
                   \ die Spur und den Sektor. Weiteres zur Interpretation der
                   \ Kombination aus Spur und Sektor siehe Kommentar bei
                   \ (getsect) im Listing.

                   \ Offensichtlich ist die Eintragung bei Offset 1be nicht
                   \ kritisch: Man haette wohl 00 (statt 80) erwartet. Ich habe
                   \ mich bei der Reparatur an die analogen Stellen in den
                   \ Partitionstabellen der Laufwerke D: bis Q: gehalten.
\end{verbatim}


Beispiel 4: Haupt--Partitionstabelle

\begin{verbatim}
showparttab        \ Anzeige mit Erlaeuterungen und Ermittlung des Bootzustandes
                   \ Gegegebenenfalls im Sektorpuffer sectbuf nach eigenem Gusto
                   \ aendern und per putmbr (mit aeusserster Vorsicht!) auf die
                   \ Festplatte zurueckschreiben.
\end{verbatim}

Beispiel 5: Bootmanager auf Diskette
\begin{verbatim}
                   \ Als "Bootdiskette" rudimentaere DOS-Diskette einrichten:
                   \ Forth-System draufladen, BOOTMAST.FTH (siehe Listing)
                   \ hinzuladen, das Ganze ueber SAVE-SYSTEM als BOOT.COM (auf
                   \ Diskette) abspeichern.
                   \ Im BIOS zum Booten "1. Diskette, 2. HD" einstellen.
                   \ Booten (per Diskette): Am Prompt beispielsweise boot 3 boot
                   \ eingeben. DOS herunterfahren. Diskette herausnehmen. System
                   \ (jetzt per HD) neu starten. Die 3 (in boot 3 boot) bewirkt
                   \ auf meiner Anlage, dass dann Windows 98 (eingerichtet mit
                   \ FAT16) gebootet wird (dritte Zeile in der Partitionstabelle
                   \ des MBRs).

                   \ Ich glaube niemandem, nicht einmal mir selbst.
                   \ Professionellen Bootmanagern, mit Absicherungen gegen
                   \ Fehleingaben, will ich keine Konkurrenz machen. Ich moechte
                   \ lediglich wissen, was hinter den Kulissen geschieht. Eine
                   \ vorsichtige Vorgehensweise koennte wie folgt aussehen:

showparttab        \ MBR in den Puffer (nach sectbuf) holen. Partitionstabelle
                   \ auf dem Bildschirm anzeigen. OK? Ja, dann
n (bootpart)       \ Vorbereitung im MBR-Puffer auf das Booten der Partition n.
                   \ OK? Ja, dann gaaanz vorsichtig neuen MBR auf die Festplatte
                   \ schreiben:
n bootpart         \ HD ist jetzt zum Booten (der neuen Partition) vorbereitet.
[Reset-Knopf]      \ Wirksam werden lassen.

                   \ Ist man sich seiner Sache sicher, dann kann man natuerlich
                   \ auch gleich n bootpart eingeben.
\end{verbatim}

\section{Listing}


\begin{quote}
\listinginput[1]{1}{2008-03/bootmast.fth}
\end{quote}

\begin{multicols}{2}
\section{Hintergrund}

Das Ziel im Titel ist hochgesteckt, aber eigentlich ist es auch hier nur wieder der berühmte \emph{Weg, der das Ziel verkörpert}. Mit Forth im Rucksack traut man sich leicht auch auf den schwierigsten Weg --- dem Ziel entgegen.

An sich will ich hier den immer wieder zu hörenden Spruch \glqq In einem solchen Fall sind die Daten unrettbar verloren\grqq\  ad absurdum führen. Unüberlegtes Handeln kann aber doch auch im vorliegenden Artikel große Schwierigkeiten nach sich ziehen. Außerdem sind Fehler in meinen Überlegungen oder in den Programmen vorprogrammiert. Von blinden Experimenten, wobei die Betonung auf \emph{blind} liegt, rate ich also dringend ab. Es sind auch noch genügend Fragezeichen stehengeblieben, die auf eine endgültige Behandlung warten.

Nichts ist praktischer als eine gute Theorie. Aber auch die beste Theorie nützt wenig, wenn sie nicht an brauchbaren praktischen Beispielen erklärt wird.

Das allgegenwärtige \emph{praktische Beispiel} war bei mir ein zerschossenes Windows 98 auf dem PC unter FAT16 auf einem logischen Laufwerk von 1 GB in der erweiterten DOS--Partition. \glqq Zerschossen? Da geht überhaupt nichts mehr\grqq, hat man mir im Bekanntenkreis beschieden. Nun, ja! Es hat mich aber viel hartes Nachdenken, viel Nachschlagen und enorm viel Nerven gekostet. Genau besehen,
ist es eigentlich unsinnig, sich dermaßen stark in eine Aufgabe aus einem Themenbereich zu knien, den man durch die Beschäftigung mit der Aufgabe eigentlich erst erlernen möchte. \glqq Wozu?\grqq, war die Frage, die ich zu hören bekam. \glqq Dieses Problem haben doch andere schon längst bearbeitet. Man braucht ja nur im Internet oder in der Literatur zu suchen.\grqq\  Nun, ich betreibe Forth als Steckenpferd und bin daher gar nicht so unfroh darüber, \glqq dass es immer wieder was zu tun gibt\grqq . Ich habe sehr viel dabei gelernt. Vor allen Dingen habe ich gelernt, dass man nicht in Panik geraten und blindwütig alle verfügbaren \emph{Rettungssysteme} (von zum Teil fragwürdiger Herkunft) durchprobieren sollte. Zumindest dann nicht, wenn man sich voller Ungeduld noch keine Zeit gegönnt hat, die Beschreibungen ordentlich durchzulesen.

Es werden hier einige Forth--Worte für den Umgang mit der Hauptpartitionstabelle (dem MBR) und den Partitionstabellen und den Bootsektoren der logischen Laufwerke in der erweiterten Partition angegeben. Es werden nur die Verhältnisse bei FAT16 besprochen. Und schließlich wird ein Forth--Wort entwickelt, das man als Bootmanager verwenden kann, ein Bootmanager, den man mit Forth--Mitteln ganz leicht den eigenen Bedürfnissen und Erwartungen anpassen kann. Die eigentliche
DOS--Dateiorganisation, die Dateizuordnungstabellen und alles, was zur FAT16--\emph{Reparatur} nötig ist, soll einem späteren Bericht vorbehalten bleiben.

Weiter unten gebe ich einiges FAT16--Relevantes aus der sehr lesenswerten kurzen und prägnanten Zusammenfassung von Anton Zechner [AZ] wieder. (Fehler infolge von Änderungen des Textes gehen zu meinen Lasten.)

DOS und ähnliche Betriebssysteme können nur von primären Partitionen booten (die im Byte mit Offset 1be + n*10h (n = Partition) den Hexwert 80 (erste Festplatte, zweite = 81 usw.)) eingetragen haben müssen. Alle übrigen primären Partitionen müssen versteckt werden. Einige Betriebssysteme werden zum Verstecken mit einer 1 im höherwertigen Nibble unter Offset 1c2 (+ n*10h, n=0..3) versehen. Das gilt für das hier Gesagte, aber nicht für alle denkbaren Betriebssysteme. Im vorliegenden Artikel werden über die Forth--Worte hidepart und unhidepart nur
solche Betriebssysteme berücksichtigt, die eine 1 (für versteckt) oder 0 (für sichtbar) im höherwertigen Nibble verwenden.

Das fürs Booten von Windows 98 nötige DOS (bei mir DOS 6.2) liegt natürlich (fürs Dual--Boot--Verfahren) auf einer kleinen primären FAT16--Partition. Als Bootmanager verwendete ich bisher XFDISK von Florian Painke und Ulrich Müller [PM]. Für die Reparaturarbeiten hat es sich gut gemacht, dass der Hauptteil des Windows--98--Systems auf einem logischen Laufwerk liegt: Ich kann so von überall her (Windows 95, Windows ME, Linux 9.1, FreeDOS, DOS 7.0, DOS 8.0) darauf
zugreifen. Hätte mein zerschossenes Windows 98 vollständig auf einer primären Partition gelegen, dann hätte ich diese Partition \emph{verstecken} müssen und hätte (beim Booten von einer anderen primären HD--Partition aus) keinen Zugriff mehr darauf.

An der hier zu besprechenden Computer--Anlage arbeite ich gern. Sie ist meine einzige (betriebsbereite) Anlage mit ISA--Slots für meine Transputer--Karten. (Und ein ZIP--Laufwerk habe ich dort auch noch zur Verfügung, was bei meinen anderen Anlagen nicht mehr der Fall ist.)

Die reparaturbedürftige Situation stellte sich wie folgt dar:

Beide Dateizuordnungstabellen (FAT16) von Windows 98 waren vollständig gelöscht (auf 0 gesetzt). Wahrscheinlich war \texttt{SCANDISK} von mir, nachdem es wieder mal unerwünscht losgerattert war, per Reset--Knopf am ordnungsgemäßen Zuendeführen seiner Arbeit gehindert worden.

Die Verzeichnisse und Unterverzeichnisse waren (in den FATs) fast alle als gelöscht markiert (im ersten Buchstaben ihres Namens mit einem E5h versehen) worden.

Die Dateien waren teils als gelöscht gekennzeichnet, teils nicht.

Ich hatte (und habe noch) im Netscape Navigator unter Windows 98 etwa 82 Megabyte an älteren empfangenen E--Mails und etwa 32 Megabyte an gesendeten E--Mails (mit Anhängen!) zu liegen, auf die ich nur ungern verzichten wollte. Eigenartigerweise war (fast) keine Datei wirklich angegriffen worden. Aber von einer Inbox-- oder Sent--Sammeldatei des Netscape Navigators erwartet man natürlich nicht, dass sie nicht defragmentiert ist. Und das manuelle Zusammenstückeln der einzelnen Cluster ist eine Heidenarbeit. Um es gleich zu sagen, diese Arbeit habe ich noch nicht zum Abschluss bringen können.

Meine ersten Reparaturversuche waren:

Eine Analyse mit dem Partition--Manager von Mikhail Ranish [MR]. Dabei muss ich etwas falsch gemacht haben: Die Organisation der ersten primären Partition (nicht die Dateien selbst, nur die Grenzen von Bootsektor, FAT1, FAT2, Root--Directory und Datenbereich) wurden um genau einen Cluster (16 KB = 32 Sektoren) nach höheren HD--Speicherwerten hin verschoben. Es dauerte einige Zeit, bis ich verstand, dass das Wiedereinsetzen des ursprünglichen Bootsektors den Fall behoben hätte. Und noch länger hat es gedauert, bis ich dahinterkam, dass das mit einem ganz kleinen Eingriff in den Datenteil des Bootsektors (hier der ersten primären Partition) wieder hätte hingebogen werden können. Irgendwo habe ich in der Zwischenzeit gelesen, dass sich der Ranish--Partition--Manager [RP] in den freigeschaufelten Platz (in der ersten primären Partition) einnistet. Beinahe hätte ich wegen meiner anfänglichen Unwissenheit deswegen das zu Windows 95 führende DOS--System (der ersten primären Partition) aufgegeben. (Ich hasse Neuinstallationen an einem organisch gewachsenen System.)

Als Hilfsmittel für den sektorweisen Festplattenzugriff stand mir der Diskeditor DISKEDIT (ver 1.2) von Martin Kalisch [MK] (1992) zur Verfügung. Für das Auslesen (in eine Datei) und das Wiedereinlesen der Bootsektoren (nur der primären Partitionen) und des MBRs verwendete ich anfangs das Programm SSI.COM aus dem \emph{PC--Festplattenbuch} von Michael Thieser und Andreas Finkler [TF] (Markt\&Technik 1996). (Bemerkung eines gutmeinenden Computerfreundes: \glqq Was heißt hier Bootsektoren? Von Laufwerken der erweiterten Partition kann man nicht booten.\grqq\  Nun ja, jedem seine Meinung!) Natürlich hätte man die Bootsektoren, auch die der erweiterten Partition, genauso gut auch nach dem Schema \texttt{DEBUG -l 200 2 0 1 d 200} auslesen können. Aber woher die Daten für die
Bootsektoren--Kette der aufeinanderfolgenden logischen Laufwerke (in der erweiterten Partition) nehmen? Und der MBR (mit der Haupt--Partitionstabelle) lässt sich wohl ohnehin nicht mit \texttt{DEBUG} (direkt) auslesen? Und woher die Partitionstabellen der gesamten Kette von logischen Laufwerken nehmen?

Und überhaupt: Warum soll man seine Zeit übermäßig mit dem Herumsuchen nach Programmen anderer Autoren verbringen (bei denen man meistens doch nicht genau herausbekommt, was sie eigentlich tun), wenn man sich die Dinge \emph{ganz schnell} auch selbst machen kann? Forth macht's möglich --- und es sollte hier ein erster Versuch dazu unternommen werden. Mit dem sprichwörtlichen Rad, das da nicht immer wieder neu erfunden zu werden braucht, hat das nur bedingt etwas zu tun. Mit \emph{Learning by doing} schon eher. Es soll hier nicht über Weltneuheiten berichtet werden, sondern über anfangs vergebliche Versuche eines neugierigen Forth--Hobbyisten. Im Übrigen halte ich mich gern an Rafael Deliano, der sich im VD--Heft 1/2008 wiederum auf Charles Moore bezieht, welchen man sinngemäß mit den Worten zitieren kann: \glqq Gebt mir nur die Idee, und ich programmiere mir den Rest
selbst --- in Forth.\grqq 

PCTOOLS kann beim Wiedereinbringen von gelöschten Dateien helfen, zumindest bei nicht fragmentierten. Beim Versuch, auch gelöschte Verzeichnisse zu reparieren, kam aber laufend die Meldung \emph{Sector not found} heraus. Das war für mich nicht sehr hilfreich. Und in Bezug auf PCTOOLS--Unterlagen musste ich zu mir selbst sagen: \emph{Manuals not found} --- oder \emph{Manuals überhaupt nie gehabt}.

Zu allem Überfluss wurden bei den Versuchen mit Reparaturprogrammen (ich glaube, es war \texttt{TESTDISK}) auch noch die Laufwerke R: und S: (die letzten in der Kette der Laufwerke der erweiterten Partition vor der von DOS geforderten 8GB--Grenze) zu einem einzigen Laufwerk \emph{zusammengelegt} --- mit verheerenden Folgen, was die Partitions--Tabellen--Ketten--Parameter betrifft. Und außerden wollte ich die in \texttt{R:} und \texttt{S:} angehäuften vielen schönen Programme nicht verlieren. (Mit den im
vorliegenden Artikel entwickelten Forth--Werkzeugen konnte ich das Problem schnellsten geradebiegen --- siehe Beispiel 3.) Außerdem wollte ich das dann auf meiner Festplatte noch folgende SuSE--Linux 9.1 (5 GB \emph{ganz hinten} in der erweiterten Partition) nicht leichtfertig durch Neuformatierungen an anderer Stelle der erweiterten Partition aufs Spiel setzen. Der FAT16--Teil vor der 8GB--Grenze (der erweiterten Partition) wird bei mir per \texttt{XFDISK /nowin9x} auf die Kennung 5 gesetzt und dadurch auch für DOS zugänglich gehalten, nicht nur beispielsweise für Windows ME (das bei mir auf einer primären Partition mit FAT32 \emph{ganz weit hinten} liegt).

All diese Erkenntnisse und Überlegungen haben mich dazu geführt, mir die Hilfsmittel für das Operieren an der Dateisystem--Verwaltung selbst zu machen --- es zumindest zu versuchen. Ohne Brimborium, nur das Nötigste, zielgerichtet in einer Sammlung kleinerer Hilfsbausteine, in Form von Forth--Worten, die nach Belieben in ein größeres Forth--Umfeld eingebaut werden könnten. Forth macht's möglich.

Ich habe mich im vorliegenden Artikel fürs Erste auf den MBR (\emph{master boot record}\/) und darin auf die Hauptpartitionstabelle und dann auch noch auf die Partitionstabellen (\emph{partition tables}\/) der erweiterten Partition konzentriert. Die Bootsektoren und das gezielte Lesen, Ändern und Schreiben (in Forth) von FAT16--Verzeichnissen und --Datensektoren behalte ich mir für später vor.

Als Nebenprodukt stelle ich mit dem vorliegenden Artikel einen voll (\glqq na ja\grqq ) funktionsfähigen Bootmanager zur Verfügung, der von Forth unter DOS auf Festplatte oder Diskette aus operiert und weder installiert noch deinstalliert zu werden braucht. Bootmanager gibt es \emph{wie Sand am Meer}. Etwa fünf der gebräuchlichsten liegen zur unmittelbaren Benutzung auf der sehr empfehlenswerten \emph{Ultimate Boot--CD 3.4} [UB]. Ich traue jedoch (siehe oben) keinem Bootmanager mehr -- es sei denn, ich habe ihn selbst vermurkst.

Die Vorgehensweise ist wie folgt: Man lade DOS. Am einfachsten über eine Diskette. Will man DOS von einem HD--Laufwerk aus laden, muss man sich zur Organisation etwas einfallen lassen. Das ist ein gesondertes Thema, das für das hier Gesagte nicht unbedingt lebensnotwendig ist. Vom geladenen DOS aus rufe man Forth mit dem hier besprochenen Paket von Forth--Worten auf, stelle die
Festplatte per n Bootpart auf das einzuladende Betriebssystem n um und boote neu (\emph{Affengriff} oder Reset--Knopf). An Umständlichkeit mutet das dem Benutzer auch nicht mehr zu als das (von mir immer noch gern praktizierte) Booten von Linux per \texttt{LOADLIN} von DOS aus.

Wenn man so will, kann man daraus auch per \texttt{SAVE-SYSTEM} eine eigenständige COM--Datei machen --- und vergessen, dass man Forth zum Booten missbraucht. Vielleicht kann das als eine Ergänzung zu dem von Carsten Strotmann [CS] Gesagten betrachtet werden. Carsten erwähnt in seinem interessanten Artikel aus dem VD--Heft 2/2006 (über Forth am Stick) das Programm von Alexei Frounze (Russland 2000), das sich (ähnlich wie der weiter unten auch zu erwähnende Ranish--Partition--Manager) in den von DOS und fast allen anderen Betriebssystemen ungenutzten ersten Sektoren (auf Seite 0) einklinkt und ein (von DOS--Zugriffen gesäubertes) Forth--System zum Booten verwendungsfähig macht. Carsten erwähnt weiter, dass man das bootende Forth--Rumpfsystem mit den von Alexei Frounze bereitgestellten Mitteln auch als COM-- oder EXE--Datei schon ganz am Anfang (noch vor dem sonst üblichen vom System aufgerufenen DOS) aufrufen und sich das Einbauen in die ungenutzten Sektoren sparen kann. Das eigentliche Booten geschieht dann also aus einem schon bereitliegenden Dateisystem heraus.

Das im vorliegenden Artikel beschriebene Boot--Forth braucht nicht DOS--frei zu sein. Es setzt hinter dem schon in den Computer geladenen DOS an --- so, wie ich es auch bei SuSE--Linux 9.1 beim Booten durch Aufruf von \texttt{LOADLIN} aus DOS heraus mache.

Zur Entwicklung habe ich Turbo--Forth (in der 16--Bit--Version) von Marc Petremann [MP1--3] verwendet. Die von mir im hiesigen Listing eingesetzte Assembler--Notation aus Turbo--Forth stimmt (wie ich nachgeprüft habe) mit der aus ZF überein. Mit anderen Worten, das vorliegende Programmpaket läuft auch unter ZF (von Tom Zimmer) --- wenn man das ganz am Anfang des vorliegenden Artikels über \texttt{ATTRIBUTS} Gesagte beachtet.

Unter Windows 3.11/95/98/ME kann das Turbo--Forth--System ohne Schwierigkeiten aufgerufen werden und das hier entwickelte Forth--Programm--Paket arbeitet bestens. Das Ganze funktioniert auch unter FreeDOS. (Auf ein nicht wirksam werdendes \texttt{ANSI.SYS} in der \texttt{CONFIG.SYS} kann man verzichten, indem man in Turbo--Forth \texttt{attributs off} schaltet.)

Ein Abstecher zu XP: Windows XP erlaubt \emph{keinen direkten Zugriff auf die Festplatte}. Man hat die Möglichkeit, diese Einschränkung zu \emph{ignorieren}. Dann kommen aber beispielsweise bei \texttt{showparttab} auf dem Bildschirm lauter Nullen heraus. Turbo--Forth und die hier entwickelten Forth--Programme sind für den reinen DOS--Betrieb gedacht. Aber auch XP--Systeme beziehen ihre Boot--up--Daten über die Partitionstabelle im MBR. Um mir absolute Gewissheit zu verschaffen, habe ich \emph{mal schnell} an einer XP--Maschine nachgeprüft, dass ich per USB--Diskette oder über ein \emph{normales} Diskettenlaufwerk oder mit FreeDos unter KNOPPIX auf Live--CD das mich störende XP umgehen kann. Das geht, wie erwartet, gut.

Im schon erwähnten Artikel (Forth am Stil --- Teil 1) von Carsten Strotmann aus dem VD--Heft 2/2006 [CS] wird Weiteres zum Thema \emph{Einbau von Forth ohne DOS in den Bootprozess} angekündigt. Ich bin gespannt.

An dieser Stelle steht bei den Autoren, die sich mit solchen und ähnlichen Fragen beschäftigen, üblicherweise die Bemerkung, dass die vorgeschlagenen Operationen \emph{äußerst systemgefährdend} seien. Nun ja, man kann sich ja beispielsweise den MBR vor jeder Veränderungsabsicht sicherheitshalber per \texttt{getmbr showsectbuf} (siehe Listing) anzeigen lassen und ihn mit Forth--Mitteln ganz leicht und bequem durch Abspeichern des Inhalts von \texttt{sectbuf} in eine Datei \emph{sichern}.

Wie habe ich eigentlich die Entwicklung auf einem System erledigt, das dabei den XFDISK als Bootmanager verwendet, wobei ich von XFDISK auch bei den Entwicklungsarbeiten nicht lockerlassen wollte? Zunächst einmal habe ich beim Ausprobieren alle schreibenden Zugriffe auf die Festplatte ausgeklammert. Insbesondere habe ich (\texttt{putsect}) \texttt{putmbr} \texttt{putpart} \texttt{bootpart} fürs Erste vermieden.

Ansonsten deinstalliere man vom XFDISK--Bootmanager--Menü aus eben diesen Bootmanager--Teil. Das \emph{Retten} der XFDISK--Menü--Einstellungen in eine Datei \texttt{CONFIG.XCF} ist dabei hilfreich. Nach Erledigung der vorzunehmenden Überprüfungen (\texttt{getmbr}, abändern, \texttt{putmbr} usw.) kann man dann den XFDISK--Bootmanager (unter Einbeziehung von \texttt{CONFIG.XCF}) wieder neu installieren.

Zu guter (Vor--)Letzt noch eine Schwierigkeit, bei welcher ich für Hinweise aus der Leserschaft dankbar wäre: Alles bisher Gesagte ist für ein Arbeiten mit FAT16 gedacht und funktioniert bestens. Bei mir bezieht sich der Kern der Überlegung auf das \emph{externe} Umschalten des Bootverhaltens des Computers von Windows 95 zu Windows 98 (und zurück) unter Einbeziehung von DOS 6.2 und Windows 3.11 nebst den logischen Laufwerken \texttt{D:} bis \texttt{S:} der erweiterten Partition. Der gesamte unter FAT16 anerkannte Teil der erweiterten Partition liegt unterhalb von 8 Gigabyte. Im oberen Teil der erweiterten Partition liegt SuSE--Linux 9.1. Das rufe ich per LOADLIN von DOS aus auf. \emph{Ganz hinten} auf der Festplatte (XFDISK macht's möglich) liegt Windows ME auf einer weiteren primären Partition. Die aber habe ich unter FAT32 eingerichtet. In den Bootmanager von XFDISK lässt sich ME prima einbinden und von dort aus kann es ohne Schwierigkeiten aufgerufen werden --- auch wenn der Bootmanager von XFDISK für die Zeit des Ausprobierens deinstalliert und später wieder installiert wurde. Mit den im vorliegenden Artikel beschriebenen Hilfsmitteln (außerhalb von XFDISK, per n bootpart) kann ME (bei mir wenigsten) jedoch nicht gebootet werden. Ich habe es an einer anderen, ähnlich eingerichteten Anlage noch einmal versucht --- mit demselben
Misserfolg. Und schließlich habe ich an einer dritten experimentellen Anlage Windows 98 (natürlich nicht auf DOS 6.2 aufgesetzt) auf einer primären Partition unter FAT32 eingerichtet: Auch dieses Windows 98 ließ sich mit den Mitteln aus dem vorliegenden Artikel nicht booten. Der Bootmanager von XFDISK schafft das dagegen wunderbar. Was macht der Bootmanager von XFDISK, das ich mit meinen Überlegungen (noch) nicht schaffe? Spielt außer dem MBR auch noch der Bootsektor hinein? Habe ich bei meinen \emph{Reparaturen} etwas übersehen? Aber mein Reparaturfall bezog sich ja nur auf eine einzige von mehreren daraufhin untersuchten Anlagen!

Die MBR--Eintragungen im zuletzt erwähnten Experiment unter \emph{Erster Kopf, erster Zylinder, erster Sektor} waren sowohl bei Windows 98 wie auch bei Windows ME dieselben, nämlich \texttt{00 C1 FF} . Nebenbei gesagt, zeigten auch zwei XP--Anlagen (unter NTFS mit der Kennung \texttt{07}) eben diese Eintragungen, nämlich \texttt{00 C1 FF} . Als Untersuchungsgegenstände habe ich mir zum \emph{Lüften dieser Geheimnisse} für demnächst Folgendes vorgenommen: Erweiterter Interrupt 13, FAT32, LBA statt CHS, Festplatten--Geometrie, Einbeziehung des Bootsektors.

Überflüssig zu erwähnen, dass alle hier beschriebenen Vorgänge beliebig automatisiert und menügesteuert eingerichtet werden können. Außerdem können wir als Forth--Nutzer Parameter--Eingaben auch ganz unkompliziert einfach im Quelltext vornehmen. Der muss ja sowieso vom Forth--Compiler übersetzt werden.

Alexei Frounze [AF] verwendet MSDOS 6.22 und Windows 95. Ich befinde mich also in guter Gesellschaft und brauche mich nicht zu scheuen, nicht über XP, Vista und die allerneuesten MS--Erzeugnisse zu sprechen. Aber auch Linux in den allerneuesten Versionen und Zusammenstellungen (\emph{distributions}) kann für meine Experimente außer Acht gelassen werden. A. Frounze fragt: Where do I get these compilers and assemblers from? Für mich war eine solche Frage schon immer
gegenstandslos: Ich habe Forth. Zu Forth gehört normalerweise ein Assembler. Und wenn mir der nicht reicht, feile ich ihn mir einfach weiter zurecht. Keine große Systemveränderung! Einfach nur ein Vorspann zum sowieso einzuladenden Forth--Programm. Und experimentiere ich ausnahmsweise mal mit einem Forth--System, das keinen Assembler eingebaut hat, dann kann ich mir ja ganz leicht Hex--Zahlen als \emph{Inline--Code} einbauen. Unter Forth geht alles! Ein bisschen Nachschlagen in den Assembler--Befehlslisten tut nicht weh, und bei Julian Noble ([JN1],[JN2]) steht beispielsweise, wie man den \emph{Inline--Einbau} von Hexzahlen automatisieren und gegen Fehleingaben absichern kann.)


\section{Das FAT--16--Dateiformat}

Festplatten beginnen mit dem MBR auf Kopf 0, Zylinder 0 und Sektor 1.
Der MBR enthält ein kleines Programm, das den Bootprozess einleitet.
Für den vorliegenden Artikel wichtig ist die Partitionstabelle im MBR.
Auch jedes Laufwerk in der erweiterten Partition hat eine Partitionstabelle!
Auch diese Tabellen sind wichtig.
Über die Bootsektoren soll in einem späteren Artikel berichtet werden.

Der MBR hat folgenden Aufbau (Angaben hexadezimal):

\begin{small}
\begin{verbatim}
Offset  Größe      Funktion
   000  1BE Bytes  1. Stufe des Bootcodes
   1BE   10 Bytes  1. Eintrag in der Partitionstabelle
   1CE   10 Bytes  2. Eintrag in der Partitionstabelle
   1DE   10 Bytes  3. Eintrag in der Partitionstabelle
   1EE   10 Bytes  4. Eintrag in der Partitionstabelle
   1FE    2 Bytes  Signatur 55 AA
\end{verbatim}
\end{small}

Die Partitionstabelleneinträge haben folgenden Aufbau (Auszug aus [TF]):

\begin{small}
\begin{verbatim}
Offset Größe   Funktion
    00 1 Byte  80: bootfähig 
               00: nicht bootfähig  
               81: 2. Festplatte usw.
    01 1 Byte  Startkopf der Partition (0 bis n)
    02 1 Byte  Bit 0-5 Startsektor (1-63) 
               Bit 6-7 = 8-9 vom Startzylinder
    03 1 Byte  Startzylinder (0-1023)
    04 1 Byte  OS-Typ:
               01 = FAT12
               04 = FAT16 (max. 32 MB)
               05 = erweiterte DOS-Partition
               06 = FAT16 (max. 2 GB)
               07 = HPFS/NTFS
               0A = OS/2-Bootmanager
               0B = FAT32 (CHS-Adressierung)
               0C = FAT32 (LBA-Adressierung)
               0E = FAT16 (LBA-Adressierung)
               0F = erweiterte Partition (LBA, 
                    mehr als 1024 Zylinder)
               11 = versteckt FAT12
               14 = versteckt FAT16 bis 32MB
               16 = versteckt FAT16
               17 = versteckt HPFS / NTFS
               1B = versteckt WIN95 FAT32
               1C = versteckt WIN95 FAT32 (LBA)
               1E = versteckt WIN95 FAT16 (LBA)
               3C = Partition Magic
               50 = OnTrack DM
               52 = CP/M
               81 = Booten von Laufwerk D: (?)
               82 = Linux Swap
               83 = Linux native
               84 = OS/2 versteckt C:
               86 = NTFS volume set
               87 = NTFS volume set
               9F = BSD/OS
               A6 = Open BSD
               C1 = DRDOS/sec (FAT32)
               C4 = DRDOS/sec (FAT32(LBA))
               C6 = DRDOS/sec (FAT16(LBA))
               EB = BeOS fs
               EE = EFI GPT
               EF = EFI (FAT12/16/32)
    05 1 Byte  Endkopf der Partition (0 bis n)
    06 1 Byte  Bit 0-5 Endsektor (1 bis 63) 
               Bit 6-7 = 8-9 vom Endzylinder
    07 1 Byte  Endzylinder (0 bis 1023)
    08 4 Bytes Anfangssektor der Partitionsdaten 
               (absoluter LBA)
    0C 4 Bytes Größe der Partition in Sektoren
Offset Größe   Funktion
\end{verbatim}
\end{small}

Die LBA--Adressierung (\emph{large block array}\/) ist für Festplatten mit mehr als 1024 Zylindern vorgesehen, bei weniger Zylindern kann weiter die CHS--Adressierung verwendet werden (\emph{cylinder head sector}\/). Bei der LBA--Adressierung wird statt Kopf, Zylinder, Sektor ein 32--Bit--DWORT--Wert für die Sektor--Adressierung verwendet.

Aus den Partitionsdaten kann die Position und Größe der logischen Laufwerke ermittelt werden. Dazu dienen die DWORD--Werte bei Offset \texttt{08} und \texttt{0C}. Handelt es sich bei der Partition um eine \emph{erweiterte Partition}, so ist diese kein logisches Laufwerk, sondern eine weitere Unterpartition mit einem weiteren Master--Boot--Record (Partitionstabelle). Zu allen Positionen der LBAs ist der Anfangssektor der erweiterten Partition hinzuzuzählen (relative Angaben).

\section{Aufbau einer Partition}

Am Anfang jeder FAT16--Partition eines logischen Laufwerkes steht der Boot--Sektor. Er enthält Angaben über die Größe und Art der Partition. Anschließend kommt ein Bereich mit reservierten Sektoren. Diese können auch eine Kopie des Bootsektors enthalten. Danach kommen die FAT--Sektoren. Um eine höhere Sicherheit zu erhalten, werden meist zwei FAT--Tabellen verwendet, für den Fall, dass eine davon beschädigt wird. Die FAT--Tabellen enthalten Informationen über die Cluster--Ketten, die in den einzelnen Dateien gespeichert sind. Nach den FATs folgt das Rootverzeichnis. Es enthält alle Dateien, die im Hauptverzeichnis stehen. (Bei FAT32--Partitionen ist kein Rootverzeichnis vorhanden, es ist durch eine Cluster--Kette ersetzt, deren Anfang im Boot--Sektor steht.) Zuletzt kommen die Datensektoren. Der Bereich ist in einzelne Cluster unterteilt. Jeder Cluster besteht aus ein oder mehreren Sektoren. Der erste Cluster hat die Nummer 2 und beginnt beim ersten Datensektor.

Vor dem immer wieder zitierten \emph{Anfang} eines logischen Laufwerks einer FAT--Partition steht (auf Seite 0) die zugehörige Partitionstabelle.


\section{Der Boot--Sektor}

und alles damit Zusammenhängende soll in einem späteren Artikel besprochen werden.


\end{multicols}

\section{Andere Disk--Editoren}

\begin{tabular}{p{7mm}p{15cm}}
{}[CW] & CWDSKEDT (CW--Diskedit) 2.22 (1997--99) Christoph Walter. Freeware, DOS mit
     Mausunterstützung. Ohne eingeschalteten Maustreiber geht nichts. Gute
     Partitionstypen--Liste.\\
{}[MK] & DISKEDIT 1.2 von Martin Kalisch (1992). DOS oder auch Windows (DOS--Box).\\
\end{tabular}

\section{Andere Bootmanager}

\begin{tabular}{p{7mm}p{15cm}}
{}[ZS] &DocsBoot+ 0.25ß. 1994 Zac Schroff. Residiert in Spur 0.\\
{}[UB] &Ultimate Boot--CD 3.4. Begleit--CD zu PC--Professionell 9/2006.\\
{}[PM] &XFDISK. Florian Painke und Ulrich Müller.\\
{}[  ] &Kalle Gerwien: Retter in der Not --- GRUB--Boot--Diskette erstellen.
     easyLINUX 11/2004, S.74--76.\\
\end{tabular}


\section{Literatur und Internet--Adressen}

\begin{tabular}{p{7mm}p{15cm}}
{}[AZ] &\url{members.inode.at/anton.zechner/az/FatFormat.htm}\\
{}[TF] &Michael Thieser und Andreas Finkler: PC--Festplattenbuch, Markt\&Technik--
     Verlag 1996.\\
{}[MR] &Ranish Partition Manager liegt u.a. auch  auf der Ultimate Boot--CD 3.4 .
     \url{http://www.ultimatebootcd.com/}\\
{}[CS] &Carsten Strotmann: Forth am Stil. VD--Heft 2/2006.\\
{}[AF] &Alexei Frounze. E--Mail: alexfru@chat.ru. Homepage: \url{http://alexfru.chat.ru}.\\
&     Mirror: \url{http://members.xoom.com/alexfru} . Das Programmpaket von A.F. findet
     sich unter dem Namen BOOTPROG im PC--WELT--Sonderheft 1/2000. Von FAT32 ist
     bei A.F. nicht die Rede. Es geht nur um FAT12 (Floppy) und FAT16
     (Festplatte).\\
{}[JN1] &Julian Noble: A Call to Assembly 1--3. Forthwrite 113--115 (September 2001,
     November 2001, Januar 2002). Der besagte Micro--Mini--Assembler steht im
     zweiten Teil der Artikelfolge des Autors.\\
{}[JN2] &Julian Noble: Ein Assembl(i)eraufruf 1--3. Vierte Dimension 2--4/2002.
     Übersetzung der Artikelfolge des Autors aus der Forthwrite. Übersetzer:
     Fred Behringer.\\
{}[MP1] &Marc Petremann e.a.: Manuel de référence de Forth--83--standard. 1987.\\
{}[MP2] &Marc Petremann e.a.: Turbo--Forth --- Manuel d'apprentissage. Paris 1990.\\
{}[MP3] &Marc Petremann e.a.: Turbo--Forth --- Guide de référence. Paris 1990.\\
\end{tabular}
\bigskip

%\section{Listing}

%\listinginput[1]{1}{2008-03/bootmast.fth}
\hfil\includegraphics[width=0.7\textwidth]{2008-03/showparttab}
\end{document}