Nachrichten

1501

Offtopic / Video von allem auf dem Bildschirm erstellen

« am: 25. May 2005, 00:37 »

Fraps (Spiele), Hypersnap DX (Spiele + Windows), Camtasia (Windows)

1502

OS-Design / Wie Windows arbeitet ...

« am: 24. May 2005, 11:55 »

@N00B: naja also es haben leute geschafft was damit anzufangen. irgendeine lücke beim verwalten von bitmap (wenn ich mich recht errinnere) ist aufgedeckt wurden, indem sich die leute den code angeschaut haben.

Wie kann eine Firma auf dieser Welt nur 200 Megabyte unkommentierten, unnützen, unbrauchbaren und unübersichtlichen Quelltext zusammenkopieren? (Ich sage bewusst zusammenkopieren ^^)

indem sie es einfach tun? ist ja nicht schwer, wenn man genug codesklaven hat, kostet ein paar mille, aber passt scho, und funktionieren tuts auch noch einigermaßen

den windows source code gibt es übrigens auch kostenlos, legal und (fast) vollständig: Shared Source ... allerdings nur für ausgewählte personen ("most valuable professionals")
einige unis und firmen haben z.b. durch dieses programm auch einblick in den code

1503

OS-Design / Wie Windows arbeitet ...

« am: 23. May 2005, 23:08 »

... genauso wie das disassemblieren

1504

Offtopic / Danger !

« am: 18. May 2005, 17:00 »

Was waren die letzten Worte eines PC Users, der nur mal eben die CMOS-Batterie rausnehmen wollte?

Aber ich versichere dir, dass selbst 286er noch mit Originalbatterien
laufen und nicht explodieren.

*scnr*

@Topic: Mehr als ein kleines Puff (eher ein Zischen) und eine mittelkleine Sauerei (weniger schlimm als Cola über die Tastatur) mit irgendwelchen Elektrolyten kann ich mir bei einer Batterieexplosion aber auch nicht vorstellen.

1505

tyndur / [KERNEL] SDK Release Milestone 0

« am: 16. May 2005, 20:00 »

ich finde, es ist nicht so intelligent in setpath.bat die alte PATH-Variable vor die neue zu. es sollte wohl besser

Code: [Auswählen]

set PATH=[...];%PATH%
heissen, um wirklich die mitgelieferten compiler zu nehmen und nicht den eigenen, der sonst weiter vorne im PATH ist.

und dann find ich die wahl von `make install' für die installation des floppy-treibers ein bisschen irreführend. normalerweise verstehe ich unter `make install' wirklich die installation der software. also hier das was `make copy' macht.

1506

Offtopic / Kleine Programmierspäße

« am: 13. May 2005, 23:15 »

übrigens wenn man will das int sicher 16 bit ist schreibt man short und fertig

Was tut das dann auf nem 8-Bit-System mit nem Buggy Compiler?? Sicher ist nie was...und bei C erst Recht nicht.

short ist garantiert mindestens 16 bit groß. steht so im standard. wer verbuggte compiler nutzt, ist selbst schuld.

sehr schön find ich auch noch sowas:

Code: [Auswählen]

printf("%s", &0["foobar"]);

1507

OS-Design / ToDo Liste

« am: 13. May 2005, 23:11 »

Was zu implementieren wäre...
Speichereien, Multitasking, Shell/GUI, Anwendungs-API.
Hardwareschnittstelle mit Treibern, Netz wäre prima, Unterstuetzung
fuer Speichermedien lebensnotwendig (FD, HD, CD). Naja und so weiter halt...

Linux hat all das schon in Version 0.0.1 gehabt. Ich würde sagen, 1.0 ist die Version, die das erste mal im Laden steht/stehen könnte.

1508

OS-Design / ToDo Liste

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

Und Programme sollten dabei sein. Sonst ist es nur ein Kernel *klugscheiss*

1509

Offtopic / Kleine Programmierspäße

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

(*(void(*)())0)();

sollte das gleiche sein wie

Code: [Auswählen]

call 0x00000000

