Nachrichten

41

tyndur / Datentypen

« am: 19. June 2005, 20:06 »

hallo,

diese Datentypen sind an die winapi angelegt, wie unschwer zu erkennen ist. Das ist bis jetzt teilweise unschön umgesetzt, das muss ich selber zugeben. Aber ich denke trotzdem, wir sollten trotzdem die jetztigen typen weiter verwenden.

BYTE ist 1 Byte groß,
WORD ist 2 Byte groß,
DWORD ist 4 Byte groß,
QWORD ist 8 Byte groß.

Das soll für das os gelten *punkt*
Die verwendung von native datentypen sollte meiner meinung nach möglichst vermieden werden. Syntax-hl hin oder her.

MfG
DDR-RAM

42

tyndur / CVideoRam & CVideoRamManager - Sinn?

« am: 19. June 2005, 20:00 »

hiho,

also

Code: [Auswählen]

CVideoRam* const g_pVideoRam = (CVideoRam*)0x000B8000;
Wird nie initialisiert ja
ich sag dir auch warum, weil der pointer schon zur runtime bekannt ist.
Bei Verwendung von g_pVideoRam muss also kein pointer geladen werden oder so. Der Compiler kann alles wegoptimieren und das tut er, falls ihr mal den asm code angesehen habt.

und, was daran unschön ist weiß ich jetzt ehrlich gesagt nicht.
Den videoram als klasse zu haben und eine klasse, die diesen verwaltet, was soll daran falsch sein?
Ich sag nicht, das der code nicht noch ausbaufähig ist oder so, das wäre ja total vermessen. Aber an dem code ist nichts zwanghaft oop-mäßiges.

Und das mit dem Bildschirm löschen ist ja nun nen guter witz, wie schon vorher gesagt, du kannst ein globales videoram mgr objekt verwenden

Und der code ist nur zum testen des Kernels da, er wird in einer fertigen version nicht mehr benötigt.

MfG
DDR-RAM

43

Offtopic / Kleine Programmierspäße Teil 2 lol

« am: 12. June 2005, 02:13 »

Ich gebe mal nen Tipp

3^(2^5) - 1 = 3^32 - 1 = 1853020188851840 = 2^7 * 5^1 * 17^1 * 41^1 * 193^1 * 21 523 361^1

vielleicht hilft das ja wem

44

Offtopic / Kleine Programmierspäße Teil 2 lol

« am: 11. June 2005, 17:41 »

einem geübten Assemblerprogger und Kenner des Binärsystems fällt doch mal sofort auf, dass 4294967296=2^32 is. Durch den Modulo muss das Ergebniss auf jeden fall kleiner als 4294967296 sein, also in ein DWORD passen

Ja

(214013 ^ 4294967296) - 1) / 214012) kann man andersgeschrieben so auffassen: (x^n-1)/(x-1) das ist glaube ich auf jeden fall was ganzzahliges

Auch richtig

das bedeutet, dass das ergebniss schonmal nicht 0 sein kann, da 2531011 kein ganzzahliger teiler von 2^32 ist

2531011 = 7^1 * 17^1 * 21 269^1
also ggT(2531011, 2^32) = 1, aber falls ggT(((214013 ^ 4294967296) - 1) / 214012, 2^32) = 2^32, könnte am ende doch wieder 0 rauskommen.

Wenn ich mich nicht vertan habe liegt das ergebniss also irgendwo von 1 bis 2^32 vielleicht hilft das ja jemandem

Also was zwischen 0 bis ausschließlich 2^32.
Aber nur eins ist richtig  

45

Offtopic / Anti-Hoax

« am: 11. June 2005, 15:06 »

jaja, die blume wird blau ^^
Das ist MÜLL

46

Offtopic / Anti-Hoax

« am: 11. June 2005, 12:52 »

da tut einer aber ganz schön spammen

47

Offtopic / Kleine Programmierspäße Teil 2 lol

« am: 10. June 2005, 23:43 »

Ich *glaube* die Zahl hat 77309411328 bits (also ca. 9 GB )
aber so schwer ist es eigentlich nicht, das man das ausrechnen muss

um (214013 ^ 4294967296) / (214013 ^ 4294967296) zu errechnen musst du den genauen wert ja auch nicht kennen.

MfG
DDR-RAM

48

Offtopic / Kleine Programmierspäße Teil 2 lol

« am: 10. June 2005, 23:35 »

