Virtuelle COM als DLL

Geht auch ohne DLL, nur ein wenig Hardware:

Man nehme einen PC mit drei COM Ports und läßt dem ollen Progi seinen 
RS232-Datenstrom auf den ersten COM Port los. Über ein Nullmodemkabel
fängt man die Daten via zweiten Port auf, bearbeitet sie mit dem neuen 
Progi und schickt via dritten Port zur Zielhardware. Ganz einfach, 
nicht?

N. Tesla schrieb:
> Geht auch ohne DLL, nur ein wenig Hardware:

Geht auch ohne Hardware:
Mit com0com und hub4com (-> http://com0com.sourceforge.net/) lassen sich 
virtuelle COm Ports einrichten, die sich auch anzapfen lassen.

gruss

@ N. Tesla

das ist pure Hardware verschwendung, da ist die COM0COM Lösung doch 
schon eleganter ... aber auch nicht unbedingt das was ich suche

ich habe jetzt schon nach COM >> socket Lösungen gesucht und getestet
funktioniert aber alles nicht so richtig ...

Gruss Ralf

Ralf G. schrieb:
> ich suche eine Virtuelle COM die über eine API(DLL) angesprochen werden
> kann, also quasi direkt, ohne die Umwege einer umgelenkten zweiten COM

dann kann nicht gehen, dafür braucht man einen Systemtreiber und dort 
Programmiert man soetwas nicht rein.

Aber mit dem com2com brauchst du nicht mal eine DLL und kannst einfach 
so programmieren.

Das was du suchst dürfte beispielsweise hier zu finden sein:
http://www.eltima.com/products/ -> unter "Developer Software" das 
'Virtual Serial Port ActiveX'
http://www.eterlogic.com/Products.VSPE.html
http://www.fabulatech.com/products.html#serial

Was das Com2Com angeht, nette Idee, aber es wäre halt schon schön, 
wenn's das eben in der o.g. Form gibt: Eine DLL o.ä., mit der man einen 
VCP erzeugen kann.

Ralf

Ralf G. schrieb:
> aber es könnte doch ein Gerätetreiber(virtuelle COM) geben der über eine
> DLL angesprochen werden könnte ...
ja aber wozu sollte man noch ein dll brauchen wenn ein schon eine 
einheitliche Schnittstelle (com) gibt?

Was soll da noch der vorteil von dll sein?

Mach doch 'ne DLL, die auf den physischen COM-Port zugreift und über 
eine API 'ne Anzahl von NamedPipes zur Verfügung stellt. Auf die 
NamedPipes haste dann  Zugriff wie auf 'nen COM-Port, nur dass du eben 
nicht "\\.\COMn" als Filename nimmst, sondern "\\.\pipe\<name><nr>", 
z.B. "\\.\pipe\VCP1". Dann kannste mittels ReadFile(), WriteFile() ganz 
normal auf dem Handle operieren wie mit 'nem seriellen Port auch. Wird 
auch von der libC zur Verfügung gestellt, die Funktion schimpft sich da 
eben "pipe()" und liefert 'nen FileDescriptor zurück.

VirtualBox kann sowas z.B. machen um die COM-Ports der VM auf eine Pipe 
des Hosts zu lenken, falls dieser keine UARTs zur Verfügung stellt. Wozu 
man da ein COM-Objekt braucht, seh ich ehrlich gesagt auch nicht ein.

Das bringt natürlich nur was, wenn du Funktionalität trennen oder 
multiplexen willst. Für einfachen Mehrfachzugriff reichen die 
FILE_SHARE_{READ|WRITE} Flags beim CreateFile doch aus.

Peter II schrieb:
> Ralf G. schrieb:
>> aber es könnte doch ein Gerätetreiber(virtuelle COM) geben der über eine
>> DLL angesprochen werden könnte ...
> ja aber wozu sollte man noch ein dll brauchen wenn ein schon eine
> einheitliche Schnittstelle (com) gibt?
>
> Was soll da noch der vorteil von dll sein?

Naja, wenn man beispielsweise (alte) Software hat, die eine 
COM-Schnittstelle voraussetzt, man aber über eine eigene Software die 
Daten reinfüttern will.

Ralf

Ralf G. schrieb:
> Dafür brauche ich eine Virtuelle COM, die ich möglichst direkt aus
> meiner Software steuern/verwenden will, ohne zusätzliche Tools !
wenn schreibe dir selber einen Treiber

> @ Ralf
>> Naja, wenn man beispielsweise (alte) Software hat, die eine
>> COM-Schnittstelle voraussetzt, man aber über eine eigene Software die
>> Daten reinfüttern will.

und genau das geht mit com2com

> und genau das geht mit com2com
Und genau das sehe ich nicht, wie das bei com2com gehen soll, denn 
soweit ich das verstanden habe erzeugt com2com immer zwei 
Schnittstellen, die miteinander verknubbelt sind.

Ralf

Das stimmt schon, aber es gibt halt Leute die nicht vier VCPs anlegen 
möchten, wenn sie sich beispielsweise dazwischen hängen möchten.
Und andere möchten die Eingangsdaten einer echten Schnittstelle 
modifizieren, bevor sie sie an die Uraltsoftware weiterreichen.

Ralf

Ralf schrieb:
> Das stimmt schon, aber es gibt halt Leute die nicht vier VCPs anlegen
> möchten, wenn sie sich beispielsweise dazwischen hängen möchten.

keine Angst windows kann auch mit mehr als 10 schnittstellen umgehen

> Und andere möchten die Eingangsdaten einer echten Schnittstelle
> modifizieren, bevor sie sie an die Uraltsoftware weiterreichen.
das ist nun schon wieder etwas ganz anders, und hat nichts mit dem 
ursprünglichen Problem zu tun.


Mit Com2Com hättest du schon einen Lösung für dein Problem, nur weil sie 
etwas unschön ist nimmst du sie nicht? Da scheint das Prblem nicht 
wichtig zu sein.

@Peter II:
> keine Angst windows kann auch mit mehr als 10 schnittstellen umgehen
grins

>> Und andere möchten die Eingangsdaten einer echten Schnittstelle
>> modifizieren, bevor sie sie an die Uraltsoftware weiterreichen.
> das ist nun schon wieder etwas ganz anders, und hat nichts mit dem
> ursprünglichen Problem zu tun.
Der Vorschlag Com2Com aber auch nicht, denn es wurde nach einer DLL o.ä. 
zur Erzeugung eines VCP gefragt und nicht nach einem virtuellen 
Nullmodemkabel ;)

