Thema: Erste Schritte!

[Patrick75]

Hallo,
ich hoffe Ihr könnt mir Helfen?
Ich versuche schon seit Tagen, dass Einsteiger Tutorial unter Windows zum laufen zu bringen (Teil 4 Hello World). Allerdings bekomme ich es nicht kompiliert. Die Dateien sehen so aus wie im Tutorial beschrieben.

cmd Starten mit:
SET PATH=C:\Programme\crosstools-complete\i586-elf\bin;C:\MinGW\msys\1.0\bin;C:\Programme\NASM;%PATH%
cmd.exe /k cls

make Ausführen
 
Die Ausgabe:
gcc -m32 -Wall -g -fno-stack-protector -c -o init.o init.c
gcc.exe: CreateProcess: No such file or directory
make: *** [init.o] Error 1

Ich hoffe auf Hilfe. Vielen Dank schon mal im voraus!!!

[Patrick75]

peinlich, peinlich

http://lowlevel.eu/wiki/Crosscompiler_f%C3%BCr_Windows

habs wohl übersehen!

[Jidder]

Hi,

klappt der Workaround denn? Ich hab den Cross Compiler erstellt, und zweifle selbst immer wieder daran, ob es wirklich so sinnvoll war, den im Wiki zu verlinken. Immer wieder treten bei dem Probleme auf, die ich selbst nicht reproduzieren kann.

Es ist halt so, dass ein selbstkompilierter Compiler auf dem eigenen Rechner ohne Probleme funktionert, und ich deswegen jedem nur dazu raten kann, sich die Zeit dafür zu nehmen. Die Hürden dafür sind auch unter Windows (MinGW) mittlerweile sehr niedrig, und man kann jede für Linux gedachte Anleitung fast 1:1 befolgen.

PorkChicken

[kevin]

Erstmal willkommen im Forum!

Das Problem scheinst du ja selbst gelöst zu haben (so mag ich das), aber zum Thema Peinlichkeit: Dass man den Wald vor lauter Bäumen vor allem am Anfang nicht sieht, ist doch in gewisser Weise normal. Solange du nicht zu den Leuten gehörst, die man mit der Nase auf einen Artikel stößt und die es dann trotzdem nicht fertigbringen ihn auch zu lesen, ist alles im grünen Bereich. Also keine falsche Zurückhaltung beim Fragen.

[Programm Noob]

Moin

klappt der Workaround denn? Ich hab den Cross Compiler erstellt, und zweifle selbst immer wieder daran, ob es wirklich so sinnvoll war, den im Wiki zu verlinken. Immer wieder treten bei dem Probleme auf, die ich selbst nicht reproduzieren kann.

Also ich habe lanmge Zeit unter Windows OS-DEV betrieben und hab keine Probleme gehabt, die ich nicht selber lösen konnte. Ich habe die meiste Zeit deinen Cross Compiler benutzt, weil ich keine Lust hatte mir auf allen PC's den GCC zu bauen. Es war auf jedenfall richtig von dir, weil so auch leute die auf Windows programmieren wollen der Einstig leicht gemacht wird.

@Patrick75
Ich empfehle jedoch inzwischen auch, wenn du tatsächlich OS-DEV betreiben willst, installier dir nen Linux, entweder in einer virtuellen Maschine oder auf deinem PC neben Windows. Es ist viel angenehmer dort zu programmieren, weil auch viele andere Tools die man so nebenbei brauchten kann unter Windows nicht verfügbar sind.

PNoob

[Patrick75]

Hallo,
erst mal vielen Dank für die Antworten.
Also, wenn man im Tutorial nichts überliest bekommt man es hin. Der CrossCompiler funktioniert auch. Ähm, soweit ich es beurteilen kann.

Linux hatte ich auch schon unter Virtual PC laufen. Ging viel einfacher. Jedenfalls das Erstellt des Kernels. Einen Emulator hatte ich noch nicht laufen… kommt aber noch.

Patrick

[Svenska]

Virtual PC ist ein Emulator/Simulator/Virtualisator.
Wobei zum Debuggen deines eigenen Kernels wahrscheinlich Bochs (und evtl. auch Qemu) geeigneter sein sollten.

Kann man Virtual PC (VMware, Qemu-KVM, VirtualBox) eigentlich in einer Virtual PC-(VMware-, Qemu-KVM-, VirtualBox-)Instanz ausführen? Qemu (ohne KVM) und Bochs sollten das können, da sie simulieren und nicht virtualisieren - aber wie ist das mit den "großen" Systemen? Hat das mal wer ausprobiert?

