Nachrichten

601

Lowlevel-Coding / Ohne Änderung funzt Kernel auf einmal nich mehr!

« am: 16. May 2005, 14:43 »

Na ja, ein Limit von 0x17 bytes ist nicht grad viel oder?
Vielleicht passt ja auch deine GDTR nicht mehr, ich denke die wirst du wohl vom Assembler/Linker berechnen lassen, vielleicht hast du durch andere Änderungen (Startaddresse, andere Programmteile die hinzugekommen sind und von daher Addressen beim Linken durcheinanderbringen könnten) einen Bug ausgelöst.

EDIT: Also beim Far Jump zum Code stürzt der ab, oder danach? Weil Bochs sich ja über ES beschwert und nicht CS, benutzt die Instruktion die danach folgt ES?

602

Lowlevel-Coding / C++ Pointer auf Funktionen

« am: 15. May 2005, 19:29 »

Also, wohl besser (meiner Meinung nach) geht das mit ner Factory. (ANMERKUNG: hatte das 2 posts über mir nicht gelesen, da steht im prinzip das selbe)

Ich nehme an, das du eigentlich Vererbung und virtuelle Funktionen benutzen würdest, wenn du das ganze nicht dynamisch laden würdest. Das geht auch mit dynamischem laden.

Host:

Code: [Auswählen]

class IKlasse {
public:
         virtual ~IKlasse ();

         virtual void test () = 0;
};

Dann in dem Modul:

Code: [Auswählen]

class Implementation : public IKlasse {
           virtual void test ();

           static IKlasse* factory ();
};

Code: [Auswählen]

IKlasse* Implementation::factory ()
{
          return (new Implementation ());
}

soo, jetzt musst du nur noch dafür sorgen das die factory-funktion geladen wird und die du diese aufrufst, um dein richtiges Objekt zu erhalten. Evtl. wäre es auch eine möglichkeit, die als C funktion in einem extern "C" { ... } block zu packen.

603

OS-Design / ToDo Liste

« am: 14. May 2005, 17:39 »

...das ist nämlich auch mein Gedanke.

Also das sollte man in der heutigen Zeit auf jeden Fall zur 1.0 nehmen.
Netzwerke mit Treibern fuer mindestens NE2000, NE2k (PCI) und
RTL8192 oder wie der heisst *g*

Vergleichbar auch mit allem anderen, was wesentlich ist; wenn wir GUI
haben wollen, sollte der Vesatreiber auch ersetzbar sein (ich hab noch ne
Doku fuer das WD90C26A von meinem Notebook glaubsch...Vesa 1.3
kann ich nur per DOS-TSR nachruesten).

Naja das sind so meine Gedanken dazu.
Und jetzt bitte wieder OnTopic.

Svenska

Ein paar Standardtreiber mitzuliefern ist sicher eine gute Idee - sie so fest ins System reinzuhängen wie bei Linux aber nicht, denn es bringt nix (ausser das mein einziges Riesenprojekt hat, Kernel+Treiber) - nicht mal wirklich Performance

604

OS-Design / ToDo Liste

« am: 14. May 2005, 00:43 »

Erzähl das mal auf der LKML oder nem Linux-Zealot ...  

605

OS-Design / Software Multitasking

« am: 13. May 2005, 16:28 »

http://legendos.codingworld.net/tutorials/software_task_switching.html

606

OS-Design / Frage zu GDT und IDT- Unterschiedliche implentierungen

« am: 12. May 2005, 21:55 »

Memset ist auch in jeder C Library vorhanden, die Funktion dürfte wohl Paging-erprobt sein!

607

OS-Design / Frage zu GDT und IDT- Unterschiedliche implentierungen

« am: 11. May 2005, 22:20 »

also macht das keinen großen unterschied? dann mach ich das mit C,
dann is die Implentierung leichter zu verstehen

Abgesehen das die meisten die wohl eh nur einmal beim Start setzen.

