Betriebssysteme I - Entwicklungsumgebung Windows aufsetzen.

Schritt 0: Vorwort

ACHTUNG:
Es wird kein Unterstützung für Windows gewährt! Jeder der unter Windows entwickeln möchte muss seine Probleme selber lösen. Es wird dringend empfohlen unter Linux/Solaris zu entwickeln. Für alle, die dennoch Windows verwenden wollen, bietet diese Anleitung eine Orientierung einer möglichen Einrichtung der Entwicklungsumgebung unter Windows. Es wird nicht garantiert, dass die Befolgung dieser Anleitung zwangsweise zum Ziel führt.

Eine nicht funktionierende Entwicklungsumgebung ist keine Ausrede, warum eine Aufgabe nicht rechtzeitig abgegeben werden konnte.
Die Verwendung dieser Anleitung geschieht auf eigene Gefahr, bestimmte Schritte können in seltenen Fällen das System (Windows) zerstören bzw. unbrauchbar machen.

Es gibt viele Möglichkeiten auch unter Windows ein Betriebssystem zu entwickeln. Aufgrund der Vorgaben für den GNU-C-Compiler wurde sich für eine Kombination von Cygwin, Doxygen, QEMU und Visual Studio 2010 entschieden. Eine Alternative zu Cygwin bietet MinGW.
Diese Anleitung wurde unter Windows 7 Professional 64 Bit, mit Visual Studio 2010 Ultimate - beides mittels MSDNAA für FIN-Studenten kostenlos zu erhalten - vom 14.08. bis 21.09.2011 herum mit den neusten Versionen von Cygwin, Doxygen, Graphviz, QEMU und Syslinux entwickelt und getestet.

Schritt 1: Cygwin

Unter http://cygwin.com/install.html kann die Installationsroutine herunter geladen werden. Diese bietet lediglich ein Interface, in dem die gewollten Pakete ausgewählt werden. Diese werden dann aus dem Internet herunter geladen und installiert.
Nachdem die Routine heruntergeladen wurde, muss sie ausgeführt werden. Dabei ist es u.U. erforderlich, der Anwendung Administratorrechte zu erlauben (Windows Vista/Windows 7). Im Anschluss werden sich die Informationen durchgelesen und zweimal "Weiter" betätigt. Nun gilt es den Installationsort auszuwählen, es wird einer ohne Leerzeichen im Pfad empfohlen, in dieser Anleitung wird "F:\Programme\CygWin\" verwendet. Danach "Weiter" klicken und dann den Ort auswählen, in dem die aus dem Internet heruntergeladenen Dateien zwischengespeichert werden sollen. Abschließend wird dieser mit "Weiter" festgelegt. Im folgenden Dialog wird eine Direktverbindung zum Herunterladen ausgewählt. Nach einem weiteren Klick auf "Weiter" werden kurz Dateien aus dem Internet geladen und dann eine Liste mit Mirror-Servern angeboten. Hier muss einer ausgewählt werden und dieser erneut mit "Weiter" betätigt werden. Nun werden einige Grunddateien aus dem Internet herunter geladen. Es kann dabei eine Meldung auftauchen, dass dies eine Installation ist und eine bereits installierte Version beeinflussen könnte. Dies kann mit "OK" bestätigt werden.
Es folgt ein Menü mit der Auswahl der zu installierenden Pakete, gemäß der Linux-Umgebung werden folgende Pakete benötigt und sollten ausgewählt werden (per Klick auf "Skip"):

          unter "Devel"
            binutils
            gcc4 (Version 4.5.3 oder höher)
            gcc4-core (Version 4.5.3 oder höher)
            gcc4-g++ (Version 4.5.3 oder höher)
            gdb
            make
            patchutils

Es sollten keine Pakete abgewählt werden, die vorausgewählt waren. Wichtig ist an dieser Stelle, dass die gcc4-Pakete als 4.5-Version (oder höher) ausgewählt werden. Beim ersten Klick auf Skip wurde bei den Tests manchmal 4.3.4 als Version angezeigt. Diese unterstützt allerdings die benötigte Option "-fno-leading-underscore" nicht. Ein erneuter Klick bringt in einem solchen Fall dann die 4.5.3 hervor. Dies ist für alle gcc4-Pakete einzeln anzugeben.
Mit "Weiter" werden Abhängigkeiten aufgelistet, die mit installiert werden müssen. Hier sollte ein Haken bei "Select required packages" vorhanden sein. Mit "Weiter" werden die Pakete dann heruntergeladen und installiert. Nachdem dies abgeschlossen ist, kann mit "Fertig stellen" die Installation abgeschlossen werden. Es wird ein Neustart des Computers empfohlen.

Bilder

Schritt 2: Doxygen und Graphviz

