Re: Our experience with XPe
From: KM (konstmor_at_nospam_yahoo.com)
Date: 09/15/04
- Next message: KM: "Re: About drive letter assignments"
- Previous message: Slobodan Brcin \(eMVP\): "Re: Component Designer"
- In reply to: rjungbeck: "Re: Our experience with XPe"
- Next in thread: Slobodan Brcin \(eMVP\): "Re: Our experience with XPe"
- Reply: Slobodan Brcin \(eMVP\): "Re: Our experience with XPe"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 15 Sep 2004 12:59:48 -0700
> 2) Target Designer is not able to distinguish between components
> automatically added and those manually added. Therefor it is not
> possible to
> see the effects of removing one component or dependency (eg in a self
> developed component), because earlier autoresolved components remain in he
> configuration. The only alternative (saving before autoresolve and than
> rstoring) is very timeconsuming.
> >
> > Yes this is true, but can be workaround up to some level by manually determining component dependencies and adding them manually
> > instead of autoresolve.
Dependency Check (especially with autoresolve enabled) is amasingly slow. It is obvious why - VB Script implementation, CMI, COM,
SQL Server data access, some more levels.
That was the reason why I created DependencyExplorer a while ago. It takes much less time for me to find out neeeded dependencies
with that component. I wish MS would have sometimes similar.
Interesting that there is a new SP2 feature of showing dependencies through Help system - will be very useful.
> What we are trying to archieve is, to have one makro component per szenario
> (2) and one mako per harware configuration(right now 3 but more a coming).
> Autoresolve will add add around 500 to these. If we later modify eg a
> szenario to depend (or not depend) on another component, we would simply
> like to redo the build process.
> >
> > > 3) Target Designer is not able to work with a fresh mounted SDI file (at
> > > least you need to partition and format it, on XP SP2 you even need special
> > > handling for "System Volume Information")
Turn off System Restore service on a particular disk and the "System Volume Information" won't bother you.
> > I fail to see connection between TD and SDI file.
>
> We are using a SDI to bring the result of the target designer build to our device.
> > > 3) The hole process (from finished component design to resealed image) is
> > > MUCH TOO COMPLICATED. It involves numerous manual steps on different
> > > machines. What is really needed is a TOTALLY AUTOMATED process with no manual
> > > intervention at all (so it could be included in an automated build). It
> > > should be easily callable from a batch file.
> >
> > Not true. Everything can be automated. Something must go trough custom applications that use API but this is usually not a
problem
> > if you are or have some programmer at your disposal.
> How do you do these? Currently we need to open at least Target Desiger,
> build a a new configuration, include our makro components, do an autoresolve,
> mount a blank SDI, partition, format and clear it, build with target
> designer, unmount the SDI, bring these image to the PE booted device, copy
> the image onto the device, let it run until reseal (including several boots),
> reboot PE , save the image , reboot to test.
I agree - it involves many steps now to work with SDI. :-(
I heard MS is working on improving the process (automating) for LHe.
> > > 5) The idea of building the complete system from components is a good one,
> > > but it's pretty useless, as long as most szenarios require FBA (which means
> > > the whole process is very difficult, if not impossible, to automate).
> >
> > FBA is used for exactly this purpose, to automate all PnP and other similar configuration operations. But this sometimes
involves
> > writing simple applications for configuring XPe image. And you don't need to configure anything manually.
>
> Our intend is to use XPe on several 1000 distributed systems, which should
> be installed (or updated) in the field. We don't want multiple boots on our
> target devices during install. (Ideally we want to restore a disk image and
> off we go).
Again, again since LH/LHe is going to be much more componentized, there will be less needs for FBA.
Most components will be set up during build phase.
> > > 6) Microsoft component dependencies are much too broad (ie if you want FTP,
> > > you also need NTLM authentication). This make small footprint systems
> > > impossible. Also, even if have an application which requires no GUI, if you
> > > require any form of networking, you are forced to include GUI (although even
> > > the networking does not support any form of GUI). And any GUI requires FBA
> > > (which make the generation process complicated).
> >
> > Yes. For this we will have to wait for LHe.
>
> That's what MS told us with XPe when there was just NTe...
Do you still believe in someone promises (or better say, product feature list ads)? :-)
> > > 8) The difference between a disk and a partition SDI image is not documented
> > > well (it takes a while to find out when to use which (eg RAM boot)).
> >
> > Never had problems with these, it is documented and intuitive.
> Especially the error, that you get if you try to boot from the wrong RAM
> disk....
I don't agree with that. SDI BLOBs are not good documented. If there were no RAM Boot Using SDI tech article from Saad, it would be
very hard to figure out this stuff.
> > > 9) SDI files could not be used with Virtual PC directly (although the
> > > virtual disk drives there solve the same purpos).
> >
> > Could you elaborate more on feature that you would like? Also sent a MS feedback on this.
>
> We were looking for ways to do the FBA run's automaticly (from our
> automatic build). If a system needs to boot, maybe Virtual PC could help us.
> But this of course would also require, that we could configure Virtual PC
> with different virtual (custom) hardware.
XPe is based on XP Pro x86 binaries, therefore x86 is the only hardware platform available.
I think there is no good separation for Hardware (Platform) and Software components in XPe Configurations.
This all comes to the TD (CMI) limitations of not being able to delete a component tree. To expand on this I give you an example:
- I have a few Platform Macro components
- I add one of the Platform macro (e.g. Virtual PC) to my build and autosolve dependencies
- I build the image, test it, etc.
- I want to switch to another platform by removing previous added Platform component (and, of course, all the hardware
components added with it) and adding another Platform macro
This way I can really easy test my software stack on an Emulation platform first (like Virtual PC). I don't have to mess up
around target hardware, etc. Moreover, there will be pretty good separation between software and hardware. Some dedicated software
engineers may work on hardware, some - on software. Much more efficient considiring the fact that software guys usually don't deal
much with hardware and vice verse. I can see now that people working on XPe images sometimes have to work on hardware and software
components. It is absolutely hard to come over and comprehend all the components in XPe (especially in XPe as the software stack is
huge there).
Basically, the concept described above is pretty weel implemented in MS Platform Builder (Windows CE).
I am not saying it would be easy to implement all the above with XPe, but still doable.
> > > 10) Virtual PC can not be used to run the FBA (because the image would than
> > > support a different hardware).
> >
> > Why would someone want to use Virtual PC in the first place? It probably might be good for quick initial testing of XPe image,
but
> > for real usage there is no real need.
I would find it VERY useful to have an Emul platform to test the software stack.
> > > With the current status of the XPe tools, it is probably easier to modify a
> > > retail XP system to be an embedded system, than to use XPe (although pricing
> > > might make XPe desireable).
>
> >
> > This only depend on number of required features in XPe.
> >
> > But consider increased security, preinstalled drivers, no need for product activation, everything preconfigured automatically.
In
> > most cases XPe is easier to use and maintain then XPP.
>
> Our experience is, that the required features change with time, and for
> every change you need to redo the whole XPe thing.
And this is why it is important to have an automated testing process for XPe which is really hard to implement with the current
ToolKit version. :-(
KM
- Next message: KM: "Re: About drive letter assignments"
- Previous message: Slobodan Brcin \(eMVP\): "Re: Component Designer"
- In reply to: rjungbeck: "Re: Our experience with XPe"
- Next in thread: Slobodan Brcin \(eMVP\): "Re: Our experience with XPe"
- Reply: Slobodan Brcin \(eMVP\): "Re: Our experience with XPe"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
