Treiber machen

Status
Für weitere Antworten geschlossen.
und was für ne kernelarchitektur hat zb. windows?

wird der adressraum von zb. der grafikkarte auch protected?
 
DonnyDepp schrieb:
wer redet von spielen?
schonmal was von grafikdemos gehört?
http://www.pouet.net/
wenn dem so wäre, müsste bei der Installation eine Windows-Warnung kommen, dass du einen nicht zertifizierten Gerätetreiber installierst, ist dem so? Nein! Die programmieren auch keine Treiber sondern nur eine Softwarebibiliothek auf Basis von der Graka durch Treiber bereits zur Verfügung gestellten Funktionen.

F.b schrieb:
@ice-breaker deswegen schrieb er ja auch nicht-directX-basiert (wobei openGL auch geht;)). Klar schreibt kein Spielehersteller seinen eigenen Treiber^^
es ist trotzdem noch immer kein Treiber, selbst mir einem "nicht-directx-basiert" Hinweis. Ein Treiber ist etwas ganz anderes.

DonnyDepp schrieb:
wie würde man das denn machen, um die hardware direkt anzusprechen?
Dazu benötigst du erstmal die Spezifikationen von ATI oder Nvidia für eine ganz spezielle Grafikkarte, und diese wird man dir nicht geben.
 
da verwechselst du was.
die windows-warnung von wegen nicht-zertifizierter treiber kommt, wenn du einen "richtigen" treiber installierst.
hier wird aber nur ein programm ausgeführt.

btw.
asdfman schrieb:
Jeder einzelne Grafikchip hat eine eigene Architektur und Maschinensprache.
mit deinen worten hört sich das so an, als wär die grafikkarte eine komplette blackbox und nur über vesa, opengl oder directx ansprechbar?


evtl. war jetzt die grafikkarte ein schlechtes beispiel, weil da alle aus ihren löchern gekrochen kommen...
aber grundsätzlich ist doch treiberprogrammierung (hardwareprogrammierung) nichts anderes, als bits in die register der geräte zu schreiben.
oder ganz simpel ausgedrückt: schalter umlegen bis der taktgeber den zustand auswertet (das kann man auch selbst sein, wenn man den stecker kurz in die steckdose steckt), das ergebnis zu erhalten und die schalter erneut umlegt.

@Ice-breaker:
http://www.x.org/docs/AMD/R6xx_3D_Registers.pdf
aber für softwarerendering reichen auch die standardregister...
 
Zuletzt bearbeitet:
DonnyDepp schrieb:
da verwechselst du was.
die windows-warnung von wegen nicht-zertifizierter treiber kommt, wenn du einen "richtigen" treiber installierst.
hier wird aber nur ein programm ausgeführt.

Um mit der Hardware kommunizieren zu dürfen, musst die Software sich als Treiber ausgeben, die ein Teil der Hardwareabstraktionsschicht ist.
http://de.wikipedia.org/wiki/Hardwareabstraktionsschicht

Nur die Hardwareabstraktionsschicht kann auf Hardware zugreifen, alle andere Software kann und muss es nur unter Vermittlung der Hardwareabstraktionsschicht.

Und selbst dann ist es nicht mal möglich, direkt mit der Grafikkarte zu kommunizieren, da diverse Controller dazwischen liegen. Man Kommuniziert dann mit den Controllern.
http://de.wikipedia.org/wiki/Gerätetreiber

Dazu nutzt es Schnittstellen zum Kommunikationsbus oder anderen Kommunikationssystemen, an denen das Gerät angeschlossen ist, um Steuersignale und/oder Daten zum Gerät zu senden bzw. von ihm zu empfangen.
 
Zuletzt bearbeitet:
richtig. "alle andere Software kann und muss es nur unter Vermittlung der Hardwareabstraktionsschicht"
und ein treiber ist eine software.
aber eine software muss nicht unbedingt die eigenschaften eines treibers besitzen.

zwei sätze weiter:
Sie erleichtert es auch, Gerätetreiber zu programmieren, weil diese auf der Hardwareabstraktionsschicht aufsetzen.
 
