"Generic USB Input Device Support" for keydisks?

[Georges Berenger]

The is the component "Generic USB Input Device Support" that provides
generic support for USB mouse & keyboards. Is there a similar component
for USB keydisks?

So far, our image supports all the different keydisks we have tried
(maybe 10 or 15 brands/models?), but is there a better way to be sure?

thanks,
-georges

 

[KM]

Georges,

"DiskOnKey USB personal storage device" under "Hardware : Devices :
Universal Serial Bus controllers" ?

 

[Slobodan Brcin \(eMVP\)]

Hi Georges,

Component "USB Mass Storage Device"

Among other things it supports compatible ID:
USB\Class_08&SubClass_06&Prot_50

This should support all your devices if not modify this ID to match all your
devices.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/install/hh/
install/idstrings_4n6v.asp

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KM]

I guess "DiskOnKey USB personal storage device" depends on "USB Mass Storage
Driver"

 

[Georges Berenger]

Georges,

"DiskOnKey USB personal storage device" under "Hardware : Devices :
Universal Serial Bus controllers" ?

I believe that DiskOnKey is a brand, so that's not really what I am
looking for here. I'd like to support all key disks (so far, we had no
failure).
I guess, Slobodan's answer is what I was looking for.
Thanks for the tips.

-georges

 

[Georges Berenger]

Thanks for the answer and the link to MS's page. That helps.

-georges

 

[KM]

Yes, DiskOnChip is M-Systems's trademark.
"USB Mass Storage Device" would be better for your case.

 

[Slobodan Brcin \(eMVP\)]

It depends on "USB Root Hub".

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KM]

True. I just checked.
It also has "USB Mass Storage Driver" service data resource. Don't know why
"DiskOnKey .." does not depend on the "USB Mass Storage Driver" component.

 

[Slobodan Brcin \(eMVP\)]

They don't depend on each other because they are basically same component.
Use filter option to filter out all components that contains usbstor.sys.
You will end up with more than 70 components that are made from same inf
file and use same driver. So all these components are the same. If you make
component similar to "USB Mass Storage Driver" you could replace all these
70 components with one component that would have exact functionality as if
you entered all these components in your image. And many more components
that are not even produced yet.

This is the only reason why I have stopped using TAP long time ago to detect
hardware in my target device.
With few generic components you can cover all types of hardware, and let FBA
PnP do the rest of installation.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KM]

Agree.

I saw and keep seeing the same: a lot of different components coming from
one .inf file (Printers, Modems, Keyboards, etc.) that basically bring the
same files in to the image and then FBA PnP does the install job. Even
worse, there is a lot of hardware component with the same names. The
difference is only in PnP IDs (but file sections are the same so the same
inf(s) get copied to the image).
My guess is that currently most of the components in XPe database are
developed by importing XP inf files. There is not much componentization on
hardware side of the database. E.g., a "perfect" XPe DB would have only
instance of the "usbstor.sys". All other "relative" components should depend
on the component that brings "usbstor.sys".
However, more done on software side.

My two cents.

 

[Slobodan Brcin \(eMVP\)]

BTW:
I forgot to mention to you.
Since you are not using USB disk as boot device. You don't need any
component that will modify registry. Only thing you need are two files that
any of these components will provide. During the FBA PnP phase or at any
time when you connect new USB disk device PnP will use info from inf file to
install device driver for any compatible model (all DOK models current and
future).

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Slobodan Brcin \(eMVP\)]

I'm glad that someone else agrees on this with me.

Few days ago I have already opened discussion on this topic and gave some
suggestions to MS.
Today I was writing few possible approaches how they should solve this, I
need to revisit few details, and then I'll send them more feedback on this.

Your guess about importing inf files is correct.
How would you make drivers for let us say Intel chipset?

Import inf files and from each inf file you will have 5 or more similar
components.
For NVIDIA graphic cards even worse maybe 40,50 components.
And list goes on and on.

Since most drivers are not critical for first OS boot. We can use generic
drivers, and copy all inf, dll, sys files on their place in windows folders.
FBA PnP will detect all present hardware and use inf files to install
appropriate drivers.

So for 99% of scenarios there is no need for us to use componentized drivers
and make myriads of components.

Heck if you want to support 8 different graphic adapters from NVIDIA or ATI
normally you would be expected to import 8 components to your project.
(creepy)
And then you would have problem with which component to use for setting
default display resolution.

What do you think?

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KM]

Slobodan,

I see a few issues that MS may keep in mind solving the problem:

1. Although any approach you come up with will not probably require much to
do on the XPe Tools side, changing components in XPe database will require
tremendous QA efforts.