(void(*)()) macht aus der 0 einen Zeiger auf eine Funktion und (*[...])() ruft diese dann auf, denk ich mal.

Auch in C weiss man wie gross ein Integer ist :32Bit auf 32Bit Systemen 16 auf 16Bit Systemen was daran so schwer?

Die Schwierigkeit ist, dass ein Programm, das von 32 Bit Integern ausgeht, auf einem 16 Bit System aufgeschmissen ist, weil es dauernd overflowed. (Bzw. genauer gesagt: bei einem Compiler, der 16 Bit ints hat). Auf einem 64 Bit System ist ein Integer (int) afaik immer noch 32 Bit groß. Also das ist (leider) keine allgemeingültige Regel ...

1510

Lowlevel-Coding / java in osdev

« am: 09. May 2005, 18:44 »

http://java.sun.com/docs/books/vmspec/ <-- schaut recht offiziell aus

1511

Offtopic / Fentilator

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

Warum sagen wir nicht gleich Windträger (Ventus = Wind, lator -> latum -> ferre -> tragen)

sonst würd ich mal elfish_riders lösung ausprobieren. Im Gerätemanager müssten eigentlich die USB-Anschlüsse aufgelistet sein (evtl. sogar der Lüfter selber). Den würde ich erstmal versuchen zu deaktivieren. aber obacht: wenn du einen USB-Root-Hub deaktivierst, könnten evtl. andere USB-Geräte auch ausgehen ... egal, probieren geht über studieren

1512

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

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

Mikrocontroller werden zu Tausenden in (fast) reinem C Programmiert.

streng genommen nein. weil "in()" und "out()" nicht zu C gehören, sondern zu der lib

nein so mein ich das nicht. bei bestimmten plattformen gibt es keine ports, die man per in und out ansteuert, sondern die sind direkt in den speicher gemappt. also wenn man an ein bestimmtes offset im RAM was schreibt landet es bei irgendeiner hardware.

DDR-RAM: hmm ... das erste Beispiel hat mich irgendwie überzeugt. da kann ich nix mehr gegen C++ sagen. wobei ich nicht dafür bin, alles zwanghaft abzuleiten, sondern ab und zu auch einfach mal ein struct als eigenschaft eines objekts zu machen.

<-- widerstand gegen c++ aufgeb

1513

tyndur / Source-Verwaltung

« am: 09. May 2005, 16:34 »

Vorteile von Subversion gegenüber CVS

• In Subversion können Dateien (und Verzeichnisse) auch umbenannt und verschoben werden. In CVS muss eine Datei an der alten Stelle auf "Gelöscht" gesetzt und an der neuen Stelle neu eingefügt werden, wobei die Historie der Datei nicht übernommen wird.
• Subversion kann auch Verzeichnisse und Dateiberechtigungen (rwx) verwalten.
• Subversion bietet einen verbesserten Umgang mit Binärdaten. Es erkennt binäre Dateien (beispielsweise Bilder oder Audiodateien) automatisch und es werden (wie bei Textdateien) nur die Differenzen zwischen den geänderten Versionen gespeichert. In CVS geht das umständlicher über Eintrag von binären Dateitypen (deren Endung) in cvswrappers und wobei diese Filetypen voll gespeichert werden.
• Commits sind in Subversion atomar, weshalb eine Änderung entweder komplett oder gar nicht ins Repository gespeichert wird. Verbindungsabbrüche und mehrere, gleichzeitige Commits können somit nicht zu inkonsistenten Zuständen führen.
• Das Versionsschema von Subversion bezieht sich nicht mehr auf einzelne Dateien, sondern auf das ganze Repository. Bei jedem Commit erhöht sich die Revisionsnummer aller Dateien. Somit kann man einfacher eine exakte Version beschreiben (z. B. "Version 2841" statt "Version vom 23. März 2004 20:56:31 GMT"), allerdings bedeutet dies auch, dass sich zwei Revisionen einer Datei nicht unbedingt unterscheiden müssen.
• Zusätzlich zu einem eigenen Server und der Speicherung im lokalen Dateisystem existiert auch ein Modul für den Apache 2 Webserver, mit dem die Daten auch mit der HTTP/HTTPS-Erweiterung WebDAV übertragen werden können.
• Einige Operationen (update, tagging, branching) sind deutlich schneller als bei CVS.
• Manche Operationen, welche bei CVS Zugriff auf das Repository benötigen, kommen bei Subversion ohne einen solchen Zugriff aus, da eine Kopie der BASE-Revision innerhalb des Arbeitsverzeichnisses gespeichert wird. Dadurch entfällt bei Remote-Repositories die Notwendigkeit eines Netzwerk-Zugriffs.
[/list:u]