Zuletzt bearbeitet:
Treiber sind Teile des I/O-Managers und die Treiber müssen sich dort Registrieren, damit sie überhaupt geladen werden, aber wenn ich eine Demo starte sehe ich nicht, dass dort ein Treiber geladen wird.

Was meinst du, wieso die Treiber eines Kopierschutzes (z.B. SecuROM) im GeräteManager zu finden sind? Richtig! Weil der Treiber sich registriert hat.

Also dann erkläre mir mal, wie die Demoszene es schafft Treiber zu entwickeln, die sich nicht im I/O-Manager registrieren brauchen, während Hardware Entwickler (SecuRom wurde von Sony entwickelt) es nicht schaffen?

Auf diese Antwort bin ich gespannt.
 
ok ^^
aber bevor ich dir die frage beantworte, erkläre mir doch mal, was du unter einem "treiber" verstehst :D
auf diese antwort bin ich gespannt
 
oh super, du verlinkst wikipedia.
nagut... wo steht, dass sich ein treiber beim iomanager registrieren muss? (was auch immer du dadrunter verstehen magst, verlinkst du ja nur wikipedia)

abstraktes "fassbares" beispiel:
virtuelle maschinen. sind die treiber in der virtuellen maschine keine treiber?
sie sind schließlich nicht im "io-manager" (meinst wahrscheinlich kernel) des host-systems.



nagut, ich kürze das mal ab...
http://www.enzyklo.de/Begriff/virtuelle Treiber
"virtueller treiber" ist eine software, die direkt auf die hardware zugreift.
sei es um als "treiber" damit eine schnittstelle für andere software bereitzustellen (opengl dx), oder nur um ausschliesslich selbst die hardware zu benutzen.
und jetzt zum link weiter oben: http://de.wikipedia.org/wiki/Betriebssystemkern
windows 95/98 hatte eine monolithischen kernel. dh. alle programme werden im userspace ausgeführt und haben keinen zugriff auf die hardwareregister. virtuelle treiber sind hier also ausgeschlossen, jeder treiber muss installiert werden.

alle windows-versionen danach haben eine microkernel-architektur. wie man aus der grafik in wikipedia sieht, sind die "gerätetreiber" im gelben "Benutzermodus"-Bereich.
dh. man kann mit assembler oder c direkt auf die register zugreifen, die von der hardwareabstraktionsschicht gemapt werden.
n kumpel hat mal ne eigene rendering-engine geschrieben. dh. per hand die einzelnen register befüllt und damit punkte aufm bildschirm erzeugt.
linien, ebenen, translationen etc. müssen da auch per "hand" berechnet werden.
er hat nicht die 3d-register der grafikkarten benutzt, sondern nur die standardregister, die auch benutzt werden, damit man nach dem einschalten etwas sieht... und zwar egal, welche grafikkarte nun um rechner steckt.
oder habt ihr schonmal ein mainboard gekauft, das nur mit einer speziellen grafikkarte läuft? :D


trotzdem müssen wir den threadersteller enttäuschen, weil er ohne register-dokumentation seine hardware wohl nur unter einem alten betriebssystem benutzen kann.
ausser er ist profi in reverse engineering von treibern ;)
 
Zuletzt bearbeitet:
Ich hoffe, du kanst Englisch

Die Dokumentation des I/O-Managers:
http://msdn.microsoft.com/en-us/library/ff565734(v=vs.85).aspx

http://en.wikipedia.org/wiki/Windows_Driver_Model <- heutiges Treibermodell
http://en.wikipedia.org/wiki/VxD <- Treibermodell von Win 3.x und 9x

Und warum gibst du eigentlich die Demoszene als Beispiel?
Die Demoszene hat ihren Ursprung beim C64, Amiga und Atari. Erst so um 1993 (Mit der Einführung von OpenGL) wurde die Demoszene auf den PC aufmerksam.
Beim C64/Amiga gabs keine Treiber in Softwareform. Wozu auch? Es gibt ja nicht einmal unterschiedliche Hardware. Es gab beim C64 nur zwei Befehle, mit denen man auf die Hardware zugreifen konnte: peek und poke.
Ein Befehl löste Systemroutinen aus: sys
Da es zu dieser Zeit keine großen Schutzmechanismen gab, konnte man mit Assembler direkt auf die Register zugreifen.

