Themen

1

tyndur / LOST unter Windows kompilieren

« am: 16. June 2006, 17:40 »

Ich habe mal eine Anleitung geschrieben, wie man eine Umgebung aufsetzt um LOST unter Windows zu kompilieren. Ich hoffe das Ganze ist verständlich.

http://www.soldatserver.rootzilla.de/wiki/index.php?title=Kompilieren

Edit: Kleine Anmerkung: Zur Zeit muss /bin/bash in der buildmk.sh durch sh ersetzt werden, wenn nicht irgendwo ein Cygwin im Hintergrund (d.h. hinter den selbst definierten Path-Variablen) liegt. Später gibt es dafür eine endgültigere Lösung.

2

Offtopic / Änderungsvorschlag

« am: 23. May 2006, 20:30 »

Ok, dann will ich N00Bs Bitte respektieren und meine Gedanken in einem neuen Thema mal weiter ausführen. Und wenn ich schon mal dabei bin, hol ich auch mal weiter aus.

Es geht mir (in erster Linie) nicht darum, dass die Seite einen neuen Hoster braucht, jemand die Seite neu designen oder coden sollte, oder EIN neuer Mod oder Admin ernannt wird, sondern um den Verlust der Integrität (blödes Wort, ich weiss) der Community.

Ich glaube, OS-Dev, was das ist, was die meisten hier herführt, macht keiner hier professionell, sondern ist für alle nur ein Hobby. Sich mit diesem Thema zu beschäftigen entstammt der fixen Idee, etwas von dem man anfangs gar keine und später nur wenig Ahnung hat, besser zu können als andere. Die meisten von uns haben jedoch noch andere Sachen im Kopf wie Schule, Counter-Strike Clans, ehrliche Arbeit, etc. Deswegen läuft das ganz gemächlich ab und zwischen den einzelnen Erfolgen liegen Monate, wenn nicht sogar Jahre.

Diese Idee, ein Schöpfer von etwas grundlegendem und dennoch speziellem (ein OS) zu sein, und diese Motivation, an der an sich nichts schlechtes ist, breitet sich jedoch auch in andere Bereiche in dieser Community aus, wo wesentlich mehr Verantwortung gefordert ist. Dennoch bleibt diese Einstellung eines Hobbys haften und die Unverbindlichkeit seine Aufgaben zu erfüllen. Das ist ebenfalls kein bisschen falsch, allerdings unter der Voraussetzung, dass es andere gibt, die dann einspringen, wenn einer "nachlässt". Eine Community muss geführt werden, sonst fällt sie auseinander, und zusammen halten. Wir haben hier zwei sehr gute Beispiele dessen, woran ich mich störe.

Fangen wir bei mastermesh an: Wenn ihr euch mal die ersten Ausgaben von Lowlevel anschaut, seht ihr dass es ursprünglich ein mastermesh-Magazin war. Das war auch gut so, denn mastermesh war daran interessiert und engagiert. In späteren Ausgaben wird jedoch offensichtlich, dass er die Lust verloren hat. Er hat dann die Leitung an Roshl abgegeben, und nach nur einer Ausgabe hat Joachim Neu die Leitung übernommen, die er auch schon wieder abgegeben hat. Dennoch hat er immer die Macht auf sich fixiert, und immer dafür gesorgt, dass er die Kontrolle hat. Die Auswirkung könnt ihr alle sehen: Seine von ihm eingesetzten Admins und Moderatoren, lassen sich hier praktisch nicht mehr blicken, und hier geht es für die ruhigen Lowlevel-Verhältnisse drunter und drüber.

Dann gibt es noch Toaster: Er hat so ziemlich alles bezüglich LOST im Griff. Bloß blöd wenn die Telefongesellschaft ihn nicht ins Internet lässt. Schon bleibt das Projekt wieder stehen und alle, die schon erste Artworks mit Paint für die GUI gemacht haben, können sie wieder einpacken. Es ist nicht Toasters Schuld, dass es niemanden gibt, der das Projekt in seiner Abwesenheit weiterführt, sondern wir können froh sein, dass überhaupt jemand was tut.

In beiden Fällen ist das Problem, dass einzelnen Personen die gesamte Verantwortung übertragen wurde. Jedoch die Ursache ist unterschiedlich. Während bei LOST nur nörgelnd zugeguckt wird, wie - irgendwer hatte es so genannt - "ToasterOS" unter anderem Namen entsteht, wird bei dem viel akuteren Problem einfach nur ausgeharrt. Dieses Hoffen darauf, dass mastermesh oder Roshl (ich glaube er war der einzige andere Admin) zurückkehren, um sich ihnen praktisch zu unterwerfen, kotzt mich an. Uns fehlt nicht EIN Admin, sondern eine Gesamtführung, die zuverlässig ist.

Ich finde es komisch, dass dann immer gesagt wird, "X hat 100 Posts" oder "Y kennt sich aus, macht den zum Mod/Admin!". Das geht an dem Problem vorbei, denn auf so eine Hierarchie, wie sie hier (nicht) herrscht, kann man sich nicht verlassen. Stattdessen brauchen wir eine komplett neue Admin- und Moderatorengruppe, mit wesentlich demokratischeren Strukturen. Etwas, das hier schwerlich geht, ohne dass mastermesh seine Macht abgibt, oder zumindest (genau wie alle anderen Admins dann) teilt.

Dafür ist aber ein Umdenken in der Community nötig, weg von der Passivität, wie sie hier einige bei LOST zeigen, hin zu mehr Beteiligung. Denn wir brauchen ganz sicher mehr als einen Admin/Mod, denn 6 reichen offensichtlich nicht. (ich habe 3 Admins und 3 Mods gezählt, von denen alle aus verschiedenen Gründen ziemlich unbeteiligt sind.)

Deswegen lautete mein Vorschlag vorhin einen kompletten Neuanfang zu wagen. Dies ist natürlich nicht der einzige Weg, dennoch muss irgendwas geschehen, und ich glaube nicht, ob Abwarten und Hoffen das richtige ist. Ich sehe den einzigen Ausweg in einer drastischen Änderung, aber wenn ihr bessere Vorschläge als Nichtstun habt, raus damit.

3

tyndur / Codestil

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

Welchen Codestil werden wir für die Assembler und C-Dateien nehmen? Ich bin dafür, dass wir uns auf einen möglichst einheitlichen Stil einigen, damit der Code gut lesbar und wartbar bleibt.

Für Assembler würde ich vorschlagen, dass Instruktionen mit einem Tab eingerückt werden. Labels werden nicht eingerückt. Dadurch heben sich Labels sofort sichtbar von den Instruktionen ab und die Struktur des Codes ist gut sichtbar. Außerdem sollten Doppelpunkte hinter Labels Pflicht sein, es sei denn es folgt ein db, dw oder ähnliches. Zeilenumbrüche vor Labels und zusammenhängenden Codeabschnitten können die Lesbarkeit noch verbessern, aber strecken bei übermäßigen Einsatz auch die Länge des Codes deutlich.

Beispiel

Code: [Auswählen]

label1:
    mov eax, foo
    sub [bar], eax
label2:
    or eax, eax
    jnz label1
foo db "Foo Bar", 13, 10, 0

Das wars eigentlich schon speziell zu Assembler, was mir so einfällt. Fangen wir also mit dem wohl strittigsten Punkt bei der C Formatierung an: Dem Einrücken und dem Setzen von Klammern. Ich halte folgendes für sinnvoll: (ist glaub ich Kernighan&Richie Style)
 - Immer einrücken mit 1 Tab (im Editor sollte es auf 4 Zeichen eingestellt sein)
 - Hinter einer geöffneten, geschwungenen Klammer ("{") folgt ein Zeilenumbruch und es wird eine weitere ebene tiefer eingerückt.
 - eine Einrückstufe zurück vor einer geschlossenen, geschwungenen Klammer ("}")
 - geschwungene öffnende Klammern bei Funktionensdeklarationen immer auf die nächste Zeile
 - geschwungene öffnende Klammern nach if, for, while, etc immer auf die selbe Zeile.


Beispiel:

Code: [Auswählen]

void tuwas(char *arg);

int main(int argc, char **argv)
{
    int i;
    for(i = 0; i < argc; i++) {
        tuwas(argv[i]);
    }
}

