Wenn man unter den von Dir genannten Betriebssystemen arbeitet, sollte
es kein sonderliches Problem darstellen, die jeweilige
Programmiersoftware dahingehend anzupassen, daß sie statt direkter
I/O-Zugriffe mit einem Devicetreiber kommuniziert; ich würde sogar
stark vermuten, daß sie das eh' schon machen wird.
Wieso vermutest Du, daß das Abfangen von I/O-Zugriffen unter anderen
Betriebssystemen nicht funktionieren soll? (MacOS mal ausgenommen, das
läuft auf einer Hardware, die gar keine separaten I/O-Zugriffe kennt)
Das wird es mit Sicherheit tun, sonst könnte ja eine belibige
Usermode-Applikation mit einigen wohlgemeinten I/O-Zugriffen das System
auskanten (Interruptcontroller umprogrammieren, Timer umprogrammieren
etc.).
Unter MacOS werden zwar keine I/O-Zugriffe, sondern memory-mapped-I/O
verwendet, aber auch diese Zugriffe werden abgefangen, da sonst dort
das gleiche Problem aufträte.
Also muss "nur" analog zum Windows-Devicetreiber mit
I/O-Zugriffs-abfangmöglichkeit ein Linux/BSD-Devicetreiber geschrieben
werden - durch die Veröffentlichung der Sourcen des Windows-Treibers
hat der Herr Haftmann schon viel lobenswertes getan.
Wenn die die I/O-Zugriffe machende Software nicht im Sourcecode
vorliegt, sondern festcodierte I/O-Adressen für die drei
Standard-Druckerschnittstellen enthält, können übrigens weder PCI- noch
Cardbus-/PCMCIA-Karten verwendet werden. Die nämlich legen ihre
I/O-Adressen in einen anderen Adressbereich, außerdem werden die
Adressen dynamisch zugewiesen.
Abschließend sei noch angemerkt, daß es einen Versuch wert ist,
auszuprobieren, welche Parallelport-Programmierer/-JTAG-Software mit
diesem speziellen USB-Adapter klarkommt.
Ich werde das Thema in absehbarer Zeit mit einem Arm-Wiggler und einem
AVR-ISP testen.