Grüße

[erik.vikinger]

Hallo,

Kann man Virtual PC (VMware, Qemu-KVM, VirtualBox) eigentlich in einer Virtual PC-(VMware-, Qemu-KVM-, VirtualBox-)Instanz ausführen? Qemu (ohne KVM) und Bochs sollten das können, da sie simulieren und nicht virtualisieren - aber wie ist das mit den "großen" Systemen? Hat das mal wer ausprobiert?

Virtualisierer wird man wohl nicht ineinander verschachteln können. Was IMHO gehen müsste ist innerhalb von Qemu VMWare oder Virtual-Box auszuführen, es sollte auch möglich sein Qemu mehrfach in einander zu verschachteln, aber was da für eine Performance raus kommt wenn ein Simulator von einem Simulator von einem Simulator .... ausgeführt wird ist wieder ein anderes Problem. Auch innerhalb von Virtualisierern die VanderPool/Pazifika benutzen wird man kaum einen vergleichbaren Virtualisierer ausführen können (innerhalb der VM steht sowas nicht zur Verfügung), das gibt x86 einfach nicht her. Auf einer anders konzipierten CPU wo Befehle die den Systemzustand beeinflussen/erkennen klar von den normalen Befehlen getrennt sind (also kein Programm einen Unterschied erkennen kann) müsste das aber theoretisch möglich sein.
Es kann aber auch sein dass das alles Quatsch ist, ausprobiert hab ich soetwas noch nie.


Grüße
Erik

[kevin]

KVM kann dem Gast SVM anbieten, wenn es selbst auf SVM läuft. Das ist aber wohl eher als experimentelles Spielzeug anzusehen. KVM selbst läuft darauf wohl ganz gut, aber ich habe damit auch schon Triple Faults im Level-1-Gast hinbekommen. Performancemäßig dürfte es mit NPT halbwegs gehen (jedenfalls wenn man nur eine Ebene schachtelt ).

Ich glaube, andere Virtualisierer probieren es gar nicht erst.

@erik: Deine x86-Kenntnisse sind wohl nicht mehr auf dem neuesten Stand. SVM und VMX bieten genau diese Trennung von privilegierten Befehlen an. Dafür hat man sie erfunden.

[erik.vikinger]

Hallo,

@erik: Deine x86-Kenntnisse sind wohl nicht mehr auf dem neuesten Stand. SVM und VMX bieten genau diese Trennung von privilegierten Befehlen an. Dafür hat man sie erfunden.

Diese Mechanismen verhindern aber nicht "pushfd" oder "mov ax,cs" (Intel-Syntax) und damit auch nicht das ein Client die Virtualisierung durchschauen kann also ist die nicht perfekt. Gegen "pushfd" würde es helfen wenn die Steuerungs-Flag nicht im normalen Flag-Register sind und "mov ax,cs" wird in einem Flat-Memory-OS wohl nie gemacht werden. Ich bin mir ziemlich sicher das in VMware oder Virtual-Box ein OS das voll auf 386-PM-Segmentierung setzt nicht laufen könnte, in Qemu oder Bochs aber schon.


Grüße
Erik

[kevin]

Bist du dir sicher, dass du dir SVM oder VMX schonmal angeschaut hast?

[erik.vikinger]

Hallo,

Bist du dir sicher, dass du dir SVM oder VMX schonmal angeschaut hast?

Ich muss zugeben das ich das vor Jahren zwar gelesen hab aber wohl nicht gründlich genug. Solange der Hypervisor dem Client-OS einen sauberen physischen Speicher vorgaukeln kann braucht der Hypervisor sich nicht viel für die Segmente vom Client-OS zu interessieren so das dieses seine eigenen Segmente benutzen darf und ein "mov ax,cs" damit auch keine Lücke darstellt.

Das mit den privilegierten Befehlen ist bei x86 trotzdem nicht sehr schön gelöst, es gibt ne Menge Befehle die eigentlich jedes User-Programm braucht und die trotzdem in verschiedenen Situationen kritisch sein können. Das z.B. das IE-Flag in einem Register liegt in dem der User-Mode-Code ständig arbeitet empfinde ich einfach als ungeschickt, ich möchte nicht wissen wie viele Transistoren da nötig sind um bei jedem Schreibzugriff auf das Flag-Register zu erkennen ob eine Exception ausgelöst werden muss oder nicht.


Grüße
Erik