Thema: Graphische Oberfläche mit GRUB, C und VGA

[Spiderschwein13]

Hallo,
alle sagen immer, dass man um ein OS mit GUI zu basteln min. 2 Jahre und ein Informatikstudium braucht.
Wenn ich mich aber auf vorhandenen Sachen, wie einem Standard VGA Treiber, der LibC und dem Bootloader GRUB aufbauen würde, wäre es doch kein sooo großer Aufwand oder? (Wenn bei irgendeiner bootbaren CD Grafiken, z.B. BMP Datein angezeigt werden, brauchen die doch auch nen Grafikkartentreiber, oder?)
Also, wenn ich mich zunächst auf den Standardmodus beschränke und eine freie C Bibliothek verwende, ist eine einfache GUI doch nicht sooo schwer, oder?

[Korona]

Nunja, du brauchst einen funktionierenden Kernel mit Virtual Memory Management, Multitasking/threading und minimalen IPC Funktionen. Die darauf aufbauenden Anwendungen werden dann vergleichsweise wenig Zeit beanspruchen, vor allem, wenn du eine vorhandene C Library etc. benutzt. Wenn du etwas programmiererfahrung hast (auch im Lowlevel Bereich, du solltest wissen wie Pointer funktionieren und wie die I/O auf x86 CPUs funktioniert etc.) dann ist eine einfache GUI in wenigen Monaten möglich. Es ist allerdings fraglich, ob es sinnvoll ist, möglichst schnell eine schicke GUI zu implementieren. Ein stabiler Kernel und das Kerneldesign sind die wichtigsten Komponenten in einem OS. Viele Hobby OS Entwickler hier konzentrieren sich zunächst auf den Kernel und sein Design, bevor sie "highlevel" Userspace Applikationen implementieren.

[bluecode]

alle sagen immer, dass man um ein OS mit GUI zu basteln min. 2 Jahre und ein Informatikstudium braucht.

Letzteres hat niemand behauptet (soweit ich das sagen kann) und wenn dann war damit eher Erfahrung im Osdev bzw. Programmierbereich gemeint. Bei ersterem ging es eher darum eine gescheite Basis unter deiner Gui zu haben.

Wenn ich mich aber auf vorhandenen Sachen, wie einem Standard VGA Treiber

Gute Informationen dazu sind rar und das was vorhanden ist ist wie ich finde ziemlich unverständlich (zumindest auf den ersten Blick, mehr hab ich dem noch nicht gewidmet), da es einfach nicht ausreicht in einen Port 1024 und in den anderen 768 zu schieben.

der LibC

Die du natürlich zuerst portieren musst.

Wenn bei irgendeiner bootbaren CD Grafiken, z.B. BMP Datein angezeigt werden, brauchen die doch auch nen Grafikkartentreiber, oder?

Im allgemeinen nein, da es im Realmode ein paar nette Interrupts gibt mit denen man ganz einfach die Auflösung ändern kann und die Adresse des Framebuffers zum reinmalen bekommt.
Selbst im Protected-Mode ist es noch über den Virtual-8086-Mode und VBE (VESA BIOS Extensions) möglich einige Sachen über die Graka herauszufinden, Modi zu setzten und die Adresse des Framebuffers zu bekommen.

Es kommt immer darauf an was man will. Im Realmode ist sowas ziemlich einfach, aber realmode ist nunmal schei*e (meine Meinung und die erhebt natürlich keinen Anspruch auf Vollständigkeit) und damit auch keine solide Basis für ein OS. Außerdem wirst du kaum einen 16bit Compiler und portable libc finden.
Im Protected-Mode ist der Aufwand für eine Gui schon etwas größer.

edit: Ich kann Korona nur zustimmen.

[Spiderschwein13]

Achso,
das bedeutet also, ich brauch im PM am besten einen Graphikkartentreiber?
Aber warum steht dann bei Windows immer, wenn er keinen Treiber findet, dass er den Standard-VGA Treiber nutzt? Der VGA Treiber müsste doch immer gleich sein, da es ja um den VGA-Standard geht. Und wie werden Bootanimationen angezeigt? Da wird sich doch das OS schon im PM befinden oder?
Ich dachte mir, wenn ich meine "StartGUI" auf einem Graphikkartenstandard aufbaue, beeinflusst das nicht umbedingt gleich die Stabilität meines Kernels.

[bluecode]

das bedeutet also, ich brauch im PM am besten einen Graphikkartentreiber?

Wenn du von einem Treiber für eine spezifische Karte redest, dann vergiss es. ATI hat zwar im letzten halben Jahr einiges an Dokumentation rausgegeben, aber wenn man sich das mal anschaut, dann sind das pro Dokument ~600 Seiten NUR mit Beschreibungen von I/O Ports. Ich würde mal sagen, dass es kein Laie schafft da in ein paar Monaten überhaupt was mit anfangen zu können.
Dann gibts da noch Intel, die in den letzten Tagen einige Specs freigegeben haben. Ich hab mal kurz reingeschaut und das schaut schon freundlicher aus. Trotzdem glaube ich der Aufwand ist ziemlich groß und kaum einer hat soweit ich das sehe in einem Desktop/Laptop (abgesehen von Apple) eine Intel Graka.
Und Nvidia hält es erst garnicht für nötig Dokumentation freizugeben.

edit: Wie gesagt, mit VBE und Virtual-8086-Mode oder Standard-VGA (wer mit den Auflösungen noch was anfangen kann) kommt man auch hin.

Aber warum steht dann bei Windows immer, wenn er keinen Treiber findet, dass er den Standard-VGA Treiber nutzt? Der VGA Treiber müsste doch immer gleich sein, da es ja um den VGA-Standard geht.

Mit Standard-VGA kommst du maximal zu ner Auflösung von 800x600 bei 256 Farben iirc.
Ich hab aber kA was Windows macht.

Da wird sich doch das OS schon im PM befinden oder?

Imho ja, entweder bereits den Grafikkartentreiber geladen, Standard-VGA, Virtual-8086-Mode (unwahrscheinlich) oder Auflösung im Realmode geändert und dann in den Pmode gewechselt.

Ich dachte mir, wenn ich meine "StartGUI" auf einem Graphikkartenstandard aufbaue, beeinflusst das nicht umbedingt gleich die Stabilität meines Kernels.

Das hat mit der Stabilität nicht viel zu tun. Versuch es einfach und du wirst sehen & uns berichten können, was dabei rausgekommen ist

[kevin]

Wenn ich mich aber auf vorhandenen Sachen, wie einem Standard VGA Treiber, der LibC und dem Bootloader GRUB aufbauen würde, wäre es doch kein sooo großer Aufwand oder?

Was du willst, ist nicht, ein OS schreiben, sondern eine GUI für ein bereits vorhandenes schreiben. Das ist nichts verwerfliches, aber eine andere Baustelle. Nimm dir ein DOS, ein aufs Minimum abgespecktes Linux oder am besten natürlich LOST () her, dort hast du eine richtige Grundlage und mußt nicht ständig an Dingen basteln, die dich im Grunde gar nicht so sehr interessieren.

[Spiderschwein13]

Hey,
hab jetzt einfach mal nach nem Tutorial gegoogelt und was ziemlich brauchbares, wie ich finde gefunden:
http://brackeen.com/vga
http://www.monstersoft.com/tutorial1/VESA_intro.html

Mir ist nur noch nicht klar, wie ich meiner Dev-C Laufzeitumgebung bzw. dem gcc Compiler die GLibC beibringen soll. Denn das Manual von der is ziemlich lang...

[bluecode]

[...] die GLibC beibringen soll.

Soweit ich weiß stehen die Chancen bei der glibc sehr schlecht. Es heißt sie sei unportabel. Besser dafür ist wie ich es mitgekriegt hab, newlib. Dir sollte aber bewusst sein, dass ein C library portiert werden muss, damit die komplette Funktionalität genutzt werden kann?

edit: fast hätte ich es vergessen, gcc kann keinen (richtigen) 16bit realmode Code erzeugen und glibc/newlib geht auch von einem protected-mode OS aus.

hab jetzt einfach mal nach nem Tutorial gegoogelt und was ziemlich brauchbares, wie ich finde gefunden:

Beide Tutorials behandeln so wie ich das sehe den Interrupt 0x10 und sind somit an das BIOS, d.h. real-mode oder virtual-8086-mode (zumindest zum Wechseln der Auflösung), gebunden. Dessen solltest du dir bewusst sein. Abgesehen davon gehen beide Tutorials mit den angegebenen Auflösungen über den VGA-Standard hinaus, siehe wikipedia für ne kleine Liste.

btw. überleg dir wirklich mal ob taljeth nicht vielleicht Recht hat.

[MNemo]