> Mit Com2Com hättest du schon einen Lösung für dein Problem, nur weil sie
> etwas unschön ist nimmst du sie nicht? Da scheint das Prblem nicht
> wichtig zu sein.
Ja, es wäre eine Lösung für sein Problem. Aber vielleicht nicht die, die 
er wollte. Abgesehen davon: wie man hier öfter mal sieht tun sich einige 
schwer mit der UART-Schnittstelle und wie man sie richtig bedient. Daher 
kann ich mir durchaus vorstellen, dass ein VCP, der über eine DLL 
bedient wird eben attraktiver ist - ob die Bedienung der DLL nicht 
genauso ein Gefrickel ist wie die eines VCPs steht auf nem ganz anderen 
Blatt ;)

@Rufus:
> Einerseits gibt es dort auch hub4com, und andererseits auch das von Dir
> anscheinend komplett übersehene com2tcp.
Schön. Er hatte aber nach EINEM VCP gefragt, der durch eine DLL 
zugreifbar ist und NICHT DURCH EINEN ZWEITEN VCP oder ne IP-Adresse oder 
oder oder.

> Ansonsten:
> Wenn das Aufstampfen und "ich will aber" wichtiger ist als das Finden
> einer praktikablen Lösung, hindert Dich nichts in der Welt daran, Dir
> den Kram so zu entwickeln, wie Du ihn Dir wünschst.
Ich behaupte nicht, dass Com2Com nicht praktikabel ist. Ich möchte aber 
mal anmerken, dass du aufstampfst und "aber willst, dass Com2Com die 
Antwort" ist.
Eine mögliche Lösung ist Com2Com, keine Frage. Er hat aber nach nem 
anderen Weg gefragt. Ob er Com2Com nimmt oder sich für einen meiner 
Links entscheidet muss er beurteilen, nicht wir.