Doxygen kann zwar mit Cygwin installiert werden, allerdings gab es in letzter Zeit einige nützliche Änderungen, weshalb empfohlen wird, die neuste Version zu verwenden.
Diese kann von der Doxygen-Webseite unter Downloads herunter geladen werden. Hier sollte das "binaries in a zip"-Paket genutzt werden. Nachdem dieses heruntergeladen wurde, kann es entpackt werden. Prinzipiell ist es egal, wo die zwei Exe-Dateien hin gespeichert werden, der Pfad sollte aber bekannt und ohne Leertaste sein. In dieser Anleitung wird "F:\Programme\Doxygen\" verwendet, eine ordentliche Strukturierung ist immer gut.

Analoges gilt für Graphviz. Dieses kann auf der offiziellen Webseite unter Downloads herunter geladen werden. Dazu muss den Lizenzen zugestimmt werden. Im Anschluss kann der Windows-Installer, in diesem Beispiel "graphviz-2.28.0.msi" geladen und danach ausgeführt werden. An dieser Stelle möchte ich einmal die Warnung der Webseite zitieren:

Warning: Not safe to use on Windows 7! On September 17, a Windows 7 user warned that a failed installation wiped out the system PATH variable and this was a lot of trouble because the installer does not create a restore point. We will investigate. 

Legt also vor der Installation einen Wiederherstellungspunkt an und speichert euch am besten noch die PATH-Umgebungsvariable zwischen (unter Windows 7 Tastenkombination [Windows]+[Pause], links "erweiterte Systemeinstellungen", untere Schaltfläche "Umgebungsvariablen", bei Systemvariablen Path suchen und auswählen, "Bearbeiten" und den Wert in eine Textdatei kopieren und diese speichern).
In diesem Beispiel wird Graphviz nach "F:\Programme\Graphviz" installiert. Ist die Installation geglückt, so ist ein Neustart bestimmt keine schlechte Sache.

Schritt 4: Codevorbereitung

Nachdem nun Großteile der Entwicklungsumgebung existieren, geht es an den Quellcode selber. Es ist an der Zeit die Vorgaben der ersten Aufgabe herunter zu laden und zu entpacken. In diesem Beispiel werden die Daten nach "F:\Daten\oostubs\code" gepackt. Der Ordner "F:\Daten\oostubs" soll später alles direkt für OOStuBS enthalten. Sollte nach dem entpacken ein Ordner namens "F:\Daten\oostubs\code\oostubs" existieren, so ist dessen Inhalt nach "F:\Daten\oostubs\code", also einen Ordner höher, zu verschieben, so dass z.B. die Datei "F:\Daten\oostubs\code\Makefile" existiert, der leere oostubs-Ordner kann nun gelöscht werden.

Windows-Anpassungen - misc

Die Vorlagen sind nicht für Windows ausgelegt. Deshalb gilt es zuerst die Vorlage baufähig zu machen. Dazu muss Windows als Plattform hinzugefügt werden. Eine einfache Variante ist es, dieses Zip-Paket herunter zu laden und nach "F:\Daten\oostubs\code\misc" zu entpacken, so dass die Ordner "F:\Daten\oostubs\code\misc\windows" und "F:\Daten\oostubs\code\misc\windowscross" existieren.
Die vier Dateien unter "F:\Daten\oostubs\code\misc\linux64\build\" - namentlich crtbegin.o, crtend.o, crti.o und crtn.o - müssen nach "F:\Daten\oostubs\code\misc\windowscross\build\" kopiert werden.

Windows-Anpassungen - Makefile

Die letzte Änderung ist leicht gemacht, in der Datei "F:\Daten\oostubs\code\Makefile" muss in der Zeile mit "PLATFORM=" der Teil danach in "windows" anstelle des vorhandenen - in diesem Beispiel "linux64" - umgeändert werden.

Optional: Funktionstest

Es besteht nun die Möglichkeit zu schauen, ob OOStuBS bereits gebaut, wenn auch noch nicht mit QEMU gestartet, werden kann. Dies müsste theoretisch bereits der Fall sein, sofern keine Fehler aufgetreten sind.
Zu diesem Zweck wird die Datei "F:\Programme\CygWin\Cygwin.bat" ausgeführt. Im Anschluss wird "cd /cygdrive/f/Daten/oostubs/code/" [ENTER] und danach "make" [ENTER] eingegeben. Es sollten keine Fehlermeldungen angezeigt werden. Danach folgt noch ein "make clean" [ENTER]. Der komplette Ablauf müsste dann etwa wie folgt aussehen:

a@b ~
$ cd /cygdrive/f/Daten/oostubs/code/

