Nachrichten

561

Offtopic / Plattformübergreifende API

« am: 03. June 2005, 16:49 »

POSIX und Konsorten würde ich persönlich aber abschaffen - POSIX wegen Konzepten wie fork() usw. unter Konsorten würde ich mal z.B. BSD Sockets mal packen (das ewige hin- und hergecaste, oh man). Und einen echten Standard für GUI Programmierung gibt es in diesem Umfeld nicht.

Deswegen würde ich mir eher die Frage stellen: Warum macht niemand eine GUTE plattform übergreifende API, und ich würde sagen, da käme man schon weit wenn man Java oder auch .NET für C++ abkupfern würde.

562

Offtopic / eigene api erstellen

« am: 02. June 2005, 17:19 »

NTFS kann ja zu einer Datei beliebiege Attribute speichern, das macht sowas gleich einfacher ...

563

Offtopic / Vergleich von OpenGL und DirectX

« am: 01. June 2005, 19:31 »

Stimmt, da hab ich nicht nachgedacht und vom Threadtitel blind abgeschrieben.
EDIT: Andererseits macht ein Vergleich anders auch kaum einen Sinn - natürlich kann man DirectX es als Vorteil anrechnen, nicht nur die 3D API zu sein.

564

Offtopic / Wo ist der Unterschied

« am: 31. May 2005, 21:54 »

Du kannst z.B. nach wie vor den selben Floppytreiber brauchen, aber z.B. zusammen mit ext2fs von Linux, das geht auch (natürlich nicht mit Floppies die von Windows formatiert wurde).

565

Offtopic / Vergleich von OpenGL und DirectX

« am: 31. May 2005, 18:53 »

Jo, ich wage trotzdem mal einen (sehr) groben Vergleich:

- OGL
  Grosser Vorteil: Platformunabhängig (zumindestens im Kern)
  Möglicher Vorteil - Erweiterbar: ATI und NVidia bringen sehr schnell ihre neuesten Technologien als OpenGL Extensions raus - somit könnte man schneller auch diese nutzen.
  Vorteil - Abwärtskompatibel: Alte OpenGL Programme laufen nach wie vor.

 Mögliche Nachteile:
    - "Unaufgeräumt": Es befinden sich auch noch sehr, sehr veraltete Funktionen im Standard und in jedem OGL Treiber, und wenn man die unbedacht benutzt mit neueren Funktionen aus neueren Extensions, dann kann das durchaus zu Überraschungen führen (z.B. NVidia's VAR Extension wollte auf ner Geforce 2 nur in ganz bestimmten Konstellationen beschleunigend sein! )
    - Teilweise Hardwarespezifisch: ATI und NVidia bringen ihre neuesten Technologien direkt als OpenGL Extensions auch raus - allerdings ist das Architecture Review Board nicht grad schnell wenn es darum geht eine einheitliche Lösung zu präsentieren (z.B. weil Microsoft da auch drin sitzt?)
    - Evtl. etwas aufwendiger: Wegen den Extensions muss man sich auch damit rumschlagen - suchen, initialisieren, usw.

DirectX:
  Vorteile:
    (Fast?) Immer aufgeräumt: Nach dem erstem, schlechtem Weg über Execution Buffers kam das direkte Zeichnen von Primitiven, was die Programmierung erleichterte - das alte Interface wurde rausgeschmissen (es steht in der Runtime natürlich noch zur Verfügung, aber wenn man für DirectX9 programmiert, wird man es nicht benutzen können). Ähnlich verfährt Microsoft bei jedem grösserem Versionssprung.
   (Eigentlich) Generisches Programmieren: Microsoft bemüht sich auch dafür zu sorgen das die Programmierer mit einem Stück Code ATI und NVidia-Karten abdecken können. (In der Praxis gibt es aber scheinbar doch ein paar Fallstricke)

Nachteile:
     Nicht abwärstkompatibel: Man wird wohl grosse Stücke alten Codes wohl nicht ohne Änderung auf eine neue DirectX Version übernehmen.
     Nicht erweiterbar: Generell ist eine DirectX Version ziemlich festgelegt.
     Nicht platformunabhängig: Da es DirectX ja nur für Windows gibt.

Wie man sieht, tauchen auf beiden Seiten Features sowohl bei Vorteil als auch bei Nachteil auf. Wenn man sich sowieso auf Windows festlegen will, wird die Platformunabhängigkeit wohl keine Rolle spielen, usw.

566

Lowlevel-Coding / Wieviele Takte benötigt ein Befehl?

« am: 31. May 2005, 18:31 »

sind wenig im Vergleich von einem guten zu einem schlechten Algorithmus.

Ja, das will keiner abstreiten

Ja warum streitet ihr euch dann hier überhaupt? Ja, 20-30% waren schon aus der Luft gegriffen, aber zumindestens früher war das durchaus noch möglich (und da hab ich auch schon programmiert, falls jemand auf die idee kommen sollte sich zu fragen warum mich das interressiert )

GCC 3.4 und die aktuellen Intel Compiler usw. machen es einem da schon viel schwerer

Aber wenn dann lohnt es sich auch mehr die Compiler zu optimieren als alles in Assembler zu optimieren - wenige (zwar grosse) Programme die verbessert werden, und dadurch laufen alle Programme schneller, als wenn man alle(!) Programme auf dieser Ebene optimieren wollte.

Ähnlich sieht es wohl auch innerhalb eines einzigen Programmes aus - in der Art das man dafür sorgen sollte auch nen aktuellen Compiler zu haben (der dann hoffentlich besser optimiert).

567

Lowlevel-Coding / Wieviele Takte benötigt ein Befehl?

« am: 31. May 2005, 13:26 »

Boah leute, die 20-30% die ne gute(!) ASM Implementierung wohl gegenüber ner guten(!) Hochsprachenimplementation bringen wird (ausser wohl im Bereich von SIMD, da die Compiler wohl noch nicht so toll sind ) sind wenig im Vergleich von einem guten zu einem schlechten Algorithmus.

Implementiert erstmal einen ordentlichen Algorithmus, wenn ihr das habt, dann guckt mal ob sich ASM überhaupt lohnt.

568

Lowlevel-Coding / Sprung R0 nach R1

« am: 30. May 2005, 10:37 »

Unter AMD64 ist das gut möglich ... unter x86 wohl eher nicht wenn man die Ringe benutzt (und das wird man ja meistens ...)!

Obwohl, SYSCALL/SYSENTER könnten auch eine Möglichkeit bereitstellen, kann ich aber nicht exakt sagen!

569

Lowlevel-Coding / Grafikkartenstandards?

« am: 28. May 2005, 23:29 »

Na ja, man kann es auch so sehen das die Linux Entwickler es nicht wollen/packen das ATI und NVidia die Treiber *ordentlich* für sie schreiben können, aber das ist eigentlich OT und führt schnell zu Flames.

570

Offtopic / Ein wenig Win Source beim VS .Net

« am: 28. May 2005, 10:32 »

Dann konnte dein malloc die Anfrage ohne zusätzlichen Speicher erfüllen, probier mal so 30mb zu allokieren.

571

Offtopic / Ein wenig Win Source beim VS .Net

« am: 27. May 2005, 21:16 »

Das ist die C/C++ Bibliothek, und sowas gibt es schon auch z.B. beim MSVC++ 6.0. Wenn du immer weiter in die Funktionsaufrufe reingehst, wird dir evtl. a) irgendwann assembler begegnen aus ner Datei deren Source Code halt nicht dabei ist oder aber sicher b) die Meldung das man in Systemaufrufen nicht reinspringen kann.