Beim Amiga sah das ähnlich aus.

DonnyDepp schrieb:
abstraktes "fassbares" beispiel:
virtuelle maschinen. sind die treiber in der virtuellen maschine keine treiber?
sie sind schließlich nicht im "io-manager" (meinst wahrscheinlich kernel) des host-systems.

Was ist das für ein bescheuertes Beispiel?
Dieses Beispiel passt nicht mal ansatzweise.
Eine VM ist eine Sandbox.

Aber warscheinlich weißt du auch nicht mal, was eine Sandbox ist.

Oh mann ...
Das wird ja immer dümmer.
Virtuelle Treiber müssen sich auch im I/O-Manager anmelden.
Schon mal VirtualBox installierst? Den virtuellen Treiber für die Netzwerkschnittstelle findest du im Geräte-Manager des Host-Systems ...

Und nur zur Info: Windows hat nen Hybrid-Kern ...

dh. man kann mit assembler oder c direkt auf die register zugreifen, die von der hardwareabstraktionsschicht gemapt werden.
Vom virtuellen Adressraum hast du anscheinend auch noch nichts gehört.
Dann versuch mal mit C den Speicher einer anderen Anwendung auszulesen. Viel spaß.

edit:
weißt du, warum es "virtueller Treiber" heißt?
Weil diese Software eine Hardware emuliert.
z.B. ein virtueller Treiber für eine Ethernet-Schnittstelle:
Jede Ethernet-Schnittstelle kann mit der virtuellen Schnittstelle auf normale Art kommunizieren.
Es geht also nicht darum, dass hier ein Treiber installiert wird, der mit einer echten Hardware kommuniziert, sondern in erster Linie um eine Software, die wie eine Hardware angesprochen werden kann.
Also der umgekehrte Weg.

edit2: Ich denke, du wirst das wohl sowieso nicht mehr lesen, aber:

DonnyDepp schrieb:
n kumpel hat mal ne eigene rendering-engine geschrieben. dh. per hand die einzelnen register befüllt und damit punkte aufm bildschirm erzeugt.
linien, ebenen, translationen etc. müssen da auch per "hand" berechnet werden.
er hat nicht die 3d-register der grafikkarten benutzt, sondern nur die standardregister, die auch benutzt werden, damit man nach dem einschalten etwas sieht... und zwar egal, welche grafikkarte nun um rechner steckt.
oder habt ihr schonmal ein mainboard gekauft, das nur mit einer speziellen grafikkarte läuft? :D

Was für ein Bullshit.
Es gibt keine 3D-Register. Im Framebuffer liegen 2D Grafiken.
Das einzige, wo permanent die selben 3D Werte gespeichert werden, sind die Displaylisten.
Weißt du, in der Grafikkarte werden 3D Informationen in 2D umgewandelt, damit ein Bildschirm die Bilder überhaupt anzeigen kann. Um dies zu bewerkstelligen, laufen die 3D Daten durch zig Stationen, die in der Grafikkarte implementiert sind.

Die Stationen sind:
Geometry -> Rasterizer -> Framebuffer

Im Detail:
ModelView Transformation -> Lighting -> Perspective Transformation -> Primitive Assembly -> Clipping -> Perspective Division -> Window-to-Viewport Transformation -> Scan Conversation -> Fragment Processing -> Per Fragment Operations -> Framebuffer Operations -> Framebuffer

Bei der Detailierten Auflistung erkennst du vielleicht auch, dass man da einfach nicht ein paar Schalter umlegen kann, damit ein Bild, was aus 3D Informationen besteht, auf dem Bildschirm angezeigt wird.

Aber wahrscheinlich redest du vom Raytracing. Eine Art, wie 3D Informationen in 2D umgewandelt werden können. Diese Art kann aber nicht in die Hardware implementiert werden, da dieses Verfahren recht komplex ist. Deswegen wird sie per Software implementiert. Bis jetzt konnte noch kein Echtzeit Raytracer entwickelt werden. Erzeugt aber ein realeres Bild und wird deswegen überwiegend bei Animationsfilmen verwendet.

Und hier sehe ich nun den Zusammenhang, mit dem Beispiel der Demoszene, da Gruppen öfters mal einen Raytracer basteln.