@Spiderschwein13
Dass du eine 'gescheite Basis' für deine GUI brauchst, soll nicht heißen, dass es nicht ohne geht. Du kannst ein Dach auch auf die Erde stellen. Nur wird es dann schwierig Mauern darunter zu bauen. (ich hoffe du verstehst was ich meine)

[Spiderschwein13]

Edit: Seh grad, dass es schon nen Thread mit dem gleichen Problem gibt, aber dort wurde nur festgestellt, dass unter Linux kein Unterstrich vor die Main Funktion gestellt wird! (bin hier unter Windows)
Hi,
hab grad das Tutorial http://lowlevel.brainsware.org/wiki/index.php/C-Kernel_starten
durchgelesen und mir ne Batch-Datei zum kompilieren erstellt.
Beim Linken
(

Code: [Auswählen]

..\ld -T link.txt -o c32kernel.bin )
mekert er aber folgendes:
ckernel.obj<.text+0x4)=kernel_c: undefined reference to   main'

Weiß jmd woran das liegen könnte? Und das 0x4 zeigt doch auf die Stelle wo der Fehler in der Datei aufgetreten ist, oder? Das is ungefähr da, wo die Funktion int main() definiert wird.
Wie gesagt, das ist der Kernel aus dem C Tutorial.

Wenn ich den kompiliert hab, dacht ich fürn Anfang nehm ich den Windows Bootloader, der sollte ja auch gehn..

Und nochmal zum Thema GUI :
Also, in wiefern hängen denn eigentlich GUI und Kernel zusammen?
Und kann eine GUI eine Konsole ersetzen?

Grüße
Keks

[FreakyPenguin]

Naja, mit Windows oder Linux hat das eigentlich nicht viel zu tun. Eher damit, wie der gcc konfiguriert wurde. Am besten hängst du bei deinen CFLAGS ein -fno-leading-underscore an, dann kannst du davon ausgehen, dass keine Unterstriche benutzt werden.

Und ja, das 0x4 ist die Adresse Instruktion, die für den Fehler verantwortlich ist. Ich glaube eher nicht, dass das die main() ist, sondern eher die Stelle im Assemblercode, wo die main angesprungen werden soll.

Am besten Zeigst du mal den C und den ASM-Code her und sagst uns, welche Flags du zum kompilieren benutzt.

Zum Windows-Bootloader kann ich keine Auskunft geben. Ich befürchte aber, der ist nicht dafür gemacht, flache Binärdateien zu laden.
Ich würde dir, dazu raten, einen Multiboot-Header in deinen Assemblercode zu packen, ELF als Ausgabeformat zu benutzen und danach GRUB als Bootloader hernehmen. Damit können wir dir hier am Besten helfen.


Wie das zusammenhängt kannst du eigentlich grösstenteils selbst bestimmen. Klar, die GUI hängt vom Kernel ab, aber da gibt es verschiedene Ansätze wie man die GUI ins System integrieren kann. Der erste wäre der, der von Windows benutzt wird, also die GUI als Teil des Kernels. Die andere Möglichkeit sieht man bei Linux. Der Grafikserver X ist ein eigenständiges Programm und braucht den Kernel nur, um mit der Hardware zu kommunizieren.

Ob eine GUI die Konsole ersetzen kann, hängt von deinen Zielen ab. Aber prinzipiell ist das möglich.

[Spiderschwein13]

Bei Verwendung der -fno-leading-underscore Option kommt der selbe Error.
Eigentlich hab ich ja in meiner Assembler-Datei, die die C-Main Funktion aufruft eh einen Unterstricht (beim Verwenden der Funktion hab ich den natürlich jetz grad entfernt) ...
Also,
den kompletten Code hat ja der liebe Lowlevel-C-Tutorial-Ersteller schon sehr schön http://www.jay-code.de/files/ckernel.zip geuppt.

"Kernel16"

Code: [Auswählen]

[BITS 16] ;16 Bit Code erstellen
jmp start ;GDT überspringen

NULL_Desc:
dd 0
dd 0

CODE_Desc:
dw 0xFFFF ;Segmentgröße Byte 0/1
dw 0 ;Segmentbasisadresse Byte 0/1
db 0 ;Segmentbasisadresse Byte 2
db 10011010b ;Zugriffsberechtigungen
db 11001111b ;Zusatz + Segmentgröße Bits 16 - 19
db 0 ;Segmentbasisadresse Byte 3


DATA_Desc:
dw 0xFFFF
dw 0
db 0
db 0x92
db 0xCF
db 0

gdt:
Limit dw 0 ;Größe der GDT (wird später eingetragen)
Base dd 0 ;Adresse der GDT (wird später eingetragen)