a@b /cygdrive/f/Daten/oostubs/code
$ make
(ASM  ) build/boot.o <- src/asm/boot.S
(CXX  ) build/cgastr.o <- src/device/cgastr.cc
(CXX  ) build/guardian.o <- src/guard/guardian.cc
(CXX  ) build/cgascr.o <- src/machine/cgascr.cc
(CXX  ) build/keyctrl.o <- src/machine/keyctrl.cc
(CXX  ) build/o_stream.o <- src/object/o_stream.cc
(CXX  ) build/strbuf.o <- src/object/strbuf.cc
(CXX  ) build/main.o <- src/main.cc
(ASM  ) build/compat.o <- src/asm/compat.S
(CC   ) build/inifini.o <- misc/windows/inifini.c
(LD   ) bin/oostubs <- [boot.o cgastr.o guardian.o cgascr.o keyctrl.o o_stream.o strbuf.o main.o compat.o inifini.o]

a@b /cygdrive/f/Daten/oostubs/code
$ make clean
(CLEAN)

a@b /cygdrive/f/Daten/oostubs/code
$

Anmerkung: Anstelle von a@b müsste der unter Windows verwendete Benutzername "@" Computername des gerade genutzten Computers erscheinen.

Schritt 5: Visual Studio

Prinzipiell existiert bereits alles, um OOStuBS zu bauen, dokumentieren, auszuführen und zu debuggen. Allerdings ist dafür noch einige "Handarbeit" notwendig, um jedes Mal die Einzelteile zusammen zu führen. Diese Arbeit soll Visual Studio abnehmen. Weitere Vorteile sind die Code-Vervollständigung und die Syntaxhervorhebung.
Dazu ist dieses vorbereitete Paket herunter zu laden und nach "F:\Daten\oostubs" zu entpacken. Somit müssten sich dann unter "F:\Daten\oostubs" drei Ordner befinden, "code", in dem die OOStuBS-Vorgaben liegen, "scripts", in dem einige Hilfs-Batch-Dateien liegen und "vsproject", in dem die Visual Studio Projekte liegen.

Bevor nun Visual Studio gestartet wird, sollte die Datei "F:\Daten\oostubs\scripts\setVariable.bat" überprüft werden. In dieser sind die Orte eingetragen, an denen die verschiedenen Programme vorzufinden sind. Die Datei müsste wie folgt aussehen:

@set "CYGWINPATH=F:\Programme\CygWin"
@set "DOXYGENPATH=F:\Programme\Doxygen"
@set "QEMUPATH=F:\Programme\QEMU"
@set "GRAPHVIZPATH=F:\Programme\Graphviz"

@set "CROSSPATH=F:\Programme\CygWin\usr\src\cross"

Wurden andere Orte als die in dieser Anleitung verwendet, so gilt es nun diese Pfade zu korrigieren. Es ist wichtig darauf zu achten, dass alles vor dem Gleichheitszeichen (incl.) und die Anführungszeichen am Ende unverändert bleiben. "CROSSPATH" muss an dieser Stelle nicht verändert werden, es dient nur einer alternativen Variante (siehe Alternativen).
Wurde alles kontrolliert und notfalls angepasst, kann nun Visual Studio gestartet werden, indem entweder die Datei "F:\Daten\oostubs\vsproject\oostubs.sln" oder "F:\Daten\oostubs\vsproject\oostubs.vcxproj" geöffnet wird. Sollte eine neuere Version von Visual Studio verwendet werden, so wird nun vermutlich eine Konvertierung stattfinden, die hoffentlich auch korrekt funktioniert. Da aktuell keine neuere Visual Studio Version existiert, kann dies natürlich momentan nicht getestet werden.
Nach dem Start kann nun die Entwicklung losgehen.

Arbeiten mit Visual Studio als Verwalter

Das ganze System ist so aufgebaut, dass alles über Projekte gesteuert wird. Von diesen gibt es fünf Stück.
Das wichtigste Projekt ist "oostubs". In diesem sind die Quellcode-Dateien eingebunden und die Code-Autovervollständigung ist entsprechend konfiguriert. Um OOStuBS zu bauen gilt es das Projekt zu erstellen. Eine Möglichkeit dazu ist über einen Rechtsklick auf das Projekt und "erstellen". Zum Ausführen von OOStuBS kann allerdings keine der Standard-Ausführungs-Varianten von Visual Studio ([F5], [Strg]+[F5], grüner Pfeil, ...) verwendet werden. Wird dies versucht, so kommt u.U. erst eine Warnung, wird der Vorgang dann mit "Ja" fortgesetzt, erscheint Wordpad mit einem kleinen Text.
Zum Ausführen von OOStuBS sind die Projekte "run_debug" und "run_normal" vorgesehen. Diese müssen erstellt werden, um OOStuBS zu starten. Dies mag jetzt etwas seltsam klingen, jedoch ist es eine einfache Variante, mit Visual Studio projektspezifisch andere Programme zu starten, ohne dass Visual Studio versucht diese mit den internen Mitteln zu debuggen und ohne dass Visual Studio dafür - zum Beispiel über PlugIns - verändert werden muss.
Bei "run_debug" wird QEMU wartend gestartet und kurze Zeit später GDB, welches mit QEMU Kontakt aufnimmt. Wird hingegen "run_normal" erstellt, so wird kein GDB gestartet und QEMU pausiert auch nicht, sondern führt OOStuBS direkt aus.
Die Dokumentation kann mittels "write_doc" erstellt und mittels "show_doc" im Standard-Internet-Browser geöffnet werden.