Dafür programmiert man sich aber nicht einen Treiber, sondern benutzt Schnittstellen, wie z.B. OpenGL oder DirectDraw/3D.
 
Zuletzt bearbeitet:
Oh Gott Leute.. es ist wieder zum Heulen wie viele Falschmeldungen und Halbwahrheiten hier verbreitet werden. Wiedermal hat keiner der Beteiligten Ahnung von Systemprogrammierung und Hardwaresteuerung.

Dryline 86 schrieb:
grundvoraussetzung ist schon so ,, die beherschung von C++
Windows-Gerätetreiber werden standardmäßig in C programmiert. C++ kommt nur ein Einzelfällen zur Anwendung, und dann auch nur mit ganz bestimmten Subfeatures.

DonnyDepp schrieb:
da verwechselst du was.
die windows-warnung von wegen nicht-zertifizierter treiber kommt, wenn du einen "richtigen" treiber installierst.
hier wird aber nur ein programm ausgeführt.
Es gibt keine "richtigen" oder "falschen" Treiber. Totaler Nonsens.

DonnyDepp schrieb:
mit deinen worten hört sich das so an, als wär die grafikkarte eine komplette blackbox und nur über vesa, opengl oder directx ansprechbar?

Ohne Gerätetreiber ist das unter Windows auch exakt der Fall. VESA mal ausgenommen, darauf gibts keinen Zugriff.

DonnyDepp schrieb:
@Ice-breaker:
http://www.x.org/docs/AMD/R6xx_3D_Registers.pdf
aber für softwarerendering reichen auch die standardregister...

Für Softwarerendering sind wie der Name schon sagt überhaupt keine Register nötig. Die Grafikkarte dient dabei _nur_ als Framebuffer und tut sonst gar nichts.


Whiz-zarD schrieb:
Um mit der Hardware kommunizieren zu dürfen, musst die Software sich als Treiber ausgeben, die ein Teil der Hardwareabstraktionsschicht ist.

Steht das so in der Wikipedia? OMG..

Whiz-zarD schrieb:
Und selbst dann ist es nicht mal möglich, direkt mit der Grafikkarte zu kommunizieren, da diverse Controller dazwischen liegen. Man Kommuniziert dann mit den Controllern.
http://de.wikipedia.org/wiki/Gerätetreiber

Elektrisch korrekt, logisch falsch! Die Kommunikation läuft transparent über Port-IO und MMIO. Der Controller ist für den Treiber i.d.R. vollkommen transparent.
Ausnahme sind Auxiliary-Geräte, z.B. Spannungswandler und DVB-Tuner/Demods. Die werden häufig über SMBus oder I2C angesprochen.

Whiz-zarD schrieb:
Treiber sind Teile des I/O-Managers und die Treiber müssen sich dort Registrieren, damit sie überhaupt geladen werden

Wieder falsch! I/O-Manager unter Windows ist dafür da um mit dem Treiber zu kommunizieren. Ein Treiber kann I/O implementieren, muss es aber nicht.

DonnyDepp schrieb:
abstraktes "fassbares" beispiel:
virtuelle maschinen. sind die treiber in der virtuellen maschine keine treiber?
sie sind schließlich nicht im "io-manager" (meinst wahrscheinlich kernel) des host-systems.

Das ist schon so falsch dass es fast weh tut. Was in der virtuellen Maschine läuft hat mit dem Host-OS rein GAR NICHTS zu tun, auch nicht mit dem I/O-Manager.

DonnyDepp schrieb:
alle windows-versionen danach haben eine microkernel-architektur. wie man aus der grafik in wikipedia sieht, sind die "gerätetreiber" im gelben "Benutzermodus"-Bereich.
dh. man kann mit assembler oder c direkt auf die register zugreifen, die von der hardwareabstraktionsschicht gemapt werden.

Wo hast du denn den Quatsch her? Windows-NT und neuer hat ein Protected Memory Model. Hardware-I/O wird dort nicht einfach in den Userspace gemapped. Das ist ein Irrglaube!

DonnyDepp schrieb:
n kumpel hat mal ne eigene rendering-engine geschrieben. dh. per hand die einzelnen register befüllt und damit punkte aufm bildschirm erzeugt.

