H2 check the presence of a hardware in a target ?

[RichardV]

Hello,

How to check the presence of a specific hardware using dependencies ?

- My targets are PC having different configurations. I made as many
components as target types
(components are based on pmq imports) and set them as membership of a
group called : "Available Targets".

- I have an componentized application : myApp, this app needs a PC with
parallel port. This component has a group
dependency on "Available targets".

- When I start a new configuration with TD, I only add one component :
myApp. Then, after a first dependencies
check, I just have to choose my target in the "Resolve Dependency" window
and my image is "ready to go".

What do I have to do to ensure that my target has a parallel port ?

One possibility is to set a conflict between myApp and all targets that have
no parallel port.
Another one is to have 2 dependency groups, one with the supported targets
and one with the target having no parallel,
and then, apply a dependency only to the first group.

But I would like to go further these solutions since this could be the case
for any hardware, disk capacity etc...
I would like to check from a high level, that means I don't want to check
for a particular Vendor_ID etc.. but just
ensure that the PC has the required functionnality whatever the vendor and
drivers (since it's already in the target component).

I thought to add a "flag" for every targets config saying "I have" or "I
haven't" a parallel port. And during build, myApp could
check the presence of this flag for the selected target.
I First tried to set an extended propertie for each target: e.i.
oemHasParallelPort / Boolean / True or False but I don't know
how to check this value during build, do I have to use vbscript ? and how ?

Does someone has a better ideas ?

Thanks,
Richard.

 

[Slobodan Brcin \(eMVP\)]

Brrrrr. This is heavy.

Also what if you disable some hardware physically. Marking in image what hardware is present in not a very good thing.

Find devcon example in DDK. From there you will see how to search and enumerate present hardware in your system. That is working,
that has problems, and that was installed but now it is not.

As a starting point look at function SetupDiGetClassDevs from there is should be straight forward.

Also if your hardware is similar on all devices (same HAL for instance) you should consider making one image that will work on all
different platforms. In this way you will ease yourself maintenance job.
Read this thread it might give you some info:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&[email protected]

Regards,
Slobodan

 

[KM]

RichardV,

I think there are basically two major approaches to make a platform support package that will work for a few different targets
(assuming, of course, the same HAL):
- including all the possible hardware support in your image and then disable it at runtime (see Slobodan's port). this way you
may get only image that will work on all your targets.
- try to resolve necessary hardware dependencies at build time (your current approach, right?). This way you get an image per
each target.

Both approaches have some advantages and disadvantages. The choice will likely depend on the image specs/deployment method/factory
support/development efforts/dev knowledge expertise/etc.

Not speaking about the first approach (Slobodan has already provided you with enough information), I can understand the needs in
your current approach.
Basically, you need to resolve some dynamic dependencies during build time (TD). You may, of course, use some global flags to do
that (extended properties of some components/configuration). You may do even better - you can have extended properties that point to
necessary hardware components (just strings with the component names). At build time (dependency resolve time) you will check if a
particular platform macro includes a particular hardware component as a dependency.
The only way, I think, how to implement that is using CMI. There are events available like cmiOnPreBuild, cmiOnBuild,
cmiOnBeginResolveDependencies/cmiOnEndResolveDependencies, etc. (these are listed only ones you may be interested in). Within the
build and resolve dependency event handlers' code you may check for any conditions (e.g., extended properties values) and any
component dependencies being added.
Something similar is implemented in "Language Support Prototype" component.

However, when you think about implementing all this, keep in mind that:
- the component script code will be VB Script based (either within dhtml or asp)
- CMI is undocumented (but you may hack the interfaces)