2. You mentioned that for 99% of scenarios there is no need for us to use
componentized drivers. I agree. I was not happy to see many unnecassary
components coming from INF imports of some drivers. The very common approach
on XP is to just copy all driver required files to appropriate directories
and then PnP will do the install. However, what's about the rest "1%"?
Perhaps, it is up to driver developer(s) (hardware manufacture) to decide
what components should be included. Until most manufactures really support
XPe (providing not INFs but SLDs), there is nothing MS can to do to separate
simple "99%" drivers from complex "1%".

One of the approaches I see to solve the problem with NEW drivers is to have
"simple" and "complex" INF imports. The simple import should just prepare a
component with all the files going to corresponding windows directories. FBA
PnP will do the rest. The complex import would be to wrap up all the
components from INF. The Component Designer does the complex import now.

In any case (simple/complex) integrating a driver in to an XPe image does
not promise (prove) the driver will work properly. XPe devs have to do the
runtime testing anyway. So, even having problems with "simply" imported
components a Dev can always switch to the complex imports.

Not thinking about issue #1 (QA efforts), on current XPe database it is
possible to write a set of automated CMI scripts to re-organize components
so that there will be only instance of the components that wrap a particular
driver. E.g., it is pretty easy to go through DB and find out all the
components with "usbstor.sys" in Files section. The final component is
likely the one that would be in result of "simple" import.

And again, this should touch only Hardware category.
These are just ideas, though.

KM

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

One extreme case: for instance importing display adapter drivers from NVIDIA
will create much more than 50 components with same purpose and
functionality. Only difference between them will be their names and Hardware
ID used to identify them. In case of display adapters more natural way would
be that for each driver (per inf file or even per manufacturer) we have the
tool that can create component with following characteristic.
One inf file imported will create one component that will contain hardware
IDs for all supported adapters. This option is to maintain compatibility
with TAP results that allow automatic selection and import of components.
Since this component is not critical for boot, presence of this component
should not write anything to the registry. All driver installations should
be left for FBA PnP.
In this driver type category fall devices like Network adapters, Display
Adapters, Chipsets etc.
The best way I see would be to somehow create one component based on
"Compatible Ids" instead of having many "Hardware Ids"
For instance PCI\VEN_10DE&CC_030000 would match all NVIDIA video adapters.

Second category would be components that contain critical drivers required
to boot device.
Similar thing with "Compatible Ids" could be applied especially to them with
only difference that this component must modify registry to mark that
compatible Id as critical device required for system boot.

To support all chipsets we use I'm using standard components beginning with
"PCI standard *" and few other components to mark critical boot chipset
devices.
And then I have few components that copy all required files mostly inf files
that are used during the PnP phase to install adequate drivers and names.

So these two categories should cover all drivers. Only problem is how tools
for creating these components should look like. Or both MS and we should
mannualy create components by analyzing each driver inf file and other
specifics.

Do you have any idea how tools for this should look like?

Regards,
Slobodan

 

[KM]

Slobodan,

I see your point.

Basically, my idea was similar. By "simple import" I meant parsing INF so
that all required files would go to corresponding windows directories and
all required PnP IDs (your Hardware IDs) would go to the component
resources. This should be compatible to TAP results as it will search and
include components by PnP IDs of drivers anylized on target device.

You are right about the two categories. Critical drivers should also get
required registry data.

What if the tool you are talking about just has to parse an INF file,
setting Files section (all files in to corresponding directories) and adding
all possible PnP ID resources from the INF. FBA PnP will install drivers for
present hardware.
So, the difference between current MS INF parser and the tool you want
should be in merging all result components in the final SLD in to one
component with all PnP IDs in it. This approach seems to work fine when I
look at NVIDIA components (parsed INF).

However, one question is left - will TAP be still compatible with this? If
PMQ parser does nothing more than just searching in XPe database for
components (to make them as dependencies) which include PnP IDs mentioned in
the PMQ. Then the answer is yes.

That's probably too late now to get the whole picture. I'll think more on
the subject tomorrow.

Konstantin

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

Basically, my idea was similar. By "simple import" I meant parsing INF so
that all required files would go to corresponding windows directories and
all required PnP IDs (your Hardware IDs) would go to the component
resources. This should be compatible to TAP results as it will search and
include components by PnP IDs of drivers anylized on target device.

This is the first part (but I would try to avoid having component resources
when ever possible). Or at least if we set that device is critical for boot
most of resources should not modify registry, only one resource that uses
Compatible Id should modify registry.

You are right about the two categories. Critical drivers should also get
required registry data.

What if the tool you are talking about just has to parse an INF file,
setting Files section (all files in to corresponding directories) and adding
all possible PnP ID resources from the INF. FBA PnP will install drivers for
present hardware.
So, the difference between current MS INF parser and the tool you want
should be in merging all result components in the final SLD in to one
component with all PnP IDs in it. This approach seems to work fine when I
look at NVIDIA components (parsed INF).

But PnP ID resource definition should be little modified so it should not
modify registry in any scenario. Or there could be new PnP2 ID type.
And old PnP ID resource should be used for making registry changes needed
for boot critical devices.

However, one question is left - will TAP be still compatible with this? If
PMQ parser does nothing more than just searching in XPe database for
components (to make them as dependencies) which include PnP IDs mentioned in
the PMQ. Then the answer is yes.

I think that this is how current implementation of PMQ import works. Nothing
more than search for best match component and add it to list.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KM]

Slobodan,

I don't see problems having Compatible Ids in the component resources (one
Compatible Id per set of the components from one INF file, say). However,
not changing TAP code much we will have to have PnP resources that match TAP
input with the XPe database components.

That is how I vision the tool from the discussion: import an INF file
creating only one component with all the PnP IDs from the INF file. This
will maintain compability with TAP. Files and Registry data sections should
have links to all the resources parsed from the INF files so that all fiiles
go to corresponding windows directories and if necessary some registry are
included (e.g. Nvidia requires a helper service data). As you will have only
one component to add to your configuration it will save you from having
multiply components' settings (e.g. only display driver settings in TD).
I don't see, however, where you apply Compatible IDs here? Sorry, I am
missing a piece here.
Also, how having all PnP Ids in registry may confuse FBA PnP? Why are you
trying to avoid it? If I understand this, I will understand your idea.

There should not be a problem of separating critical boot drivers from
non-critical's (hardware category).

Also, adding Compatible Ids concept do you want to change existing XPe
database components? Or you just want to apply this change to new components
that we all create?

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

I don't see problems having Compatible Ids in the component resources (one
Compatible Id per set of the components from one INF file, say). However,
not changing TAP code much we will have to have PnP resources that match TAP
input with the XPe database components.

TAP code should not be changed at all. Analyze PMQ file more closely and you
will see that TAP will provide you with both information's HARDWAREIDS and
COMPATIBLEIDS:
CD and TD should be slightly modified to support this. And also there is a
problem with importing inf files since I have not seen compatible IDs in inf
files so we probably must provide that info manually.

<DEVICE ConfigFlags="0">
<DEVICEDESC>Intel(R) 82845G/GL/GE/PE/GV Processor to I/O Controller -
2560 </DEVICEDESC>
<HARDWAREIDS>
<DEVICEID
Order="1">PCI\VEN_8086&amp;DEV_2560&amp;SUBSYS_00000000&amp;REV_02</DEVICEID<DEVICEID
Order="2">PCI\VEN_8086&amp;DEV_2560&amp;SUBSYS_00000000</DEVICEID>
<DEVICEID Order="3">PCI\VEN_8086&amp;DEV_2560&amp;REV_02</DEVICEID>
<DEVICEID Order="4">PCI\VEN_8086&amp;DEV_2560</DEVICEID>
<DEVICEID Order="5">PCI\VEN_8086&amp;DEV_2560&amp;CC_060000</DEVICEID>
<DEVICEID Order="6">PCI\VEN_8086&amp;DEV_2560&amp;CC_0600</DEVICEID>
</HARDWAREIDS>
<COMPATIBLEIDS>
<DEVICEID Order="1">PCI\VEN_8086&amp;CC_060000</DEVICEID>
<DEVICEID Order="2">PCI\VEN_8086&amp;CC_0600</DEVICEID>
<DEVICEID Order="3">PCI\VEN_8086</DEVICEID>
<DEVICEID Order="4">PCI\CC_060000</DEVICEID>
<DEVICEID Order="5">PCI\CC_0600</DEVICEID>
</COMPATIBLEIDS>

That is how I vision the tool from the discussion: import an INF file
creating only one component with all the PnP IDs from the INF file. This
will maintain compability with TAP. Files and Registry data sections should
have links to all the resources parsed from the INF files so that all fiiles
go to corresponding windows directories and if necessary some registry are
included (e.g. Nvidia requires a helper service data). As you will have only
one component to add to your configuration it will save you from having
multiply components' settings (e.g. only display driver settings in TD).
I don't see, however, where you apply Compatible IDs here? Sorry, I am
missing a piece here.