start:

cli ;Interrupts ausschalten

mov eax, cs ;EAX auf derzeitiges Codesegment setzen
mov ds, ax ;DS auf Codesegment setzen

shl eax, 4 ;EAX mit 16 multiplizieren (Lineare Adresse
;des Codesegments errechnen)
mov [CODE_Desc+2], ax ;Lineare Adresse des Codesegmentes als
mov [DATA_Desc+2], ax ;Startadresse des Code- und Datendeskriptors
shr eax, 16 ;eintragen
mov [CODE_Desc+4], al
mov [DATA_Desc+4], al

mov eax, cs ;Startadresse der GDT errechnen
shl eax, 4
add eax, NULL_Desc

mov [Base], eax ;Startadresse der GDT eintragen
mov [Limit], WORD gdt - NULL_Desc -1 ;Größe der GDT errechnen und eintragen

lgdt [gdt] ;GDT laden

mov eax, cr0 ;In den Protected Mode schalten,
or eax, 1 ;indem Bit 0 des CR0 Registers auf 1
mov cr0, eax ;gesetzt wird

db 0xea ;FAR-JUMP zum Codesegment
dw PMODE
dw 0x8


[BITS 32] ;32 Bit Code erstellen

PMODE:
mov WORD [CODE_Desc+2], 0 ;Code Segmentstartaddresse auf 0 setzen
mov WORD [DATA_Desc+2], 0 ;Daten Segmentstartadresse auf 0 setzen
mov BYTE [CODE_Desc+4], 0 ;Code Segmentstartaddresse auf 0 setzen
mov BYTE [DATA_Desc+4], 0 ;Daten Segmentstartadresse auf 0 setzen

mov eax, 2 ;Selektor für das Datensegment erstellen
shl eax, 3

mov ds, ax ;Daten- Stack- und Extrasegment mit
mov ss, ax ;Datensegmentdeskriptor laden
mov es, ax
mov eax, 0 ;FS und GS mit Null-Deskriptor laden
mov fs, ax
mov gs, ax
mov esp, 0x1FFFFF ;Stack auf unterhalb der 2 MB Grenze setzen

jmp 0x8:0x10000 + PMODE2 ;Sprung in das "neue" Codesegment

PMODE2:
jmp END ;Zum Ende Springen

times 512-($-$$) db 0; ;Da der Linker sich nicht mit ungeraden
;Dateigrößen verträgt, wird diese Datei auf 512
;gepaddet.

END:
Kernel32:

Code: [Auswählen]

[Bits 32]
extern _main
global start
global _EnableA20Gate

start:

call _main

STOP:
jmp STOP

;#######################################################################
][Bits 32]
extern _main
global start
global _EnableA20Gate

start:

call _main

STOP:
jmp STOP

;#######################################################################

und die Kernel.c:

Code: [Auswählen]

int main()
{
char *Text = "Welcome to Protected Mode"; 
char *VideoMem = (char*)0xA8000; 
 
while(*Text) 
{ 
*VideoMem = *Text; 
*VideoMem++; 
*VideoMem = 7; 
*VideoMem++; 
*Text++; 
} 

return(0);
}


Mein System soll mehr so ein DAU-OS werden, soähnlich wie Windows KlickiBunti, intuitiv, also wahrscheinlich nix für die meisten von euch, die wissen wollen, was ihr System macht.
Wenn ich tatsächlich irgendwann auf ne Konsole verzichten würde, dann müsste ich die GUI eigentlich von Anfang an ziemlich in den Kernel integrieren, oder? Denn sonst hat man, wenns dumm läuft ja garkeine Eingabemöglichkeit...

[FreakyPenguin]

Naja nach der Fehlermeldung zu schliessen macht dein Kompiler da kein unterschied hin. Das müsstest du auch bestätigt kriegen, wenn du mal ein objdump -d von deiner ckernel.obj machst.
Die Fehlermeldung kann eigentlich nur davon kommen, dass der deine Funktion anders nennt, oder dass die Datei mit dem C-Kernel nicht mitgelinkt wird.
Oder benutzt du vielleicht den g++ zum kompilieren? Der kann zwar prinzipiell auch C kompilieren, aber spätestens beim Linken gibts da probleme.

Naja, für den Anfang ist die Konsole ja ganz praktisch. Das kannst du auch später noch rauswerfen.

[Spiderschwein13]

