Windows CE: Stream Interface Driver Registry Settings
Created by samphung on 11/20/2010 10:54:27 PM

If you have looked at my other posts on stream interface drivers, you have seen that the registry settings that I use for Driver Shell are:

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\DriverShell]
    "Dll"="DriverShell.dll"
    "Order"=dword:4
    "Prefix"="XXX"
    "DeviceArrayIndex"=dword:1
    "IClass"="{A32942B7-920C-486b-B0E6-92A702A99B35}"

I thought that I would discuss these a little more, and includes some other settings.

Let’s start with the key HKEY_LOCAL_MACHINE\Drivers\Builtin\DriverShell. The key HKEY_LOCAL_MACHINE\Drivers\Builtin is the default key for listing drivers to be loaded by the device manager, via BusEnum (see Windows CE: Enhanced BusEnum), but like so much in Windows CE this is configurable. I don’t see a reason to change the default so I won’t go further into that. Each driver that you want to be loaded this way needs to have a unique key under Builtin, in this case the name is DriverShell.

The values under HKEY_LOCAL_MACHINE\Drivers\Builtin\DriverShell are:

Value Name	Value That I Used	Description
Dll	DriverShell.dll	The name of the driver dll file. I prefer to have drivers in the system path, but you can explicitly set the path to the dll here as well.
Order	4	This sets the order that the driver will be loaded relative to other drivers. The higher the number, the later the driver will be loaded, but if you don’t set a value it will be loaded last. If more than one driver has the same order value, then the load order is not define (or subject to change without notice anyway.)
Prefix	XXX	This is the three letter prefix used in your driver to replace the XXX_FunctionName.   In this case, I left the prefix as XXX, but I don’t recommend that for a real driver, use one that makes more sense.
IClass	{A32942B7-920C-486b-B0E6-92A702A99B35}	Defines an interface class for the driver. In this case I added IClass when I added power management to the driver (see Windows CE: Stream Interface Driver Power Management)
DeviceArrayIndex	1	This one is really specific to the driver. It identifies the hardware that it will manage.

 

Values that I did not use, but could have:

Value Name	Value That I Could have Used	Description
Index	1	This sets the value that you will use when opening the driver from your application, the n value in COMn or XXXn. If you do not explicitly set this value in the registry, then the value will be set for you based on the when the driver loads. That is the first instance loaded will be 1 and the second 2, and so on.
Flags	4	I don’t use Flags much, but I do find setting Flags to 4 can be useful for debugging, or providing optional drivers that my customers can enable later by changing the registry.   Possible values: DEVFLAGS_NONE           0x00000000 -          The default value of no flags set DEVFLAGS_UNLOAD         0x00000001 -          Tells the device manager to unload the driver after loading it and calling XXX_Init DEVFLAGS_LOADLIBRARY    0x00000002 -          Causes the driver to be loaded with a call to LoadLibrary instead of LoadDriver DEVFLAGS_NOLOAD         0x00000004 -          Allows you to have the registry settings, but not actually have the driver loaded. You can use this to keep the driver from loading until you call ActivateDeviceEx() you can set this flag, but you must clear it before calling ActivateDeviceEx()      DEVFLAGS_NAKEDENTRIES   0x00000008 -          Use this flag If you want to leave the prefix off of the driver functions DEVFLAGS_BOOTPHASE_1    0x00001000 -          Use this flag for drivers that must be loaded to load the hive registry DEVFLAGS_IRQ_EXCLUSIVE        0x00000100 -          This flag prevents drivers from loading if they will share an IRQ

 

This is certainly not an exhaustive list of registry settings, but it should be enough to get you started.

------------------------------------------------------------------------------------------------------------------------------

Note:  This article is written by Bruce Eitman, and is posted to the Embedded101 site with Bruce’s permission.

 

Copyright © 2010 – Bruce Eitman – All Rights Reserved

 

http://geekswithblogs.net/BruceEitman/

 

 

 

 

---

 

If you have looked at my other posts on stream interface drivers, you have seen that the registry settings that I use for Driver Shell are:

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\DriverShell]
    "Dll"="DriverShell.dll"
    "Order"=dword:4
    "Prefix"="XXX"
    "DeviceArrayIndex"=dword:1
    "IClass"="{A32942B7-920C-486b-B0E6-92A702A99B35}"

I thought that I would discuss these a little more, and includes some other settings.

Let’s start with the key HKEY_LOCAL_MACHINE\Drivers\Builtin\DriverShell. The key HKEY_LOCAL_MACHINE\Drivers\Builtin is the default key for listing drivers to be loaded by the device manager, via BusEnum (see Windows CE: Enhanced BusEnum), but like so much in Windows CE this is configurable. I don’t see a reason to change the default so I won’t go further into that. Each driver that you want to be loaded this way needs to have a unique key under Builtin, in this case the name is DriverShell.

The values under HKEY_LOCAL_MACHINE\Drivers\Builtin\DriverShell are:

Value Name	Value That I Used	Description
Dll	DriverShell.dll	The name of the driver dll file. I prefer to have drivers in the system path, but you can explicitly set the path to the dll here as well.
Order	4	This sets the order that the driver will be loaded relative to other drivers. The higher the number, the later the driver will be loaded, but if you don’t set a value it will be loaded last. If more than one driver has the same order value, then the load order is not define (or subject to change without notice anyway.)
Prefix	XXX	This is the three letter prefix used in your driver to replace the XXX_FunctionName.   In this case, I left the prefix as XXX, but I don’t recommend that for a real driver, use one that makes more sense.
IClass	{A32942B7-920C-486b-B0E6-92A702A99B35}	Defines an interface class for the driver. In this case I added IClass when I added power management to the driver (see Windows CE: Stream Interface Driver Power Management)
DeviceArrayIndex	1	This one is really specific to the driver. It identifies the hardware that it will manage.

 

Values that I did not use, but could have:

Value Name	Value That I Could have Used	Description
Index	1	This sets the value that you will use when opening the driver from your application, the n value in COMn or XXXn. If you do not explicitly set this value in the registry, then the value will be set for you based on the when the driver loads. That is the first instance loaded will be 1 and the second 2, and so on.
Flags	4	I don’t use Flags much, but I do find setting Flags to 4 can be useful for debugging, or providing optional drivers that my customers can enable later by changing the registry.   Possible values: DEVFLAGS_NONE           0x00000000 -          The default value of no flags set DEVFLAGS_UNLOAD         0x00000001 -          Tells the device manager to unload the driver after loading it and calling XXX_Init DEVFLAGS_LOADLIBRARY    0x00000002 -          Causes the driver to be loaded with a call to LoadLibrary instead of LoadDriver DEVFLAGS_NOLOAD         0x00000004 -          Allows you to have the registry settings, but not actually have the driver loaded. You can use this to keep the driver from loading until you call ActivateDeviceEx() you can set this flag, but you must clear it before calling ActivateDeviceEx()      DEVFLAGS_NAKEDENTRIES   0x00000008 -          Use this flag If you want to leave the prefix off of the driver functions DEVFLAGS_BOOTPHASE_1    0x00001000 -          Use this flag for drivers that must be loaded to load the hive registry DEVFLAGS_IRQ_EXCLUSIVE        0x00000100 -          This flag prevents drivers from loading if they will share an IRQ

 

This is certainly not an exhaustive list of registry settings, but it should be enough to get you started.

------------------------------------------------------------------------------------------------------------------------------

Note:  This article is written by Bruce Eitman, and is posted to the Embedded101 site with Bruce’s permission.

Copyright © 2010 – Bruce Eitman – All Rights Reserved

http://geekswithblogs.net/BruceEitman/