Anpassung der Projekte bei späteren Vorgaben

Das oostubs-Projekt kennt nur die in Aufgabe 1 vorhandenen Dateien. Dateien späterer Aufgaben sind entsprechend noch nicht berücksichtigt und müssen von Hand hinzugefügt werden. An dieser Stelle wird anhand der fiktiven Datei src/test/test.cc beispielhaft das Vorgehen gezeigt. Es wird davon ausgegangen, dass die Dateien schon im entsprechenden code-Ordner existieren (Schritt 7).
Per Rechtsklick auf "src", "Hinzufügen", "neuer Filter" und der Benennung in "test" wird ein neuer virtueller Ordner angelegt. Der Übersichtlichkeit wird hier die gleiche Struktur verwendet, wie sie real aussieht. Per Rechtsklick auf "test", "Hinzufügen", "Vorhandenes Element..." kann eine neue Quelltextdatei (oder mehrere auf einmal) hinzugefügt werden. Im Aufgehenden Dialog wird in den korrekten Ordner gewechselt und die entsprechende Datei ausgewählt.
Fertig.

Bilder

Schritt 6: bootfähiger USB-Stick

Da die Abnahmen der Aufgaben an realen Computern geschehen, ist es notwendig, das Betriebssystem auf einem echten Computer direkt auszuführen. Dies geschieht, indem ein USB-Stick bootfähig gemacht wird und so eingerichtet wird, dass er OOStuBS startet. An dieser Stelle wird Syslinux verwendet, um OOStuBS vom Stick zu starten.
Als Arbeitsmaterial wird ein USB-Stick benötigt, der prinzipiell bootfähig ist. Da während der Behandlung alle Daten des USB-Sticks vernichtet werden, gilt es diese zu sichern!

FAT32 formatieren

Syslinux kann nicht mit NTFS umgehen, aber mit FAT32. Deshalb muss der Stick FAT32 formatiert werden. Auch wenn der Stick bereits dieses Format hat, bietet sich eine Formatierung an, um alte Leichen und evtl. Fehler im Dateisystem zu bereinigen.
Im Windows Explorer sollte mit einem Rechtsklick auf das Laufwerk des USB-Sticks, in diesem Beispiel G:, geklickt und "Formatieren..." ausgewählt werden. Ist der Stick nicht zu groß, wird unter "Dateisystem" FAT32 angeboten, welches auszuwählen ist. Unter "Größe der Zuordnungseinheiten" wird "Standardgröße" ausgewählt. Es wird empfohlen, den Haken bei "Schnellformatierung" zu entfernen. Damit wird der komplette Speicherbereich beschrieben. Dann kann "Starten" geklickt werden.
Ist die Formatierung abgeschlossen, kann das Fenster geschlossen werden.

Syslinux aufbringen

Nun geht es an das Aufspielen von Syslinux. Auf der Webseite von Syslinux kann über "download" auf eine Unterwebseite von Kernel.org gelangt werden. Hier kann das aktuelle ZIP-Paket (momentan syslinux-4.04.zip) herunter geladen zu werden. Zur Zeit der Erstellung dieser Anleitung sind die Syslinux-Webseite und die Kernel.org-Webseite leider offline genommen, bei Syslinux wird nur die die Meldung "The Syslinux website is currently out of order. " zu lesen sein. Ende August wurde ein erfolgreicher Angriff auf Kernel.org, welche auch die Linux-Quelltexte enthält, festgestellt. Deshalb ist es u.U. notwendig, einen alternativen Download zu verwenden. Per Suchmaschine findet man schnell beispielsweise muntinternet.net. Hier kann dann syslinux-4.04.zip geladen werden. Es ist nicht bekannt, ob die entsprechende Seite vertrauenswürdig ist, eine Benutzung der Pakete geschieht deshalb, wie allg. bei dieser gesamten Anleitung, auf eigene Gefahr.
Konnte das Paket endlich geladen werden, so wird es nach "F:\Temp\Syslinux" entpackt. Das Paket enthält bereits Windows-Dateien, ein Erstellen dieser ist also nicht mehr notwendig. Es wird die Eingabeaufforderung von Windows gestartet, mit Administratorrechten gestartet - zum Beispiel über "Start", bei "Programme/Dateien durchsuchen" wird "cmd" eingegeben, auf das vorgeschlagene "cmd.exe" wird ein Rechtsklick, "Als Administrator ausführen" getätigt. Im erscheinenden Fenster wird in das richtige Laufwerk gewechselt, hier "F:" und danach in den richtigen Ordner per "cd F:\Temp\Syslinux\win32" gegangen. Mit dem Befehl "syslinux.exe -m -a -d boot G:" wird nun Syslinux auf den USB-Stick G: übertragen und dieser zugleich bootfähig gemacht. Die Eingabeaufforderung kann nun wieder geschlossen werden. Ein Beispielablauf könnte so aussehen:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Windows\system32>F:

F:\>cd Temp\Syslinux\win32

F:\Temp\Syslinux\win32>syslinux.exe -m -a -d boot G:

F:\Temp\Syslinux\win32>

Der sonst leere USB-Stick müsste nun die versteckte Datei "ldlinux.sys" enthalten. Da sie versteckt ist, kann es sein, dass sie nicht angezeigt wird.

Syslinux für OOStuBS konfigurieren

Auf dem USB-Stick werden dann die Ordner "G:\boot" und "G:\boot\kernel" angelegt. Die Datei "F:\Temp\Syslinux\com32\mboot\mboot.c32" wird nach "G:\boot\" kopiert. Dort wird auch eine Text-Datei mit dem Namen "syslinux.cfg" angelegt. Der Inhalt dieser müsste dann wie folgt gesetzt werden:

PROMPT 1
TIMEOUT 10
DEFAULT oostubs
DISPLAY bootmenu.lst

LABEL oostubs
  KERNEL /boot/mboot.c32
  APPEND /boot/kernel/oostubs

Es folgt das Anlegen der Datei "G:\boot\bootmenu.lst":

oostubs   - aktuelle OOStuBS-Version [DEFAULT]

Nachdem dies erledigt ist, muss nur noch die oostubs-Datei von "F:\Daten\oostubs\code\bin\oostubs" nach "G:\boot\kernel\" kopiert werden.
Der Stick ist nun bereit und es kann OOStuBS gestartet werden.

Optional: mehrere Versionen

Möchte man für jede Aufgabe eine eigene Bootoption haben - beispielsweise um später in Nostalgie zu schwelgen oder nachzusehen, ob bestimmte Fehler auch schon in früheren Versionen auftreten, kann ein Menü angelegt werden. In diesem Beispiel wurde Aufgabe 1 und 2 bereits bearbeitet wurde und Aufgabe 3 teilweise. Die aktuelle Version ist immer noch "G:\boot\kernel\oostubs". Die fertige Aufgabe 1 liegt als "G:\boot\kernel\oostubsA1" vor und Aufgabe 2 als "G:\boot\kernel\oostubsA2".
Nun wird zuerst die Datei "F:\Temp\Syslinux\com32\menu\menu.c32" nach "G:\boot\" kopiert. Im Anschluss wird die "G:\boot\syslinux.cfg"-Datei bearbeitet, diese müsste dann wie folgt aussehen:

PROMPT 1
TIMEOUT 100
DEFAULT oostubs
UI /boot/menu.c32
MENU TITLE OOStuBS Bootmenue mit Syslinux

LABEL -
	MENU LABEL OOStuBS:
	MENU DISABLE

LABEL oostubs
	MENU LABEL ^oostubs   - aktuelle Version [DEFAULT]
	MENU INDENT 1
	TEXT HELP
Dies ist die aktuelle Entwicklungsversion von OOStuBS.
	ENDTEXT
	KERNEL /boot/mboot.c32
	APPEND /boot/kernel/oostubs

LABEL oostubsA1
	MENU LABEL oostubsA^1 - fertige Aufgabe 1
	MENU INDENT 1
	TEXT HELP
Diese Version von OOStuBS beeinhaltet nur die abgeschlossene Aufgabe 1.
	ENDTEXT
	KERNEL /boot/mboot.c32
	APPEND /boot/kernel/oostubs.A1

LABEL oostubsA2
	MENU LABEL oostubsA^2 - fertige Aufgabe 2
	MENU INDENT 1
	TEXT HELP
Diese Version von OOStuBS beeinhaltet nur die abgeschlossenen Aufgaben 1 bis 2.
	ENDTEXT
	KERNEL /boot/mboot.c32
	APPEND /boot/kernel/oostubs.A2

