Eigenen Com Port erstellen
-
Hallo !
Ich möchte einen eigenen Com Port erstellen mit dem ich Daten empfangen und senden kann.
Für andere Applicationen soll es so aussehen, als ob z.B. ein com7 mit alles seinen Einstellmöglichkeiten, wie Baudrate etc. existiert.
Hinter com7 soll aber mein Programm/Treiber laufen, der die weitere Verarbeitung der erhaltenen seriellen Daten übernimmt.Geht das ? Kann mir jemand einen tip geben ?
Vielen Dank.
-
zwei tips im win/dos32 konsolenfaq
ein tip im win32 faq
-
Dazu musst Du einen Treiber schreiben...
Warum verwendest Du nicht fertige Produkte (z.B. virtual serial Port). Der simuliert zwei Ports die direkt miteinander verbunden sind. So kannst Du an den einen Port Deine Applikation dranhängen und an den anderen Port kann sich eine andere Dranhängen. Für beide sieht es so aus, also ob ihr direkt miteinander kommuniziert. Kann ich nur empfehlen.
-
Jochen Kalmbach schrieb:
Dazu musst Du einen Treiber schreiben...
man kann auch mit detours ( http://research.microsoft.com/sn/detours/ ) sämtliche apis hooken, die für rs232 zustaändig sind (einschliesslich ReadFile() und WriteFile()), dann braucht man keinen kernel treiber...
-
Wie erstellt man mit API Hooks einen neuen seriellen Port?
-
Gästchen schrieb:
Wie erstellt man mit API Hooks einen neuen seriellen Port?
du hookst erstmal 'CreateFile()' bzw. NtCreateFile(). wenn als name "COM1234" o.ä. kommt, dann gibst du ein 'fake handle' oder 'magic number' zurück. am besten eine ungerade zahl weil die echten handles gerade (oder sogar immer vielfache von 4) sind. jede weitere comm-spezifische funktion, die dann mit diesem handle gefüttert wird, wird auf eine eigene prozedur umgelenkt (z.b. WriteFile() sendet dann über einen socket). das ist eigenlich ganz einfach, selbst sowas wie 'overlapped i/o' (m$ jargon für asynchrone ausführung) lässt sich simulieren.
-
net schrieb:
wenn als name "COM1234" o.ä. kommt,
Und dieser Name ist garantiert nicht belegt und bleibt das garantiert auch (es wird zum Beispiel ausgeschlossen, daß USB <-> Seriell Adapter verwendet werden). Enumerieren kann man den neuen Port natürlich auch, zum Beispiel mit den SetupDi-Funktionen, denn von irgendwoher muß ich ja wissen, welche Ports vorhanden sind.
Also wenn Du mich fragst: Das ist Bullshit.
-
Gästchen schrieb:
Und dieser Name ist garantiert nicht belegt und bleibt das garantiert auch (es wird zum Beispiel ausgeschlossen, daß USB <-> Seriell Adapter verwendet werden).
das es einen namen wie "COMxxxx"(vierstellig) schon gibt kann man zwar nicht ausschliessen aber es wird doch selten vorkommen.
Gästchen schrieb:
Enumerieren kann man den neuen Port natürlich auch, zum Beispiel mit den SetupDi-Funktionen, denn von irgendwoher muß ich ja wissen, welche Ports vorhanden sind.
natürlich geht das auch, SetupDiXXX() gleich mithooken
Gästchen schrieb:
Also wenn Du mich fragst: Das ist Bullshit.
das funzt aber. mein selbstgemachter rs232<-->tcp/ip redirektor arbeitet so. das schöne dabei ist: man muss nix installieren. einfach den redirektor starten und dieser startet dann das programm welches meint es würde über die serielle kommunizieren aber in wirklichkeit geht's übers netzwerk...
-
net schrieb:
das es einen namen wie "COMxxxx"(vierstellig) schon gibt kann man zwar nicht ausschliessen aber es wird doch selten vorkommen.
Also ist das bereits ein KO Kriterium:
net schrieb:
natürlich geht das auch, SetupDiXXX() gleich mithooken
Super, und wenn der Client, den man schließlich nicht notwendigerweise kennt, eine andere Strategie wählt, gibt es gleich das nächste Problem. Was soll ich denn noch alles hooken? Außerdem gibt es genügend Programme, die schlicht und einfach versuchen, den Port zu öffnen und im Falle eines Fehlschlags auf ERROR_FILE_NOT_FOUND testen. Ich habe allerdings noch kein Programm gesehen, daß versucht, Ports über 255 zu öffnen. Wie lösen wir das jetzt? Hooken wir das Programm auch gleich noch, oder was?
Auf der anderen Seite: Bis Du alle nötigen Funktionen (bis Du sicher, daß Du nichts vergessen hast?) gehookt und mit vernünftigem Inhalt gefüllt hast, bin ich mit meinem Treiber lange fertig.
net schrieb:
das funzt aber.
Aber nur bei Dir, hoffentlich. So ein Scheiß darf den eigenen Rechner nicht verlassen. Das ist und bleibt absoluter Pfusch. Wie man soetwas mit ruhigem Gewissen weiterempfehlen kann, entzieht sich meinem Verständnis.
Ich fange gerade an, mich richtig zu ärgern.
-
Und wo wir gerade so schön dabei sind, kannst Du mir sicherlich schnell noch den internen Aufbau von HDEVINFO erkären. Den muß ich schliesslich kennen, wenn ich mich in die Setup-Funktionen einklinken möchte. Die Beschreibung muß aber mit der Garantie versehen sein, daß das auf den gängigen Plattform identisch ist und sich auch in Zukunft nicht ändern wird.
-
net schrieb:
man kann auch mit detours ( http://research.microsoft.com/sn/detours/ ) sämtliche apis hooken, die für rs232 zustaändig sind (einschliesslich ReadFile() und WriteFile()), dann braucht man keinen kernel treiber...
Du vergisst nur, dass Du dazu in dem passenden Prozess sein musst; und global würde ich sowas nicht machen wollen...
-
Jochen Kalmbach schrieb:
...
Warum verwendest Du nicht fertige Produkte (z.B. virtual serial Port). Der simuliert zwei Ports die direkt miteinander verbunden sind ...Das das gut funktioniert, glaube ich gerne, aber mich schrecken die ca. $100 ab ...
-
Gästchen schrieb:
Auf der anderen Seite: Bis Du alle nötigen Funktionen (bis Du sicher, daß Du nichts vergessen hast?) gehookt und mit vernünftigem Inhalt gefüllt hast, bin ich mit meinem Treiber lange fertig.
hab's innerhalb von zwei tagen zusammengebastelt und mit 4 terminalprogrammen getestet, eins davon macht async i/o. in der zeit stellste keinen vollwertigen treiber auf die beine
Gästchen schrieb:
Ich fange gerade an, mich richtig zu ärgern.
warum?
Gästchen schrieb:
Und wo wir gerade so schön dabei sind, kannst Du mir sicherlich schnell noch den internen Aufbau von HDEVINFO erkären. Den muß ich schliesslich kennen, wenn ich mich in die Setup-Funktionen einklinken möchte. Die Beschreibung muß aber mit der Garantie versehen sein, daß das auf den gängigen Plattform identisch ist und sich auch in Zukunft nicht ändern wird.
man muss die funktionen nicht 1:1 nachbauen sondern nur deren verhalten simulieren. der aufrufer muss zufrieden sein. das reicht.
Jochen Kalmbach schrieb:
net schrieb:
man kann auch mit detours ( http://research.microsoft.com/sn/detours/ ) sämtliche apis hooken, die für rs232 zustaändig sind (einschliesslich ReadFile() und WriteFile()), dann braucht man keinen kernel treiber...
Du vergisst nur, dass Du dazu in dem passenden Prozess sein musst; und global würde ich sowas nicht machen wollen...
so isses. es werden nur ausgewählte prozesse manipuliert. alle anderen werden nicht gehookt. das bringt übrigens einen weiteren vorteil mit sich: mehrere prozesse können einen vermeintlich gleichen (umgelenkten) comm-port öffnen
-
net schrieb:
hab's innerhalb von zwei tagen zusammengebastelt
Du sagst es: Du hast gebastelt.
net schrieb:
warum?
Weil Du so merkbefreit bist. Du baust Scheiße und empfiehlst das weiter!
net schrieb:
man muss die funktionen nicht 1:1 nachbauen sondern nur deren verhalten simulieren. der aufrufer muss zufrieden sein. das reicht.
Und wie stelle ich das sicher an?
net schrieb:
alle anderen werden nicht gehookt. das bringt übrigens einen weiteren vorteil mit sich: mehrere prozesse können einen vermeintlich gleichen (umgelenkten) comm-port öffnen
Naja, das mache ich seit Jahren, habe dafür aber einen eigenen Prozess laufen. XP hat's durch FUS nötig gemacht.
-
tueftler schrieb:
Das das gut funktioniert, glaube ich gerne, aber mich schrecken die ca. $100 ab ...
Das ist Dir zu günstig und Du hast Angst, daß da noch ein Haken ist. Oder erwartest Du, daß sie Dir das hinten rein blasen?
-
Gästchen schrieb:
net schrieb:
man muss die funktionen nicht 1:1 nachbauen sondern nur deren verhalten simulieren. der aufrufer muss zufrieden sein. das reicht.
Und wie stelle ich das sicher an?
winapi-funktionsn sind sehr gut beschrieben. guckst du: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_winbaseservices.asp
wenn sich die gehookte funktion gemäss der specs. verhält, kannste davon ausgehen, dass es mit 99% der anwendungen klappt...aber eine absolute sicherheit gibt es natürlich nie...eine weitere schöne bastelei mit detours ist z.b. mein registry-faker. dabei werden registry-zugriffe in ein verzeichnis auffer pestflatte umgelenkt. nur eine spielerei, doch sehr interessant (aber sicher nicht für dich).
edit: ist mir gerade aufgefallen: jochen, wieso postest du als 'gästchen'?
