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

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@hotmail.com> wrote in message
news:OOlxXM1QFHA.612@TK2MSFTNGP14.phx.gbl...

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@stopspam.acm.org> wrote in message
news:7Xt8e.1533$Gq6.937@fe02.lga...

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@hotmail.com> wrote in message
news:Osnv$a1QFHA.2252@TK2MSFTNGP15.phx.gbl...

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@stopspam.acm.org> wrote in message
news:Sfu8e.1537$Gq6.751@fe02.lga...

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@hotmail.com> wrote in message
news:OUtApu1QFHA.3076@TK2MSFTNGP14.phx.gbl...

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@stopspam.acm.org> wrote in message
news:nLu8e.1543$Gq6.264@fe02.lga...

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@hotmail.com> wrote in message
news:ex6m$B2QFHA.3880@tk2msftngp13.phx.gbl...

No. This is true only if the driver is loaded by import resolution, and not by
SC. This in turn depends on whether this driver is registered in SC database at
all.

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

This is fine. Just have no DriverEntry in a kernel-mode DLL. For instance, MS's
SCSIPORT is such.

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

Hi Maxim,

How do I force the load of the driver (an export_driver) by the system as a
driver and not as a DLL?

Is such a keyword available in the INF file? Or is such a definition
possible in the driver code?

What I understand from this is that the DriverEntry is called when the
export driver is loaded as a normal driver and the DllInitialize is called
when the driver is loaded as DLL by import resolution.

How do I make sure that the driver is always loaded as normal driver and not
due to import resolution?

Thanks in advance,

Regards,

Raj

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:uit7mT3QFHA.248@TK2MSFTNGP15.phx.gbl...

Hi Maxim,

As I said that's not so easy. I want to use my driver as a normal driver and
just provide the API interface to it for other drivers by providing them a
LIB file. This is not possible until I make sure that the driver is loaded
as a normal driver and not as a DLL.

In case of normal driver, the DriverEntry is called and the AddDevice is
called and then the PnpDespatch. But I want to make sure all these happen in
any case.

Thanks in advance for the reply,

Regards,

Raj

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:%23jKIYV3QFHA.580@TK2MSFTNGP15.phx.gbl...

install the driver as a service, then the SC (service controller) will start
it if the start type is correct. as long as it is not disabled (0x4) or
demand start (0x3), DriverEntry will be called. BUT, it will be loaded as
an NT4 legacy style driver (no AddDevice will be called)unless the driver is
also installed on a pnp device.

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.


"G.N.Raj" <gnraj@hotmail.com> wrote in message
news:e$cf9S8QFHA.1528@TK2MSFTNGP09.phx.gbl...

Thanks for the reply Doron,

The driver is installed on a PnP Device. It is a PCI Card driver.

I don't want to get into the legacy mode now as the PnP implementation is
fully functional. I just want to export the APIs from my driver in the
kernel mode to other drivers.

Is there any way to force the DriverEntry in case of PnP?

Thanks in advance,

Regards

Raj

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:O%23hEJt%23QFHA.2384@tk2msftngp13.phx.gbl...

use a 3rd driver to export these functions. the driver model is not really
designed to do what you want. seeing that there is no way to unload the
export driver w/out first unloading all the clients that use it, you are
just as well off putting the functionality in a lib in each client instead
w/out all of this hassle.

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.


"G.N.Raj" <gnraj@hotmail.com> wrote in message
news:OA4S4gMRFHA.2748@TK2MSFTNGP09.phx.gbl...

Thank you very much.

Now I am convinced that the only way out is to implement another Kernel DLL
interfacing with the current driver and get that interface with the other
drivers.

--Raj

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:ecqA2SXRFHA.2744@TK2MSFTNGP10.phx.gbl...

Another alternative is to load as a PnP driver (what you call a "normal"
driver) and then use kernel callbacks for your clients to find you (or get
notified when your driver loads if they happen to load -before- your driver
does) , get your entry points and pass their entry points to you.
The fact that the clients have to use kernel callbacks to get a list of your
entry points should not be a blocker for you to define and document how
these entry points work. Yes, you need to use versioning in the call tables
you exchange with your clients so you can add to these entry points as
necessary.


Check out ExRegisterCallback and ExNotifyCallback.

Let me know if you are interested in this approach and I'll try to post some
sample code.(after WinHec)

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"G.N.Raj" <gnraj@hotmail.com> wrote in message
news:OA4S4gMRFHA.2748@TK2MSFTNGP09.phx.gbl...

Yes Ali,

I am interseted in exploring this approach as well. Let me know more details
and please give me some sample code for me to understand it better.

--Raj

"msnews.microsoft.com" <alid@online.microsoft.com> wrote in message
news:e$%23thhKSFHA.3144@tk2msftngp13.phx.gbl...