Der Wert bei TIMEOUT gibt an, wie lange gewartet wird, bis die Standard-Option genutzt wird. Die Angabe ist in 1/10 Sekunden, der Wert 100 besagt also 10 Sekunden.
Bei den Namen gilt die "8+3"-Regel zu beachten, max. acht Zeichen vor und zwei Zeichen nach dem Punkt.
Der Lohn der Mühe sieht dann wie folgt aus:

Schritt 7: Vorgaben weiterer Aufgaben

Die Vorgaben zu den weiteren Aufgaben werden als patch-Dateien angeboten. Am Beispiel der zweiten Aufgabe wird das Vorgehen zum Einpflegen dieser Veränderungen gezeigt. Es wird davon ausgegangen, dass die Datei bereits heruntergeladen wurde. In diesem Beispiel ist sie als "F:\Daten\oostubs\oostubs_task2.patch" abgelegt.
Hinweis: Es empfiehlt sich vor dem Aktualisieren ein Backup der Dateien, am Besten des kompletten code-Ordners, anzulegen.
Sollte noch ein Programm - Visual Studio, QEMU oder GDB - auf Dateien von OOStuBS zugreifen, so sollten diese jetzt beendet werden. Danach wird die Datei "F:\Daten\oostubs\scripts\doConsole" gestartet. Der Patch wird dann mittels "patch -p1 -i ../oostubs_task2.patch" eingespielt. Der Ablauf könnte dort so aussehen:

Setup Environment

F:\Daten\oostubs\code>patch -p1 -i ../oostubs_task2.patch
patching file include/machine/io_port.h
patching file Makefile
patching file include/device/keyboard.h
patching file include/device/panic.h
patching file include/guard/gate.h
patching file include/machine/cpu.h
patching file include/machine/keyctrl.h
patching file include/machine/pic.h
patching file include/machine/plugbox.h
patching file include/user/task2.h
patching file src/device/keyboard.cc
patching file src/device/panic.cc
patching file src/machine/pic.cc
patching file src/machine/plugbox.cc
patching file src/main.cc
Hunk #1 succeeded at 9 with fuzz 2.
Hunk #2 succeeded at 28 (offset 4 lines).
Hunk #3 succeeded at 36 with fuzz 1 (offset 4 lines).
patching file src/user/task2.cc

F:\Daten\oostubs\code>

Damit sollte alles abgeschlossen sein, das Konsolenfenster kann wieder geschlossen werden.

Probleme beim Zusammenführen

Das Programm patch versucht die in der "*.patch"-Datei angegebenen Änderungen durchzuführen. Dabei muss es die passenden Stellen in den zu ändernden Dateien finden, wobei einige Zeilen davor und danach bekannt sind. Wurden hier beispielsweise bei der Entwicklung von OOStuBS Manipulationen vorgenommen, kann das Programm die Stellen nicht eindeutig identifizieren. In einem solchen Fall meldet patch die Probleme. Hier ist eine Beispielausgabe:

patching file include/machine/io_port.h
patching file Makefile
Hunk #1 FAILED at 9.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
patching file include/device/keyboard.h
patching file include/device/panic.h
patching file include/guard/gate.h
patching file include/machine/cpu.h
patching file include/machine/keyctrl.h
Hunk #1 succeeded at 20 with fuzz 2 (offset 8 lines).
patching file include/machine/pic.h
patching file include/machine/plugbox.h
patching file include/user/task2.h
patching file src/device/keyboard.cc
patching file src/device/panic.cc
patching file src/machine/pic.cc
patching file src/machine/plugbox.cc
patching file src/main.cc
Hunk #1 FAILED at 9.
Hunk #2 succeeded at 29 (offset 5 lines).
Hunk #3 FAILED at 37.
2 out of 3 hunks FAILED -- saving rejects to file src/main.cc.rej
patching file src/user/task2.cc

In der Makefile, vermutlich ab Zeile 9, konnte er den "Hunk", also die Änderung nicht durchführen. Genauso verhält es sich mit der Datei "code/src/main.cc" ab vermutlich Zeile 9 und Zeile 37. In der main.cc-Datei konnte er aber eine von drei Änderungen erfolgreich durchführen. Vermutlich bedeutet dabei, dass das Programm patch davon ausging, dass dort der Bereich der Änderungen anfängt, da er aber nicht erfolgreich war, kann diese Zeilenangabe nur als Anhaltspunkt genommen werden.
In dieser Anleitung wird die Fehlerbehebung am Beispiel von der Makefile gezeigt.
Nach der Einspielung des Patches gibt es drei Dateien in dem Ordner "/code/", Makefile, Makefile.orig und Makefile.rej. Die erste Datei enthält alle erfolgreichen Änderungen, die zweite Datei ist in der Form vor dem Einspielen des Patches und die dritte Datei gibt die nicht erfolgreichen Veränderungen an. In diesem Beispiel sind Makefile und Makefile.orig gleich, da es nur eine Veränderung in der makefile gab und die fehlgeschlagen ist. Die reject-Datei Makefile.rej sieht so aus:

