Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
141
tyndur / Namens-Abstimmung zum CommOS
« am: 15. May 2005, 22:34 »
(L)LOST hat gewonnen? =D>
28. April 2024, 07:52
Beiträge anzeigen
Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.
142
Lowlevel-Coding / C++ Pointer auf Funktionen
« am: 15. May 2005, 12:58 »
Vielleicht hilft der Code:
Was soll das sein?
eine MemberVariable, f, die ein pointer auf eine funktion hat, die ein p übernimmt.
MfG
DDR-RAM
Code: [Auswählen]
#include <iostream>
class foo
{
public:
foo() :
m_pfnBar(bar1)
{}
protected:
void bar1()
{
std::cout << "bar1" << std::endl;
}
void bar2()
{
std::cout << "bar2" << std::endl;
}
public:
void CallBar()
{
(this->*m_pfnBar)();
}
public:
void SetBar1()
{
m_pfnBar = foo::bar1;
}
void SetBar2()
{
m_pfnBar = foo::bar2;
}
protected:
void (foo::*m_pfnBar)();
};
typedef void (foo::*FOO_MEMBER_METHOD)();
int main()
{
foo meinFoo;
meinFoo.CallBar();
meinFoo.SetBar2();
meinFoo.CallBar();
meinFoo.SetBar1();
meinFoo.CallBar();
return 0;
}
Was soll das sein?
Code: [Auswählen]
void (*f)(p*);
eine MemberVariable, f, die ein pointer auf eine funktion hat, die ein p übernimmt.
MfG
DDR-RAM
143
Lowlevel-Coding / C++ Pointer auf Funktionen
« am: 15. May 2005, 12:39 »
Ich hab dein Problem nicht verstanden, aber ich zeige einfach
mal nen Weg auf, wie das so mit Pointern auf Memberfunktionen läuft:
MfG
DDR-RAM
mal nen Weg auf, wie das so mit Pointern auf Memberfunktionen läuft:
Code: [Auswählen]
class foo
{
public:
void bar()
{}
};
// definiere Typen pointer auf memberfunktion von foo, die void zurückgibt und keine Argumente übernimmt
typedef void (foo::*FOO_MEMBER_METHOD)();
int main()
{
FOO_MEMBER_METHOD pfnBar = foo::bar;
foo einFoo;
foo *pEinFoo = &einFoo;
(einFoo.*pfnBar)(); // direkter Aufruf
(pEinFoo->*pfnBar)(); // Aufruf über Zeiger
return 0;
}
MfG
DDR-RAM
144
tyndur / Bekomme Comm-OS nicht zum booten!
« am: 13. May 2005, 16:02 »
Es wird Grub (bzw. ein anderer Multiboot-Loader) als bootloader verwendet, Roshls Bootloader, wird nicht verwendet.
MfG
DDR-RAM
MfG
DDR-RAM
145
tyndur / Kerneldesign Milestone 1
« am: 12. May 2005, 18:26 »Zitat von: hannibal
ad Prozessverwaltung/Scheduling: d.h. ein ' externes ' modul ist dann fuer das eigentliche laden der prozesse verantwortlich?
ja
Zitat
wie soll denn das funktionieren den scheduler als eigenen prozess zu machen? der scheduler ist doch im grunde nur eine kombination aus interrupts, oder hab ich da was falsch verstanden?
Der trägt sich als Taskgate in die IDT ein. Daher, hat eigenes TSS und so.
Das auch immer in der GDT vorhanden sein muss. Er besitzt, nicht wie die anderen Prozesse/Threads noch irgendwelche prozess/thread-spezifische Zusatzinformationen. Hoffe, das ist verständlicher.
Zitat
ansonsten, sehr huebsch
Danke
Zitat
lg, hannibal
MfG
DDR-RAM
147
Lowlevel-Coding / Seltsammes Verhalten meines Laptops bei schleifen...
« am: 11. May 2005, 20:28 »
Wie soll ne Page bei Paging nicht da sein?
wenn CR3 register out of bound ist, ka was passiert, wird evtl. immer wieder bei 0 Angefangen zu zählen.
Aber ansonsten, liegt immer definiertes Verhalten vor, das entweder zu einem pagefault oder nix anderem führt.
Außer vielleicht noch, da ist irgendwas mit ROM-bereich oder so.
MfG
DDR-RAM
wenn CR3 register out of bound ist, ka was passiert, wird evtl. immer wieder bei 0 Angefangen zu zählen.
Aber ansonsten, liegt immer definiertes Verhalten vor, das entweder zu einem pagefault oder nix anderem führt.
Außer vielleicht noch, da ist irgendwas mit ROM-bereich oder so.
MfG
DDR-RAM
148
Wie sieht es eigentlich aus mit Namenskonventionen?
Da spielt ja wieder ein wenig, das Thema "C oder C++" mit rein,
Hiermal ne kleine Umfrage, mir fallen gerade nicht mehr sachen ein.
Ich hab mal meine Standardwerte mit x versehen, ist eigentlich sowie WinApi und MFC
Ungarische Notation:
[ ] nicht festgelegt
[ ] ja immer
[ ] noch seltener
[ ] gar nicht
Präfixe (mehrfachauswahl möglich ^^):
[ ] nicht festgelegt
[ ] m_ für member von einfachen C-Structs
[ ] a_ für Argument
[ ] p_ für Parameter
[ ] l_ für lokal
Schreibweisen:
Funktionen:
[ ] nicht festgelegt
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern
Variablen:
[ ] nicht festgelegt
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern
Typen:
[ ] nicht festgelegt
[ ] Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern mit _t suffix
[ ] alles groß, wahlweise Bindestriche zwischen den einzelnen Wörtern mit _T suffix
C-Strukturen:
[ ] nicht festgelegt
[ ] Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern
Klassen:
[ ] nicht festgelegt
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern
[ ] alles groß, wahlweise Bindestriche zwischen den einzelnen Wörtern
Präfixbuchstabe für Klassen:
[ ] (kein)
[ ] K
[ ] G
[ ] x
[ ] X
[ ] T
[ ] (usw.)
Makros:
[ ] klein
sagt mal wie ihr es so macht.
Achso, ich hab C++-Spezifik sicherheitshalber reingenommen.
Schlüsselwort struct wird nur für C-Structs verwendet, also solche, die keine Funktionen haben.
MfG
DDR-RAM
Da spielt ja wieder ein wenig, das Thema "C oder C++" mit rein,
Hiermal ne kleine Umfrage, mir fallen gerade nicht mehr sachen ein.
Ich hab mal meine Standardwerte mit x versehen, ist eigentlich sowie WinApi und MFC
Ungarische Notation:
[ ] nicht festgelegt
[ ] ja immer
- ja außer z.B. i
[ ] noch seltener
[ ] gar nicht
Präfixe (mehrfachauswahl möglich ^^):
[ ] nicht festgelegt
- s_ für für static
- g_ für für global
[ ] m_ für member von einfachen C-Structs
- m_ für member von Klassen
- t_ für template
[ ] a_ für Argument
[ ] p_ für Parameter
[ ] l_ für lokal
Schreibweisen:
Funktionen:
[ ] nicht festgelegt
- Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern
Variablen:
[ ] nicht festgelegt
- Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche, falls keine ungarische Notation, der erste Buchstabe klein
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern
Typen:
[ ] nicht festgelegt
[ ] Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern mit _t suffix
- alles groß, wahlweise Bindestriche zwischen den einzelnen Wörtern
[ ] alles groß, wahlweise Bindestriche zwischen den einzelnen Wörtern mit _T suffix
C-Strukturen:
[ ] nicht festgelegt
[ ] Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern
- alles groß, wahlweise Bindestriche zwischen den einzelnen Wörtern
Klassen:
[ ] nicht festgelegt
- Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern
[ ] alles groß, wahlweise Bindestriche zwischen den einzelnen Wörtern
Präfixbuchstabe für Klassen:
[ ] (kein)
- C
[ ] K
[ ] G
[ ] x
[ ] X
[ ] T
[ ] (usw.)
Makros:
- groß
[ ] klein
sagt mal wie ihr es so macht.
Achso, ich hab C++-Spezifik sicherheitshalber reingenommen.
Schlüsselwort struct wird nur für C-Structs verwendet, also solche, die keine Funktionen haben.
MfG
DDR-RAM
149
Lowlevel-Coding / Seltsammes Verhalten meines Laptops bei schleifen...
« am: 11. May 2005, 19:19 »
13 ist general protection fault, kann alles mögliche sein,
wie lautet der Error Code?
wie lautet der Error Code?
150
Also, ich man könnte, aufteilen in Kernmodule(z.B. IPC), Hardwaretreiber(z.B. Laufwerke), Softwaretreiber (z.B. Dateisysteme),
mir ging es um den technischen Unterschied, außer das Softtreiber auf Hardwaretreibern aufbauen müssen.
Ich hatte nie vor jemandem ASM/C zu verbieten
Mache mich nur dafür stark, lieber C++ als C zu verwenden und asm nur wenn notwendig, um die kompatiblität und evtl. Transportablität auf andere System zu maximieren.
MfG
DDR-RAM
mir ging es um den technischen Unterschied, außer das Softtreiber auf Hardwaretreibern aufbauen müssen.
Ich hatte nie vor jemandem ASM/C zu verbieten
Mache mich nur dafür stark, lieber C++ als C zu verwenden und asm nur wenn notwendig, um die kompatiblität und evtl. Transportablität auf andere System zu maximieren.
MfG
DDR-RAM
153
tyndur / C vs. C++ bzw. wo ist was sinnvoll?
« am: 09. May 2005, 19:57 »
Bist du dir sicher?
Du weißt, wie du dir die dekorierten Namen angucken kannst?
Also, wenn du mich eines besseren belehrst ok, ich hab mit Linux nicht so viel am Hut.
Du weißt, wie du dir die dekorierten Namen angucken kannst?
Also, wenn du mich eines besseren belehrst ok, ich hab mit Linux nicht so viel am Hut.
155
tyndur / C vs. C++ bzw. wo ist was sinnvoll?
« am: 09. May 2005, 19:36 »
Also die meisten, also eigentlich fast alle, können beides, jedenfalls geben die meisten das in dem "Lagebesprechung"-Thread an.
Softwareinterrupts sind ja in den meisten Fällen eh Funktionsaufrufen ähnlich.
Da der Kernel sehr micro sein wird, kann jeder der Lust hat, ein Modul bauen, um Unix/Windows-interrupts zu mappen, evtl. wird es auch noch ein weiteres geben, welches unseren kernel nativer unterstützt, dann wären sachen wie
extern "C" kann nur für Funktionen und Variablen verwendet werden, die keine Memberfunktionen sind und auch nicht für Klassen.
Es geht dabei nur darum, das für C++ jeder Compiler ein anderes Namensdekorationsschema verwendet, für C hingegen ist es einheitlich, es wird immer ein Unterstrich hinzugefügt, Beispiel:
foo wird also vom MS VC++ 2003 so dekoriert, bei einem anderen Compilier wird es wahrscheinlich anders sein. mit C-Linkage haben alle Funktionen den gleichen namen. Für mit extern "C" deklarierte Funktionen gilt allerdings das man sie nicht überladen kann.
aber ich bin recht optimistisch, wenn mir endlich mal einer erklärt, wie die Treiber die Funktionen finden sollen.
MfG
DDR-RAM
Softwareinterrupts sind ja in den meisten Fällen eh Funktionsaufrufen ähnlich.
Da der Kernel sehr micro sein wird, kann jeder der Lust hat, ein Modul bauen, um Unix/Windows-interrupts zu mappen, evtl. wird es auch noch ein weiteres geben, welches unseren kernel nativer unterstützt, dann wären sachen wie
Code: [Auswählen]
mov eax, funktionsnummer
mov ecx, fensterpointer
mov ebx, höhe
mov edx, breite
int 0XYh
extern "C" kann nur für Funktionen und Variablen verwendet werden, die keine Memberfunktionen sind und auch nicht für Klassen.
Es geht dabei nur darum, das für C++ jeder Compiler ein anderes Namensdekorationsschema verwendet, für C hingegen ist es einheitlich, es wird immer ein Unterstrich hinzugefügt, Beispiel:
Code: [Auswählen]
void foo(); // ?foo@@YAXXZCode: [Auswählen]
extern "C" void foo(); // _foo foo wird also vom MS VC++ 2003 so dekoriert, bei einem anderen Compilier wird es wahrscheinlich anders sein. mit C-Linkage haben alle Funktionen den gleichen namen. Für mit extern "C" deklarierte Funktionen gilt allerdings das man sie nicht überladen kann.
aber ich bin recht optimistisch, wenn mir endlich mal einer erklärt, wie die Treiber die Funktionen finden sollen.
MfG
DDR-RAM
156
Lowlevel-Coding / java in osdev
« am: 09. May 2005, 18:28 »
kenn ich nicht
kann ich auch nicht viel sagen, für nen x86 muss man trotzdem ne VM druntercoden.
kann ich auch nicht viel sagen, für nen x86 muss man trotzdem ne VM druntercoden.
157
Lowlevel-Coding / java in osdev
« am: 09. May 2005, 18:23 »
geht nicht, du müsstest dir ne VM coden, das kannste nicht mit Java, da Java eine VM vorraussetzt, also ist es sowieso blödsinn.
Außerdem hat Java keine ASM-Fähigkeiten.
MfG
DDR-RAM
Außerdem hat Java keine ASM-Fähigkeiten.
MfG
DDR-RAM
158
tyndur / C vs. C++ bzw. wo ist was sinnvoll?
« am: 09. May 2005, 17:09 »
Also new muss keine exception werfen können, der Standard sieht auch ein new vor, welches keine exception wirft. Bei Treibern kann es schon wieder anders sein, wenn wir kompatibel, dynamisch usw. sein wollen, dann müssen wir sowieso C++-Treiber mit Exception-Handling zulassen.
Die new/delete-Methoden des Treibers könnten z.B. auf eine malloc/free-Version des Kernel zugreifen, aber Back to Topic.
static_cast wirft niemals eine exception, reinterpret_cast wirft niemals eine, const_cast ist Blödsinn -> verboten im Kernel
und dynamic_cast, welches eine exception werfen kann verwendet RTTI, würde ich auch weglassen im Kernel, außerdem vorallem bei Mehrfachvererbung in Verbindung mit virtuellen Funktionenen verwendet.
reinterpret_cast und static_cast funktionieren eh wie C-Cast, also mir wäre es egal ob C-Casts oder C++-Casts
Mal nen beispiel:
So ungefähr halt.
Wo ist da Arbeitsaufwand?
oder man nimm reinterpret_cast und leitet die Klasse nicht ab, gefällt mir fast noch besser, denn:
Zu dem Problem mit dem Name-mangling oder wie das heißt,
es muss doch möglich sein für jeden Compiler ne .LIB-Datei zu bauen, damit die die C++-Klassen verwenden können. Kann mir mal bitte wer verraten, wie das funktioniert, sonst krieg ich nen Fön
Für Windows gibts doch auch nen DDK, keine Ahnung wie das funktioniert, weiß wer was darüber?
Das umständliche packen in eine c-struct sieht man oben in meinen 2-Code Beispielen
Also, klärt mich mal bitte auf, wie die Treiber unabhängig kompiliert werden. Dazu müssen sie ja wissen, wo die Prozeduren des Kernels liegen.
MfG
DDR-RAM
Die new/delete-Methoden des Treibers könnten z.B. auf eine malloc/free-Version des Kernel zugreifen, aber Back to Topic.
static_cast wirft niemals eine exception, reinterpret_cast wirft niemals eine, const_cast ist Blödsinn -> verboten im Kernel
und dynamic_cast, welches eine exception werfen kann verwendet RTTI, würde ich auch weglassen im Kernel, außerdem vorallem bei Mehrfachvererbung in Verbindung mit virtuellen Funktionenen verwendet.reinterpret_cast und static_cast funktionieren eh wie C-Cast, also mir wäre es egal ob C-Casts oder C++-Casts
Mal nen beispiel:
Code: [Auswählen]
//ckernel.h
struct PROCESS
{
DWORD dwID;
//[...]
};
#ifdef __cplusplus
extern "C" {
#endif
void MacheEtwasMitPROCESS(const PROCESS* pProcess);
//[...]
#ifdef __cplusplus
};
#endif
//cppkernel.h
#include "kernel.h"
class CProcess : protected PROCESS
{
public:
DWORD GetId();
//[...]
public:
void MacheEtwas() const;
//[...]
};
//kernel.cpp
#include "ckernel.h"
#include "cppkernel.h"
void MacheEtwasMitPROCESS(const PROCESS* pProcess)
{
static_cast<const CProcess*>(pProcess)->MacheEtwas();
}
void CProcess::MacheEtwas() const
{
//[...]
}
So ungefähr halt.
Wo ist da Arbeitsaufwand?
oder man nimm reinterpret_cast und leitet die Klasse nicht ab, gefällt mir fast noch besser, denn:
Code: [Auswählen]
// x86.h
class CTSSegment
{
public:
//[...]
protected:
DWORD m_wBackLink; // only low 16-bit are used
DWORD m_dwESP0;
};
// cppkernel.h
#include "x86.h"
class CThread : public CTSSegment
{
public:
void MacheEtwas();
//[...]
protected:
CProcess* m_pProcess;
//[...]
};
// ckernel.h
struct THREAD
{
DWORD dwBackLink; // only low 16-bit are used
DWORD dwESP0;
//[...]
PROCESS* pProcess;
};
// ich spar mir den #ifdef __cplusplus quatsch
extern "C" void MacheEtwasMitTHREAD(THREAD* pThread);
// kernel.cpp
void MacheEtwasMitTHREAD(THREAD* pThread)
{
reinterpret_cast<CThread*>(pThread)->MacheEtwas();
}
void CThread::MacheEtwas()
{
}
Zu dem Problem mit dem Name-mangling oder wie das heißt,
es muss doch möglich sein für jeden Compiler ne .LIB-Datei zu bauen, damit die die C++-Klassen verwenden können. Kann mir mal bitte wer verraten, wie das funktioniert, sonst krieg ich nen Fön
Für Windows gibts doch auch nen DDK, keine Ahnung wie das funktioniert, weiß wer was darüber?
Das umständliche packen in eine c-struct sieht man oben in meinen 2-Code Beispielen
Also, klärt mich mal bitte auf, wie die Treiber unabhängig kompiliert werden. Dazu müssen sie ja wissen, wo die Prozeduren des Kernels liegen.
MfG
DDR-RAM
159
tyndur / C vs. C++ bzw. wo ist was sinnvoll?
« am: 09. May 2005, 11:46 »
der Vorteil von asm geht aber auch gegen 0,
die einzigen somd Wirklich die volle Kontrolle und die maximal mögliche Optimierung, allerdings werden nicht viele besseren Asm-Code bauen als nen C/C++-Compiler.
MfG
DDR-RAM
die einzigen somd Wirklich die volle Kontrolle und die maximal mögliche Optimierung, allerdings werden nicht viele besseren Asm-Code bauen als nen C/C++-Compiler.
MfG
DDR-RAM