hm, ich habe noch einen ^^

(2531011 * (((214013 ^ 4294967296) - 1) / 214012)) % 4294967296

das ^ ist das hochzeichen (oder wie man es nenne mag, nix mit xor) und % ist mod operator (nix mit prozent ^^)

Wers rausfindet kriegt nen Keks

MfG
DDR-RAM

49

tyndur / Zeichensatz

« am: 10. June 2005, 22:16 »

ja, also als Kodierung würde ich mal UTF-8 vorschlagen, für die die nichts damit anfangen können:
ein Zeichen wird mit 1 bis 4 Bytes kodiert
us-acsii (7bit) zeichen sind ein Byte breit, sie entsprechen unicode 0x00-0x7F.
0x0080 - 0x07FF werden in 2 Bytes kodiert, das erste byte
sieht so aus 110xxxxx, das zweite so 10xxxxxx, sind 11 variable bits 2^11 = 2048, (0x800 passt also)
0x0800 - 0xFFFF werden in 3 Bytes kodiert, das erste byte
sieht so aus 1110xxxx, das zweite so 10xxxxxx, das dritte so 10xxxxxx
16 variable bits, 2^16 = 65536 (0x10000 passt also )
0x10000 - 0010FFFF werden in 4 Bytes kodiert, das erste byte
sieht so aus 11110xxx, das zweite/dritte/vierte so 10xxxxxx,
sind 21 variable bits 2^21 = 2 M (^^) (0x1FFFFF, sind als ca. doppelt soviel )
vorteil ist halt, das man standard-ascii net konvertieren muss (also nur 1 Byte, keine 2). Deshalb allgemein sehr platzsparend.
Durch die Redundanzen, die man leicht erkennt, kann man den Text irgendwo in der anfangen zu lesen. also beschädigte dokumente sind nicht komplett verloren.
Nachteil ist, das man die Textlänge nicht einfach durch die Anzahl der Bytes herausfindet.

MfG
DDR-RAM

50

tyndur / Zeichensatz

« am: 10. June 2005, 21:19 »

Also,

seit windows 2000 oder nt oder was auch immer, verwendet windows intern Unicode. Winapi funktionen gibt es meist in 2 Varianten,
eine mit Suffix A (ASCII/ANSI) und eine mit Suffix W (Wide character/Unicode).
z.B. CreateFileA und CreateFileW

In den c standard libs (evtl. ms spezifisch was jetzt kommt) gibt es 4 verschiedene varianten. z.B.: von strstr
1) strstr, klar ascii
2) wcsstr, unicode
3) _mbsstr, multibyte character set kann ascii oder unicode sein, ist von lokalen einstellungen abhänging
4) _tcsstr, wird je nach einstellung gemappt auf strstr, wcsstr oder _mbsstr

Ich hoffe, ich konnte alle klarheiten beseitigen.
Ich bin immernoch für unicode als internen Zeichensatz.
Das lässt alle Möglichkeiten offen.
Am Anfang lässt man halt jedes zweite byte ungenutzt, bzw. die standardzeichen werden erstmal als balken (z.b.: 䳳 ^^ ) oder gar nicht dargestellt.
Dann gibt es entweder die Möglichkeit, nur unicode zu unterstützen oder auch standard ascii (7 bit) oder halt auch extended ascii und dann halt an Hand der aktuellen codepage in unicode umzuwandeln.
Windoofs macht letzteres und ich würde auch letzteres machen.
standard ascii in unicode umwandeln sollte nicht so problematisch sein.
Und es bringt keine Punkte intern erst irgendwelchen ascii zu verwenden und dann später mal umstellen, weil halt ne menge über strings geht und man dann den kot neuschreiben müsste.

MfG
DDR-RAM

51

tyndur / Kerneldesign Milestone 1

« am: 10. June 2005, 20:59 »

Mit dem Zeitscheibenverfahren... ich finde ein Prioritätsbasiertes System nuetzlicher. Drei Stufen wuerden imho reichen, Wichtig, Normal, Unwichtig. Ein wichtiger Prozess kriegt doppelt so viel Zeit, ein unwichter die Hälfte der Zeit wie ein normaler, einfach wichtig => nochmal reinschalten, normal => weiterschalten, unwichtig => jedes zweite Mal ueberspringen. Ansonsten kann man ja mit Zeitscheiben arbeiten.
Sodass man im Prinzip ein Programm "nach hinten" stellen kann, damit es den Rechner nicht blockiert oder nach vorne, um eine bestimmte Aufgabe zu beschleunigen (zB der Taskmanager von Win ist immer höhere Priorität).

