Thema: gui proggen

[gismo2004]

hi leutz

nachdem ich mich jezt einige zeit mit der Assembler programmierung auseinandergesetzt hab hab ich diese mal beiseite gestellt und mich einem anderen projekt gewidmet.

Ich hab schon seit ein paar jahren die idee mir ein eigenes os zu proggen.
da ich aber mich erst jezt intensiv damit beschäftige ist mir aufgefallen das ich den kernel in assembler progzramieren sollte. da ich dieser sprache noch nicht mächtig bin hab ich vor erstmal freedos zu nutzen um darauf mein system aufzubauen. Später will ich dann mein eigenen kernel und alles was dazu gehört schreiben. meine frage nun wie programmiere ich in c++ nun eine grafische oberfläche  leider konnte mein freund google mir da auch nicht weiterhelfen.

Hoffe jemand kann mir helfen gismo

[kleiner]

Tja anfangen solltest Du indem Du Dir Gedanken über den Aufbau machst.
Also welche Ur-Klasse, ob mit Fenstern etc und da erstmal ne Hirarchie aufbauen.
Danach wäre als nächstes die Frage: Eigene Grafikbib schreiben oder bestehende nutzen.
Wenn Du selbst eine entwerfen willst, dann natürlich da des gleiche. Erst mal ein Konzept aufbauen, wie die funktionieren soll und wie die Schnittstellen aussehen sollen.
Tja und dann kannste fast schon anfangen, die einzelnen Dinge zu programmieren.

[chr15]

Du kannst dir ja mal die grafische Oberfläche von freedos angucken um zu sehen, wie soetwas funktionieren kann. (Bin mir aber nicht sicher ob die auch in C ist, ober in freepascal)

[zacK]

mein tip: www.stormos.net

auch noch in den anfangstadien aber nice!

mfg

[TeeJay]

Es ist falsch von vorne nach hinten zu arbeiten.

Ohne einen Kernel, der deinen Bedürfnissen genügt und deine GUI bis ins letzte unterstützt, bringt es nix gleich bei einer GUI anzufangen.

Immer wieder haben Leute hier das Bedürfnis gleich in einer Woche SICHTBARE Ergebnisse zu sehen. Das geht beim OS-Coding eben nicht so.

Eine GUI zu proggen hat mit einem OS schon nicht mehr viel gemeinsam. Da geht es mehr um Grafikaufbau usw. Aber das Grundlegende eines OS (SPeicherverwaltung, Task-Management, Hardwaresteuerung usw.) sind dabei voll ausgelassen.

Einen Kernel NACHHER zu schreiben, der zu deiner GUI passt ist irgendwie ein komisches ding. Wenn du dann auf Probleme stößt etwas umzusetzen, musst du deine komplette GUI umschreiben usw.

[chr15]

Du kanst ja auch eine portable GUI schreiben. So kanst du dann auch hinterher prüfen, ob der Fehler an deinem OS liegt oder an der GUI. Die GUI sollte meiner Meinung nur Optional sein und nicht fester Bestandteil eines OSes.

[TeeJay]

Das mit dem portable ist immer so leicht gesagt!

Die GUI ist doch recht fest an Struktur deines Kernels gebunden.
Man kann ja auch nicht einfach so das X-System auf einem Windows-Kernel zum laufen bringen.

Siehe Windows! Da ist das GUI sehr eng mit dem restlichen System verzahnt!
Und da kann man nicht einfach mal eben die GUI oder den Kernel wechseln.

Wer ein OS proggen will, der soll doch irgendwo auch mal am Anfang anfangen und nicht mitten einsteigen! Da verpasst man ja das ganze! Und einen Kernel muss man keineswegs komplett in ASM schreiben! Vieles geht auch in C, wie ja in einigen Tutorials auch beschrieben ist.

[chr15]

Ich würde mir ja an Windows ja auch kein Beispiel nehmen. Ich stimme dir ja auch eigendlich zu, dass wenn man ein OS mit GUI haben möchte erst den Kernel schon sehr weit programmiert haben sollte. (Man kann sowas ja nie fertig programmieren )

Trotzdem würde ich mich dann eher an dem X-Window System orientieren, wenn ich eine GUI schreibe, als an die Oberfläche der Redmonder, da X auch sehr portabel ist (Gibt es sogar auf verschiedenen Architekturen) und man sich im Quellcode auch Infos holen kann.

[joachim_neu]

also ich würde zunächst den Kernel schreiben, denn da kann man ja schon mal den ein oder anderen teil einer API schreiben, die man dann bei der entwicklung einer GUI hilfreich benutzen kann...

[GhostCoder]

Hiho,

ich find es auhc am besten erst den Kernel "komplett" zu programmieren(Paging,MemManagment,Multitasking,vfs,syscalls) usw. und danach einfach ein Programm schreiben, das direkt über den Kernel mit dem Grafiktreiber kommuniziert und auf dem Programm baut dann die GUI auf z.B. durch ipc oder systemcalls. Das hat den Vorteil, das der Kernel auch komplett ohne GUI arbeiten kann, und man wahlweise auch einen anderen Window Server starten kann. bzw. mehrere gleichzeitig.

Und genau den Ansatz verfolge ich in meinem OS auch. Aber ich weiß das es ätzend is, nach Wochen/Monaten nen Kernel zu haben, der noch nichts "richtiges" für Auge bieten kann.

MfG GhostCoder

[rumpel]

moin.

Ich halte es ehrlichgesagt für sinnlos, erstmal einen eigenen Kernel mit Low-Level Krams zu schreiben, wenn das eigentliche Interesse im Entwickeln einer GUI liegt. Wenn man sich mal GUIs wie Gnome oder KDE anschaut .. die Jungs sind bestimmt nicht nur drauf aus, schnell sichtbare Ergebnisse zu schaffen, sondern sie haben einfach gesehen: Ein gutes OS gibt es schon, aber ich mag die GUIs nicht... Das sind doch zwei recht unterschiedliche Themen würd ich mal sagen.

Auf der Seite von Bonafide gibts ne Anleitung zum Thema GUIs:
http://www.osdever.net/?id=42

allerdings schliesse ich mich den meisten hier an: Lowlevel-Krams ist verdammt spannend (wenn auch manchmal etwas frustrierend...).

mfg, rumpel.

[chr15]

Das ist wahr, nur war das hier vermutlich anders gemeint. Wir haben nicht direckt an einen Windowmanager, wie KDE gedacht, sondern eher an sowas treibermäßiges wie X. Eventuell haben auch die eines, das eine, die anderen dass andere Gedacht, darum eventuell auch komunikationsschwierigkeiten...
Der unetrschied von X zu KDE ist, das KDE auf X aufsetzt und so unabhängig vom System ist und X setzt direkt auf den Kernel (Das OS) auf, so dass es auch an dieses angepasst werden muss. Darum braucht jedes OS seine eigene X-Version (solange die OSes nicht kompatibel sind), welche dann auch an das OS angepasst wird, welches man aber besser nach der Programmierung der Grundfunktionen im Kernel machen sollte.