Hallo Julian,
ich möchte vorausschicken, dass ich absolut keine Ahnung von der Treiberprogrammierung unter Windows habe. Mein letzter Treiber war ein Druckertreiber für einen NEC P6, der an meinem Atari angeschlossen war.
Weil ich dachte, die inpout32.dll würde direkt auf dem Port schreiben, habe ich im Geräte-Manager den Parallel-Port deaktiviert und gehofft das Windows oder was auch immer da Blödsinn macht dann da nichtmehr hinschreibt. Nur mein Programm ging dann auch nichtmehr... (Wieso? Wenn die DLL direkt auf den Port schreibt dürfte Windows doch da nichts zu sagen haben?)
Ah ja :-)
Im Gegensatz zu DOS oder Windows 9x ist die NT-Linie ein im Großen und Ganzen ordentliches Betriebssystem. D.h. das Betriebssystem hat die Kontrolle über die Hardware. Dazu nutzt das Betriebssystem Treiber, die im Kernelmodus laufen. Anwendungssoftware läuft im Anwendungsmodus und hat somit _keinen_ direkten Zugriff auf die Hardware. Das ist gut so. Das ist auch unter Windows-NT-ähnlichen Betriebssystemen so. Und das ist richtig. Wenn über das Betriebssystem Hardware deaktiviert wurde, darf keine Software, die unter diesem Betriebssystem im Anwendungsmodus läuft, auf diese Hardware mehr zu greifen. Das ist gut so.
Mir ist bewusst das die sauberste Lösung eine externe Elektronik zur Ansteuerung wäre. Das stellt für mich aber einen ziemlichen Mehraufwand dar, weil ich für sowas zu planlos auf diesem Gebiet bin.
Alternative: Win 9x oder DOS installieren, Programm unter DOS entwickeln und laufen lassen?
Ich gehe davon aus dass der Fehler softwareseitig bei irgendeinem Treiber oder einem "Feature" von Windows NT/2k/XP zu suchen ist, und hoffe das jemand, der ein ähnliches Problem schonmal hatte, mir einen Tipp geben kann, wie ich das deaktivieren oder den Parallel-Port für mein Programm reservieren/"locken" kann.
Ich vermute: es ist ein "Feature", aber kein Fehler.
Meine Ausführungen sind aus der Erinnerung zusammengekratzt, sollten aber im Wesentlichen richtig sein. Für Details keine Garantie :-)
Freundliche Grüsse,
Vinzenz