(Drucker-) Treiber-Entwicklung mit C#

Hallo,

ich möchte einen Druckertreiber entwickeln. Kann ich das mit .NET und C#? Kann mir jemand ein "Hello World"-Beispiel geben?

Es soll kein Druckertreiber im eigentlichen Sinne sein. Es soll nicht auf einen Drucker ausgedruckt werden, sondern: ich möchte das ein UserInterface aufploppt wo der Benutzer diverse Dinge klicken kann, etc. (aber wahrscheinlich macht das keinen Unterschied was genau geschieht).

Danke für eure Antworten.

Gruß,
André

Ehrlich gesagt versteh ich nicht was du willst.

Treiber zu entwicklen ist in .Net nicht möglich. Dazu brauch man unamnaged Code.
Jetzt wirds bei dir bissle wirr find ich. Du willst also das jemand deinen Drucker auswählen kann im Dialog, und statt zu drucken geht aber ein Fenster auf mit dem gedruckten, und was soll jetzt der User können?

Oder hab ich des bisher schon falsch verstanden?

Hallo tiredwarlord,

ob du einen Druckertreiber schreiben willst oder ein UserInterface, bei dem man diverse Dinge klicken kann, ist ein entscheidender Unterschied. Für ersteres eignet sich C# nicht, für letzeres sehr gut.

Was dein Hello-World-Beispiel angeht: das findest du, wie auch alle weiteren relevanten Informationen zum erstellen von C# Programmen und Benutzerschnittstellen in Galileo <openbook>: Visual C# 2005 von Andreas Kühnel.

herbivore

Ja danke. Ich habe mich wohl missverständlich ausgedrückt. Meine Idee war, dass ich einen Druckertreiber entwickle, der das Dokument nicht auf einen Drucker ausgibt, sondern etwas anderes mit dem Dokument macht.

Das Tool sollte durch einen Druckertreiber in jedem Programm (welches ein Dokument drucken könnte) vorhanden und erreichbar sein.

Also im Prinzip ein virtueller Druckertreiber... ähnlich wie ein PDF-Druckertreiber. Der gibt das Dokument ja auch nicht auf einen Drucker aus, sondern es erscheint in der Regel ein Dialog wo noch diverse Einstellungen vorgenommen werden können und anschließend kann auf ein Knöpfchen für die PDF-Generierung geklickt werden.

Gruß,
André

Sorry, Treiberentwicklung und .Net schliessen sich sowieso aus.
Bitte warte 9 Jahre(mindest)...

Druckertreiber unter Win oder Linux, sonstwas... - nicht hier(völlig falsch gelandet). Aber vermutlich ist deine Art von Treiber eh Hardwareunabhängig oder Illusion...

Erzähl mir was über Treiber...

Sag lieber was du machen willst...

Treiber kann man derzeit unter Assembler, C , C++(mit Fremdanbietern) entwickeln. Nicht mit hastenichjesehn Wünschen...

@ikaros:
Stimmt auch nicht wirklich.
Natürlich kann man Treiber auch in .NET schreiben.
Du musst nur bereit sein etwas Geld auszugeben und ein Tool wie das von Jungo
zu erwerben.

http://www.jungo.com/windriver_windows.html

Nun, es ist nicht möglich Treiber unter .Net Framework zu erstellen. Keine Ahnung wie das Jungo macht, aber ich schätze mal, das die nur unmanaged calls machen. Ein Assembly kann und darf kein Treiber sein.

Es ist technisch auch gar nicht möglich, weil
a) Eine managed dll keine exports unterstützt. Und Treiber-Dlls(Vxds) müssen bestimmte exports unerstützen ("far calls"). Das kann nur Assembler/C/C++ (mit DDK)
b) Das .Net Framework im Kernel-Modus nicht geladen ist (sprich der Kernel unterstützt kein CLR)
c) Der Heap einer Treibers darf nicht größer 32MB sein. Ein im .Net ausgeführtes Programm (plus GC / im Hintergrund geladenes Framework) dürfte locker über 32MB sein.

Darum geh ich mal davon aus, das das ziemlich böse ist was Jungo da macht. Im unmanaged Bereich ist es garantiert nen super Tool, aber im managed Bereich würde ich es nicht benutzen.

Das einzige was funktionieren sollte - aber nicht empfehlenswert - ist auf die IOCTL Schnittstelle des Treibers per PInovke zuzugreifen.

Fazit: Treiber unter .Net nicht möglich!
Vielleicht gibt es in ein paar Jahren mit einem neuen OS von MS ja einen Kernelmodus, der die CLR unterstützt. Wäre schön, aber ich glaub irgendwie nicht dran.

Dieses Tool erlaubt es nur, einen User-Mode-Treiber zu erstellen. Da stünde .NET zur Verfügung. Für diesen Einsatzzweck wäre ein User-Mode-Treiber sogar angezeigt.

Treiber laufen aber nicht im UserMode...
Oder, die Definition "Treiber" muss geändert werden.

Nein, nur deine Definition von Treiber muss geändert werden.