Fortunately compatible ids are not required for hardware display driver and
network category. This category does not require us to provide any resources
like service initialization or some registry entries.
Since during installation PnP will use all required info from inf file
itself.
Merging of all sections from inf file could be even dangerous, since there
is possibility that some hardware require some specific service installed
while some other does not require it.
So for this type of drivers only file copy should be enough and auto
detection from PMQ file would be nice.

Also if you use different manufacturers in same image like ATI and NVIDIA.
It is not good to set resolution from driver components.
In my image I'm using directly prototype component "Device: Display" it
allows me to set resolution independently of drivers I choose to put in my
image. Also this component should support settings for more that one
monitor.

Also, how having all PnP Ids in registry may confuse FBA PnP? Why are you
trying to avoid it? If I understand this, I will understand your idea.

I'm following the logic "The less things you have in registry the less
things can go wrong". And who knows it might speed boot process for few mil.
sec

There should not be a problem of separating critical boot drivers from
non-critical's (hardware category).

Also, adding Compatible Ids concept do you want to change existing XPe
database components? Or you just want to apply this change to new components
that we all create?

Let me think.
1. It would be nice to have native mechanism to create components like this
for our purposes, right?
2. MS could make few new components if they have time to spare. (keeping old
for compatibility)
3. Big picture. In few years we will have LHe. Do you think that they should
keep compatibility with XPe components and way to componentized drivers?

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KM]

Slobodan,

TAP code should not be changed at all. Analyze PMQ file more closely and you
will see that TAP will provide you with both information's HARDWAREIDS and
COMPATIBLEIDS:

I hadn't noticed the Compatible/Hardware IDs in PMQ results. Now I see. I
was mostly tending to see INF parser results and there are no Compatible IDs
currently :-(.
The Hardware IDs and Compatible IDs come from PnP enum subkeys of
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum] (REG_MULTI_SZ values).
Please correct if I am wrong.

CD and TD should be slightly modified to support this. And also there is a
problem with importing inf files since I have not seen compatible IDs in inf
files so we probably must provide that info manually.

Do you know how Compatible IDs get in to the registry? I don't think that XP
PnP sets this info. I think Compatible ID info are in INF files (maybe, not
always) but INF importer just does not parse it and sets all the PnP ID
resources to have IsCompatibleID flag set to FALSE.
However, if for example, you take a look into the MS default monitor
driver's INF you will see that its Compatible IDs is there (*PNP09FF).

I am not an expert in INF format so I may be wrong here.

...>


Fortunately compatible ids are not required for hardware display driver and
network category. This category does not require us to provide any resources
like service initialization or some registry entries.
Since during installation PnP will use all required info from inf file

itself.

I see.

Merging of all sections from inf file could be even dangerous, since there
is possibility that some hardware require some specific service installed
while some other does not require it.

That is why I was referring to having "simple" and "complex" INF import
processes. This may always be up to dev (XPe, manufacturer) to decide
whether it is dangerous to merge the components. We have to test images
anyway.

So for this type of drivers only file copy should be enough and auto
detection from PMQ file would be nice.

Also if you use different manufacturers in same image like ATI and NVIDIA.
It is not good to set resolution from driver components.
In my image I'm using directly prototype component "Device: Display" it
allows me to set resolution independently of drivers I choose to put in my
image. Also this component should support settings for more that one

monitor.

Yup, if you support more than one platform - prototype "Device: Display" is
a good choice.
However, how do you want to tell TAP to choose the "Device: Display"
automatically and not to match the real display driver PnP with an XPe
database component?

idea.
I'm following the logic "The less things you have in registry the less
things can go wrong". And who knows it might speed boot process for few

mil. sec

Agree. It also simplifies the image build process.

Let me think.
1. It would be nice to have native mechanism to create components like

this for our purposes, right?

Sure. A custom INF parser should do the trick if we come to agreement on the
Compatible IDs.

2. MS could make few new components if they have time to spare. (keeping

old for compatibility)

So, you don't change existing XPe database. Then a few multiply TAP results
used in one confuguration may not work properly with your concept.

3. Big picture. In few years we will have LHe. Do you think that they

should keep compatibility with XPe components and way to componentized
drivers?

As I heard LH (not embedded) is going to be much more componentized in first
place than, say, XP Pro.
Basically, there may be LHe only and LH will be built as one of the possible
configurations (the biggest one!).
However, these rumors seem mostly apply to the software stack. I don't know
MS plans for the hardware stack in XPe, though. I don't think it is possible
to change the hardware support dramatically maintaining compability to all
the hardware supoprted by XP Pro now.
My personal vote would be to re-design current XPe database (not only around
the hardware categories, btw).

Regards,
Konstantin