Exporting interface from NDISPROT-like driver

Dear, ALL!

I already have posted this message to
comp.os.ms-windows.programmer.nt.kernel-mode, but noone gave any
commnets on the issue, so I try to repeat my post here - may be this
group is more active?

Currently I am developing NDIS protocol driver based on NDISPROT DDK
sample. During initialization it creates a device object and binds it
to file name "\\Device\\NdisProt". This approach is not good for me,
since all other my drivers do not name their device objects, but export

some interfaces. This way all existing software may operate with new
devices with new drivers, using some basic IOCTL codes, which are
common among all the drivers. If I use NDISPROT approach with naming
device object I will need to redesign all the existing tools. So, is
there any way around this issue?


With best regards,
Vladimir S. Mirgorodsky

pavel_a
Wed Jun 01 11:52:20 CDT 2005

"v_mirgorodsky@yahoo.com" wrote:
> Dear, ALL!
>
> I already have posted this message to
> comp.os.ms-windows.programmer.nt.kernel-mode, but noone gave any
> commnets on the issue, so I try to repeat my post here - may be this
> group is more active?
>
> Currently I am developing NDIS protocol driver based on NDISPROT DDK
> sample. During initialization it creates a device object and binds it
> to file name "\\Device\\NdisProt". This approach is not good for me,
> since all other my drivers do not name their device objects, but export
>
> some interfaces. This way all existing software may operate with new
> devices with new drivers, using some basic IOCTL codes, which are
> common among all the drivers. If I use NDISPROT approach with naming
> device object I will need to redesign all the existing tools. So, is
> there any way around this issue?
>
>
> With best regards,
> Vladimir S. Mirgorodsky
>

Of course you don't have to follow the DDK sample literally.
Make any interface you want (and are abe to write and debug ;)

--PA

fat_boy
Mon Jun 06 04:42:17 CDT 2005

Hi
If you want future proof code make the "\\device\\name" string a
configurable resistry entry for the driver so it reads it at boot time
and creates adevice with that name.

>From the apps point of view, put the file name for CreateFile() in a
string table. If it needs to change in te future just edir the exe as
a resource using VS, (or other resource editing tool).

Re you other drivers, if they export IOCTL interfaces usable by an app,
they did a create device with a "\\device\\name" string, so I dont see
what you are having a problem with using the same methiod in a protocol
driver.

ATB

v_mirgorodsky
Mon Jun 06 09:39:21 CDT 2005

All other APP's are using SetupDiEnumInterfaces() API call to find the
file name of device driver to open. This way it don't need to know
anything about driver except GUID. More moution comes to scene if it is
possible to have several instance of the same driver, servicing several
pieces of hardware. In case of interface changes in filename are
handled by driver manager and I can find any number of my driver
instances just enumerating interfaces. In case of fixed file name I
will need to create some sort of assumption how to name every next
driver instance when it appears in system.

And, additionaly, existing software expects to see only new GUID to
work with new hardware, which makes idea about fixed filenames
completelly unusable, since I don't have access to this software
sources.

With best regards,
Vladimir S. Mirgorodsky


fat_boy wrote:
> Hi
> If you want future proof code make the "\\device\\name" string a
> configurable resistry entry for the driver so it reads it at boot time
> and creates adevice with that name.
>
> >From the apps point of view, put the file name for CreateFile() in a
> string table. If it needs to change in te future just edir the exe as
> a resource using VS, (or other resource editing tool).
>
> Re you other drivers, if they export IOCTL interfaces usable by an app,
> they did a create device with a "\\device\\name" string, so I dont see
> what you are having a problem with using the same methiod in a protocol
> driver.
>
> ATB

Eliyas
Wed Jun 15 08:17:10 CDT 2005

Since network protocol drivers are legacy NT4.0 style drivers, you cannot
register device interface. In order to register device interface
(IoRegisterDeviceInterface), you need PDO but non-pnp drivers don't have a
PDO.

--
--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/driver/default.mspx
http://www.microsoft.com/whdc/driver/kernel/KB-drv.mspx

v_mirgorodsky
Tue Jun 21 14:17:38 CDT 2005

Actually, I solved that problem. I created a PnP WDM driver without any
real hardware, got it enumerated as unknown root-enumerated device,
created device interface and after that registered with NDIS. All this
works fine with Windows XP. Now I am developing NDIS infrastructure
based on your sample NdisProt. Everything seems to be fine with Windows
XP. Will it introduce any problems with Windows 2000 or future Windows
releases?

With best regards,
Vladimir S. Mirgorodsky

Eliyas Yakub [MSFT] wrote:
> Since network protocol drivers are legacy NT4.0 style drivers, you cannot
> register device interface. In order to register device interface
> (IoRegisterDeviceInterface), you need PDO but non-pnp drivers don't have a
> PDO.
>
> --
> --
> -Eliyas
> This posting is provided "AS IS" with no warranties, and confers no rights.
> http://www.microsoft.com/whdc/driver/default.mspx
> http://www.microsoft.com/whdc/driver/kernel/KB-drv.mspx

Eliyas
Wed Jun 22 13:47:03 CDT 2005

If you don't install the protocol driver using the proper INF
(Class=NetTrans), there is no guarantee that this will work. You have to
involve network class installer (netcfg) in installing any network
components (NetService, NetTrans, Net). Otherwise, bindings between
components wouldn't be created properly.

--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx