stupid question

[Guest]

Are XPe images hardware specific? ie. can I take an image from one model of
Wyse and copy it to an HP, or vice versa? Or from Wyse to Wyse? What
should I be using to clone my XPe systems? Is there an MS tool for this?
Thank you for any help. I am new to this.

 

[Brad Combs]

Mike,

In a nutshell yes they are hardware specific. In order to create an XP
Embedded image you run a probe utility called tap.exe to create a hardware
layout. That layout is typically used as the starting point for the image.
There are Macro components in the XPe database that will work with a large
group of target hardware (Minlogon Sample Macro for example) but its likely
that Wyse and HP created a configuration specific to their hardware.

As for tools to clone systems every situation is different. Some people use
things like Ghost and DriveImage. I normally just copy the files to a newly
formatted disk from an archive like zip, etc...

You can investigate SDI from MS. There are utilities in the XPe toolkit
(sdi2hd) that will load a disk from a single image file (SDI File).

HTH,
Brad

 

[Matt Kellner \(MS\)]

Hi Mike. I see several separate questions here, so I'll try to address each
of them. =)

Your ability to move a runtime image from one system to another (or deploy
on multiple systems) depends mainly on your image configuration. Did you
create a PMQ file for the first target system and import that into your SLX?
If so, the runtime image is built specifically for that target system, and
will most likely only run on that system and identical (or near-identical)
systems. It's important also to know about all of the hardware in the
target computers - many systems by the same manufacturer will have different
chipsets and base hardware, different HALs, etc., and those all need to be
accounted for if you're making a hardware-specific runtime. (If the two
systems are by the same manufacturer and are the same model number, it's
usually safe to assume they have the same hardware, so moving your runtime
from one computer to another would be safe here.)

However, if you create a generic runtime based on the Winlogon or Minlogon
Sample Macros, you will have a runtime that should be compatible with all
PCs because it is comprised of "lowest common denominator" components. (You
can find these sample macros in the Target Designer component tree, under
"Software >> Test & Development".) In a generic runtime, the components
that are brought in to the runtime are the ones that are virtually
guaranteed to run on any system, such as a generic IDE controller, Standard
PC HAL (all ACPI systems are backwards-compatible with Standard PC), generic
VGA driver, etc. Your system will boot and function, but may not perform
very well because there are no hardware-optimized drivers running.

You can add specific hardware drivers to your runtime at the sacrifice of a
small footprint. If you know you'll need to deploy your runtime image to
multiple target systems, you can add the specific drivers for each system to
your runtime. The only limitation here (as I explained in another thread)
is that each target system must be running the same HAL (such as Standard
PC, ACPI Multiprocessor PC, etc). You can only have one active HAL
component per image, so if you need runtimes for different HALs, you'll need
to create and build separate images for them or use Standard PC across all
of them.

As for running the same image across multiple systems: Included in the XPe
Tools is the System Cloning Tool (Software >> System >> System Services >>
Base). This component allows you to reseal your runtime image and deploy it
to multiple systems. See the following article for more information on
System Cloning:
http://msdn.microsoft.com/library/en-us/xpehelp/html/xeconCloning.asp .

You can also just deploy the same image to multiple systems and let all of
them run through FBA, but this is more time-consuming - this is what the
System Cloning tool is designed for.

--
Matt Kellner ([email protected])
STE, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================

 

[KM]

Mike,

There is a low level utility to download an image to (re-image)Wyse terminal. It is network based (just crossover connection to a
PC) and works with BIOS client on the terminal. It is quite handy.
You should contact manufacturer (Wyse, HP) to get the tool.

 

[Guest]

Matt,

Wow, thanks for your detailed message. There's a lot in there that's greek
to me. eg. I have no idea what a PMQ or SLX is. I just unboxed this Wyse
Winterm, disabled it's write filter, made appropriate changes, then reenabled
it to "seal" it. So now it's set to go. I image XP w/Ghost all the time,
so I understand from your message now that these are pretty much the same,
hardware wise. Thankfully, we'll be ordering about 400 of the exact same
boxes, so I am assuming this very image will work on all of them. Now I
just need to be able to bang these things out.

I don't know what minlogon or winlogon, sorry. Like I said - the hardware
will be exactly the same, so I think a lot of the complications you bring up
won't apply to me. As my XP's, I'll have a standard image for each hardware
device we have, which should be very few.

I didn't see that tool on this device, I'll look again. Thanks for your
help you've given me at least a starting point! Any more wisdom you can
shoot my way would be appreciated. Off to lunch - back in a bit...

Thanks

 

[KM]

Mike,

In my experience, Wyse terminal images were using an undocumented flash sys driver that was reading some device specific information
(computer name, etc.) off a hidden partition on the Flash early at boot time.
I am not sure if this applies to all Wyse terminals but that was the case for a few of them at least.

This is to say that you should be careful using Ghost software copying the images. There might be some troubles for you on this
route.

 

[Matt Kellner \(MS\)]

Sorry about that - here's some terminology for ya:

A PMQ file is a file that identifies the specific hardware in a system. In
the XPe tools, you will find a program called "tap.exe", which you can run
from WinXP Pro, Win2K or .NET Server. This tool just goes through and gets
a list of the hardware in the system. You can then copy the resulting PMQ
file (by default it's named "devices.pmq") to your development system. In
Target Designer, you can go "File >> Import" and select this devices.pmq
file. TD will spend a few minutes crunching on this file, and then you'll
have all the hardware components TD recognizes added to your configuration.
=)

Target Designer saves runtime configurations with the extension .SLX , so
it's common to refer to a configuration as an SLX.

Minlogon and Winlogon are base-level components (mutually exclusive) that
handle the main user interface and security for the system. The sample
macros provided in the "Software >> Test & Development" branch in Target
Designer will help you become oriented with these components.

System Cloning Tool is a component that you can access from Target
Designer - it is not a separate executable in the Embedded Tools folder.
You can access it by name or find it under "Software >> System >> System
Services >> Base" in the component tree. See the article I linked you to
for more information on that tool.

Please let us know if you need more assistance. =)

--
Matt Kellner ([email protected])
STE, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================

 

[Richard]

KM, that sure sounds like a useful tool. Do we have anything like that for
other machines or is it a custom bios thing for Wyse only?

 

[KM]

Richard,

It is more than just a custom BIOS for Wyse machines. There is a hidden partition on the terminals (at least used to be there) and
is used a BIOS extension to provide the necessary code implementation for the feature.