How do I determine "Build Order Dependencies" for a new component?

G

Guest

I have been trying to establish some simple components (Registry Tweaks
mostly) to minimize the time spent customizing the Windows environment after
the FBA process. Many of my attempts have been fuitless. I suspect that I
need to adjust the Build Order (default is 1000) or set some Build Order
Dependencies. There are tools to explore the dependencies of existing
components. But how do I establish the proper dependencies for a component I
am creating?

There is an example in Nick's Blog from 22 April 2006.
(http://blogs.msdn.com/embedded/archive/2006/04/15/576734.aspx)
He gave no explanation how he determined that his registry component needed
a build order dependeny against another specific component. And another user
came up with 2 more dependencies in August. So it wouild appear that even a
Microsoft insider like Nick failed to find all the needed dependencies for
his component to work reliably. How then can I hope to succeed where Nick
failed? How did Trevor find the additional undocumented dependencies?

I had hoped that after this much time, XPe would more of a science and less
of a black art!
When will Microsoft realize that Blogs and Newsgroups and Forums are no
substitute for proper documentation? All this trial and error stuff is
extremely wasteful. XPE is just one of many responsibilties for me. But every
time I touch it, it becomes a full time job for days at a time.

Any Ideas?

Andrew Roy
Irwin Research & Development
 
K

KM

Andrew,

Looks like to asked two different questions below:
- Build Order control
- Why it is often hard to fix issues in XPe?

There is no easy way to figure out all the components in the database (or your configuration) that may interfere with yours and
potentially overwrite some registry value you are trying to setup. Myself I found a way how to find out most of those "dependencies"
(not really dependencies but the build order chain) if I search the DB first for the list of components that contains particular
registry value I am trying to set up. The only way to do that, as far as I know, is to use the DependencyExplorer and
ConfigurationExplorer components off the XPeTools package on www.xpefiles.com.
I wish Microsoft implement the "registry search" feature in TD but they never did so the above is the only way I know.

Please keep in mind that you may still get into the situation where you reg keys may be overwritten during FBA. Some component may
dynamically mess with some registry keys at runtime and you have no control over it. Only way to avoid this is to set up a FBA
generic command that will install the required registry keys/values during FBA at very late phase.


Now the second part of your question. Well, the only explanation I see (the below is only my opinion) is that the XPe is not truly
componentized version of XP. What I mean by that is that XPe components rely on the binary (Dll) componentization that's been done
with XP at first place. It should've been vice versa in my opinion - XPe should come out first with the proper level of
componentization and then XP could be built as just a full blown image of XPe + some manual setup. Unfortunately, it would take a
huge effort to drive this across big company like Microsoft.
Another example you have is Windows CE - another embedded OS from Microsoft. There most [lots of] OS components were created from
the ground with the proper dependency chain. Also, lots of source code there makes it much easier to work on some OS specific
issues. However, some IP related issues still prevented Microsoft to ship most of the application code there (mostly only kernel and
driver source code available) so you still have to fight with OS issues once in a while.

Also, please keep in mind that regardless of the implementation big OS like XP, CE, Linux, etc. may suffer from not having enough
documentation or, more often, from not providing the right tools and ways to search the documentation. It is frequently hard to find
an answer in the documentation because you don't know the source of the issue you are trying to research. For any person, insider or
external, it would be almost impossible to know all the aspects of the OS. However, some corner sources of info like Google, MSDN,
Technet, various MVP websites and etc. are the first place to start digging into if you are working on some XPe related issues.
 
G

Guest

Thanks KM,

I had used Dependency Explorer before, but I was not aware that I could
search for Registry Keys. It does have a problem with some searches, however.
If the registry path includes a space, it finds absolutely nothing. Entering
a partial path works, but you have to sift through the results to find the
genuine dependencies.

Thanks again,
Andy

KM said:
Andrew,

Looks like to asked two different questions below:
- Build Order control
- Why it is often hard to fix issues in XPe?

There is no easy way to figure out all the components in the database (or your configuration) that may interfere with yours and
potentially overwrite some registry value you are trying to setup. Myself I found a way how to find out most of those "dependencies"
(not really dependencies but the build order chain) if I search the DB first for the list of components that contains particular
registry value I am trying to set up. The only way to do that, as far as I know, is to use the DependencyExplorer and
ConfigurationExplorer components off the XPeTools package on www.xpefiles.com.
I wish Microsoft implement the "registry search" feature in TD but they never did so the above is the only way I know.

Please keep in mind that you may still get into the situation where you reg keys may be overwritten during FBA. Some component may
dynamically mess with some registry keys at runtime and you have no control over it. Only way to avoid this is to set up a FBA
generic command that will install the required registry keys/values during FBA at very late phase.


Now the second part of your question. Well, the only explanation I see (the below is only my opinion) is that the XPe is not truly
componentized version of XP. What I mean by that is that XPe components rely on the binary (Dll) componentization that's been done
with XP at first place. It should've been vice versa in my opinion - XPe should come out first with the proper level of
componentization and then XP could be built as just a full blown image of XPe + some manual setup. Unfortunately, it would take a
huge effort to drive this across big company like Microsoft.
Another example you have is Windows CE - another embedded OS from Microsoft. There most [lots of] OS components were created from
the ground with the proper dependency chain. Also, lots of source code there makes it much easier to work on some OS specific
issues. However, some IP related issues still prevented Microsoft to ship most of the application code there (mostly only kernel and
driver source code available) so you still have to fight with OS issues once in a while.

Also, please keep in mind that regardless of the implementation big OS like XP, CE, Linux, etc. may suffer from not having enough
documentation or, more often, from not providing the right tools and ways to search the documentation. It is frequently hard to find
an answer in the documentation because you don't know the source of the issue you are trying to research. For any person, insider or
external, it would be almost impossible to know all the aspects of the OS. However, some corner sources of info like Google, MSDN,
Technet, various MVP websites and etc. are the first place to start digging into if you are working on some XPe related issues.

--
=========
Regards,
KM
I have been trying to establish some simple components (Registry Tweaks
mostly) to minimize the time spent customizing the Windows environment after
the FBA process. Many of my attempts have been fuitless. I suspect that I
need to adjust the Build Order (default is 1000) or set some Build Order
Dependencies. There are tools to explore the dependencies of existing
components. But how do I establish the proper dependencies for a component I
am creating?

There is an example in Nick's Blog from 22 April 2006.
(http://blogs.msdn.com/embedded/archive/2006/04/15/576734.aspx)
He gave no explanation how he determined that his registry component needed
a build order dependeny against another specific component. And another user
came up with 2 more dependencies in August. So it wouild appear that even a
Microsoft insider like Nick failed to find all the needed dependencies for
his component to work reliably. How then can I hope to succeed where Nick
failed? How did Trevor find the additional undocumented dependencies?

I had hoped that after this much time, XPe would more of a science and less
of a black art!
When will Microsoft realize that Blogs and Newsgroups and Forums are no
substitute for proper documentation? All this trial and error stuff is
extremely wasteful. XPE is just one of many responsibilties for me. But every
time I touch it, it becomes a full time job for days at a time.

Any Ideas?

Andrew Roy
Irwin Research & Development
 
K

KM

Andrew,

That is true :-( The "search with spaces" bug has been there for quite some time.
I still don't have enough time to fix that bug. Will probably take some time to trace it this week since it seems now that it is not
only me who suffers from it.

Btw, be careful with saving DependencyExplorer's Registry Key filter you typed in as TD filter in case you want to use it later in
TD. TD will crash if you try to edit the filter via TD Filter UI.

--
=========
Regards,
KM

PS. Used to work with a guy from Irwin R&D some time ago.
Are you guys still based in Yakima?

Thanks KM,

I had used Dependency Explorer before, but I was not aware that I could
search for Registry Keys. It does have a problem with some searches, however.
If the registry path includes a space, it finds absolutely nothing. Entering
a partial path works, but you have to sift through the results to find the
genuine dependencies.

Thanks again,
Andy

KM said:
Andrew,

Looks like to asked two different questions below:
- Build Order control
- Why it is often hard to fix issues in XPe?

There is no easy way to figure out all the components in the database (or your configuration) that may interfere with yours and
potentially overwrite some registry value you are trying to setup. Myself I found a way how to find out most of those
"dependencies"
(not really dependencies but the build order chain) if I search the DB first for the list of components that contains particular
registry value I am trying to set up. The only way to do that, as far as I know, is to use the DependencyExplorer and
ConfigurationExplorer components off the XPeTools package on www.xpefiles.com.
I wish Microsoft implement the "registry search" feature in TD but they never did so the above is the only way I know.

Please keep in mind that you may still get into the situation where you reg keys may be overwritten during FBA. Some component
may
dynamically mess with some registry keys at runtime and you have no control over it. Only way to avoid this is to set up a FBA
generic command that will install the required registry keys/values during FBA at very late phase.


Now the second part of your question. Well, the only explanation I see (the below is only my opinion) is that the XPe is not
truly
componentized version of XP. What I mean by that is that XPe components rely on the binary (Dll) componentization that's been
done
with XP at first place. It should've been vice versa in my opinion - XPe should come out first with the proper level of
componentization and then XP could be built as just a full blown image of XPe + some manual setup. Unfortunately, it would take a
huge effort to drive this across big company like Microsoft.
Another example you have is Windows CE - another embedded OS from Microsoft. There most [lots of] OS components were created from
the ground with the proper dependency chain. Also, lots of source code there makes it much easier to work on some OS specific
issues. However, some IP related issues still prevented Microsoft to ship most of the application code there (mostly only kernel
and
driver source code available) so you still have to fight with OS issues once in a while.

Also, please keep in mind that regardless of the implementation big OS like XP, CE, Linux, etc. may suffer from not having enough
documentation or, more often, from not providing the right tools and ways to search the documentation. It is frequently hard to
find
an answer in the documentation because you don't know the source of the issue you are trying to research. For any person, insider
or
external, it would be almost impossible to know all the aspects of the OS. However, some corner sources of info like Google,
MSDN,
Technet, various MVP websites and etc. are the first place to start digging into if you are working on some XPe related issues.

--
=========
Regards,
KM
I have been trying to establish some simple components (Registry Tweaks
mostly) to minimize the time spent customizing the Windows environment after
the FBA process. Many of my attempts have been fuitless. I suspect that I
need to adjust the Build Order (default is 1000) or set some Build Order
Dependencies. There are tools to explore the dependencies of existing
components. But how do I establish the proper dependencies for a component I
am creating?

There is an example in Nick's Blog from 22 April 2006.
(http://blogs.msdn.com/embedded/archive/2006/04/15/576734.aspx)
He gave no explanation how he determined that his registry component needed
a build order dependeny against another specific component. And another user
came up with 2 more dependencies in August. So it wouild appear that even a
Microsoft insider like Nick failed to find all the needed dependencies for
his component to work reliably. How then can I hope to succeed where Nick
failed? How did Trevor find the additional undocumented dependencies?

I had hoped that after this much time, XPe would more of a science and less
of a black art!
When will Microsoft realize that Blogs and Newsgroups and Forums are no
substitute for proper documentation? All this trial and error stuff is
extremely wasteful. XPE is just one of many responsibilties for me. But every
time I touch it, it becomes a full time job for days at a time.

Any Ideas?

Andrew Roy
Irwin Research & Development
 
G

Guest

Hi KM,

Oops, I guess I was putting spaces where they did not belong. So I have not
encountered the bug after all, yet.

Yes, we are based in Yakima. This is a privately owned company. Jere Irwin
established this company back in the mid 1960's. I know of a few people that
have left here to work for Microsoft.

Cheers,
Andy

KM said:
Andrew,

That is true :-( The "search with spaces" bug has been there for quite some time.
I still don't have enough time to fix that bug. Will probably take some time to trace it this week since it seems now that it is not
only me who suffers from it.

Btw, be careful with saving DependencyExplorer's Registry Key filter you typed in as TD filter in case you want to use it later in
TD. TD will crash if you try to edit the filter via TD Filter UI.

--
=========
Regards,
KM

PS. Used to work with a guy from Irwin R&D some time ago.
Are you guys still based in Yakima?

Thanks KM,

I had used Dependency Explorer before, but I was not aware that I could
search for Registry Keys. It does have a problem with some searches, however.
If the registry path includes a space, it finds absolutely nothing. Entering
a partial path works, but you have to sift through the results to find the
genuine dependencies.

Thanks again,
Andy

KM said:
Andrew,

Looks like to asked two different questions below:
- Build Order control
- Why it is often hard to fix issues in XPe?

There is no easy way to figure out all the components in the database (or your configuration) that may interfere with yours and
potentially overwrite some registry value you are trying to setup. Myself I found a way how to find out most of those
"dependencies"
(not really dependencies but the build order chain) if I search the DB first for the list of components that contains particular
registry value I am trying to set up. The only way to do that, as far as I know, is to use the DependencyExplorer and
ConfigurationExplorer components off the XPeTools package on www.xpefiles.com.
I wish Microsoft implement the "registry search" feature in TD but they never did so the above is the only way I know.

Please keep in mind that you may still get into the situation where you reg keys may be overwritten during FBA. Some component
may
dynamically mess with some registry keys at runtime and you have no control over it. Only way to avoid this is to set up a FBA
generic command that will install the required registry keys/values during FBA at very late phase.


Now the second part of your question. Well, the only explanation I see (the below is only my opinion) is that the XPe is not
truly
componentized version of XP. What I mean by that is that XPe components rely on the binary (Dll) componentization that's been
done
with XP at first place. It should've been vice versa in my opinion - XPe should come out first with the proper level of
componentization and then XP could be built as just a full blown image of XPe + some manual setup. Unfortunately, it would take a
huge effort to drive this across big company like Microsoft.
Another example you have is Windows CE - another embedded OS from Microsoft. There most [lots of] OS components were created from
the ground with the proper dependency chain. Also, lots of source code there makes it much easier to work on some OS specific
issues. However, some IP related issues still prevented Microsoft to ship most of the application code there (mostly only kernel
and
driver source code available) so you still have to fight with OS issues once in a while.

Also, please keep in mind that regardless of the implementation big OS like XP, CE, Linux, etc. may suffer from not having enough
documentation or, more often, from not providing the right tools and ways to search the documentation. It is frequently hard to
find
an answer in the documentation because you don't know the source of the issue you are trying to research. For any person, insider
or
external, it would be almost impossible to know all the aspects of the OS. However, some corner sources of info like Google,
MSDN,
Technet, various MVP websites and etc. are the first place to start digging into if you are working on some XPe related issues.

--
=========
Regards,
KM

I have been trying to establish some simple components (Registry Tweaks
mostly) to minimize the time spent customizing the Windows environment after
the FBA process. Many of my attempts have been fuitless. I suspect that I
need to adjust the Build Order (default is 1000) or set some Build Order
Dependencies. There are tools to explore the dependencies of existing
components. But how do I establish the proper dependencies for a component I
am creating?

There is an example in Nick's Blog from 22 April 2006.
(http://blogs.msdn.com/embedded/archive/2006/04/15/576734.aspx)
He gave no explanation how he determined that his registry component needed
a build order dependeny against another specific component. And another user
came up with 2 more dependencies in August. So it wouild appear that even a
Microsoft insider like Nick failed to find all the needed dependencies for
his component to work reliably. How then can I hope to succeed where Nick
failed? How did Trevor find the additional undocumented dependencies?

I had hoped that after this much time, XPe would more of a science and less
of a black art!
When will Microsoft realize that Blogs and Newsgroups and Forums are no
substitute for proper documentation? All this trial and error stuff is
extremely wasteful. XPE is just one of many responsibilties for me. But every
time I touch it, it becomes a full time job for days at a time.

Any Ideas?

Andrew Roy
Irwin Research & Development
 
K

KM

Now I am not sure we are talking about the same bug :)
Well, the one I saw a few months ago was where the search function didn't return correct results if you typed in a registry value
name with spaces in it. Haven't tested this with the latest version, though.

--
=========
Regards,
KM
Hi KM,

Oops, I guess I was putting spaces where they did not belong. So I have not
encountered the bug after all, yet.

Yes, we are based in Yakima. This is a privately owned company. Jere Irwin
established this company back in the mid 1960's. I know of a few people that
have left here to work for Microsoft.

Cheers,
Andy

KM said:
Andrew,

That is true :-( The "search with spaces" bug has been there for quite some time.
I still don't have enough time to fix that bug. Will probably take some time to trace it this week since it seems now that it is
not
only me who suffers from it.

Btw, be careful with saving DependencyExplorer's Registry Key filter you typed in as TD filter in case you want to use it later
in
TD. TD will crash if you try to edit the filter via TD Filter UI.

--
=========
Regards,
KM

PS. Used to work with a guy from Irwin R&D some time ago.
Are you guys still based in Yakima?

Thanks KM,

I had used Dependency Explorer before, but I was not aware that I could
search for Registry Keys. It does have a problem with some searches, however.
If the registry path includes a space, it finds absolutely nothing. Entering
a partial path works, but you have to sift through the results to find the
genuine dependencies.

Thanks again,
Andy

:

Andrew,

Looks like to asked two different questions below:
- Build Order control
- Why it is often hard to fix issues in XPe?

There is no easy way to figure out all the components in the database (or your configuration) that may interfere with yours
and
potentially overwrite some registry value you are trying to setup. Myself I found a way how to find out most of those
"dependencies"
(not really dependencies but the build order chain) if I search the DB first for the list of components that contains
particular
registry value I am trying to set up. The only way to do that, as far as I know, is to use the DependencyExplorer and
ConfigurationExplorer components off the XPeTools package on www.xpefiles.com.
I wish Microsoft implement the "registry search" feature in TD but they never did so the above is the only way I know.

Please keep in mind that you may still get into the situation where you reg keys may be overwritten during FBA. Some component
may
dynamically mess with some registry keys at runtime and you have no control over it. Only way to avoid this is to set up a FBA
generic command that will install the required registry keys/values during FBA at very late phase.


Now the second part of your question. Well, the only explanation I see (the below is only my opinion) is that the XPe is not
truly
componentized version of XP. What I mean by that is that XPe components rely on the binary (Dll) componentization that's been
done
with XP at first place. It should've been vice versa in my opinion - XPe should come out first with the proper level of
componentization and then XP could be built as just a full blown image of XPe + some manual setup. Unfortunately, it would
take a
huge effort to drive this across big company like Microsoft.
Another example you have is Windows CE - another embedded OS from Microsoft. There most [lots of] OS components were created
from
the ground with the proper dependency chain. Also, lots of source code there makes it much easier to work on some OS specific
issues. However, some IP related issues still prevented Microsoft to ship most of the application code there (mostly only
kernel
and
driver source code available) so you still have to fight with OS issues once in a while.

Also, please keep in mind that regardless of the implementation big OS like XP, CE, Linux, etc. may suffer from not having
enough
documentation or, more often, from not providing the right tools and ways to search the documentation. It is frequently hard
to
find
an answer in the documentation because you don't know the source of the issue you are trying to research. For any person,
insider
or
external, it would be almost impossible to know all the aspects of the OS. However, some corner sources of info like Google,
MSDN,
Technet, various MVP websites and etc. are the first place to start digging into if you are working on some XPe related
issues.

--
=========
Regards,
KM

I have been trying to establish some simple components (Registry Tweaks
mostly) to minimize the time spent customizing the Windows environment after
the FBA process. Many of my attempts have been fuitless. I suspect that I
need to adjust the Build Order (default is 1000) or set some Build Order
Dependencies. There are tools to explore the dependencies of existing
components. But how do I establish the proper dependencies for a component I
am creating?

There is an example in Nick's Blog from 22 April 2006.
(http://blogs.msdn.com/embedded/archive/2006/04/15/576734.aspx)
He gave no explanation how he determined that his registry component needed
a build order dependeny against another specific component. And another user
came up with 2 more dependencies in August. So it wouild appear that even a
Microsoft insider like Nick failed to find all the needed dependencies for
his component to work reliably. How then can I hope to succeed where Nick
failed? How did Trevor find the additional undocumented dependencies?

I had hoped that after this much time, XPe would more of a science and less
of a black art!
When will Microsoft realize that Blogs and Newsgroups and Forums are no
substitute for proper documentation? All this trial and error stuff is
extremely wasteful. XPE is just one of many responsibilties for me. But every
time I touch it, it becomes a full time job for days at a time.

Any Ideas?

Andrew Roy
Irwin Research & Development
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top