572

Lowlevel-Coding / RISC CPU

« am: 27. May 2005, 18:59 »

Na ja, im Desktopsegment verdient man nicht direkt - aber könnte ne Architektur durchsetzen!

573

Lowlevel-Coding / RISC CPU

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

Und es gab keine IA-64 CPU die ein "Normalsterblicher" sich einfach hätte leisten können - dafür sollte es ja weiter hin 32-Bit x86 geben.

574

OS-Design / Zum Thema Mikrokernel

« am: 27. May 2005, 14:52 »

Um Bound zu benutzen musst du auch wissen wie lang der Puffer ist, und an nem simplem Pointer, der am besten noch aus nem long wert initialisiert wurde, kannst du dies in der Regel nicht ablesen. Da muss man schon einiges intern tun damit das klappt.

575

OS-Design / Zum Thema Mikrokernel

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

Und nix mit Datenpacket von aussen. Wenn du nun ein Packet einliest und den Wert auf den Stack pusht und ret machst - nun, das ist dann scheinbar der Sinn der Funktion. Die ist dann etwas dämlich, aber da fehlt immer noch der Angriff.

576

OS-Design / Zum Thema Mikrokernel

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

Nein, weil dein Puffer, den du halt auf dem Stack allokiert hast, overflowed wird *g*. Mit dynamischem Speicher lässt sich "weniger" anfangen was exploits angeht, aber nen statisches Array auf dem Stack ist so schön simpler ^^

EDIT: Da war einer schneller als ich!

577

Lowlevel-Coding / Sprung R0 nach R1

« am: 27. May 2005, 13:30 »

Per einfachem Rücksprung kommst du sowieso nicht in Ring 0 zurück.

578

OS-Design / Zum Thema Mikrokernel

« am: 27. May 2005, 13:25 »

Ehm, nein, sogar im Studium hiess das auch Buffer Overflow - abgesehen das die ganzen Buffer Overflow die man evtl. auf heise.de findet zum Code einschleusen immer solche Fehler sind.

579

Lowlevel-Coding / Sprung R0 nach R1

« am: 27. May 2005, 13:21 »

Wie kann es denn vor dem ret den Stack manipulieren? Da läuft doch noch Ring 0 Code. Und bevor du in den niedrigeren Ring springen willst, wirst du wohl den Stack anpassen wollen (bei iret geht das ja in einem Schritt), abgesehen davon das der Stack vom Ring 0 gar nicht erst erreichbar sein dürfte für den Ring 1 Code.

580

OS-Design / Zum Thema Mikrokernel

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

Bei nem DoS schon, aber der ist ja noch richtig harmlos im Vergleich zum Buffer Overflow - damit könnte man System ja nicht nur vorrübergehend lahm legen, sonder infizieren, das macht direkt noch viel mehr Spass!