@Robert:
> wo soll hier das Problem mit com0com liegen?
Es gibt kein Problem an sich. Einige Leute würden eben einen anderen Weg 
bevorzugen. Nicht mehr hab ich behauptet.
Ich möchte nur mal anmerken, dass es sicherlich funktioniert, wenn man 
dann zwei Schnittstellen bedienen muss bzgl. Buffern, wechselnden 
RTS/CTS/DTR/DSR/etc.-Signalen, aber das ist Schnittstellen-spezifisch. 
Ein VCP, der über DLL angesprochen wird und bei dem man die Daten 
reinschiebt und gut ist, ist für manche einfach attraktiver.
Und ja, ich weiss dass er die Logik und Bedienung der Schnittstelle in 
eine eigene Klasse verpacken kann um das gleiche Ziel zu erreichen - 
aber das muss er dann auch erstmal machen.

Ralf

@Rufus:
> Nö. Da keinerlei Begründung außer "will nicht" gekommen ist, sehe ich
> das anders.
oO Verzeihung, wo habe ich geschrieben "_ich_ will das so nicht"?
Wo hat der Beitragsersteller geschrieben, "_er_ will das so nicht"?

> Wären die Forderungen (ja, so muss man das wohl nennen) so detailliert,
> wie Du sie Dir gerade zurechtinterpretiert hast, dann sähe die
> Situation anders aus.
Was fehlt dir noch an Details? Der Beitragsersteller hat geschrieben, 
dass er's per DLL machen möchte, und die ActiveX Controls die ich 
gepostet hatte kommen der Sache schon recht nahe und näher als Com2Com.
Ich habe da also m.E. nix reininterpretiert.
Wo ich die Zügel locker gelassen habe waren die (teils theoretisch, 
teils praktisch hergeholten) Anwendungsfälle unter dem Gesichtspunkt der 
'Programmierfreundlichkeit', sofern man Wert darauf legt.

Ralf

Ralf G. schrieb:
> Ich möchte gerne eine Virtuelle COM über API(DLL) verwenden, also senden
> und empfangen und natürlich auch steuern(konfigurieren) ...

was willst du da steuern? RTS, CTS usw geht auch mit der com2com und 
viel mehr kann man da doch gar nicht machen.

Ralf G. schrieb:
> Dachte da eher an
> Baudrate/Anzahl-DatenBits/Anzahl-StopBits/Parity-Bit/Handshake-Einstellu

das kann du doch alles über die Virtuelle ComPorts von der Applikation 
einstellen. (bin mir aber nicht sicher ob es überhaupt eine auswirkung 
hat, denn es werden ja keine wirklichen daten mit einem Takt 
übertragen).

Ralf G. schrieb:
> wenn ich es richtig gelesen habe  ... sieht WINDOWS eine Verwendung
> einer RS232 über API aber vor ...
>
> in der WIN32 gibt es eine API um mit einer RS232 zu kommunizieren ...
>
> oder die port.dll oder die rsapi.dll ... ist nur eben mit einer echten
> COM

nein - alles Programm die mit einer echten Com umgehen können, können 
auch mit einer Virtuellen umgehen. Für die Programm ist das überhaupt 
kein unterschied. Aus dem Grund kann man auch alte hardware mit alter 
Software für einen USB zum Com adapter betreiben.