Die will ich sehen.

Whiz-zarD schrieb:
Es gibt keine 3D-Register. Im Framebuffer liegen 2D Grafiken.
Falsch. Die Grafikkarten haben meist getrennte 2D und 3D-Einheiten, die von unterschiedlichen Teilen der Treiber gemanaged werden.

Whiz-zarD schrieb:
Aber wahrscheinlich redest du vom Raytracing. Eine Art, wie 3D Informationen in 2D umgewandelt werden können. Diese Art kann aber nicht in die Hardware implementiert werden, da dieses Verfahren recht komplex ist.
Unsinn. Komplex ist das nicht. Und es gibt sehr wohl Implementierungen auf der GPU für Raytracing. Nvidia hat sogar eine Demo dafür erstellt.


@Lyrion: Deine Frage ist ganz einfach zu beantworten. Du kannst solche Treiber nicht erstellen. Könntest du es, dann hättest du den Thread hier nicht erstellt. So etwas entwickelt sich nicht so einfach wie ein x-beliebiges Stück Software. Treiber gehören zu dem anspruchsvollstem was das Programmieren so hergibt. Ich weiß wovon ich rede, habe selbst Treiber für Windows entwickelt.


[x] Vote for Close
 
IceMatrix schrieb:
DonnyDepp schrieb:
n kumpel hat mal ne eigene rendering-engine geschrieben. dh. per hand die einzelnen register befüllt und damit punkte aufm bildschirm erzeugt.
Die will ich sehen.
Vermutlich hat der Mann einen Softwarerenderer gebastelt, der in den VESA Framebuffer schreibt,
und Herr JohnnyDepp hatte keinen Plan und die Sache deshalb total falsch verstanden.
 
applaus. per directdraw in den framebuffer schreiben.
damit steuert man die hardware aus dem userspace sozusagen direkt, richtig?
und software, die hardware direkt ansteuert (und sei es auch nur der framebuffer), kann man "treiber" nennen.

und im kernelmode kannste, wie der hersteller es tut, auch als normalsterblicher fast alles ansteuern. siehe omegadriver.
das beispiel mit den virtuellen maschinen sollte nur aussagen, dass man auch software treiber nennt, wenn diese lediglich virtuelle geräte steuern.
es ging mir eigentlich nur um die definition von "treiber".
was fürn ring jetzt treiber in diesem und jenem betriebssystem für diesen und jenen bereich voraussetzen... ist doch wurst ;D

kann mir mal jemand verraten, warum die leute sich immer in details verbeissen, wenn man über ganz grundsätzliche sachen spricht? :D
 
Zuletzt bearbeitet:
IceMatrix schrieb:
Steht das so in der Wikipedia? OMG..

Vielleicht falsch ausgedrückt, aber ein Treiber muss erstmal installiert werden, damit man ihn auch verwenden kann und dazu gehört auch die Identifikation, um was für ein Treiber es sich handelt, wann sie geladen werden sollen, wie das System reagieren soll, wenn sie nicht geladen werden können, etc.

IceMatrix schrieb:
Falsch. Die Grafikkarten haben meist getrennte 2D und 3D-Einheiten, die von unterschiedlichen Teilen der Treiber gemanaged werden.
Sicherlich, aber sowas, wie DonnyDepp es sich vorstellt, also Schalter umlegen und schon zeichnet er einen Punkt in einem 3D Raum auf dem Bildschirm, gibt es nicht.

3D Informationen, die in 2D umgewandelt worden sind, werden wieder gelöscht. Die einzigen 3D-Daten, die permant gespeichert werden, sind die Displaylisten.
In den Displaylisten liegen fertige Objekte, damit diese Objekte nicht immer wieder erstmal neu berechnet werden müssen.
Z.B. wenn man häufig ein Würfel benötigt. Dann lässt man einmal ein Würfel zeichnen und schiebt diesen Würfel in die Displayliste. Nun kann man diesen Würfel aus der Displayliste nehmen und muss ihn nicht immer wieder neuzeichnen.

IceMatrix schrieb:
Wieder falsch! I/O-Manager unter Windows ist dafür da um mit dem Treiber zu kommunizieren. Ein Treiber kann I/O implementieren, muss es aber nicht.