ich benutze die gcc.exe aus dem bin Verzeichnis meiner Dev-C Umgebung^^
Die gcc.exe aus dem DJGPPBuchstabenzeugs Zip Packer, die ich nach der Anleitung samt den ganzen Ordnern und Zeugs in das Verzeichnis C:\DJGPP entpackt hab, meldet, dass es keine zulässige Win32 Anwendung sei
Also ich geh jetz mal davon aus, dass der Code von dem Lowlevel Tutorial da eigentlich stimmt und es an meinem C-Compiler (der ja eigentlich keine Fehlermeldung bring) oder an meinem Linker liegt.
Also, ich brauche doch nur den GCC Compiler unter Windows DJGPP, den LN-Linker und den NASMW (oda auch NASM) Assembler.

[FreakyPenguin]

Wie gesagt, mit den Informationen, die ich im Moment von dir habe, kann ich nicht gross weiterhelfen. Das objdump -d könnte da noch am ehsten weiterhelfen.

Als Compiler unter Windows würde ich dir den Crosscompiler aus dem Wiki empfehlen: http://lowlevel.brainsware.org/wiki/index.php/Crosscompiler_f%C3%BCr_Windows

Ich kann dir nur noch raten, deine INPUT-Zeile im Linkerskript genau anzuschauen, und zu probieren, den Unterstrich im ASM-Code wegzunehmen.

[Spiderschwein13]

Also mit nem Dump von kernel32.obj wirds grad leida nix mehr
Iwi meint er jetzt nurnoch Fileformat not recognized. Ich hab mal unter C:\compile das Lost Packet da einschließlich MinGW installiert, kann es daran liegen?

Dump vom ckernel:

Code: [Auswählen]

ckernel.obj:     file format pe-i386

Disassembly of section .text:

00000000 <_main>:
   0: 55                    push   %ebp
   1: 89 e5                mov    %esp,%ebp
   3: e8 00 00 00 00        call   8 <_main+0x8>
   8: 80 3d 00 00 00 00 00 cmpb   $0x0,0x0
   f: b9 00 00 00 00        mov    $0x0,%ecx
  14: ba 00 80 0a 00        mov    $0xa8000,%edx
  19: 74 10                je     2b <_main+0x2b>
  1b: 0f b6 01              movzbl (%ecx),%eax
  1e: 41                    inc    %ecx
  1f: 88 02                mov    %al,(%edx)
  21: 42                    inc    %edx
  22: c6 02 07              movb   $0x7,(%edx)
  25: 42                    inc    %edx
  26: 80 39 00              cmpb   $0x0,(%ecx)
  29: eb ee                jmp    19 <_main+0x19>
  2b: 5d                    pop    %ebp
  2c: 31 c0                xor    %eax,%eax
  2e: c3                    ret   
  2f: 90                    nop   

Ist das dump tool sowas wie ein deassembler?

[kevin]

Ja, das -d steht für Disassemblieren.

In dem Stück ist jetzt zu sehen, daß eine Funktion _main existiert, keine main. Hast du das in deinem Assemblercode entsprechend? Deine Fehlermeldung spricht ja von main.

[Spiderschwein13]

ja ... eben genauso, wie in dem Tutorial,
aber jetzt kommt ja auch noch beim Linken (nicht beim kompilieren!) von kernel32.obj "File Format not recognized".
Edit: Ach, ich hab bei dem Lost-Compiler Zeugs die LD-Exe geändert und jetzt auf die ld.exe, die im Dev-C\bin Verzeichnis liegt zurückgeändert, die gibt die obige Meldung aus, meine andre ld.exe, die ich in des Verzeichnis kopiert hab, wo meine kernel32.asm liegt, sagt des mit der ___main Funktion ...
und objdump mag ja meine kernel32.obj file auch nich (auch not recognized)

Wie gesagt, die kernel32.asm lautet

Code: [Auswählen]

[Bits 32]
extern _main
global start
global _EnableA20Gate

start:

call _main

STOP:
jmp STOP

;#######################################################################

und ich mich plagt noch so n dummer Windowstrojaner, der die ganze Zeit mit irgendwelchen Meldungen von wegen, mein System sei beschädigt und ich müsste ihn installieren daherkommt ...

[kevin]

Dann solltest du entweder den Compiler oder den Linker wechseln, so daß beide zusammenpassen.

Ach, und weil du dich gerade so schön über Win ärgerst: Unter Linux funktioniert das einfach.

[Spiderschwein13]

ich starte Linux, vllt hätte ich das gleich machen sollen