608

Lowlevel-Coding / java in osdev

« am: 10. May 2005, 21:07 »

1. Natürlich, das wirst du irgendwie sogar machen müssen, du willst ja auch die Main funktion des Programmes aufrufen

2. Die Grundzüge sind nicht mal so schwer - im Wesentlichen geht es das class-fileformat zu implementieren. Dieses ist jedoch schon nicht ganz "programmfreundlich" - es ist ja auf eine kleine Dateigrösse optimiert. Dann noch einige Opcodes.

Schwieriger wird es dann auch alles zu 100% zu behandeln (das heisst im wesentlichen auch alle komplizierteren opcodes wie lookupswitch, wenn ich mich richtig erinnere hiess das gute beispiel so ).

Und richtig schwierig, eigentlich genug für ein eigenes Projekt, ist dann die Optimierungsarbeit, im Wesentlichen in Form von einem JIT und einem schnellem Garbage Collector.

609

Lowlevel-Coding / java in osdev

« am: 10. May 2005, 11:00 »

@Legend:
Paging brauchst du ja trotzdem noch, damit jeder "Java" Prozess in nem eigenen Speicherbereicht liegt. Und für Swapping auch...

Gruß, GhostCoder

Für Swapping wäre es eine Überlegung, für ein System das nur Java-Programme (oder auch andere Safe Languages ausführt), ist das ansonsten nur Verschwendung - man muss eine virtuelle Machine ja nicht unbedingt als user mode Programm realisieren wollen, wenn man den Schritt mit Java in Osdev komplett durchgehen will.

610

tyndur / C vs. C++ bzw. wo ist was sinnvoll?

« am: 09. May 2005, 21:56 »

GCC unter Linux fügt in der Regel keinen Unterstrich vorne hinzu...

Jop, aber unter Windows tut er es, zur Info, falls es wichtig werden sollte! Gibt aber nen Kommandozeilenparameter das zu ändern.

611

Lowlevel-Coding / java in osdev

« am: 09. May 2005, 21:50 »

Gibts eigentlich nen guten Grund Java zu verwenden? Ich denke dass ist relativ langsam und hat nicht wirklich viele Vorteile gegenüber C++.

Also ich habe so etwas in Ansätzen für OS Dev schon umgesetzt. Wenn man es vollständig in seinem Design berücksichtig, kann es wohl besser umgesetzt werden als in z.B. Windows oder Linux.

Und dann erhält man so manchen Vorteil:
- Keine Probleme mit Name Manglings beim Linken
- Garbage Collection   - besonders Dinge wie XML's zu Parsen
ist ne Qual ohne.
- Man kann auf Paging zum Speicherschutz verzichten - der Speicherschutz folgt aus Java's Spracheigenschaften und das man Java Bytecode validieren kann - nach der Ladephase ist das eine Möglichkeit einen Geschwindigkeitsvorteil von C++-Code wieder wettzumachen.
- Analog dazu: Java Code ist praktisch immun gegen Buffer Overflows, wenn etwas in dieser Art passiert, erhält man eine Exception, meistens wohl die ArrayIndexOutOfBoundsException, d.h. man kann so keinen Code einschleusen. Worst Case ist eine nicht behandelte Exception, so dass die JVM das Programm halbwegs sauber noch terminiert.
- C++ hat an manchen Stellen Probleme mit seinem Design, Templates können problematisch werden und zu unwartbaren Code führen, Multiple Inhertiance IST sehr schnell problematisch.

Ein Grossteil der Zeit beim Starten von einer Java Anwendung verbringt die JVM mit dem laden und validieren von Klassen - wenn sich alle Anwendungen eine JVM teilen würden, was ja kein konzeptionelles Problem darstellt (ausser man braucht verschiedene Versionen von manchen Libs gleichzeitig, ugh), dann kann man den Programmstart wohl um eigenes beschleunigen - ich denke mal die meisten die sagen Java ist langsam den Start von Applets in Erinnerung haben.