Nachteile gegenüber CVS

• Die gleichen Daten (z. B. nach Konvertierung) benötigen in einem Subversion-Repository deutlich mehr Platz als in einem CVS-Repository.
• Da im Arbeitsverzeichnis eine Kopie der BASE-Revision gehalten wird, benötigen Arbeitsverzeichnisse ungefähr den doppelten Platz.
• Subversion ist noch nicht so gut getestet wie CVS.
• Benötigt den Apache HTTP Server 2.0, wenn das WebDAV-Feature genutzt werden soll. Allerdings könnte man hier entgegnen, dass CVS WebDAV gar nicht unterstützt. Außerdem gibt es auch ein eigenes Protokoll, welches vergleichbar mit dem Netzwerkprotokoll von CVS ist.
[/list:u]

Quelle

Viele der Punkte hätte ich auch selber nennen können, aber wozu gibt es die Wikipedia? Wirklich Interessierte hätten zunächst mal eine Suchmaschine oder Wikipedia befragt

1514

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

« am: 09. May 2005, 16:16 »

naja exceptions in einem kernel machen den kernel nur inkonsistent, weil man nie sicher sein kann wann eine geworfen wird und wann nicht. wenn wir new aber richtig verwenden wollen, dann brauchen wir exceptions, weil das "standard konforme" new eine exception (bad_alloc) wirft.

da fallen mir die casts ein, die in C++ schreibarbeit (static_cast<...>) sind und gerne mal exceptions werfen. (naja wobei ich mir selbst nicht vorstellen kann wo da exceptions auftreffen sollten ...). in einem kernel gibts es sicherlich auch tausende casts und ich hoffe doch ihr wollt in einem C++-Kernel nicht mit C-Style casts ankommen, oder?

Verstehe ich nicht recht, die Treiber gehören doch nicht zum Mircokernel?

Treiber müssen aber irgendwie mit dem Kernel kommunizieren. Dazu müssen sie sich einigen ob C++-Objekte oder einfache C-Structs transportiert werden. Das gibt für einen C++-Kernel sehr viel Konvertier-Arbeit.

Aber festgenagelt werden sie aber auf jedenfall nicht, wenn sie kein C verwenden, denn das C-Interface wird mit extern "C" deklariert.

ja klar geht das so, aber was ist daran dann noch C++? Da kann ich mich doch gleich auf C beschränken.

Der Kernel selber, befasst sich gar nicht so viel mit Hardware, das machen doch eher die Treiber, der Kernel befasst sich mit Abstrakten Typen, wie Prozessen, die sehr wohl als Objekt darstellbar sind.

Was wenn ein C/Assembler/Pascal-Programm Informationen über einen Prozess haben will? Dann muss diese C++ Prozessinformation von Kernel erst umständlich in ein c-struct verpackt werden. Mit allen anderen Informationen, die in (Instanzen von) Klassen gespeichert sind, ist es genauso. es müssen also alle strukturen, die für andere programme/treiber von belang sind in 2 formen (c-struct und c++-objekt) vorhanden sein und es muss möglichkeiten geben, sie in einander umzuwandeln.

Zeige mir ne Hardware die man mit C ansteuert, rofl.

Mikrocontroller werden zu Tausenden in (fast) reinem C Programmiert.
Außerdem meinte ich dass Hardware nicht besonders darauf ausgelegt ist, als ein "Objekt" im Sinn von C++ behandelt zu werden.