void tuwas(char *arg)
{
    char *foo, *bar;
    if(arg != NULL) {
        if(arg[0] == '-') {
            /* ... */
        } else if(arg[0] == '/') {
            /* ... */
        } else {
            /* ... */
        }
    }
}

Auch hinter einem einzeiligen if, for, while usw, kommen immer geschwungene Klammern. Aber ich denke bei sehr kurzen {}-Blöcken ist es auch sinnvoll den komplett auf die Selbe Zeile wie die if-Abfrage zu schreiben.

Code: [Auswählen]

if(arg == NULL) { doSomething(); }

Im Beispiel habe ich die Pointer-Sternchen auch schon direkt an den Variablennamen geschrieben. Eigentlich gehört der Pointer zum Typ, aber es ist eine fiese Falle, wenn man schreibt:

Code: [Auswählen]

char* foo, bar;
und glaubt foo und bar wären beide jeweils Pointer. Deswegen gewöhne
ich mir an * und & immer an den Variablennamen.
Wobei es am einfachsten so ist:

Code: [Auswählen]

char * foo;
char * bar;
Dann können solche Fehler nicht passieren und die Position des * ist eigentlich egal.

Kommentare sollten C-Style Kommentare sein: Also /* ... */, aber ich denke wir haben alle Compiler, die nicht noch aus dem kalten Krieg stammen, also sollten C++-Style //-Kommentare auch völlig ok sein.

Sonst noch was allgemeines zu beiden Sprachen: (Die Beispiel lasse ich einfach mal in C, wobei sie auch in ASM zutreffen sollten.)

Hinter Kommata und Semikolons ein Leerzeichen, davor keins, wie auch in der deutschen Sprache üblich. Vor und hinter +, -, *, /, %, |, &, ||, &&, <<, !=, !, ~, = usw immer ein Leerzeichen, außer wenn +, -, ~ der ! ein Vorzeichen sind (oder * oder & als Pointer verwendet werden.) Hinter einer öffnenden Klammer und vor einer schließenden Klammer kein Leerzeichen.

Code: [Auswählen]

int foo = !bar;
int foo = -1;
int foo = bar * ((49 + foobar[i] + quux) % 100);
int foo = &bar;
int foo = *bar;

Nicht sofort eindeutige vorrangigkeiten von Rechenoperationen sollten wegen der besseren Lesbarkeit mit Klammern verdeutlicht werden.
Nicht so gut:

Code: [Auswählen]

int foo = bar << foobar & mask; /* was wird zuerst ausgeführt? der shift oder die &-operation? */
Besser:

Code: [Auswählen]

int foo = bar << (foobar & mask); /* so ist es eindeutig */

Konstanten und Makros immer in Großbuchstaben schreiben.

Code: [Auswählen]


// C:
#define KERNEL_LOAD_ADDRESS 0x10000
; NASM-Syntax:
%define KERNEL_LOAD_ADDRESS 0x10000
; oder
KERNEL_LOAD_ADDRESS equ 0x10000


Wir müssen nicht unbedingt mit Tab arbeiten um einzurücken, aber es ist einfach sinnvoller, weil dann das Einrücken konsistent ist. (Kein Leerzeichen zählen. Außerdem ist Speicherschonend .) Wer sein Tab auf 8 Zeichen eingestellt hat und sich darüber aufregt, dass bereit nach 4 Tabs der Code schon über den rechten Bildschirmrand hinausragt, sollte seine Editoreinstellungen korrigieren. (Oder auf meinen Lieblingseditor Code::Blocks umsteigen. )

Ich hoffe mal ich hab das Wichtigste genannt. Auf jedenfall hab ich mich nicht grad kurz gefasst. Die Vorschläge basieren alle auf meinem persönlichen Stil und ich halte sie somit für das non-plus-ultra Das muss aber nicht mit eurer Meinung übereinstimmen und deswegen denke ich, wir sollten uns schnell auf einen Stil einigen, damit dadurch nicht die eigentliche Programmierung aufgehalten wird. Ich bin auch bereit mich an eure Code-Stile anzupassen, sofern sie denn sinnvoll sind und sich alle dran halten.

Wenn wir uns geeinigt haben, ist dies sicherlich aus was, das man ins Wiki übertragen sollte.