OK, dann ist das mein Fehler, da ich es andersrum verstanden habe. Dass die Treiber mit dem I/O-Manager kommunizieren.

applaus. per directdraw in den framebuffer schreiben.
damit steuert man die hardware aus dem userspace sozusagen direkt, richtig?
und software, die hardware direkt ansteuert (und sei es auch nur der framebuffer), kann man "treiber" nennen.

Du redest immer noch Bullshit.
Hier wird nicht direkt mit der Hardware kommuniziert, sondern über DirectDraw und DirectDraw ist eine Schnittstelle um mit den Treibern kommunizieren zu können.

Wenn ich Person A was sage und Person A sagt es zu Person B weiter, dann rede ich doch auch nicht mit Person B direkt.

Der Omegadriver ist nur eine optimierung des normalen Treibers. Hier wurde kein eigener Treiber entwickelt. Es wurde der original Treiber von ATi/nvidia genommen und einige Parameter optimiert.
http://en.wikipedia.org/wiki/Omega_Drivers
The drivers are tweaked versions of those officially released by ATI and nVidia, mainly using registry tweaks and offering an alternative installer. They are not custom drivers compiled from source code.

Schön für dich, dass du eine eigene Definition vom Wort "Treiber" hast, aber eine Software, die eine Grafikschnittstelle, wie OpenGL oder DirectDraw/3D benutzt, ist kein Treiber.

DonnyDepp schrieb:
kann mir mal jemand verraten, warum die leute sich immer in details verbeissen, wenn man über ganz grundsätzliche sachen spricht?
Weil du die grundsätzlichen Sachen nicht verstanden hast.
 
Zuletzt bearbeitet:
achso? also wenn ich über directdraw "scheinbar" direkt in den framebuffer schreibe, ist das eigentlich gar nicht direkt der grafikspeicher, sondern die daten werden von directdraw bearbeitet und landen dann erst im grafikspeicher?


ich dachte bis jetzt zumindest, dass der das so weiterleitet, als würde man unter linux nach /dev/fb* schreiben.
 
Zuletzt bearbeitet:
Du sagst DirectDraw, dass Daten in den Framebuffer geschrieben werden sollen.
Dann sagt DirectDraw den Treibern, dass Daten in den Framebuffern geschrieben werden sollen.
Die Treiber leitet die Daten bis zum GPU weiter und teilt dem GPU mit, dass Daten in den Framebuffer geschrieben werden sollen.

In der Informatik wird alles von einander getrennt und Abstrahiert.

Schon was vom Spruch "Alles ist eine Datei" gehört? Der stammt zwar aus der Unix-Welt, aber Windows macht es genauso.
Das Betriebssystem verwaltet jede Hardware wie eine Datei. Der Programmierer greift dann lediglich nur auf diese virtuelle Datei zu, aber nicht auf die hardware. Das macht das Betriebssystem.

Weil jede Hardware wie eine Datei gehandelt wird, gibt es auch im Prinzip nur zwei Arten von Treibern:
Kernel-Mode Treiber und File System Treiber. Welche Art ein Treiber ist, muss er bei der Installation angeben.

Wenn es diese Abstraktion nicht gäbe, müsstest du für jede Hardware und Rechnerzusammenstellung dein Programm komplett ändern. Darum gibt es diese Abstraktionsschichten, damit der Benutzer sich darum nicht kümmern muss, was unter der Haube letzendlich passiert.
Ein Programmierer will ja nicht wissen, wie ein Prozessor die Daten in den Arbeitsspeicher speichert. Er möchte nur eine Variable anlegen.
Genauso möchte ein Anwender nicht wissen, wie die Mausbewegung intern abläuft. Er möchte nur den Mauszeiger bewegen können.

Das gilt auch für deinen Beispiel. Du möchtest halt Daten in den Framebuffer schreiben.
Wie genau die Daten nun in den Framebuffer gelangen, interessiert dich ja nicht.
DirectX hält Befehle bereit, die zum Auslesen und Schreiben auf den Framebuffer von Nöten sind.
Screenshot Capture Tools machen ja sowas. Die Lesen den Framebuffer aus und wandeln diese Werte in eine Bilddatei um.

