Virtual COM Port

I need to develop a Virtual COM port drive, which needs to act as a bridge
between legacy applications (using COM ports) and a USB driver (Which is
already available). To the legacy applications, this should look/feel/act
like a COM port, but internally, the driver needs to communicate with the USB
driver for the needful.
I have stared with the serail driver sample provided with DDK as the base,
is that the right place to start? Any design guidelines I should keep in
mind? Also, is there any available sample code, which can be used for
reference.

Maxim
Thu Feb 07 02:41:09 CST 2008

Write your own driver which will support all IOCTLs supported by SERIAL and
will talk to USB from its bottom edge (see the USB samples in the WDK).

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Kabir" <Kabir@discussions.microsoft.com> wrote in message
news:C879F6CD-000B-40C9-8BC6-7B9883C6E50B@microsoft.com...
> I need to develop a Virtual COM port drive, which needs to act as a bridge
> between legacy applications (using COM ports) and a USB driver (Which is
> already available). To the legacy applications, this should look/feel/act
> like a COM port, but internally, the driver needs to communicate with the USB
> driver for the needful.
> I have stared with the serail driver sample provided with DDK as the base,
> is that the right place to start? Any design guidelines I should keep in
> mind? Also, is there any available sample code, which can be used for
> reference.

Doron
Thu Feb 07 11:49:33 CST 2008

yes, the serial example is the right place to start. you will need to
suport all of the ioctls and associated semantics. instead of talking to
registers and an interrupt you must usb URBs. i strongly suggest that you
start with the KMDF serial example and use the USB WDFIOTARGETs as your
starting point

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Kabir" <Kabir@discussions.microsoft.com> wrote in message
news:C879F6CD-000B-40C9-8BC6-7B9883C6E50B@microsoft.com...
>I need to develop a Virtual COM port drive, which needs to act as a bridge
> between legacy applications (using COM ports) and a USB driver (Which is
> already available). To the legacy applications, this should look/feel/act
> like a COM port, but internally, the driver needs to communicate with the
> USB
> driver for the needful.
> I have stared with the serail driver sample provided with DDK as the base,
> is that the right place to start? Any design guidelines I should keep in
> mind? Also, is there any available sample code, which can be used for
> reference.

chris
Fri Feb 08 09:59:53 CST 2008

On Feb 7, 11:49 am, "Doron Holan [MSFT]" <dor...@online.microsoft.com>
wrote:

> yes, the serial example is the right place to start. you will need to
> suport all of the ioctls and associated semantics. instead of talking to
> registers and an interrupt you must usb URBs. i strongly suggest that you
> start with the KMDF serial example and use the USB WDFIOTARGETs as your
> starting point

Given that the serial I/O upper edge is fairly complicated, my
suggestion to the original poster is to write a KMDF lower-filter to
usbser.sys that reroutes the data I/O URBs as necessary and just
throws away the CDC ACM stuff. You may also need to play with your
descriptors to get usbser.sys to load.

Maxim
Sat Feb 09 09:05:44 CST 2008

> suggestion to the original poster is to write a KMDF lower-filter to
> usbser.sys that reroutes the data I/O URBs as necessary and just

Are you really thinking that virtual USB HC (even 1 port) is simpler then
virtual COM port?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

chris
Mon Feb 11 10:32:33 CST 2008

On Feb 9, 9:05 am, "Maxim S. Shatskih" <ma...@storagecraft.com> wrote:

> > suggestion to the original poster is to write a KMDF lower-filter to
> > usbser.sys that reroutes the data I/O URBs as necessary and just
>
> Are you really thinking that virtual USB HC (even 1 port) is simpler then
> virtual COM port?

No. Where did I say he should write a "virtual USB HC"?