Bereits geregelt... zum größten Teil.

gut

1515

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

« am: 08. May 2005, 19:33 »

C++ hat auf jedenfall einige Nachteile:

- Overhead mit new/delete, Exceptions, etc ... (ok ist relativ gering)
- Treiberprogrammierer werden dann auch dazu gezwungen ihre Treiber in C++ zu schreiben. Ein Interface von C++ nach C ist wesentlich komplizierter als von C nach C++.
- Bei der Treiberprogrammierung kommen dazu noch üble Probleme bei der Kompatibilität (C-Funktionen können einheitlich exportiert/importiert werden, bei Klassen kocht hingegen jeder Compiler sein eigenes Süppchen). Die Treiberprogrammierer werden also auf den GCC festgenagelt.
- C++ bringt keinen Vorteil bei der Programmierung von Hardware. Hardware ist darauf ausgelegt von einem Assembler- oder C-Programm (oder einer anderen Prozeduralen Programmiersprache) bearbeitet zu werden. Also nicht Objektorientiert oder ähnliches. Große Teile der Kernels werden einfach aussehen wie C-Code.

1516

tyndur / CommFS?

« am: 08. May 2005, 17:10 »

Ich stimme DDR-RAM zu.

Meiner Meinung nach ist ein eigenes Dateisystem überflüssig. Es ist zwar für den Anfang einfacher ein eigenes FS zu implementieren, weil man sich alles selbst ausdenken kann und sich nicht an irgendwelche Datenblätter halten muss, aber wenn es ein "richtiges" OS werden soll bringt das eh nix, weil es inkompatibel ist und somit im praktischen Einsatz unbrauchbar. Der Lerneffekt ist bei einem bereits verbreiteten Dateisystem außerdem viel höher. Es gibt heutzutage dutzende Standards in allen Bereichen und das Problem bzw. die Aufgabe beim Programmieren eines Betriebssystems ist mMn unter anderem das Auswählen und Implementieren bereits vorhandener Spezifikationen.

1517

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

« am: 08. May 2005, 17:05 »

Bloß mit C++ arbeiten zu _wollen_ reicht auch nicht. Wer traut sich es zu durchzuplanen welche Klassen es gibt, welche Hierarchien es geben soll, etc.? Wenn man ein richtiges C++-Projekt nicht durchplant, kann man die Möglichkeiten von C++ gar nicht ausschöpfen, sondern hat nur Flickwerk. Ist da ein relativ offenes Modell in C nicht sinnvoller und einfacher?

Ein Projekt mit einem gewissen Einsatz von C++ wird zwangläufig abstrakt. Wenn aber der Kernel zu abstrakt wird, wird alles extrem unübersichtlich und  dann kann davon auch keiner mehr was lernen. (Es soll doch noch eine art "Lern-OS" werden, oder?)

Also eine String Klasse gehört auf keinen Fall in einen Kernel. Vor allem nicht in einen Mikrokernel. Im Kernel muss außer für Fehlermeldungen fast gar nicht mit Zeichenketten gearbeitet werden. Und Fehlermeldungen sind const char*'s ...

1518

tyndur / Source-Verwaltung

« am: 08. May 2005, 16:55 »

<-- pro SVN

1519

tyndur / Namens-Abstimmung zum CommOS

« am: 08. May 2005, 12:45 »

bin für LOST mit einem L

1520

Lowlevel-Coding / C++: Bestimmten String aus Datei lesen

« am: 05. May 2005, 16:09 »

hm ich hab gedacht der code sollte so eine art tutorial sein, weil du keine frage gestellt hast.

also was mir auffällt:

tmp ist 4 bytes groß, aber du schreibst auch in tmp[4] (das ist das 5. byte) was rein. -> buffer overflow

str ist ein zeiger auf einen char, aber du initialierst str nicht. deswegen wird ein x-beliebiges stück memory bei *str++ = ch; und *str= '\0';  getrasht -> noch eine art buffer overflow