Damit man es unter MS Windows möglichst "bequem" hat, haben wir in den einzelnen Unterverzeichnissen BUILD.bat erstellt und zusätzlich eine übergeordnete Batch-Datei BUILD_ALL_WITH_FLOPPY.bat mit folgendem Inhalt:
cd user\user_program_c
call BUILD.bat
copy program.elf ..\init_rd_img\program.elf
cd ..
cd init_rd_img
call BUILD.bat
copy initrd.dat ..\..\kernel\initrd.dat
cd ..\..\kernel
call BUILD.bat
cd ..
pause
Wir haben bewusst Batch-Dateien zur Steuerung des übergeordneten Build-Prozesses auf MS Windows als Hostsystem gewählt und den Namen Windows_makefile (mingw32-make --makefile=Windows_makefile) in den Verzeichnissen verwendet. Damit bleibt der gewohnt reservierte Dateiname 'makefile' für Linux reserviert.
warum sind im SVN .exe-Dateien? Das ist ja erstens für die Quelltext-Verwaltung, zweitens bringen die unter Linux nichts, drittens hast du dich eben im IRC selbst dagegen gesträubt eine fremde .exe-Datei auszuführen, und viertens schafft das eine uneinheitliche Umgebung, und deswegen musst du überhaupt erst verschiedene Umgebungen für Linux/Windows (und da sogar nochmal Untervarianten, wie man hier sieht, und Mischumgebungen Batch/Makefile) verwalten. Und dann soll das ganze noch jemand verstehen?
drittens hast du dich eben im IRC selbst dagegen gesträubt eine fremde .exe-Datei auszuführen
Ja, das ist richtig und ein gewichtiges Argument.
Wir können das gerne ändern, aber Einsteiger müssen wissen, woher sie das richtige Tool erhalten. Das ist nicht trivial.
Bisher muss man eine direkte Floppy-Anbindung haben und ...
a)Cross-Tools installieren / Pfade einrichten (Cuervo hat dazu eine Anleitung geschrieben)
b)SVN-tarball downloaden
c)auf BUILD_ALL_WITH_FLOPPY.bat doppelklicken
That's it.
_________________ OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Zuletzt bearbeitet von Erhard Henkes am 17:55:42 08.11.2009, insgesamt 2-mal bearbeitet
Makefile ins Wurzelverzeichnis. Inhalt wäre sowas:
Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
all: image
# erstellt ein image
image: boot1 boot2 kernel programs
# image erstellen/zusammenkopieren mit dd etc
boot1: _stage1_bootloader/boot.bin (+korrekte abhängigkeiten ggf. in weiteren regeln)
boot2: _stage2_bootloader/boot.bin (+korrekte abhängigkeiten ggf. in weiteren regeln)
kernel: kernel.bin (+korrekte abhängigkeiten in weiteren regeln)
programs: ähnlich wie kernel
# weitere regeln für asm -> o, c -> o und natürlich die binärdateien
Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
all: image
# erstellt ein image
image: boot1 boot2 kernel programs
# image erstellen/zusammenkopieren mit dd etc
boot1: _stage1_bootloader/boot.bin (+korrekte abhängigkeiten ggf. in weiteren regeln)
boot2: _stage2_bootloader/boot.bin (+korrekte abhängigkeiten ggf. in weiteren regeln)
kernel: kernel.bin (+korrekte abhängigkeiten in weiteren regeln)
programs: ähnlich wie kernel
# weitere regeln für asm -> o, c -> o und natürlich die binärdateien
Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
all: image
# erstellt ein image
image: boot1 boot2 kernel programs
# image erstellen/zusammenkopieren mit dd etc
boot1: _stage1_bootloader/boot.bin (+korrekte abhängigkeiten ggf. in weiteren regeln)
boot2: _stage2_bootloader/boot.bin (+korrekte abhängigkeiten ggf. in weiteren regeln)
kernel: kernel.bin (+korrekte abhängigkeiten in weiteren regeln)
programs: ähnlich wie kernel
# weitere regeln für asm -> o, c -> o und natürlich die binärdateien
Vorteile:
* funktioniert unter Windows und Linux ohne Anpassungen (außer vielleicht eine Variable weil der Compiler mal gcc und mal i586-elf-gcc heißt)
* einheitlich für alle Komponenten (bootloader, programme, shell) -> erweiterbar
* es werden nur die notwendigen Dateien gebaut
* unabhängig von shell/cmd
* aus den letzten beiden Punkten folgt: schnell
_________________ Für mehr Kühlschränke!
Zuletzt bearbeitet von Schablone am 17:56:59 08.11.2009, insgesamt 1-mal bearbeitet
Wie im IRC gerade erwähnt finde ich diese Batch Datei, die in jeden Unterordner geht und dort Batchdateien aufruft, unschön und überflüssig. Immerhin kann make das auch und wir brauchen für Linux eh ein Makefile das genau das gleiche tut. Im jetztigen Standpunkt müsste man bei Änderungen das Makefile und die Batchdateien anpassen.
Daher wäre mein Vorschlag am anfang 2 Makefiles zu erstellen, eine für Linux und eine für Windows. In diesen Makefiles werden nur Variablen gesetzt, unter anderem sämtliche Befehle wie Compileraufrufe, Kopierbefehle etc.
Danach können beide Makefiles ein Makefile aufrufen oder includieren das nicht mehr Betriebsystemspezifisch ist. Dieses Makefile kann dann in die Unterordner gehen und dort wiederrum Makefiles aufrufen. Wenn sich nun etwas ändert braucht man nur noch die Betriebsystemunabhängigen Makefiles abändern.
Diesers Programm funktioniert mit den aktuellen PrettyOS Versionen nicht mehr, es war nur ale Test gedacht und ist hiermit als "obsolete" und unbrauchbar markiert.
Cuervo schrieb:
So, ich stelle nochmal den aktuellen Code und eine EXE-Datei rein, Code ist in BlitzPlus geschrieben (http://www.blitzbasic.com).
Programm läuft auf EIGENE GEFAHR.
Download: LINK ENTFERNT
Dieses Archiv bitte in den Source Ordner exrtrahieren, so dass die build.exe darin liegt.
Global win
AppTitle "Compiler"
win=CreateWindow("Kompilieren...",100,100,640,480,0,1+32)
Global e,es,ed
Global tarea=CreateTextArea(10,10,620,460,win)
SetTextAreaColor tarea,0,0,0,1
SetTextAreaColor tarea,0,255,0,0
Global font=LoadFont("Arial",30)
SetTextAreaFont tarea,font
Global win
AppTitle "Compiler"
win=CreateWindow("Kompilieren...",100,100,640,480,0,1+32)
Global e,es,ed
Global tarea=CreateTextArea(10,10,620,460,win)
SetTextAreaColor tarea,0,0,0,1
SetTextAreaColor tarea,0,255,0,0
Global font=LoadFont("Arial",30)
SetTextAreaFont tarea,font
Global win
AppTitle "Compiler"
win=CreateWindow("Kompilieren...",100,100,640,480,0,1+32)
Global e,es,ed
Global tarea=CreateTextArea(10,10,620,460,win)
SetTextAreaColor tarea,0,0,0,1
SetTextAreaColor tarea,0,255,0,0
Global font=LoadFont("Arial",30)
SetTextAreaFont tarea,font
Nach einer nächtlichen Diskussion in #PrettyOS habe ich da mal eine Idee für euch und euer (im Moment ziemlich verhunztes ;-)) Buildsystem:
- Schreibt euch ein kleines Script in Perl oder Python, welches prüft, auf welchem OS gebaut wird und ob etwaige weitere Konfigurationen vorhanden sind (Floppy etc.). Dann könnt ihr die Makefiles entsprechend durch das Script auf das jeweilige System abändern. Ihr könnt zwar auch alles in Makefiles packen falls das geht, aber so ein Script ist im Endeffekt sauberer.
Ist aber noch suboptimal. Schön wäre es, die ganzen .asm-Dateien des Kernel-Codes in einem Rutsch oder einer Schleife aufrufen zu können. Oder andere makefiles aufzurufen. Bin aber kein Experte, da muss mir jemand helfen.
@echo off
:Loop
IF [%1]==[] GOTO Continue
IF [%1]==[bochs] (
cmd /c tools\bochs.bxrc
)
IF [%1]==[qemu] (
echo "dummy.."
)
IF [%1]==[disc] (
tools\dd if=stage1_bootloader/boot.bin of=\\.\A: bs=512 count=1 --progress
copy stage2_bootloader\boot2.bin A:\boot2.bin
copy kernel\kernel.bin A:\kernel.bin
)
SHIFT
GOTO Loop
:Continue
Kann mit einem oder mehreren Parametern aufgerufen werden:
- "bochs" startet Bochs mit dem Image
- "qemu" soll in Zukunft Qemu starten
- "disc" soll auf Diskette schreiben: Bitte mal testen, hab kein D-Laufwerk
Ist aber noch suboptimal.Schön wäre es, die ganzen .asm-Dateien des Kernel-Codes in einem Rutsch oder einer Schleife aufrufen zu können. Oder andere makefiles aufzurufen. Bin aber kein Experte, da muss mir jemand helfen.
Du benutzt recht wenig der Funktionalität von Make. Zurzeit ähnelt das eher einer Batchdatei. Man kann die Abhängigkeiten besser nutzen und feinere Targets erstellen.
Mit diesen beide Regeln kann man eine .o erstellen, egal ob es sich bei der Quelldatei um eine .c oder .asm handelt. $< ist dabei die Eingabedatei, also xy.c oder xy.asm und $@ ist das target, also xy.o
Nun könnte man ckernel ganz einfach als Abhängigkeit schreiben:
Code:
ckernel: xy.o test.o
# Hier xy.o und test.o zusammen linken
Code:
ckernel: xy.o test.o
# Hier xy.o und test.o zusammen linken
Code:
ckernel: xy.o test.o
# Hier xy.o und test.o zusammen linken
Das "Problem" ist aber, dass alle vier Teile zusammen in einem Makefile gebaut werden und u.U. andere Flags haben. Oder kann man auch Regeln differenzierter anwenden (kann's grad nicht ausprobieren)?
Und an sich ist es ja schon recht kompakt, die ganzen C-Sourcen des Kernels werden ja z.B. mit einer einzigen Zeile kompiliert. Nur der Assembler-Kram nicht :-/
Das "Problem" ist aber, dass alle vier Teile zusammen in einem Makefile gebaut werden und u.U. andere Flags haben. Oder kann man auch Regeln differenzierter anwenden (kann's grad nicht ausprobieren)?
Eine elegante Möglichkeit fällt mir da nicht ein wenn man verschiedene Flags in einer Makefile haben will.
Aber die Targets der User Programme umbenennen. Also statt .o heißen die Targets dann z.B. .uo und im Target selber muss wieder .uo in .o gewandelt werden.
Also ungefähr so (nicht getestet)
Code:
# Liste der .uo
USEROBJ = $(patsubst %.asm, %.uo, $(patsubst %.c, %.uo, $(wildcard *.c *.asm)))
Besteht die Möglichkeit - das die Makefiles etwas "übertrimmt" sind? Zumindest kann ich das OS nicht unter Windows kompilieren. Die Fehlermeldung besagt das er dem Befehl "rm" sowie "mv" nicht finden kann. Mit meiner Laienhaftigkeit habe ich schon versucht das Problem durch eine Äquivalent mittels Batch-Datei zu ersetzen, leider gelingt mir das nur mit "rm". "mv" ist scheinbar beharrlicher...
Habt ihr vielleicht ein Idee?
NACHTRAG: mit installierter Cygwin - Umgebung und entsprechenden anpassen des Pfades läuft nun die build.bat komplett durch - bis... bis folgende Fehlermeldung erschein:
Zitat:
syscall.o:(.rodata+0x20): undefined reference to `_flpydsk_read_directory'
mingw32-make: *** [ckernel] Error 1
Besteht die Möglichkeit - das die Makefiles etwas "übertrimmt" sind? Zumindest kann ich das OS nicht unter Windows kompilieren. Die Fehlermeldung besagt das er dem Befehl "rm" sowie "mv" nicht finden kann. Mit meiner Laienhaftigkeit habe ich schon versucht das Problem durch eine Äquivalent mittels Batch-Datei zu ersetzen, leider gelingt mir das nur mit "rm". "mv" ist scheinbar beharrlicher...
Die Befehle "rm" und "mv" sind Linux/ Unix Befehle. Du brauchst Windows typische Befehle...
anubis2k5 schrieb:
Habt ihr vielleicht ein Idee?
Kompiliere das OS einfach unter ein Linux Derivat.
anubis2k5 schrieb:
NACHTRAG: mit installierter Cygwin - Umgebung und entsprechenden anpassen des Pfades läuft nun die build.bat komplett durch
Cygwin macht Linux/ Unix Befehle unter Windows Nutzbar. Daher klappt das Kompilieren mit der Linux Makefile
anubis2k5 schrieb:
- bis... bis folgende Fehlermeldung erschein:
Zitat:
syscall.o.rodata+0x20): undefined reference to `_flpydsk_read_directory'
mingw32-make: *** [ckernel] Error 1
Lade Dir mal von hier das komplette Archiv (Tar Archiv) herunter. Anschliessend patcht Du mit diesen Dateien Deine Sourcecodes. Die Datei "fat12.inc" gehört in den Ordner "stage2_bootloader".
Anschliessend alles neu kompilieren und sich über ein laufendes OS freuen
Die Tools hatte ich mir schon vorher besorgt - am Pfad hatte es gelegen
Allerdings besteht mein Fehler im Make-Prozess immernoch...
Ich habe mir den aktuellen Trunk (56) aus dem SVN Repository gezogen - auch nach der Anleitung von Gamepower funktioniert es nicht... Ich erhalte weiterhin folgende Fehlermeldung:
Ich werd's jetzt mal unter Linux versuchen. Im übrigen habe ich mich vorher durch alle erdenklichen Schlagwörter hier im Forum umgesehen, aber ich finde einfach keine andere Lösung.
Nachtrag: Revision 55 funktioniert unter Windows ohne Probleme ?!
Zuletzt bearbeitet von anubis2k5 am 14:25:28 23.01.2010, insgesamt 1-mal bearbeitet
Ich hab gestern das makefile von PrettyOS so umgebaut, das es unter Windows ohne msys funktioniert (unter Linux müsste es dank Nutzung von Variablen weiterhin funktionieren). Anlass war das nicht-funktionieren von msys bei mir (kann auch an mir liegen ). Ich möchte Euch das natürlich nicht vorenthalten und bitte um Tests (vlt. auch unter Linux, ob es da auch noch funktioniert):
Prima, finde ich gut! Bei mir klappt's, allerdings muss
RM=del
noch durch
RM=cmd /c del
ersetzt werden. (Und natürlich die Einrückungs-Leerzeichen durch Tabs ersetzen beim Copy-Pasten.
Mit diesem makefile könnte man das Problem mit msys umgehen, ohne ein zweites makefile erstellen zu müssen. Ich schlage daher vor, auf dieses makefile, wenn es unter UNIX funktioniert, umzusteigen.
Wenn die Linux-Fraktion es frei gibt, dann ok. Bei Cuervo ist es gelaufen.
_________________ OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Zuletzt bearbeitet von Erhard Henkes am 15:06:12 21.02.2010, insgesamt 1-mal bearbeitet
ich mache optionale Sachen sowieso immer, also von da her.. und ich vermute mal, dass viele, die sich in diesem Forum rumtreiben den NASM sowieso installiert haben
Ich habe jetzt auch mal euer Tutorial gefunden und ein bisschen rumprobiert. Sobald ich aber den ckernel einbinden will, wofür ich natürich den Linker benutzen muss, kommt immer bei ld.exe dieser Fehler:
kernel.o: file not recognized: File format not recognized
Ich muss übrigens die gcc.exe und ld.exe aus dem Dev-C++ nehmen, da diese 64-bit kompatibel sind. Macht das einen Unterschied?
Ich habe auch die NASM Version 2.08 genommen wie MrX sagte.
mfG TheCrip
Zuletzt bearbeitet von TheCrip am 18:38:27 27.08.2010, insgesamt 1-mal bearbeitet
aout: da benötigst du den alten Linker aus dem DJGPP, der neue kann das nicht mehr, benötigt scharfe Trennung von 16 u. 32 Bit Code. Probiers mal mit dem DJGPP.
_________________ OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Wieso muss dein Compieler denn 64 Bit fähig sein, und vor allem was meinst du damit? Die 32 Bit Version kann man problemlos auf einem 64 Bit System ausführen, und es wird für das Tutorial und PrettyOS eh nur 32 Bit Code generiert.
Ja ich versuche das Tutorial zu kompilieren. Und ich habe ein 64-bit OS, deshalb klappt die ld.exe und gcc.exe vom djgpp nicht, weil das noch alte Versionen sind.
Jetzt muss ich die beiden vom dev-Cpp nehmen, diese funktionieren. Nur das die ld.exe das aout Format nicht erkennt.
Welches Format müsste ich denn da nehmen, hab schon einige versucht...
Zuletzt bearbeitet von TheCrip am 11:10:58 29.08.2010, insgesamt 1-mal bearbeitet
Wir haben erst später 16- und 32-Bit-Code sauber getrennt, da dies nur in aout und mit dem alten Linker möglich war. coff ist das Nachfolger-Format: http://en.wikipedia.org/wiki/COFF
Hier wurde die Abwärtskompatibilität beim ld gebrochen, wie heute beim 64-bit-OS, das die 16-bit-Anwendungen knallhart im Regen stehen lässt.
Diesers Programm funktioniert mit den aktuellen PrettyOS Versionen nicht mehr, es war nur ale Test gedacht und ist hiermit als "obsolete" und unbrauchbar markiert.
Cuervo schrieb:
So, ich stelle nochmal den aktuellen Code und eine EXE-Datei rein, Code ist in BlitzPlus geschrieben (http://www.blitzbasic.com).
Programm läuft auf EIGENE GEFAHR.
Download: LINK ENTFERNT
Dieses Archiv bitte in den Source Ordner exrtrahieren, so dass die build.exe darin liegt.
Global win
AppTitle "Compiler"
win=CreateWindow("Kompilieren...",100,100,640,480,0,1+32)
Global e,es,ed
Global tarea=CreateTextArea(10,10,620,460,win)
SetTextAreaColor tarea,0,0,0,1
SetTextAreaColor tarea,0,255,0,0
Global font=LoadFont("Arial",30)
SetTextAreaFont tarea,font
Global win
AppTitle "Compiler"
win=CreateWindow("Kompilieren...",100,100,640,480,0,1+32)
Global e,es,ed
Global tarea=CreateTextArea(10,10,620,460,win)
SetTextAreaColor tarea,0,0,0,1
SetTextAreaColor tarea,0,255,0,0
Global font=LoadFont("Arial",30)
SetTextAreaFont tarea,font
Global win
AppTitle "Compiler"
win=CreateWindow("Kompilieren...",100,100,640,480,0,1+32)
Global e,es,ed
Global tarea=CreateTextArea(10,10,620,460,win)
SetTextAreaColor tarea,0,0,0,1
SetTextAreaColor tarea,0,255,0,0
Global font=LoadFont("Arial",30)
SetTextAreaFont tarea,font
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können keine Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum nicht antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.