Hi,
I am completely new to windows device driver development, attempting my first driver, and was hoping to get some help from this forum regarding a problem that I am facing. I would appreciate any help.
In essence, I am trying to develop a CDROM driver intended to work without any physical device attached. Applications can acquire a handle and issue commands to this driver. Once, the driver receives a command, I intend to redirect it to another application or driver. This briefly sums up what I am trying to do.
Now, my problem is at the very first step and while I have heavily been reading up on WDF documentation, I am still puzzled. I’m particularly puzzled about getting a driver loaded without any physical device attached. In other words, how can I trigger my DriverEntry routine to get called? How can a virtual CDROM be represented in the system? I would really appreciate any general pointers or comments that could help me with solving these issues.
Thank You,
Sajjad
wrote in message news:xxxxx@ntdev…
…
> In essence, I am trying to develop a CDROM driver intended to work without
> any physical device attached. Applications can acquire a handle and issue
> commands to this driver. Once, the driver receives a command, I intend to
> redirect it to another application or driver. This briefly sums up what I
> am trying to do.
Too late. Drivers like this already exist.
Good luck,
–pa
Hi Pavel,
Thanks for your input. I was pretty sure something similar existed. Can you elaborate please?
Regards,
Sajjad
xxxxx@broadcom.com wrote:
In essence, I am trying to develop a CDROM driver intended to work without any physical device attached. Applications can acquire a handle and issue commands to this driver. Once, the driver receives a command, I intend to redirect it to another application or driver. This briefly sums up what I am trying to do.
Now, my problem is at the very first step and while I have heavily been reading up on WDF documentation, I am still puzzled. I’m particularly puzzled about getting a driver loaded without any physical device attached. In other words, how can I trigger my DriverEntry routine to get called?
There are several ways. One way is to write a so-called “legacy”
driver, which is installed and controlled using the Service Control
Manager. You can start and stop these from an application. That’s how
the Microsoft VirtualCD power toy does exactly what you describe.
You can also write a “root enumerated” PnP device, and use the SetupDi
APIs to create a device node for you to control, just like “devcon
install”. This has always seemed like more trouble to me.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
Thank you very much. I was hoping to ask you a couple of follow-up questions.
Regarding the first method that you suggested, is it possible for a black-box application acquire a handle to this driver since it doesn’t have a device interface? Or, does the application need to be aware that this is a non-pnp device?
On the second method, I have attempted to write a rudimentary root-enumerated pnp device that belongs to the CDROM class, but “devcon install” has always failed. The setupapi.log shows error 0xe0000219 attributing the installation failure to a non-existent function driver. Anyhow, I am curious about the SetupDi API that you have mentioned. Is this API used within the driver or application?
Thanks again,
Sajjad
xxxxx@broadcom.com wrote:
Thank you very much. I was hoping to ask you a couple of follow-up questions.
Regarding the first method that you suggested, is it possible for a black-box application acquire a handle to this driver since it doesn’t have a device interface? Or, does the application need to be aware that this is a non-pnp device?
You would create a named device and a symbolic link. Your applications
would open the symbolic link using CreateFile, just like with any
service-based device. There are lots of examples of this – see
src\general\event\wdm in the WDK.
On the second method, I have attempted to write a rudimentary root-enumerated pnp device that belongs to the CDROM class, but “devcon install” has always failed. The setupapi.log shows error 0xe0000219 attributing the installation failure to a non-existent function driver. Anyhow, I am curious about the SetupDi API that you have mentioned. Is this API used within the driver or application?
Application. Everything that is done in Device Manager is exposed
through the SetupDi APIs. They are somewhat complicated, so the best
examples of their use is in the “devcon” sample application in the WDK.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> On the second method, I have attempted to write a rudimentary root-
enumerated pnp device that belongs to the CDROM class, but “devcon
install” has always failed. The setupapi.log shows error 0xe0000219
attributing the installation failure to a non-existent function
driver.
Anyhow, I am curious about the SetupDi API that you have mentioned. Is
this API used within the driver or application?
Thanks again,
Sajjad
try “devcon install” with the parameters for inf and hardware id… for
example for the OSR nothing driver
(http://www.osronline.com/article.cfm?article=390) you would do
something like “devcon install nothing.inf Root\OSRNothing”
Dan
wrote in message news:xxxxx@ntdev…
> Hi Pavel,
>
> Thanks for your input. I was pretty sure something similar existed. Can
> you elaborate please?
>
Like others already mentioned, there is the MS virtual CD, OSR virtual CD,
and so on.
Install them, observe what they do, how they interact with their usermode
control apps.
Regards.
–pa
Thank you all for your responses.
Cheers,
Sajjad
Strictly CD-ROM for a read only filesystem is nice because it can greatly simplify what needs implemented such as just file system read commands. If on the other hand a writer is needed or SCSI commands must be handled, this is a substantial task due to the vast commands and bit combinations that need handled to meet MMC. In the case SCSI commands must be handled, a miniport would be the appropriate design because all you need to do is implement SCSI commands and everything else is handled for you by the port driver. Virtual miniports are described in the WDK, in an article on this site, and there is 3rd party source code which can be googled.
> Now, my problem is at the very first step and while I have heavily been reading up on WDF
documentation
Write a virtual storport miniport instead, at least for post-XP OSes.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Are you sure? My WDK help says Vista SP1 and Server 2008 are the first
implementation of VMiniports.
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> Now, my problem is at the very first step and while I have heavily been
> reading up on WDF
>documentation
Write a virtual storport miniport instead, at least for post-XP OSes.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi,
I had a question about registering interfaces for a software only device.
I read the article that Daniel provided regarding the OSR nothing driver, and followed it to write up a simple driver, but instead of creating a symbolic link, I registered a device interface under GUID_DEVINTERFACE_CDROM. In my INF file, I specified the class as CDROM and using Devcon, I installed the driver under root\cdrom. Everything seems ok as my device shows up in DeviceManager under “DVD/CD-ROM Drives” without any warnings or problems. Even a drive letter pops up under “My Computer”. However, no application can get a handle to the interface. Calling SetupDiGetClassDevs while specifying the cdrom class guid and then calling SetupDiEnumDeviceInterfaces, doesn’t return the interface to the device. This made me wonder whether there are any restrictions on registering interfaces with software only devices. Other than registering an interface, does the driver need to perform anything else?
Another question I had was regarding symbolic links. It seems most software only devices use symbolic links. I wouldn’t mind using a symbolic link, but then will the application and driver become tightly coupled? In other words, will a third party application be able to query for the handle in some way?
Thanks agian,
Sajjad
xxxxx@broadcom.com wrote:
I had a question about registering interfaces for a software only device.
I read the article that Daniel provided regarding the OSR nothing driver, and followed it to write up a simple driver, but instead of creating a symbolic link, I registered a device interface under GUID_DEVINTERFACE_CDROM. In my INF file, I specified the class as CDROM and using Devcon, I installed the driver under root\cdrom. Everything seems ok as my device shows up in DeviceManager under “DVD/CD-ROM Drives” without any warnings or problems. Even a drive letter pops up under “My Computer”. However, no application can get a handle to the interface. Calling SetupDiGetClassDevs while specifying the cdrom class guid and then calling SetupDiEnumDeviceInterfaces, doesn’t return the interface to the device. This made me wonder whether there are any restrictions on registering interfaces with software only devices. Other than registering an interface, does the driver need to perform anything else?
The operating system can’t tell whether your driver has hardware or
not. When you register a device interface, you’re just associating the
GUID with a device object. Did you enable the interface after you
registered it?
The one restriction is that device interfaces only work with PnP
drivers. Are you root-enumerated? If you are a legacy driver (that is,
a service), then you cannot use device interfaces.
Another question I had was regarding symbolic links. It seems most software only devices use symbolic links. I wouldn’t mind using a symbolic link, but then will the application and driver become tightly coupled? In other words, will a third party application be able to query for the handle in some way?
If you use a symbolic link, then your applications must know the
symbolic link. There’s no way to go digging for it. Also, if you have
multiple instances, then you have to come up with a scheme to create
unique symbolic links. This is just one reason why interfaces are better.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> The operating system can’t tell whether your driver has hardware or not. When you register a device interface, you’re just associating the GUID with a device object. Did you enable the interface after you registered it?
At first, I didn’t enable the interface as I thought the framework automatically enabled the interface, then I went ahead and enabled it, but I don’t see any differences. Applications still can’t get a handle.
The one restriction is that device interfaces only work with PnP drivers. Are you root-enumerated? If you are a legacy driver (that is, a service), then you cannot use device interfaces.
I am root-enumerated. I install the device under root\cdrom.
Thanks,
Sajjad