S
Slobodan Brcin \(eMVP\)
Konstantin,
This registry entries are virtual anyway. Those values are provided during
hardware enumeration by bus driver. Response on IRP_MN_QUERY_ID with
parameter BusQueryComptibleIDs.
In most cases value is read directly from hardware. But there are two
reasons why inf files usually do not contain this values.
Yes they are read from hardware like any Hardware Ids.
Only difference is when PnP tries to match driver to install them from inf
files.
Priority always goes to best match. There are criterions how best match is
determined, but it is sufficient so say that all Hardware Id matches come
first before Compatible Ids.
Supporting short Compatible Ids would require from driver manufacturer to
make driver that will support forward compatibility with all new hardware
for many years in future.
Also providing descriptive Hardware Ids enable driver manufacturers to
describe each adapter with special text and to populate registry with some
special hardware requirements.
You can use compatible ids for dummy drivers or for generic drivers that
will support all hardware in given class (with at least satisfactory
support).
If inf file with Hardware Id is found it will be always used instead of inf
file and driver with compatible id.
There is description in DDK how this works. (But we have no issues with this
since we don't want to force hardware manufacturers to change their inf
files, and that would be bad solution anyway).
What I want is to define some standard for us developers and possibly MS how
to detect drivers that can be configured trough one component and to create
one component to cover wide range of devices.
Maybe example of what I'm currently using will help you to understand what I
want.
Look at components beginning with "PCI standard *" or "Standard *" you will
notice that they all use compatible IDs and that some of them have critical
device set to TRUE.
Having components like these your image will allow you to generically
support all hardware types. Some of these components are just placeholders
to set some info in critical database and some offer driver functionality
trough files like pci.sys pciide.sys, atapi.sys, etc.
This will allow us to reach FBA PnP phase and as you have noticed if we just
copy new drivers and inf files they will override generic drivers (which btw
are used by Intel etc with only name modification from inf file same MS
binaries are used) that override some of this functionality.
Check component: PCI standard RAM Controller. This hardware resource does
not use any driver it just exist as hardware resource access point. Other
manufacturers just change name of this node trough inf file. They do this by
providing hardware Id that always have better match than compatible Id
provided by MS.
Bottom line is if we use few MS components to make system boot, everything
else will be handled by PnP.
So we need a way to create component from let us say Intel 845.inf, 865.inf
and 852.inf files.
Ok we can have 6-7 components but not 15-20 components. Also all that
components should know that they are using functionality (generic drivers
provided by MS and not third party)
and according to these knowledge CD could create component that will use
compatible ID that we see in component "PCI standard RAM Controller".
If we had these options then it could be possible for MS to improve TD so we
could sort components in central panel trough their meaning chipset drivers
of some type, or drivers generally, etc... (topic for another discussion)
Uhhh.... I hope that I explained more successfully what I want.
Regards,
Slobodan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This registry entries are virtual anyway. Those values are provided during
hardware enumeration by bus driver. Response on IRP_MN_QUERY_ID with
parameter BusQueryComptibleIDs.
In most cases value is read directly from hardware. But there are two
reasons why inf files usually do not contain this values.
Yes they are read from hardware like any Hardware Ids.
Only difference is when PnP tries to match driver to install them from inf
files.
Priority always goes to best match. There are criterions how best match is
determined, but it is sufficient so say that all Hardware Id matches come
first before Compatible Ids.
Supporting short Compatible Ids would require from driver manufacturer to
make driver that will support forward compatibility with all new hardware
for many years in future.
Also providing descriptive Hardware Ids enable driver manufacturers to
describe each adapter with special text and to populate registry with some
special hardware requirements.
You can use compatible ids for dummy drivers or for generic drivers that
will support all hardware in given class (with at least satisfactory
support).
If inf file with Hardware Id is found it will be always used instead of inf
file and driver with compatible id.
There is description in DDK how this works. (But we have no issues with this
since we don't want to force hardware manufacturers to change their inf
files, and that would be bad solution anyway).
What I want is to define some standard for us developers and possibly MS how
to detect drivers that can be configured trough one component and to create
one component to cover wide range of devices.
Maybe example of what I'm currently using will help you to understand what I
want.
Look at components beginning with "PCI standard *" or "Standard *" you will
notice that they all use compatible IDs and that some of them have critical
device set to TRUE.
Having components like these your image will allow you to generically
support all hardware types. Some of these components are just placeholders
to set some info in critical database and some offer driver functionality
trough files like pci.sys pciide.sys, atapi.sys, etc.
This will allow us to reach FBA PnP phase and as you have noticed if we just
copy new drivers and inf files they will override generic drivers (which btw
are used by Intel etc with only name modification from inf file same MS
binaries are used) that override some of this functionality.
Check component: PCI standard RAM Controller. This hardware resource does
not use any driver it just exist as hardware resource access point. Other
manufacturers just change name of this node trough inf file. They do this by
providing hardware Id that always have better match than compatible Id
provided by MS.
Bottom line is if we use few MS components to make system boot, everything
else will be handled by PnP.
So we need a way to create component from let us say Intel 845.inf, 865.inf
and 852.inf files.
Ok we can have 6-7 components but not 15-20 components. Also all that
components should know that they are using functionality (generic drivers
provided by MS and not third party)
and according to these knowledge CD could create component that will use
compatible ID that we see in component "PCI standard RAM Controller".
If we had these options then it could be possible for MS to improve TD so we
could sort components in central panel trough their meaning chipset drivers
of some type, or drivers generally, etc... (topic for another discussion)
Uhhh.... I hope that I explained more successfully what I want.
Regards,
Slobodan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
).