Doron Holan: Driver::works, while a nice idea, was a bug ridden product. Do not go out and
seek it, there are reasons it died.
Maxim S. Shatskih: This product was amazingly buggy, and now is actually replaced by KMDF.
Friends,
Driver::Works is not subject of this thread, but…
Driver::Works was OK. By the way, our Product received WHQL certificate too…
Driver::Works COM driver had bugs. I myself had fixed few of them and sent to support team (Levin-Berlin?) such as last versions was OK. By the way, Driver::Works COM has ~60K source, such as DDK’s COM ~660K - significant diffference
I know few marketable products which has been started with Driver::Works and use it till now…
Driver::Works had full sources. What is about KMDF…?
> Then, again, why are you not using the standard usbser.sys driver?
Because my job is to see if it is possible to make a own driver for our device.
I don’t say it’s going to be easy, or that I will succeed but I should investigate it.
And I must admit that I think it’s really intressting too.
> Then, again, why are you not using the standard usbser.sys driver?
Because my job is to see if it is possible to make a own driver for our device.
Of course it is possible. The mere existence of usbser.sys is proof of
that. That’s not the point.
The point is that your company is not in the business of selling
drivers. You’re in the business of selling a piece of hardware. You
want your hardware to be usable on Windows. THAT’S the problem you have
to solve. Given two possible solutions – use usbser.sys with a week’s
effort, or develop your own driver with four months of effort – no
company that cared about profit would ever choose the latter solution.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
So, let’s see… what you’re saying is that you know a few marketable products that are extraordinarily buggy and exhibit poor behavior in (at the very least) their power management. NICE!
To quote one of my favorite Don Burn expressions: Can you tell us the names of these products, so we can be sure to never install them on any of our machines?
Ah! You know the OP and what his company does! That certainly helps in terms of defining appropriate solutions.
No, actually, I don’t. I “assumed”, with all of the risks that
implies. Statistically speaking, I’m probably right, since there are
essentially zero companies in the world that are in the business of
selling drivers. People write drivers to drive hardware, not to drive
revenue. Gosh, that’s a good line…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, July 06, 2010 2:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Virtual COM-port driver
Ah! You know the OP and what his company does! That certainly helps in
terms of defining appropriate solutions.
No, actually, I don’t. I “assumed”, with all of the risks that implies.
Statistically speaking, I’m probably right, since there are essentially zero
companies in the world that are in the business of selling drivers. People
write drivers to drive hardware, not to drive revenue. Gosh, that’s a good
line…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Statistically speaking you’re PROBABLY right… but you’re incorrect about the rest of your assertion.
There are certainly companies that “write drivers to drive hardware, no drive revenue”… These people create commodity device drivers. But there are LOTS of companies that use their drivers as a significant part of the “value add” of their product. Not EVERY driver is a commodity.
We don’t really know the category into which the OP falls… maybe he wants a proprietary interface, or one that adds some value. Who really knows? In any case, we’ve told him there are alternatives, so if his boss wants him to look into writing his own, it’s not like we have any cause to be offended and tell him he can’t do it…
Thank you Peter.
I know this is a hugh task to do and probably it will take a hugh time and effort. But my company and specially my boss thinks this should be investigated, so I will try.
And it actually exist circumstances that make the usbser.sys a bit inappropriate for our devices. But I’m not able to talk about our devices or how the work/don’t work here at internet, so you can save your questions.
> yes ofcourse you have to implement some minor modification or add the code for initializing your port > with default configuration ,etc in adddevice routine.
I’m working with this right now and I’m not sure how to do this. I have implementet a usb-driver as a base driver for my device and it seems to work. So now I want to initialize the COM-port in EvtDeviceAdd to but I’m not sure how to do it.
I have studied the serial example and they are doing a lot of things in the SerialEvtDeviceAdd, for example:
WdfDeviceInitSetExclusive(DeviceInit, TRUE);
WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_SERIAL_PORT);
…
and setting a lot of callbacks and so on.
But my driver is a usb-driver and I don’t think I need to do all that just for initialize the COM-port. But I can’t understand what I really must do.
So, anyone have any suggestion what must be done for initalizing a COM-port with default configurations in my case?
I’m working with this right now and I’m not sure how to do
this. I have implemented a usb-driver as a base driver for my
device and it seems to work. So now I want to initialize the
COM-port in EvtDeviceAdd to but I’m not sure how to do it.
I have studied the serial example and they are doing a lot of
things in the SerialEvtDeviceAdd, for example:
WdfDeviceInitSetExclusive(DeviceInit, TRUE);
WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_SERIAL_PORT); …
and setting a lot of callbacks and so on.
But my driver is a usb-driver and I don’t think I need to do
all that just for initialize the COM-port.
Well, re-think it, because you certainly do need it.
Virtual COM ports I have written all were WDM and not WDF, but basic
idea is always the same: your driver has, in your case, USB lower edge,
but it has COM port upper edge. That is, user-mode applications see COM
port and have no idea about USB internals.
Now, COM ports are exclusive devices - if some app opens COM port, no
other app is permitted to open it. Hence -
WdfDeviceInitSetExclusive(DeviceInit, TRUE);
COM ports are, of course, devices of type FILE_DEVICE_SERIAL_PORT -
hence WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_SERIAL_PORT);
“A lot of callbacks”, as you put it are callbacks for all those COM
port-specific IRPs you must support in your driver. It is your task to
implement all these callbacks - that is, inside these callbacks you
translate serial port specific stuff into whatever is required to be
done in your USB device.
Ok, so you mean that besides every thing I do for my USB-part, I have to implement all these callbacks also for the COM-port part?
In my usb-driver I allready creates a device object (for the usb part) do you mean that I indeed must create also a device object for the COM-port? So I will have two device objects?
This confuses me because the earlier state thing about “minor modification”, I just don’t see the minor part in this.
So if I understands you correct (which I probably not do ), I must create a device object for the COM-port too, initialize it, implement all the callbacks needed, (for example EvtDevicePrepareHardware, EvtDeviceD0Entry and so on) for the COM-port too? So it will pretty much be the serial driver example and then the USB driver example put together and then implement support for all serial IOCTL:s convertion to USB?
So if I understands you correct (which I probably not do
), I must create a device object for the COM-port too,
initialize it, implement all the callbacks needed, (for
example EvtDevicePrepareHardware, EvtDeviceD0Entry and so on)
for the COM-port too? So it will pretty much be the serial
driver example and then the USB driver example put together
and then implement support for all serial IOCTL:s conversion to USB?
Now, please think logically. “EvtDevicePrepareHardware for the COM-port
too?” Which hardware do you intend to prepare? You don’t have a 16550
UART; that’s why it is called “virtual” COM port, don’t you think? No,
you do not have one separate WDF device object for USB and another one
for COM. You have one object with USB lower edge and COM upper edge.
Your driver receives COM specific IOCTLs, read and write requests - and
it is your task to proceed them, to transform them into URBs according
to your device specifications and to send them down the USB stack.
Virtual COM ports are not “minor modifications” - it’s a lot of code.
Ok, so you mean that besides every thing I do for my USB-part, I have to implement all these callbacks also for the COM-port part?
Yes. Your USB code is servicing your LOWER edge – the part that talks
to drivers below you. The COM port is servicing your UPPER edge – the
part that offers services to clients above you. Every driver has both
an upper edge and a lower edge, usually speaking two very different
languages. It’s the job of the driver to translate between them.
(Didn’t I just give this speech?)
In my usb-driver I allready creates a device object (for the usb part) do you mean that I indeed must create also a device object for the COM-port? So I will have two device objects?
No, you did NOT create a device object for the USB part. You created a
device object for your device. That device object will accept COM port
requests from above. As part of your handling of those requests, you
will send USB requests to the device object below you. Part of the
initialization of your device happens to involve preparing yourself to
send those USB requests. That’s the part you have implemented, but it’s
only half of the job. Your driver doesn’t actually DO anything at this
point.
This confuses me because the earlier state thing about “minor modification”, I just don’t see the minor part in this.
No, someone was exaggerating. There is actually a fair amount of code
required to make yourself an acceptable COM port device.
So it will pretty much be the serial driver example and then the USB driver example put together and then implement support for all serial IOCTL:s convertion to USB?
More or less. You are combining the two things. The real serial driver
accepts COM port requests at its upper edge, but its lower edge talks to
I/O ports. You need to replace the “talks to I/O ports” part with
“talks to USB”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
), I must create a device object for the COM-port too, initialize it, implement all the callbacks needed, (for example EvtDevicePrepareHardware, EvtDeviceD0Entry and so on) for the COM-port too? So it will pretty much be the serial driver example and then the USB driver example put together and then implement support for all serial IOCTL:s convertion to USB?