Svenska

Ich versuche sogar prioritätsbasierendes zu implementieren.
worst case O(n) = log2 n

Arbeitet mit sinkenden prioritäten des laufenden threads, so das nieder priorisierte threads auchmal rankommen können.

Ich hatte nur wie (vielleicht auch nicht ) gesagt die letzten 10 Tage an einem Spieleprojekt gearbeitet, wo die erste version gestern fertig sein musste, jetzt habe ich wieder ca. 2 Jahre dafür
Ich werd CommOS und das ding parallel machen.
Aber es hatte halt gerade höhere Prioritität
und jetzt versuche ich schnellstmöglich der prozessverwaltung erste lauffähige version fertigzustellen.

MfG
DDR-RAM

52

Lowlevel-Coding / Farcall vs. Interrupt

« am: 07. June 2005, 19:14 »

Für Hardware Multitasking brauchst du natürlich mehr Descriptoren, für jeden Task halt einen mehr.

nope, brauchen nicht ^^
man kann die descriptoren auch dynamisch laden, das heißt man braucht für software tasking mindestens 2.
Für weitere task gates braucht man dann mehr als 2 ^^

MfG
DDR-RAM

53

tyndur / Zeichensatz

« am: 07. June 2005, 18:26 »

Ich wäre ehrlich gesagt für Unicode. Wobei ich am anfang nur die ersten 128 Zeichen unterstützten würde, der Rest wird ignoriert ^^

MfG
DDR-RAM

54

tyndur / [KERNEL] Aufgaben/Verteilung

« am: 07. June 2005, 13:27 »

Ich mach ja die CPU-Feature Checks->ich schreib mich mal rein^^

gut gut

55

tyndur / [KERNEL] Aufgaben/Verteilung

« am: 07. June 2005, 00:52 »

das Problem ist, das wir noch kein Treiberinterface haben
Das ganze kommt ein wenig ins stocken, weil ich im Moment an nem Spieleprojekt für die Schule festsitze, das wird aber nur noch bis spätestens Donnerstag höchste Priorität haben.
Dann kommt erstmal ne Woche Partytime
Und dann bin ich wieder fürs CommOS verfügbar, sry

56

Offtopic / Extrem langer Bootvorgang

« am: 04. June 2005, 19:59 »

Macht doch ne Umfrage!
Obwohl, das gibt garantiert nen Flamethread ...

oh ja, rumflamen  

57

Offtopic / 2. OS-Coder treffen

« am: 03. June 2005, 19:40 »

nachdem das 1. OS-Coder treffen gescheitert ist, schlage ich ein zweites vor
     

 (ok ich wollte auch mal witzig sein )

58

Offtopic / eigene api erstellen

« am: 03. June 2005, 13:29 »

Dann werd ich wohl WinAPI verwenden müssen und dann alles auf WinFX umschreiben .

Die WinAPI wird weiterhin unterstützt werden müssen, um abwärtskompatibel zu bleiben, ein _muss_ existiert also nicht

Ist C# empfehlenswert zum lernen? Die meisten libs sind ja für C++.

Ich mag C# nicht und kenn mich da auch nicht so aus.
Wer mehr kann, ist immer besser gestellt.
Und ms, wird .NET nicht übern Haufen werfen, es hat also Zukunft.
Und, was für Libs brauchsten du?
Also um standard windows appz zu basteln reicht es voll und ganz aus.

MfG
DDR-RAM

59

Offtopic / Vergleich von OpenGL und DirectX

« am: 02. June 2005, 23:32 »

hm, so richtig zufrieden bin ich ja noch nicht  
@svenska: vielleicht meinte er 3D-Sound?
aber gibt es net auch OpenAL?
Und zum Vergleich gehört u.a. genau das, dass dx alles in einem anbietet.
Noch wer was beizutragen?

MfG
DDR-RAM

60

Offtopic / 1. OS-Coder treffen

« am: 02. June 2005, 23:28 »

ja, wohne auch _bei_ Berlin. (auch wenn in meinem Profil Berlin steht   )
Nach Bayern werde ich wohl eher nicht fahren
Aber ich wünsch euch schonmal viel Spaß