Re: Service Pack Installations in XP Embedded
From: Kesavan (kesavansajeev_at_hotmail.com)
Date: 02/17/04
- Next message: Kesavan: "Re: Can not install my own program to XPE"
- Previous message: David D: "Re: RAM EWF on CF hit and miss"
- In reply to: Sean Gahan: "Re: Service Pack Installations in XP Embedded"
- Next in thread: Sean Gahan: "Re: Service Pack Installations in XP Embedded"
- Reply: Sean Gahan: "Re: Service Pack Installations in XP Embedded"
- Messages sorted by: [ date ] [ thread ]
Date: 17 Feb 2004 07:13:40 -0800
Sean,
hehe , Sorry to confuse , just wanted to know whether the application
related to bits would only materialise efficient transport or
could/does it also include any other functionalities coz , Im stranger
to the language of BITS :),and was just curious to know if u have got
sumthin' like this working at your end .
Regards ,
Kesavan
"Sean Gahan" <sean@optistreams.net> wrote in message news:<#iA0KEM9DHA.1672@TK2MSFTNGP12.phx.gbl>...
> >However was your idea sumthin' like BITS or BITS itself ? Well it can
> >be more of a BITS with polling for binaries based on the log complete
> >under one .
>
> Kevsavan,
> Dude, you lost me. Please expand on this.
>
> Regards,
>
> Sean Gahan
>
>
> "Kesavan" <kesavansajeev@hotmail.com> wrote in message
> news:340a938c.0402160642.63f6a77a@posting.google.com...
> > Sean,
> >
> > I guess that would be really good work if we get sumthin' like BITS.I
> > guess the whole system could be automised in that case but the real
> > complexity would be the comparisons and other dependency checks at the
> > device end.
> > However was your idea sumthin' like BITS or BITS itself ? Well it can
> > be more of a BITS with polling for binaries based on the log complete
> > under one .
> > The log culd be a good resource as a input for all sources needed for
> > any upgrades.
> >
> > Regards,
> > Kesavan
> >
> > "Andy Allred [MS]" <andyall@online.microsoft.com> wrote in message
> news:<O#agncz8DHA.2760@TK2MSFTNGP09.phx.gbl>...
> > > Cool, BITS is a great idea (assuming it's already installed on the
> device)
> > > I'll add that to my wish list. <grin>
> > >
> > > Thanks Sean.
> > >
> > > Andy
> > >
> > > --
> > >
> > > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > > ==========================================================
> > >
> > >
> > > "Sean Gahan" <sean@optistreams.net> wrote in message
> > > news:O6CK9py8DHA.2416@TK2MSFTNGP10.phx.gbl...
> > > > Andy,
> > > >
> > > > How about using web services to facilitate what needs to be updated
> from a
> > > > build list. For example, the device could post a build log to a
> server
> > > > which would (based on the build log) figure out what binaries are
> required
> > > > and based on the requirements the server would generate a manifest of
> new
> > > > components to download which is passed to the device. Additionally,
> the
> > > > manifest would contain information about the components (like file
> size
> and
> > > > where the binaries go, kind of like a DUA script); the device then
> downloads
> > > > all of the components and uses the manifest as a checksum to make sure
> that
> > > > we got everything and that it's the right size. The device then moves
> the
> > > > binaries, updates the registry and does what ever else is described in
> the
> > > > manifest. One last thing, a great transport agent is BITS. From the
> > > > manifest, the download location and final destination could be dropped
> into
> > > > a BITS queue which would use idle bandwidth to obtain the binaries.
> One
> > > > great thing about BITS is that if there is a network connection loss
> or
> > > > power loss, BITS will resume the download when the connection has been
> > > > re-established, and if you are hooked up to a dial up modem, you can
> set
> it
> > > > up to periodically dial out and check for updates. Anyway, just an
> idea.
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > >
> > > >
> > > > Sean Gahan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "Andy Allred [MS]" <andyall@online.microsoft.com> wrote in message
> > > > news:eBmpY6k8DHA.2560@TK2MSFTNGP09.phx.gbl...
> > > > > Slobodan is right. Building the components is the easy part,
> verifying
> the
> > > > > myriad of new dependencies and their functionality is the hard part
> and
> > > > > makes me lose much sleep at night. However, the turn around time is
> only
> > > > > about 1 month which isn't bad when you look at SP1 had over 1,000
> > > > > updated/new components and almost 2,000 new files.
> > > > >
> > > > > Regarding the service pack installation, you won't be able to use
> the
> > > > > update.exe that is available to XP-Pro. However, i've already
> started
> > > > > thinking about how one would be able to deliver a service pack
> updated
> > > to
> > > an
> > > > > embedded device in the field. It would be a complicated process,
> since
> > > > > you'd have to take into account that simply updating an old binary
> isn't
> > > > > always good enough, there are new or removed reg keys that may be
> > > > > associated. Also if there are new dependencies for the updated
> binary
> you'd
> > > > > have to detect whether that feature already exists on the device or
> > > not -
> > > if
> > > > > not, then the runtime would become bloated and may no longer fit on
> the
> > > > > device. If it's not already there, you'd be introducing new features
> and
> > > > > functionality and all of the *their* dependencies not to mention
> you'd
> be
> > > > > increasing the surface attach area of the device.
> > > > >
> > > > > If anyone has ideas on this subject, i'd be very happy to
> incorporate
> them
> > > > > into a specification for the project team to see if it may be
> feasible
> or
> > > > > even desirable.
> > > > >
> > > > > Thanks
> > > > > Andy
> > > > >
> > > > > --
> > > > >
> > > > > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > > > > ==========================================================
> > > > >
> > > > >
> > > > > "Slobodan Brcin (eMVP)" <sbrcin@ptt.yu> wrote in message
> > > > > news:OV8yPLk8DHA.632@TK2MSFTNGP12.phx.gbl...
> > > > > > No in 99.99% builds you can't use ordinary service pack or
> updates.
> > > > > >
> > > > > > But MS is working on solving the problem with delays between
> normal
> > > and
> > > XPe
> > > > > > updates.
> > > > > >
> > > > > > Yes they must make components (this is the easy part). But also
> they
> must
> > > > > > test that components and make sure that they are actually working.
> > > > > >
> > > > > > Until the time of SP3 they will probably find a way to overcome
> this
> > > > > > problem.
> > > > > >
> > > > > > Regards,
> > > > > > Slobodan
> > > > > >
> > > > > >
> > > > > > "Matthias Hasenpusch" <matthias.hasenpusch@web.de> wrote in
> message
> > > > > > news:8DA68604-8612-46A2-897F-684EE53F4E0B@microsoft.com...
> > > > > > > Hi,
> > > > > > >
> > > > > > > is it possible to install a "normal" Windows XP Professional
> Service
> > > Pack
> > > on a Windows XP Embedded installation ?
> > > > > > > I ask, because I have heard that the Service Packs for Embedded
> > > appears
> > > 2
> > > Months later then the Service Packs of XP Professional. Is that true ?
> > > > > > >
> > > > > > > Whats the reason ? Is it because the component for the service
> pack
> > > must
> > > be build ?
> > > > > > >
> > > > > > > Many greetings from germany
> > > > > > > Matthias Hasenpusch
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
- Next message: Kesavan: "Re: Can not install my own program to XPE"
- Previous message: David D: "Re: RAM EWF on CF hit and miss"
- In reply to: Sean Gahan: "Re: Service Pack Installations in XP Embedded"
- Next in thread: Sean Gahan: "Re: Service Pack Installations in XP Embedded"
- Reply: Sean Gahan: "Re: Service Pack Installations in XP Embedded"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
