Mal dumm nachgefragt: wie greift man denn auf USB-Dongles zu? Ist das auch ein Dateizugriff, wie bei seriellen Ports?
Jain. Auch bei anderen ist es kein "Dateizugriff". Ähnlich wie bei unixoiden Systemen werden aber die gleichen Funktionen benutzt, wobei
DeviceIoControl (und Freunde) auf Windows in unixoiden Systemen ihre Entsprechung in ioctl() finden.
Ich versuch's mal zu umreissen und den Zusammenhang darzustellen.
Wenn du meinst, daß du auf C:\Windows\System32\kernel32.dll zugreifst, greifst du eigentlich auf das Gerät zu welches in den DOS-Namensraum als C: eingeblendet wurde. Der echte Name ist meistens \Device\HarddiskVolumeX (wobei X üblicherweise eine Ziffer ist). "\" bezieht sich hier auf den echten Namensraum in NT-Systemen. Dort sind alle möglichen Objekte aufzufinden, inklusive der Registry. Ich empfehle das Tool WinObj von Sysinternals.
Du greifst also auf das Gerät \Device\HarddiskVolumeX zu, wobei der Name eben einem "Device Object" (DO) gehört und man zwischen PDOs (Physical Device Objects) und CDOs (Control Device Objects) unterscheidet (es gibt auch noch VDOs, wobei die Abgrenzung zu CDOs eher künstlich ist).
Kleiner Ausflug: wenn man einen Treiber, egal welcher Coleur, schreibt gibt es meist auch ein CDO, ein PDO muß es aber nicht geben. Bspw. ein Dateisystemfiltertreiber (FSFD) welcher sich bspw. an das oben genannte Gerät hängt. Dieser Filtertreiber hat aus praktischen Gründen üblicherweise ein CDO (beliebiger Name) über welches man per CreateFile, DeviceIoControl und CloseFile zugreifen kann (wir bleiben mal nur beim
Win32-Subsystem).
Da das Gerät aber C: ist, bliebe die Frage wie du an die Daten von kernel32.dll kommst?! Nunja, der I/O Manager sieht einen Pfad und eine Anfrage an diesen Pfad hier sowas wie \??\C:\Windows\System32\kernel32.dll ...
Das löst er mit dem Object Manager erstmal auf, so daß wir bei dem Pfad \Device\HarddiskVolumeX\Windows\System32\kernel32.
dll landen (so sehen bspw. Filtertreiber den Pfad auch üblicherweise). Da der I/O Manager aber ab \Device\HarddiskVolumeX\ nicht mehr weiter weiß, übergibt er an das Gerät \Device\HarddiskVolumeX den Pfad \Windows\System32\kernel32.dll, wobei der zuständige Treiber (üblicherweise ein Dateisystemtreiber) dann dafür zuständig ist diesen Pfad zu interpretieren und so weiter ...
Bei Netzlaufwerken gehen alle Anfragen üblicherweise durch ein einzelnes Gerät, also nichtmal nach Laufwerk getrennt wie man das von Festplatten kennt.
Bei
COM und LPT ist es nun so, daß die Geräte bereitstehen, weil schon ein Treiber existiert der die PDOs erzeugt. Und zwar stehen sie unter echtem Namen bereit, als auch im DOS-Namensraum. Und aufgrund des letzteren kannst du über eine symbolische Verknüpfung (nicht mit dem gleichnamigen Konzept in Dateisystemen verwechseln!) aus dem
Win32-Subsystem darauf zugreifen.
Prinzipbedingt geht das mit allerlei Geräten, denn die Grundfunktionen lesen und schreiben sowie einige andere finden sich bei allen Geräten wieder, egal ob wirklich implementiert oder mit Standardbehandlungsroutine versehen. Siehe:
- IRP_MJ_CREATE
- IRP_MJ_CLOSE
- IRP_MJ_READ
- IRP_MJ_WRITE
... ich empfehle einen Blick ins WDK. Die üblichen Funktionen haben IRP_MJ_* als Namen (MJ == major). Bei weiteren Fragen können wir ja einen Mod bitten das hier abzutrennen.
Ich habe einen neuen Router bekommen (die Geschichte dazu erzähle ich später weiter), der bietet einen USB-Port mit verschiedenen Serverfunktionen. Vielleicht kann man damit etwas drehen.
Läuft der Router auf Windows?