Re: Question on EXPORT_DRIVER

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Raj,

It is not required, but from your question of keeping the new driver
independent, I thought you might be going in that direction. Good luck with
your efforts.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"G.N.Raj" <gnraj@xxxxxxxxxxx> wrote in message
news:ex6m$B2QFHA.3880@xxxxxxxxxxxxxxxxxxxxxxx
Thanks Don,

Both the approaches would do for me.

But one clarification. Why is GetProcAddress required? Even currently I
don't use this call even in user mode. I publish the list of APIs
supported and the DLL which has all these. The user mode application just
uses this DLL and calls the correspondig API.

Is there something I am missing here?

Thanks in advance,

Regards,

Raj

"Don Burn" <burn@xxxxxxxxxxxxxxxx> wrote in message
news:nLu8e.1543$Gq6.264@xxxxxxxxxxx
Raj,

A couple approaches here. Make sure your driver loads early, and
provide a check at either dllinit or the individual exported functions or
both, that the initialization is complete.

You could also create a static library, that used the
DeviceInterface model and hid it in standard calls (with checks that the
interface is present). You would need a LibInit, LibUnload functions so
that the interface can be handled correctly.

One thing to note on your design, there is no equivalent of
GetProcAddress for export drivers.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"G.N.Raj" <gnraj@xxxxxxxxxxx> wrote in message
news:OUtApu1QFHA.3076@xxxxxxxxxxxxxxxxxxxxxxx
Thanks Do,

I got this technique. This can be used between two drivers which know
each other.

I want to support something like an API library in the kernel for my
driver. I have a lot of functions to export and the caller knows about
the APIs only.

I was having the API Library as a DLL in the user mode till now and that
was connected to the kernel driver through IOCTL calls. But for me to
provide the same interfaces in Kernel, I either need to have another DLL
connecting to my existing driver through these interfaces and provide
the API Interfaces for my customer.

I was trying to see if the EXPORT_DRIVER technique works for me so that
I don't have to write anything new as such and use the current APIs in
my driver as exported APIs for my customer.

Can we not avoid the situation in which the driver load and DLL load
sequences interchange which ultimately the problem you mentioned?

Is there any way where in we can avoid this?

Thanks in advance,

Regards,

Raj

"Don Burn" <burn@xxxxxxxxxxxxxxxx> wrote in message
news:Sfu8e.1537$Gq6.751@xxxxxxxxxxx
Raj,

No, with plug and play there is now IoRegisterDeviceInterface and
IoRegisterPlugPlayNofitification. These allow you to get a create a
structure with function pointers and data for another driver, and the
other driver to know of their existance by a callback. Take a the
calls mentioned and the toaster sample which has a good example of
using them.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"G.N.Raj" <gnraj@xxxxxxxxxxx> wrote in message
news:Osnv$a1QFHA.2252@xxxxxxxxxxxxxxxxxxxxxxx
Thanks Don,

By device interfaces, you mean IOCTL interfaces?

I have to provide a Library interface to my hardware driver for use by
other drivers. This is for productization purposes.

I was thinking of leaving my driver code as is and provide the DLL
interface to it by making the driver as export_driver and providing
the .lib as part of my product release.

But if this has some known issue, I have to build another Kernel DLL
over the current driver and use the IOCTL interface between the DLL
and the current driver to provide the procedural API interface for my
driver in kernel.

Is there any other way to solve this problem?

Thanks in advance,

Regards,

Raj

"Don Burn" <burn@xxxxxxxxxxxxxxxx> wrote in message
news:7Xt8e.1533$Gq6.937@xxxxxxxxxxx
Raj,

I have not done this since the NT4.0 days, but at that time.
DriverEntry was called as the driver started through the services
entry. DriverEntry was not called if the driver was loaded as a DLL.
So as long as your export driver starts as a driver before the first
driver to use it a DLL calls the driver you can initialize things in
DriverEntry. You should have a check that initialization is done, I
had a nasty bug once where the export/device driver loaded, then
failed and was unloaded, then got reloaded as a DLL without the
initialization.

If this is in a plug and play environment, consider using
device interfaces instead. These are safer IMHO, and provide a lot
of flexibility in the presence of plug and play requests asking for a
device to added or removed.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"G.N.Raj" <gnraj@xxxxxxxxxxx> wrote in message
news:OOlxXM1QFHA.612@xxxxxxxxxxxxxxxxxxxxxxx
Hello All,

I have a question on EXPORT_DRIVER.

I have read the related articles and the questions raised on the
same and the answers also for the same. But, I could not get the
answer to my question anywhere. Please correct me if I have missed
out any posting and give me pointers for the same.

There is a mention in the DDK and in the related articles/postings
that a driver compiled as an EXPORT_DRIVER can be used as a normal
driver also.

Also, there is a mention that the DriverEntry of this EXPORT_DRIVER
is never called and the DllInitialize is called instead.

Does this mean that, if I convert my driver to an EXPORT_DRIVER, I
have to move contents of DriverEntry into DllInitialize?

Or is the DllInitialize called only when the driver is used as
EXPORT_ONLY driver?

Please clarify this point and help me in using my driver as an
EXPORT_DRIVER and DRIVER (Normal driver for Hardware).

Thanks in advance,

Best Regards,

Raj















.

Relevant Pages

  • Re: InterruptInitialize fails
    ... So what you have is a dll that implements an well published, by you, API ... functionality in a different way, ... Summary of my blog posts about writing a stream interface driver: ...
    (microsoft.public.windowsce.app.development)
  • Re: Linux Firewall/LoadBalancer
    ... The bonding driver originally came from Donald Becker's beowulf patches for ... Build kernel with the bonding driver ... "Bonding driver support" in the "Network device support" section. ... so the bonding driver will automatically load when the bond0 interface is ...
    (Security-Basics)
  • Re: wpa supplicant/ipw3945, ESSID last char missing
    ... driver interface have to be tied to the userspacewireless ... If the driver does X ... The issue is that the userspace API ...
    (Linux-Kernel)
  • [PATCH] IPMI driver updates, part 2
    ... It has been far too long since the last IPMI driver updates, ... This second part adds the "System Interface" driver. ...
    (Linux-Kernel)
  • [2.6 patch] remove comx driver docs
    ... info on the driver for Baycom style amateur radio modems ... -LMI) protocols are available as link-level protocol. ... -The COMX driver set has a new type of user interface based on the /proc ... -To create the interface 'comx0' which is the first channel of a COMX card: ...
    (Linux-Kernel)