Edit:
DonnyDepp schrieb:
ich dachte bis jetzt zumindest, dass der das so weiterleitet, als würde man unter linux nach /dev/fb* schreiben.

Und das ist nicht die Hardware.
Das ist ein Puffer/eine Datei, den/die du beschreiben/lesen kannst.
Was das Betriebssystem mit diesem Puffer/dieser Datei macht bekommst du nicht mit.
 
Zuletzt bearbeitet:
DonnyDepp schrieb:
kann mir mal jemand verraten, warum die leute sich immer in details verbeissen, wenn man über ganz grundsätzliche sachen spricht? :D

Weil du so viel Müll schreibst. Mit jedem Post disqualifizierst du dich eigentlich nur ein Stückchen mehr...

DonnyDepp schrieb:
achso? also wenn ich über directdraw "scheinbar" direkt in den framebuffer schreibe, ist das eigentlich gar nicht direkt der grafikspeicher, sondern die daten werden von directdraw bearbeitet und landen dann erst im grafikspeicher?

Wieder falsch. Das hängt wiederrum vom Modus ab. Im Normalfall schreibt man in einen eigenen Puffer, der dann vom DWM zum Desktop zusammengesetzt wird. Nur im Vollbild wird auf den Framebuffer beschrieben. Und da kann man das prinzipiell sogar direkt tun, wenn man den Framebuffer über Paging in den Usermode mapped. DirectDraw ist übrigens tot. Es lebe Direct2D.
Ergänzung ()

Whiz-zarD schrieb:
Vielleicht falsch ausgedrückt, aber ein Treiber muss erstmal installiert werden, damit man ihn auch verwenden kann und dazu gehört auch die Identifikation, um was für ein Treiber es sich handelt, wann sie geladen werden sollen, wie das System reagieren soll, wenn sie nicht geladen werden können, etc.

Nein muss nicht. Es ist unnötig, dass sich ein Treiber "identifiziert". Er wird einfach als Dienst in der Registry erstellt mit Verweis auf die Treiberdatei (i.d.R. sys). Was für ein Typ es ist spielt keine Rolle. Das wird lediglich zusätzlich über die INF-Dateien bei den meisten Treibern, so dass sie im Gerätemanager auftauchen. Aber nötig ist das nicht. Ein Beispiel dafür sind Netzwerkprotokolltreiber oder Dateisystemtreiber. Die sind nicht im Gerätemanager explizit gelistet.
 
Zuletzt bearbeitet:
Whiz-zarD schrieb:
Ich hoffe, du kanst Englisch

Die Dokumentation des I/O-Managers:
http://msdn.microsoft.com/en-us/library/ff565734(v=vs.85).aspx

http://en.wikipedia.org/wiki/Windows_Driver_Model <- heutiges Treibermodell
http://en.wikipedia.org/wiki/VxD <- Treibermodell von Win 3.x und 9x

das ist das "heutige treibermodell"?
wird nicht http://en.wikipedia.org/wiki/Windows_Driver_Foundation benutzt, wo user-mode-driver erlaubt sind?

und wenn ich nun vollbild einstelle, den framebuffer in den user-space mappe (noch was an konfiguration vergessen?), schreib ich dann endlich direkt in den speicher der grafikkarte?
oder gilt da auch die in diesem thread herrschende meinung/(tatsache?), dass direkte hardwareansteuerung im usermode nicht möglich sei?



Und das ist nicht die Hardware.
Das ist ein Puffer/eine Datei, den/die du beschreiben/lesen kannst.
Was das Betriebssystem mit diesem Puffer/dieser Datei macht bekommst du nicht mit.
oh okay. und was macht das betriebssystem mit dem inhalt des puffers?
 
Zuletzt bearbeitet:
http://de.wikipedia.org/wiki/Memory_Mapping

Das sollte deine Frage beantworten.
Falls nicht: Nein, du kommunizierst nicht direkt mit der Grafikkarte, sondern über den Arbeitsspeicher indirekt.
Beim Mapping werden die Register einer Komponente im Arbeitsspeicher abgebildet.
Und nein, auf den Arbeitsspeicher hast du auch keinen direkten Zugriff. Siehe virtuelle Speicherverwaltung,
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben