ich mich vor einigen Tagen schon einmal allgemein über das Thema Parallelport (und andere Schnittstellen) informiert und bin jetzt immerhin bei einigen konkreten Fragen angelangt:

Also ich hab herausgefunden, dass man unter den alten 16-Bit Systemen

outportb(adress, data); // o.ä.

verwenden konnte, dieser aber unter WinXP (was ich benutze) gesperrt ist.

Dazu habe ich zwei verschiedene dlls gefunden:
WinIO und
inpout32.dll.

Ich würde aber, wenn das möglich ist, lieber selbst eine Art einfachen Treiber schreiben, der es mir erlaubt, die Pins D0 bis D7 an- oder abzuschalten.
Also erstmal wirklich nur output.

Ist das mit der WinAPI möglich?
Ich habe irgendwo gelesen, dass das irgendwie mit CreateFile() gehen soll, woanders aber wieder, dass das nicht möglich sei?!?

Kann mir jemand ein einfaches Beispiel (und evtl auch noch einen Link zu einem passenden Tutorial) geben, wie ich mit Standard-C++ + WinAPI irgendeinen Pin (D0 bis D7) anschalte?
Den Rest würde ich dann gerne selbst schreiben (manchmal erfindet man das Rad doch gerne selbst, und wenn es nur ist, um es zu verstehen), aber damit ich mal so einen Ansatz habe.

Vielen Dank,
Sinthoras

Edit: Habe auch im Internet und in Buchhandlungen nach passender Literatur gesucht, aber die verwenden alle nur die fertigen DLLs und abstrahieren das ganze dann in Klassen (z.B. hier ).
Ich möchte jetzt halt gerne die Basis des ganzen verstehen.

Aber ich möchte halt gerne einen (zumindest rudimentären) Treiber dafür selbst schreiben.
Und zumindest bei WinIO scheinen sie - bis auf eigene Header - ausschließlich die WinAPI zu benutzen:

#include <windows.h>
#include <winioctl.h>
#include "k32call.h"
#include "phys32.h"
#include "..\drv\nt\winio_nt.h"
#include "winio.h"

winioctl.h kenne ich nicht, sieht für mich aber auch nach irgendeinem WinAPI-Header aus, oder nicht?

Nun möchte ich halt soetwas ähnliches - nur etwas simpler, erstmal nur Output auf D0 bis D7 - selbst schreiben und wollte dafür einen kleinen Ansatz.

Aber ich möchte halt gerne einen (zumindest rudimentären) Treiber dafür selbst schreiben.

dann sollteste dir vielleicht mal das DDK anschauen, da ist auch ein beispieltreiber für 'parallel' dabei ('parport' oder so ähnlich heisst der).
...aber das ist natürlich 'kernel mode', du willst ja alles im user-mode machen.

Sinthoras schrieb:

Und zumindest bei WinIO scheinen sie - bis auf eigene Header - ausschließlich die WinAPI zu benutzen:

das halte ich für ein gerücht. in der winapi ist meines wissens nix, um hardware direkt anzusprechen.

Sinthoras schrieb:

winioctl.h kenne ich nicht, sieht für mich aber auch nach irgendeinem WinAPI-Header aus, oder nicht?

es gibt eine funktion namens 'DeviceIOControl' oder so ähnlich, mit der kann man den treibern gewisse kommandos schicken und statusinformationen abfragen. die definitionen dafür stecken in dieser 'winioctl.h'.

Sinthoras schrieb:

Nun möchte ich halt soetwas ähnliches - nur etwas simpler, erstmal nur Output auf D0 bis D7 - selbst schreiben und wollte dafür einen kleinen Ansatz.

einfache sachen, wie IO's setzen u.ä. gehen übrigens auch ganz ohne zusätzliche DLL's oder kernel module: http://wookey.org/usermodehardwareportio.html
(man muss aber admin rechte haben)

bool GetDriverPath()
{
  PSTR pszSlash;

Was macht diese Struktur?

if (!GetModuleFileName(GetModuleHandle(NULL), szWinIoDriverPath, sizeof(szWinIoDriverPath)))
    return false;

Was genau macht GetModuleFileName? Wie funktioniert die?

pszSlash = strrchr(szWinIoDriverPath, '\\');

strrchr sucht nach dem letzten (?) Vorkommen eines Strings (oder doch eines einzelnen Zeichens?) in einem anderen String.
Was soll das hier?
Und was macht der doppelte Backslash '\'?

if (pszSlash)
    pszSlash[1] = 0;

Was soll dieser Teil bitte prüfen?

bool _stdcall InitializeWinIo()

Was macht _stdcall?
Ist das irgendetwas speziell für Dlls?

{
  bool bResult;
  DWORD dwBytesReturned;

  IsNT = IsWinNT();    // muss ich erstmal nicht verstehen, weil ich es nicht
                       // einbauen werde - ich benutze immer WinNT

  if (IsNT)
  {
    hDriver = CreateFile("\\\\.\\WINIO",
                         GENERIC_READ | GENERIC_WRITE,
                         0,
                         NULL,
                         OPEN_EXISTING,
                         FILE_ATTRIBUTE_NORMAL,
                         NULL);

Also doch über CreateFile? Ich dachte, das se gesperrt...
Was soll "\\\.\\WINIO"?
Also was sollen die ganzen Backslashes da?
Wozu wird das dann umgewandelt?

// If the driver is not running, install it

    if (hDriver == INVALID_HANDLE_VALUE)
    {
      GetDriverPath();

      bResult = InstallWinIoDriver(szWinIoDriverPath, true);

Ist das eine WinAPI-Funktion oder woher kommt die?

if (!bResult)
        return false;

      bResult = StartWinIoDriver();

Genauso hier: WinAPI oder was sonst?

Und abschließend:
Muss ich dem Compiler noch irgendwie klarmachen, dass er statt der alten outportb(...)-Funktion eine eigene (Treiber-) Funktion aufrufen muss?
Oder funktioniert ganz normal die alte Funktion, wenn der Treiber läuft?

Wo hat der Treiber denn jetzt die Lese-/ Schreibfunktion implementiert???

(In der in den WinIO-Sources zu findenen Funktion "bool _stdcall SetPortVal(WORD wPortAddr, DWORD dwPortVal, BYTE bSize)" wird dann letztlich auch nur "outp(...);" aufgerufen?)

Für mich sieht das ganze jetzt so aus, als hätte man zwar hübsch einen Treiber installiert, aber wo ist denn jetzt die eigentliche Funktion?
Also wo wird dem Programm gesagt, wie das gesperrte "outp(...)" funktionieren soll?

dann sollteste dir vielleicht mal das DDK anschauen, da ist auch ein beispieltreiber für 'parallel' dabei ('parport' oder so ähnlich heisst der).
...aber das ist natürlich 'kernel mode', du willst ja alles im user-mode machen.

Wo finde ich das DDK (Driver Development Kit oder nicht?) ?
(Hab nach "parport" gesucht, aber nur den Treiber selbst gefunden; unter "ddk" nur eine paar MinGW-Header.)
Sry, aber ich verstehe deine Unterscheidung nicht... Was meinst du mit "kernel mode" und "user mode"?

einfache sachen, wie IO's setzen u.ä. gehen übrigens auch ganz ohne zusätzliche DLL's oder kernel module: http://wookey.org/usermodehardwareportio.html
(man muss aber admin rechte haben)

Das klingt interessant, danke, aber da verstehe ich wirklich keine Zeile...
Gibt es da eine Erklärung zu oder könntst du mir das (ich weiß, dass das eigentlich zu viel verlangt ist, aber ich komme wirklich kein Stück voran...) das mal Zeile für Zeile erklären?

Vielen Dank jedenfalls soweit schonmal.

Wo finde ich das DDK (Driver Development Kit oder nicht?) ?

mal ist es frei verfügbar, dann wieder kostet es was, m$ kann sich nie so richtig entscheiden. ich weiss auch nicht wie sie's aktuell handhaben, aber ein älteres, freies DDK, sollte irgendwo im internet aufzutreiben sein (der parport driver war schon immer mit dabei).

Sinthoras schrieb:

Das klingt interessant, danke, aber da verstehe ich wirklich keine Zeile...

der code dürfte selbsterklärend sein und es sind auch kommentare drin
im prinzip läuft das so:
1. nachgucken ob das recht 'trusted computer base' aktiviert ist, wenn nicht --> einschalten
2. undokumentierte systemfunktion 'NtSetInformationProcess' mit 'ProcessUserModeIOPL' aufrufen --> enabled hardware zugriffe
3. demo: assembler IN/OUT instruction aufrufen --> geht nur, wenn (2) geklappt hat

Und 3) demonstriert das ganze dann?

D.h. statt des Assembler-Krams könnte ich auch normal "outportb(...)" aufrufen?

Wenn ich das richtig verstanden habe, deaktiviert das ganze also nur den Schutz des Parallelports vor direktem Zugriff, oder wie?

Wenn ich das richtig verstanden habe, deaktiviert das ganze also nur den Schutz des Parallelports vor direktem Zugriff, oder wie?

richtig, und das ist ja eigentlich das, was du brauchst.
eventuell könnte dir der aktive parport-treiber deiner windoofs-kiste dazwischenfunken, aber den kannste ja über die systemeinstellung irgendwie deaktivieren.

Kannst du mir trotzdem mal erklären, wie das z.B. bei WinIO mit dem CreateFile() funktioniert?
Die schaffen es ja auch irgendwie, auf den Parallelport zuzugreifen, ohne dafür generell was an den Zugriffsrechten zu ändern, oder nicht?

Mich würde halt interessieren, wie man von einem einfachen CreateFile() dazu kommt, dass Funktionen wie outportb(...) wieder auf den Port zugreifen können.

Sry, dass ich dich da jetzt so mit Fragen überhäufe, aber ich kenne halt niemanden, der davon auch nur die leiseste Ahnung hat und du scheinst dich ja auszukennen mit sowas.
Soweit jedenfalls schonmal vielen, vielen Dank für deine Mühe.

Ok, aber da hätte ich dann ja das Problem, das alles und jeder auf meinen Ports rumschreiben kann oder wohl möglich noch andere Rechte bekommt, die mir am Ende mehr schaden als nützen.

naja, kommt drauf an.
die manipulation mit 'ZwSetInformationProcess' gilt nur für den prozess, der es auch aufgerufen hat und er muss mit admin-rechten laufen. anderen prozessen, auch solchen mit admin-rechten, wird weiterhin der zugriff auf die hardware verwehrt.

Sinthoras schrieb:

Kannst du mir trotzdem mal erklären, wie das z.B. bei WinIO mit dem CreateFile() funktioniert?
Die schaffen es ja auch irgendwie, auf den Parallelport zuzugreifen, ohne dafür generell was an den Zugriffsrechten zu ändern, oder nicht?
Mich würde halt interessieren, wie man von einem einfachen CreateFile() dazu kommt, dass Funktionen wie outportb(...) wieder auf den Port zugreifen können.

die meisten davon installieren ein kernel-modul, das man mit CreateFile öffnen kann und darüber werden die hardware zugriffe gemacht. das geht erstmal wesentlich langsamer, weil das usermode-programm für jede kleine aktion mit dem kernel-modul kommunizieren muss und ist u.u. sicherheitstechnisch bedenklicher als der trick mit der undokumentierten native-api funktion.

Sinthoras schrieb:

Soweit jedenfalls schonmal vielen, vielen Dank für deine Mühe.

no problem

Ich schaue morgen mal, was ich im DDK darüber so finde und dann melde ich mich wieder.
Mich würde halt interessieren, wie man das selbst realisieren kann, so ein Kernel-Modul zu installieren (und zu benutzen).
Mal schauen, was das DDK dazu hergibt.

Gute Nacht.

Bekomme ich das DDK (meinetwegen auch ein älteres) denn nicht auch irgendwo anders her?

Kann mir denn jemand sagen, wie ich so einen einfachen Treiber selbst realisieren kann?
Denn darum geht es mir ja.

Ich möchte nur D0 bis D7 einzeln aktivieren und deaktivieren können, mehr erstmal nicht.
Min Problem ist halt, dass ich bei WinIO zwar allerlei Funktionen sehe, aber nicht erkennen kann, wo denn jetzt wirklich der Zugriff geregelt wird.

Wie geht sowas?

Ok, also an das DDK scheine ich wohl nicht ranzukommen

Doch, das ganze heisst jetzt KMDF... und darin ist das DDK drin...
http://www.microsoft.com/whdc/driver/wdf/KMDF.mspx
Und das KMDF gehört zum WDK welches Du hier bekommst:
http://www.microsoft.com/whdc/DevTools/WDK/betawdk.mspx

Edit: Ok, der Download zieht sich hin.
Ich werde mich wohl erst morgen wieder melden.

Edit: Bzw dann, wenn ich Zeit dafür gefunden habe und mich etwas reinarbeiten konnte.