RE: [ntdev] Re: Loading modules dynamically into kernel space.Microsoft prefers a driver to a DLL for a variety of reasons. By having a single entry point to load a driver we can enforce certain policies that the administrators set. For example an administrator could decide to not load any unsigned drivers.
Note that ZwSetInformationFile is not documented and we could remove it from a later release.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“Bi Chen” wrote in message news:xxxxx@ntdev…
Guys.
Kerenl dll is far better than kludge of this kind. I don’t know why Microsoft not recommending it. Display driver is a dll of graphics card miniport driver.
I used kernel dll not only export C functions, but also C++ class libraries. This feature is impossible if you use IoLoadDriver. If you really want to it to be late binding, use VC6 or later’s delayed load feature. That is if you do not call the exported function, the module will not be loaded into memory. The same is true if you use some features in Win2k that is not available in NT4.0, just don’t invoke anything exported by the dll after get the version of the OS.
Bi
-----Original Message-----
From: James Antognini [mailto:xxxxx@mindspring.nospam.com]
Sent: Thursday, October 17, 2002 12:07 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Loading modules dynamically into kernel space.
I’ve used ZwSetSystemInformation with both SystemLoadImage and
SystemLoadAndCallImage. I’ve also used ZwLoadDriver. That was several
years ago, but I don’t recall any particular problems.
In any case, I wouldn’t bother with loading a dll as a dll. What I’ve
done (actually, I cannot take the credit, as it was someone else’s
idea), and quite successfully, was to 1) load a secondary driver; 2)
have the driver’s DriverEntry build a vector of entry points to dll-like
functions, in the device extension, and 3) have other kernel functions
(in a different driver) locate the extension and invoke the functions
via the vector.
The invocations looked something like this:
ModuleIoctl =
DeviceContext->pModuleMasterDeviceContext->ModuleCallbacks.ModuleIoctl;
Status = (*ModuleIoctl) (DeviceObject, Irp, IrpSp);
The technique is admitedly not automatic as a dll – one has to load the
secondary driver, establish the vector and, elsewhere, do the lookup and
then the invocation – but it gives one complete control. An advantage
of complete control is that the dll-like driver is loaded only if and
when it is needed, and so the “main” driver cannot fail to be loaded
because of trying itself to import functions not supported in the OS.
(In fact, I made use of the technique in a driver application suited to
both WinNT and Win2K: Win2K-specific activities were isolated in the
dll-like driver, which the main driver loaded only when it sensed the OS
was Win2K.)
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
ZwSetInformationFile is in fact documented in the XP IFS kit and had
better not change. 
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nar Ganapathy[MS]
Sent: Tuesday, November 26, 2002 10:45 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Loading modules dynamically into kernel space.
Microsoft prefers a driver to a DLL for a variety of reasons. By having
a single entry point to load a driver we can enforce certain policies
that the administrators set. For example an administrator could decide
to not load any unsigned drivers.
Note that ZwSetInformationFile is not documented and we could remove it
from a later release.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no
rights.
“Bi Chen” wrote in message news:xxxxx@ntdev…
Guys.
Kerenl dll is far better than kludge of this kind. I don’t know why
Microsoft not recommending it. Display driver is a dll of graphics card
miniport driver.
I used kernel dll not only export C functions, but also C++ class
libraries. This feature is impossible if you use IoLoadDriver. If you
really want to it to be late binding, use VC6 or later’s delayed load
feature. That is if you do not call the exported function, the module
will not be loaded into memory. The same is true if you use some
features in Win2k that is not available in NT4.0, just don’t invoke
anything exported by the dll after get the version of the OS.
Bi
-----Original Message-----
From: James Antognini [mailto:xxxxx@mindspring.nospam.com]
Sent: Thursday, October 17, 2002 12:07 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Loading modules dynamically into kernel space.
I’ve used ZwSetSystemInformation with both SystemLoadImage and
SystemLoadAndCallImage. I’ve also used ZwLoadDriver. That was several
years ago, but I don’t recall any particular problems.
In any case, I wouldn’t bother with loading a dll as a dll. What I’ve
done (actually, I cannot take the credit, as it was someone else’s
idea), and quite successfully, was to 1) load a secondary driver; 2)
have the driver’s DriverEntry build a vector of entry points to dll-like
functions, in the device extension, and 3) have other kernel functions
(in a different driver) locate the extension and invoke the functions
via the vector.
The invocations looked something like this:
ModuleIoctl =
DeviceContext->pModuleMasterDeviceContext->ModuleCallbacks.ModuleIoctl;
Status = (*ModuleIoctl) (DeviceObject, Irp, IrpSp);
The technique is admitedly not automatic as a dll – one has to load the
secondary driver, establish the vector and, elsewhere, do the lookup and
then the invocation – but it gives one complete control. An advantage
of complete control is that the dll-like driver is loaded only if and
when it is needed, and so the “main” driver cannot fail to be loaded
because of trying itself to import functions not supported in the OS.
(In fact, I made use of the technique in a driver application suited to
both WinNT and Win2K: Win2K-specific activities were isolated in the
dll-like driver, which the main driver loaded only when it sensed the OS
was Win2K.)
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@nryan.com
To unsubscribe send a blank email to %%email.unsub%%
MessageSorry! I meant ZwSetSystemInformation.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“Nicholas Ryan” wrote in message news:xxxxx@ntdev…
ZwSetInformationFile is in fact documented in the XP IFS kit and had better not change.
- Nicholas Ryan
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Nar Ganapathy[MS]
Sent: Tuesday, November 26, 2002 10:45 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Loading modules dynamically into kernel space.
Microsoft prefers a driver to a DLL for a variety of reasons. By having a single entry point to load a driver we can enforce certain policies that the administrators set. For example an administrator could decide to not load any unsigned drivers.
Note that ZwSetInformationFile is not documented and we could remove it from a later release.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“Bi Chen” wrote in message news:xxxxx@ntdev…
Guys.
Kerenl dll is far better than kludge of this kind. I don’t know why Microsoft not recommending it. Display driver is a dll of graphics card miniport driver.
I used kernel dll not only export C functions, but also C++ class libraries. This feature is impossible if you use IoLoadDriver. If you really want to it to be late binding, use VC6 or later’s delayed load feature. That is if you do not call the exported function, the module will not be loaded into memory. The same is true if you use some features in Win2k that is not available in NT4.0, just don’t invoke anything exported by the dll after get the version of the OS.
Bi
-----Original Message-----
From: James Antognini [mailto:xxxxx@mindspring.nospam.com]
Sent: Thursday, October 17, 2002 12:07 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Loading modules dynamically into kernel space.
I’ve used ZwSetSystemInformation with both SystemLoadImage and
SystemLoadAndCallImage. I’ve also used ZwLoadDriver. That was several
years ago, but I don’t recall any particular problems.
In any case, I wouldn’t bother with loading a dll as a dll. What I’ve
done (actually, I cannot take the credit, as it was someone else’s
idea), and quite successfully, was to 1) load a secondary driver; 2)
have the driver’s DriverEntry build a vector of entry points to dll-like
functions, in the device extension, and 3) have other kernel functions
(in a different driver) locate the extension and invoke the functions
via the vector.
The invocations looked something like this:
ModuleIoctl =
DeviceContext->pModuleMasterDeviceContext->ModuleCallbacks.ModuleIoctl;
Status = (*ModuleIoctl) (DeviceObject, Irp, IrpSp);
The technique is admitedly not automatic as a dll – one has to load the
secondary driver, establish the vector and, elsewhere, do the lookup and
then the invocation – but it gives one complete control. An advantage
of complete control is that the dll-like driver is loaded only if and
when it is needed, and so the “main” driver cannot fail to be loaded
because of trying itself to import functions not supported in the OS.
(In fact, I made use of the technique in a driver application suited to
both WinNT and Win2K: Win2K-specific activities were isolated in the
dll-like driver, which the main driver loaded only when it sensed the OS
was Win2K.)
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@nryan.com
To unsubscribe send a blank email to %%email.unsub%%