Wie sich das in der Praxis auswirken wird, muss sich erst noch zeigen, ich würde mich bei einem OS auch nicht auf Java beschränken, da man immer noch nicht gut sagen kann wie z.B. Java gegen .NET ausgehen wird, oder ob das jemals ausgehen wird - in dem Falle sollte man beides unterstützen, jedoch scheint .NET (und damit letztendlich auch z.B. Mono) intern um einiges komplexer zu sein als Java.

612

Lowlevel-Coding / multitasking verständnis

« am: 09. May 2005, 17:57 »

Na ja, zehntausend sachen drumrum bauen um sich ein "pusha" zu ersparen, würde ich zumindestens nicht als einfacher empfinden.

613

Lowlevel-Coding / Arcus(co)sinus

« am: 09. May 2005, 17:55 »

Kannste ja selber per Taylorreihe approximieren!

614

tyndur / Über die einzelnen Teams

« am: 06. May 2005, 15:05 »

Die LGPL ist auch ziemlich sinnvoll, Weiterentwicklungen am Programm selber muss man offen legen, aber wenn man z.B. als Weiterentwicklung eine Schnittstelle zum Laden von Modulen entwickelt, kann man die Module dann unter eine Closed Source Lizenz stellen.

Z.b. beim GNU Classpath für Java ist die Lizenz sehr unglücklich gewählt mit der GPL, da dies bedeutet das man kein closed source Programm mit diesem Classpath laufen lassen dürfte, d.h. z.b. nicht die freie Java VM kaffee benutzen darf, es sei denn kaffee es gibt noch einen anderen Classpath mit dem kaffee arbeiten kann.

615

tyndur / Über die einzelnen Teams

« am: 06. May 2005, 14:47 »

Einen ganz wichtigen: Weiterentwicklungen von BSD Code muss man im Gegensatz zur GPL nicht wieder unter der BSD Lizenz veröffentlichen.

616

OS-Design / Paging

« am: 04. May 2005, 16:49 »

Stimmt, das funktioniert natürlich, aber damit wirst halt jeglichen Fehler in der Speicherhandhabung eines Programmes gleich mit legalisieren!
Aber die Diskussion hatten wir schonmal ...

617

OS-Design / Paging

« am: 02. May 2005, 20:29 »

Falls die Frage mit der 4kb Seite für eine Struktur im Raum steht -
du wirst natürlich in eine 4kb Speicherseite mehr als eine Struktur packen (wenn die Struktur nicht zu gross ist ).

Deswegen gibt es generell immer zwei Instanzen zur Speicherverwaltung.
Der Kernel gibt 4kb Seiten an die Anwendungen raus, und in der Anwendung (in der eigentlich malloc implementation) werden diese 4kb Seiten noch mal unterteilt!

618

Lowlevel-Coding / kernel in C, erweiterungen in C++?

« am: 30. April 2005, 18:41 »

Na ja, also mal wieder C++ nachgebaut!  

619

Lowlevel-Coding / kernel in C, erweiterungen in C++?

« am: 30. April 2005, 11:17 »

Du kannst auch die C Teile durch z.B. gcc jagen und die C++ Teile durch g++ - dann jedoch sollte man in den header nicht die extern "C" { ... } teile vergessen!

@Roshl: Wenn deine Controls dann solche Eigenschaften von den Fenstern geerbt haben, die keinen Sinn machen für die Controls machen, dann war es wohl nicht ganz richtig die Controls von den Fenstern erben zu lassen! [/code]

620

Lowlevel-Coding / kernel in C, erweiterungen in C++?

« am: 29. April 2005, 16:37 »

Wenn sich der Code bei euch aufbläht, nehmt einfach nen aktuellen Compiler und nicht uralt 2.95.x gcc's ... mehr sage ich dazu mal nicht!