***************
*** 9,15 ****
  LDFLAGS=-O0
  ASMFLAGS=-g
  
- OBJECT_IGNORE= task1.o
  
  INCPATHS=
  LDPATHS=
--- 9,15 ----
  LDFLAGS=-O0
  ASMFLAGS=-g
  
+ OBJECT_IGNORE= task1.o task2.o
  
  INCPATHS=
  LDPATHS=

Die obere Hälfte gibt an, die patch sich die Originaldatei in Zeile 9-15 vorstellt. Das Minus gibt an, dass diese Zeile entfernt werden soll. Die zweite Hälfte gibt an, wie er sich die fertig veränderte Datei vorstellt, das Plus gibt dabei an, dass die Zeile eingefügt wurde.
Schauen wir uns nun die Makefile dieses Beispiels von Zeile 9-15 an:

LDFLAGS=-O0
ASMFLAGS=-g

#OBJECT_IGNORE= task1.o
OBJECT_IGNORE= 

INCPATHS=

Ganz offenbar ist das schon die richtige Stelle, sie muss nur leicht abgeändert werden:

LDFLAGS=-O0
ASMFLAGS=-g

#OBJECT_IGNORE= task1.o
OBJECT_IGNORE= task1.o task2.o

INCPATHS=

Schon ist der Patch bei dieser Datei erfolgreich durchgeführt wurden. Jetzt können die .orig und .rej-Dateien gelöscht werden.
So muss auch bei anderen Fehlern vorgegangen werden.

Zugriffsfehler

In seltenen Fällen kann es passieren, dass Dateien Zugriffsrechte verlieren. Bei einem Bauversuch von OOStuBS könnte dann beispielsweise folgende Fehlermeldung erscheinen:

1>  ./include/machine/cgascr.h:13:21: schwerwiegender Fehler: ./include/machine/io_port.h: Permission denied
1>  Kompilierung beendet.

Dann ist beim Patchen etwas schief gelaufen und die Zugriffsrechte auf die Datei, in diesem Beispiel "F:\Daten\oostubs\code\include\machine\io_port.h" müssen korrigiert werden (im Explorer Rechtsklick auf die Datei, "Eigenschaften", Reiter "Sicherheit", hier kontrollieren, im Notfall "Bearbeiten" und korrigieren). Bei den Tests zu dieser Anleitung trat dies Problem jedoch nur auf, als sich nicht an diese Anleitung gehalten wurde, genauer gesagt, als Cygwin zum Patchen genutzt wurde und nicht das oben angegebene "doConsole".

Alternativen

Es gibt einen Haufen an Möglichkeiten, Betriebssysteme unter Windows zu entwickeln. An dieser Stelle werden zwei potentielle Kandidaten für OOStuBS vorgestellt, diese erfordern jedoch einen gewissen Aufwand und Zeitinvestition, haben dafür aber gewisse Vorteile.

ELF-Cross-Compiler

Bei einem ELF-Cross-Compiler handelt es sich in diesem Fall um eine Entwicklungsumgebung, bei der die Ausführbaren Dateien nicht für das laufende Betriebssystem (hier Windows), sondern für ein anderes - hier mit ELF-Dateiformat (Linux) - geeignet sind. Die Webseite OSDev.org stellt eine gute Anleitung für die Erstellung eines Cross-Compilers bereit. Diese Anleitung wurde auch für die Tests an dieser Stelle verwendet. Sie wurde jedoch nur bis einschließlich "gcc" abgearbeitet, mehr ist für die hier verwendeten Zwecke nicht notwendig.
Auch wurden einige Änderungen vorgenommen. Gleich zu Beginn bei "Preperation" wurden die beiden exports verändert:

export PREFIX==/usr/src/cross
export TARGET=i686-pc-linux

binutils wurde auch leicht anders konfiguriert:

../binutils-2.21.1/configure --target=$TARGET --prefix=$PREFIX --with-gnu-as --with-gnu-ld --disable-nls

Und zu guter letzt wurde auch gcc anders konfiguriert:

../gcc-4.6.1/configure --prefix=$PREFIX --target=$TARGET --disable-nls --enable-language=c,c++ --without-headers \
          --with-newlib --disable-gdbtk --disable-libssp --enable-threads

Die so erzeugten Dateien und Ordner von binutils und gcc liegen damit unter "F:\Programme\CygWin\usr\src\cross".
Von den oben angegebenen Schritten können alle verwendet werden, nur Schritt 4 muss abgewandelt werden. Bis einschließlich "Windows-Anpassungen - misc" ist noch alles in Ordnung. Doch die folgenden Abschnitte sind überflüssig und sollten nicht gemacht werden. Zuletzt muss noch die Makefile ("F:\Daten\oostubs\code\Makefile") angepasst werden. Hier muss in der Zeile mit "PLATFORM=" ein "windowscross" anstelle des vorhandenen - in diesem Beispiel "linux64" - eingetragen werden.
Schritt 5 und folgend kann dann wieder normal genutzt werden. Zu beachten ist nur, auch "CROSSPATH" von "F:\Daten\oostubs\scripts\setVariable.bat" zu kontrollieren und anzupassen. Im Anschluss wird oostubs dann nicht im PE-Format von Windows, sondern ELF-Format von Linux/Unix erstellt.

Der Haupt-Vorteil dieser Variante ist, dass die Vorlage nicht wesentlich verändert werden muss. Je weniger Änderungen vorgenommen werden, desto weniger neue Fehlerquellen fließen ein. Ebenfalls wird an diversen "Betriebssystem-Entwicklungs-Fronten" vermittelt, dass bei einer Entwicklung eines Betriebssystems unter Windows ein ELF-Cross-Compiler verwendet werden sollte. Hilfe gibt es dann oft nur bei Verwendung eines solchen, da sich die Personen mit anderen Varianten nicht auskennen.
Auch können diverse Boot-Manager zwar mit dem ELF-Format, aber nicht mit Windows PE-Format umgehen. Und ein Betriebssystem kann noch so toll sein, kann es nicht geladen werden, bringt es gar nichts.

Entwicklung mit Visual Studio

Auch mit Visual Studio direkt können Betriebssysteme erstellt werden. Damit kann komplett auf Cygwin verzichtet werden. Jedoch ist es dafür notwendig jeden Assembler-Code - sowohl die Assembler-Dateien, als auch die verschiedenen Stellen Inline-Assembler - von der AT&T Assembler Syntax auf die von Intel umzustellen. Dies ist eine Arbeit, die sich an dieser Stelle erspart wurde. Folglich ist diese Variante ungeprüft und es werden keine Pakete angeboten, bei denen dies bereits umgesetzt wurde.
Wen das nicht abschreckt: Einen Anhalt für das Vorgehen gibt dieser Blogeintrag (Teil 2). Auch hat OSDev.org einen entsprechenden Eintrag parat.
Grob gesagt, muss das Gleiche wie für diese Anleitung passieren, der Multi-Boot-Header muss korrekt und präsent sein und die Datei genau so vorliegen, wie sie nach dem Laden durch ein PE-fähiges Ladeprogramm im RAM aussehen würde.
Der Patcher zum Einspielen der nächsten Aufgaben kann von dieser Webseite als Windows-Binaries in Version 2.5.9 (von 2007) herunter geladen werden.

Bootloader GRUB

Eine Alternative zu Syslinux (Schritt 6) ist GRUB. Im Wiki von lowlevel.eu kann eine Anleitung gefunden werden, wie GRUB auf einen USB-Stick unter Windows installiert werden kann. Es gibt auch eine Anleitung von OSDev.org, diese empfiehlt dafür eine Linux Live CD.
Beide Varianten wurden nicht getestet.

1.0.0 (23.09.2011)	Anleitung fertig gestellt
1.0.1 (09.10.2011)	Namenskonventionen bei Syslinux angemerkt
1.0.2 (11.10.2011)	kleine Fehlerbehebung in angebotenen Dateipaketen Bilder diesbezüglich aktualisiert
1.1.0 (08.11.2011)	Umgang mit Fehlern von "patch" (reject-Dateien) eingefügt

Übersicht

Schritt 0: Vorwort

Schritt 1: Cygwin

Bilder

Schritt 2: Doxygen und Graphviz

Schritt 3: QEMU

Variante 1: fertige Binaries verwenden

Variante 2: QEMU selber bauen

Schritt 4: Codevorbereitung

Windows-Anpassungen - misc

Windows-Anpassungen - Makefile

Optional: Funktionstest

Schritt 5: Visual Studio

Arbeiten mit Visual Studio als Verwalter

Anpassung der Projekte bei späteren Vorgaben

Bilder

Schritt 6: bootfähiger USB-Stick

FAT32 formatieren

Syslinux aufbringen

Syslinux für OOStuBS konfigurieren

Optional: mehrere Versionen

Schritt 7: Vorgaben weiterer Aufgaben

Probleme beim Zusammenführen

Zugriffsfehler

Alternativen

ELF-Cross-Compiler

Entwicklung mit Visual Studio

Bootloader GRUB

Quellen und Links

Changelog