@Fzelle: meinst du meine?
Falls ja: bin echt interessierrt.
Ich glaub ein Treiber ist Treiber, und läuft in einer anderen Schicht.
Edit: So ein bisschen OSI ist echt gut. .Net-Treiber gibts frühesten ab Version 47.11...

Gibt es seit XP (Windows Driver Foundation). Die User-Mode-Seite (UMDF) basiert auf COM, daher vermutlich auch die Chance mit .NET an den Start zu gehen. Hat diverse Vorteile gegenüber einem reinen Kernel-Treiber-Modell, vor allem:

"Drivers that run in user mode, however, have access only to the user address space and therefore pose a much lower risk to system security and stability than kernel-mode drivers."

"UMDF supports the development of drivers for protocol-based or serial bus–based devices, such as USB devices and network-connected devices. For example, drivers for the following types of devices can be written in user mode:
*Portable storage devices, such as PDAs and cell phones
*Portable media players
*USB bulk transfer devices
*Auxiliary display/video devices"

"Drivers that require the following cannot be written as UMDF drivers; they must be written as kernel-mode drivers:
*Handling interrupts
*Direct access to the hardware, such as direct memory access (DMA)
*Strict timing loops
*Use of nonpaged pool or other resources that are reserved for kernel mode"

@ikaros:
Ja, deine Definition meinte ich.

Aber das ist wie mit manchen anderen "feststehenden Begriffen", wenn es
da allgemeine Interpretationsänderungen gibt, beteiligen sich einige halt nicht,
oder wollen das nicht so sehen.

Für Dich ist ein Treiber reine Schicht 0, für die meisten anderen ist es alles was
ein Gerät antreibt, also auch UserMode und CO ( wie man das auch nennen möchte ).

@FZelle:
Feststehende Bregriffe und so:
Es gibt natürlich Möglichkeiten auf bestehende Treiber aufzubauen und ein weiteres Protokoll zu Implementieren. Da finde ich aber den Begriff Treiber unangemessen. Das ist durchaus üblich aber nur eine Abstraktion des Treibers. Läuft üblicherweise als Dll also als Lib für Anwendungen.
So ein Treiber selbst brauch die Rechte um protokollunabhängig(also von Fremdsw) direkt Ports, Interrupts and so on anzusprechen. Das erfordert ganz andere Rechte und Bedingungen(DOS ist zum Glück inzw. gegessen).
Ich persönlich halte es halt(hübsche Reflektion) für wichtig den Begriff Treiber nicht zu verwischen. Die Unterschiede zw. Treiber und einer Abstraktionsschicht(zB. als Framework) sind doch Immens.
Übrigens ist Svensons Aussage auch korrekt. Es gibt tatsächlich "Treiber" im Usermode. Diese "Treiber" folgen dem vorgeschriebenen Entwicklungsmodell(so das sie als solche gelistet werden) setzen aber nur auf echte Treiber auf. Also auch nur ne Abstraktionsschicht.
Edit: Schicht 0 - würde bei mir ein Kabel sein.. 😉

Original von ikaros
Diese "Treiber" folgen dem vorgeschriebenen Entwicklungsmodell(so das sie als solche gelistet werden) setzen aber nur auf echte Treiber auf. Also auch nur ne Abstraktionsschicht.

Wie FZelle schon schrieb, die Zeiten ändern sich. Die Postleitzahlen sind jetzt auch 5-stellig. 🙂

Es handelt sich hier eben nicht um Libs, die für nen Treiber ne API bauen. Windows verwendet diese Treiber tatsächlich als Gerätetreiber. Aber nutzen diese eben nicht direkt Interrupts, sondern setzen auf einer höheren Ebene auf, z.B. einem USB-Treiber. Das war früher auch schon so, nur gab es eben keine Trennung.

Entscheidend für einen Treiber ist nicht, dass er mit Interrupts arbeitet, sondern dass er zum BS hin als Treiber agiert (z.B. Plug and Play). Druckertreiber werden z.B. seit W2k vollständig im User-Mode geschrieben - das war noch vor WDF.

Ich seh jetzt keinen Widerspruch.
Ich sagte ein Treiber hat eine bevorzugte Ebene, und es Programme die so tun als wären sie Treiber - setzen auf den Basistreiber auf usw.
Ein Treiber im Usermode ist halt kein Treiber, dh.: er hat nicht die Wahl ob er Interrupts und PÖorts usw. nutzen darf. Derartiges Wischiwaschi gibts nur noch embedded unter CE < 4.
Entscheidend zur Sichtweise ist nur die Sichtweise?
Ich halte es für entscheidend, ob ein direkter Hardwarezugriff erfolgen darf oder nicht darf. Ob das BS entscheidet der Level gilt noch als Treiber, und gleichermassen entscheiden kann das ist Lib, ist imho ein und der selbe Level.
Vielleicht reden wir auch aneinander extrem vorbei(möglich).

Hallo zusammen,

Vielleicht reden wir auch aneinander extrem vorbei

nein, ich denke nur, dass hier zwei Meinungen unvereinbar gegen überstehen. Du hast deine Definition, was ein Treiber ist und die anderen eine andere. Bei Definitionen gibt es aber gerade kein richtig und falsch. Die Diskussion geht aber gerade darum die jeweils andere Seite von der Richtigkeit der eigenen Definition zu überzeugen.

Dabei ist es eigentlich ganz einfach: Das eine ist die Definition von Treiber im engeren Sinne und das andere die Definition im weiteren Sinne. Diese haben beide ihre Berechtigung und keine von ihnen hat für sich gepachtet, die einzig glücklich machende zu sein.

Vielleicht können wir die Diskussion damit beenden.

herbivore

Wir können ja zur Unterscheidung die Bezeichnung Hardware-Treiber (Hardware Abstraction Layer, HAL) und Anwendungs-Treiber einführen.

Der HAL ist derjenige Treiber, der direkt mit der Hardware kommuniziert (Ports, Interrupts, DMA etc.). Nur dieser läuft (notwendigerweise) im Kernel Mode. Beispiele dafür sind der IDE-, USB- oder NIC-Treiber.

Anwendungstreiber sind jetzt die Bestandteile, die höhere Funktionen zur Verfügung stellen und zur Kommunikation auf dem HAL aufsetzen, selbst aber nicht direkt mit der Hardware kommunizieren und daher im User Mode laufen können (und dann auch sollten).
Um bei obigen Beispielen zu bleiben wären das dann der Dateisystemtreiber, der USB-Massenspeichertreiber oder auch der TCP/IP-Protokollstack.

Dem Benutzer sind die Unterschiede relativ egal, daher wird auch nur ein gemeinsamer Begriff verwendet. Nur für den Programmierer sind das zwei komplett andere Dinge.

Einen HAL kann man nicht mit .NET programmieren. Einen User Mode Anwendungstreiber schon.

@herbivore
Vielleicht du recht mit der Unvereinbarkeit. Vielleicht fehlen in heutiger Zeit auch nur die richtigen Begriffe. Zur Trennung und der korrekte Oberbegriff. Leider kann amn es halt nicht so einfach in einer Diskussion so definieren das alle einverstanden sind. Andererseits ist vielleicht gut so.

Also machen wir mit der Diskussion Schluss. Sonst sprengst das Forum.
Mir ist schon klar, das ich deine Forderung wiederhole, aber was soll ich sagen, ausser: "Borg ist schuld"?
I.Ü. : Hi Borg.

Hallo!

Hab' mir grad' mal die Preise bei Jungo angeschaut 8o 8o 8o 8o 8o.
Sollen wir sowas nicht mal als Projekt im Forum entwickeln und vertreiben?
Da reicht eine Version, und das Forum ist über Jahre finanziert 😁 (zumindest wenn wir dieselben Preisvorstellungen anwenden) ...

Wenn Du glaubst, das in diesem Jahrhundert fertigstellen zu können 😉

Ich hatte mal persönlichen kontakt mit denen in einem früheren Entwicklerdasein,
glaube mir, da ist mehr knowhow drin als sich die meisten vorstellen.

Hallo,

Ich bin auch der Meinung dass so ein Projekt etwas größeres ist und nicht einfach mal schnell gemacht werden kann.

Ich für meinen Teil würde es z.B.: auch reichen wenn es ein Druckertreiber gibt, der nicht eine Datei erstellt sondern die Daten direkt an einen .NET Anwendung übergibt.

So etwas habe ich bis jetzt nicht gefunden und es wäre besser zu Handhaben als einen generischen Druckertreiber zu installieren und die Datei dann zu bearbeiten.

Ist das denn jetzt möglich, z.B. einen Druckertreiber in C#.NET zu entwickeln, habe eine Anfrage von jemandem bekommen.

laut Windows Driver Kit (WDK) 8.1 Preview Samples interpretier ich das so (und einigen anderen diversen Seiten, dass das jetzt geht).

[EDIT: Habe das allerdings nur ganz schnell überflogen und kann nicht beurteilen, ob das Beispielprojekt möglicherweise nur die Schnittstelle für den Treiber bereithält]

Hallo dr4g0n76,

der Inhalt dieses Threads ist - lt. meiner Sicht - weiterhin korrekt.

Die Beispiele aus dem Link sind C/C++ und nicht C#, daher geht es auch 😉

mfG Gü

Meine Antwort von damals gilt (leider) immer noch.

Solange die CLR nicht im Kernel-Modus geladen wird, wird es nicht gehen mit c# Treiber zu programmieren. Und soviel wie ich immer mal so nebenbei gelesen habe, da die Frage immer wieder in den MS Foren auftaucht, wird es auch in absehbarer Zeit nicht der Fall sein.

MS hat ja mit Singularity schon mal vor längerer Zeit gezeigt, das ein Kernel im Managed Bereich geladen und auch verwendet werden kann (zugegeben, Singularity ist ein OS komplett in c#, bzw. spec# 😃). Aber da Singularity nicht weiterentwickelt wird, gehe ich mal davon aus, dass das leider nie wirklichkeit wird.