I got a task to create the com port for the USB printer device. The device is CDC compatible. I have taken reference from the serial sample and remove all the things which are touching the real hardware. I able to install the com port driver but I am not able to understand how I can send the request to the USB device. Some post I found that mentioned that use URB to send the request but I am new on windows device driver so I am not able to understand how I can use URB. I want to create driver similar to usbser but I am not getting the proper reference for the usbser. Please give me some suggestion that how I can create driver similar to the usbser. 
On Mar 6, 2019, at 6:49 AM, pritosh_mishra wrote:
>
> I got a task to create the com port for the USB printer device.
Why are so many people doing this? There is a long-established and well-tested USB Printer Device Class specification that is specifically designed for USB-based printers. Serial ports are a 60-year-old technology. There are better ways to do things today.
> I have taken reference from the serial sample and remove all the things which are touching the real hardware.
What is your eventual goal here? The path you are on will end up with a driver that talks to your printer and looks like a serial port to software. That’s fine, but that doesn’t get you a Windows printer device. You would only talk to it from custom applications. Is that what you’re after? Every driver in Windows has lower interface and an upper interface. The lower interface talks to a bus driver, or sometimes to hardware. The upper interface talks to applications, or to next higher level drivers. So, for example, a USB mass storage driver has a lower interface that is USB, and an upper interface that is mass storage, so it can be used by normal system disk operations. The job of the driver is simply to translate from one interface to the next.
In your case, your lower interface is USB, but what is your upper interface? Do you really want to expose a COM port? Or do you want to expose a printer?
> I able to install the com port driver but I am not able to understand how I can send the request to the USB device. Some post I found that mentioned that use URB to send the request but I am new on windows device driver so I am not able to understand how I can use URB. I want to create driver similar to usbser but I am not getting the proper reference for the usbser. Please give me some suggestion that how I can create driver similar to the usbser.
If all you want on the upper end is a serial port, then you don’t want a driver similar to usbser, you want usbser EXACTLY. Right?
You will need to understand the USB CDC spec to know what the USB protocol looks like for CDC devices. There are lots of driver examples that show how to create and send URBs You just have to figure out, for each ioctl you get, which URB or URBs need to be sent. It’s a fairly mechanical operation.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
Why are so many people doing this?
MY question is why are people posting technical questions in the Announcements and Administration category?
Is there something confusing about the Community interface that causes folks to do this?
(moving the thread to NTDEV where it belongs)
Peter
@Tim_Roberts said:
On Mar 6, 2019, at 6:49 AM, pritosh_mishra wrote:I got a task to create the com port for the USB printer device.
Why are so many people doing this? There is a long-established and well-tested USB Printer Device Class specification that is specifically designed for USB-based printers. Serial ports are a 60-year-old technology. There are better ways to do things today.
I have taken reference from the serial sample and remove all the things which are touching the real hardware.
What is your eventual goal here? The path you are on will end up with a driver that talks to your printer and looks like a serial port to software. That’s fine, but that doesn’t get you a Windows printer device. You would only talk to it from custom applications. Is that what you’re after? Every driver in Windows has lower interface and an upper interface. The lower interface talks to a bus driver, or sometimes to hardware. The upper interface talks to applications, or to next higher level drivers. So, for example, a USB mass storage driver has a lower interface that is USB, and an upper interface that is mass storage, so it can be used by normal system disk operations. The job of the driver is simply to translate from one interface to the next.
In your case, your lower interface is USB, but what is your upper interface? Do you really want to expose a COM port? Or do you want to expose a printer?
I able to install the com port driver but I am not able to understand how I can send the request to the USB device. Some post I found that mentioned that use URB to send the request but I am new on windows device driver so I am not able to understand how I can use URB. I want to create driver similar to usbser but I am not getting the proper reference for the usbser. Please give me some suggestion that how I can create driver similar to the usbser.
If all you want on the upper end is a serial port, then you don’t want a driver similar to usbser, you want usbser EXACTLY. Right?
You will need to understand the USB CDC spec to know what the USB protocol looks like for CDC devices. There are lots of driver examples that show how to create and send URBs You just have to figure out, for each ioctl you get, which URB or URBs need to be sent. It’s a fairly mechanical operation.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
What is your eventual goal here? The path you are on will end up with a driver that talks to your printer and looks like a serial port to software. That’s fine, but that doesn’t get you a Windows printer device. You would only talk to it from custom applications. Is that what you’re after? Every driver in Windows has lower interface and an upper interface. The lower interface talks to a bus driver, or sometimes to hardware. The upper interface talks to applications, or to next higher level drivers. So, for example, a USB mass storage driver has a lower interface that is USB, and an upper interface that is mass storage, so it can be used by normal system disk operations. The job of the driver is simply to translate from one interface to the next.
In your case, your lower interface is USB, but what is your upper interface? Do you really want to expose a COM port? Or do you want to expose a printer?
Yes I want to expose it as comport not a printer.
If all you want on the upper end is a serial port, then you don’t want a driver similar to usbser, you want usbser EXACTLY. Right?
Yes, I have to create a driver similar to usbser which able to handle the serial signal. Is there any example driver available that explain the CDC class.
pritosh_mishra wrote:
Yes I want to expose it as comport not a printer.
If your device complies with the USB CDC spec and advertises the proper
device class in its descriptor with class code 02 and subclass 02, then
usbser.sys will automatically be loaded as soon as your device is
plugged in to Windows 10. For earlier systems, you may need to write an
INF file, but you do not have to write a driver at all.
Yes, I have to create a driver similar to usbser which able to handle the serial signal. Is there any example driver available that explain the CDC class.
What do you mean by “similar to usbser”? How would your driver be
different from usbser? Let me point out that there is a STRONG
incentive to make your device CDC class compliant, so you can totally
avoid the hassle of writing and maintaining a driver. Just use
usbser.sys as is, out of the box. It is already installed on all of
your user’s computers.
@Tim_Roberts said:
pritosh_mishra wrote:Yes I want to expose it as comport not a printer.
If your device complies with the USB CDC spec and advertises the proper
device class in its descriptor with class code 02 and subclass 02, then
usbser.sys will automatically be loaded as soon as your device is
plugged in to Windows 10. For earlier systems, you may need to write an
INF file, but you do not have to write a driver at all.Yes, I have to create a driver similar to usbser which able to handle the serial signal. Is there any example driver available that explain the CDC class.
What do you mean by “similar to usbser”? How would your driver be
different from usbser? Let me point out that there is a STRONG
incentive to make your device CDC class compliant, so you can totally
avoid the hassle of writing and maintaining a driver. Just use
usbser.sys as is, out of the box. It is already installed on all of
your user’s computers.
Thanks, Tim for the reply, we want to handle signal as per our host application. It is the reason we require to create own driver. Is there any example for CDC driver.
pritosh_mishra wrote:
Thanks, Tim for the reply, we want to handle signal as per our host application. It is the reason we require to create own driver. Is there any example for CDC driver.
No. What is it that you need to do that the standard driver does not
do? You should consider whether you could solve your problem by using
an upper filter driver to usbser.
Serioualy, although drivers have become easier to write thanks to KMDF,
there is still a considerable investment required to design, develop,
test, distribute, and support a kernel driver, especially one that has
to match an industry specification. To develop one where an inbox
driver already provides 99% of the functionality is just a pointless
waste of human resources.