Jump to content

Winpe Vs Bartpe


ShrimpBoy

Recommended Posts

WinPE is Hard to use for a reason. M$ does not want you useing it. It is only for OEMs who have an OEM "Support" contract with them and can get the specific tools and other documentation that makes using WinPE more economical.

Since WinPE is a stripped down verion of XP, it has limits... But it still IS XP, so M$ does not want people using WinPE for their main OS. (Which would be tough, but I am sure someone (out of a million) would do it).

BartPE is easier to use becuase it was made for everyone, not just a select group.

So they are both good tools in their own way. I prefer a working copy of WinPE for dealing with Windows XP and Server 2003 Installs while I like BartPE for just about eveyrthing else.

Just keep that in mind when trying to configure and creae a custom WinPE disc, it will be tough because M$ wants it that way.

Link to comment
Share on other sites


Re-read my post. It's not hard to use. If you are using it for it's intended purposes (deployment, recovery, and troubleshooting). No, it's not as easy as Paint, or even Word for that matter.

And it wasn't designed to be hard to use - you're being just a little bit silly. It was designed to serve a limited role. If you want a Swiss Army knife that can do 1,001 things, depending on how you build it, again see my post above - That's what Windows XP Embedded was (is) for.

Link to comment
Share on other sites

XP Embedded is a full version of XP that was componentized (if that is even a word) so that each component could be removed and the OS could be strictly customized and shrunk to fit customized hardware such as cellphones, pda type equipment, NAS, Hand-Held scanners, etc...

WinPE was made to be cryptic, it was made for advanced users and MCSEs. BartPE was made for anyone who wanted to use it. If WinPE was made to be easy then there would be more tools for it other than mkimg.cmd.

If you read my post completly you would have seen that I also identified the differences of both tools.

(from my previous post)

So they are both good tools in their own way. I prefer a working copy of WinPE for dealing with Windows XP and Server 2003 Installs while I like BartPE for just about eveyrthing else.
If M$ was not so worried about the use of WinPE Why would they impose such arbitraty Limitations to it...

(this was taken directly from the OPK User's Guide)

To prevent its use as a pirated operating system, Windows PE automatically stops running the shell and reboots after 24 hours of continuous use.

No network access to files or folders on a Windows PE computer from another location on your network.

Because something was created for recovery and configuration does not mean it has to be feature-less or hard to use, it's the fact that Microsoft has a specific audience it has targeted to use this software, they provide additional resources for that audience... I should know, I am legally a part of that audience and I have been given access to other tools and documentation that has been helpful in my implementation of WinPE for system deployment to our clients.

MS is a company, they want to make money, to do this they have to give tools to their larger clients to make deployment easier. WinPE is one of those tools.

Link to comment
Share on other sites

---

PEBuilder:

Dos support - Bart's builder has a plugin called "dospe".

WinPE:

This is something that WinPE does not provide… Is there a real need?  What DOS apps do you need to run from your 32 bit environment?

---

I've used BartPE once, and I've never used WinPE. However I have installed Windows XP many times. Durring Windows XP setup, you can press Shift-F10 to get a command prompt....

Does WinPE offer the same feature? (pardon my ignorance on this matter)

Link to comment
Share on other sites

XP Embedded is a full version of XP that was componentized (if that is even a word) so that each component could be removed and the OS could be strictly customized and shrunk to fit customized hardware such as cellphones, pda type equipment, NAS, Hand-Held scanners, etc...

WinPE was made to be cryptic, it was made for advanced users and MCSEs. BartPE was made for anyone who wanted to use it. If WinPE was made to be easy then there would be more tools for it other than mkimg.cmd.

If you read my post completly you would have seen that I also identified the differences of both tools.

If M$ was not so worried about the use of WinPE Why would they impose such arbitraty Limitations to it...

(this was taken directly from the OPK User's Guide)

Because something was created for recovery and configuration does not mean it has to be feature-less or hard to use, it's the fact that Microsoft has a specific audience it has targeted to use this software, they provide additional resources for that audience... I should know, I am legally a part of that audience and I have been given access to other tools and documentation that has been helpful in my implementation of WinPE for system deployment to our clients.

MS is a company, they want to make money, to do this they have to give tools to their larger clients to make deployment easier. WinPE is one of those tools.

1: Windows XP Embedded is not used for handhelds. That is Windows CE .NET. Windows XP Embedded also isn't usually used for NAS devices, there are versions of Windows 2000 and Windows Server 2003 designed specifically for that.

2: The thought that WinPE was intentionally made "to be cryptic... for advanced users and MCSEs..." is, as I said, silly. Making something easy to use for consumers, and something easy to use for people who actually do deployments day in and day out are two totally different things. WinPE does a very good job for the latter case. That is by design. Mkimg.cmd is the only tool because for deployment, that's all you need. Something to build WinPE. From the command prompt then you can script any tool you need for deployment. You don't need a shell. You don't need sound. You don't need an RDP client... you need a 32-bit, simple user interface that can handle scripting. That's it.

3: Again, since WinPE was designed for deployment, and there is no deployment task on the planet that takes more than 24 hours, and no need for you to connect to WinPE, since it can connect to UNC's already, and it's a deployment client, not a server, it has limitations built into it. That doesn't speak to your point about it being arbitrary. It's not a server. It's a deployment environment, Windows Preinstallation Environment. Not Windows "Perfect for Everything"

4: It's not feature-less. It has the features - and has grown in each version to add more features - needed for deployment and recovery. WinPE comes with documentation. It's not huge. Most of it isn't rocket science for anyone to figure out if they've ever written a script of any kind before.

I think the point I'm trying to make is that WinPE was not "intentionally made confusing" as you keep alluding to. Ease of use was intentionally "not driven down to a consumer level" because there is, was, and will be no need to do so. Consumers don't build scripted deployment or recovery solutions. They take their systems to a technician (who does), or buy consumer-focused recovery applications.

Link to comment
Share on other sites

1: Windows XP Embedded is not used for handhelds. That is Windows CE .NET. Windows XP Embedded also isn't usually used for NAS devices, there are versions of Windows 2000 and Windows Server 2003 designed specifically for that.

I am sorry but you are not correct in all of you assumptions...

I sell over 300 devices that are considered handhelds that run Win XPe, not CE becuase of their functionality.

2: The thought that WinPE was intentionally made "to be cryptic... for advanced users and MCSEs..." is, as I said, silly. Making something easy to use for consumers, and something easy to use for people who actually do deployments day in and day out are two totally different things. WinPE does a very good job for the latter case. That is by design. Mkimg.cmd is the only tool because for deployment, that's all you need. Something to build WinPE. From the command prompt then you can script any tool you need for deployment. You don't need a shell. You don't need sound. You don't need an RDP client... you need a 32-bit, simple user interface that can handle scripting. That's it.

Then why doesn't MS make a gui tool to add features like Bart does? Because they don't want it to be easy to modify.

3: Again, since WinPE was designed for deployment, and there is no deployment task on the planet that takes more than 24 hours, and no need for you to connect to WinPE, since it can connect to UNC's already, and it's a deployment client, not a server, it has limitations built into it. That doesn't speak to your point about it being arbitrary. It's not a server. It's a deployment environment, Windows Preinstallation Environment. Not Windows "Perfect for Everything"

I showed you in MS's own words that it was to make sure WinPE was not used as a pirated OS. That was my point on this matter.

4: It's not feature-less. It has the features - and has grown in each version to add more features - needed for deployment and recovery. WinPE comes with documentation. It's not huge. Most of it isn't rocket science for anyone to figure out if they've ever written a script of any kind before.
It is feature-less. It has no features except the recovery console in a Win32 enviroment. If you want Windows Scripting support, or HTA support you have to add it seperately, thus making WinPE feature-less... unless you add the features manually. (The way it was meant to be, I do not disupte this).
I think the point I'm trying to make is that WinPE was not "intentionally made confusing" as you keep alluding to. Ease of use was intentionally "not driven down to a consumer level" because there is, was, and will be no need to do so. Consumers don't build scripted deployment or recovery solutions. They take their systems to a technician (who does), or buy consumer-focused recovery applications.

I agree that there is no need to bring it to a consumer level, because the consumer is not the target audience. That is my point. It is by design too cryptic for the common customer (without any programming experience, or more extensive knowlege of how Windows works other than using it and configuring the minor settings). It's not a claim I came to by my own volition (excuse the sp errors), but a claim that has been supported by a few MCSE OEM Texts I have access to from work, and MSPSS Techs I have dealt with on issues concerning WinPE.

I am sure we can debate on this forever, at this point I am agreeing to disagree about the situation. I feel that we both have twisted the subject of this thread and I only posted to publish my opinion. It is ok that my opinion based on my experiences with MSPSS and other texts is different than yours, in fact, difference is what keeps the IT industry moving forward... if we all agreed, we wouldn't have very many options to choose from (now, that comment can open up a whole new can of worms so I will leave it at that).

Have a good one :-)

Link to comment
Share on other sites

1: There are a handful of "handhelds" that run XP Embedded. It's utility in that size of device is limited in that it only supports X86-based processors (and only Pentium and newer at that) - a class of processors rarely (but sometimes) utilized in small devices.

2: "Then why doesn't MS make a gui tool to add features like Bart does? Because they don't want it to be easy to modify." No, there was no GUI made because there was no time, nor was it critical to do so for the audience for which WinPE was intended. Had nothing to do with obfuscating WinPE's ease of use.

3: "I showed you in MS's own words that it was to make sure WinPE was not used as a pirated OS. That was my point on this matter." Correct - it is intended to be used for preinstallation. Nothing more. Adding limitations to enforce that is perfectly in line with the rest of Windows XP/2003 where Activation became the norm.

4: "It is feature-less. It has no features except the recovery console in a Win32 enviroment. If you want Windows Scripting support, or HTA support you have to add it seperately, thus making WinPE feature-less... unless you add the features manually. (The way it was meant to be, I do not disupte this)." It has the features it needs for it's role. No, WSH, HTA, and ADO (the first of which should have been in PE to begin with) have to be hacked in - but they were added specifically to meet the needs of deployment scenarios - as was DFS, WMI, and several other features. A blank piece of paper is feature-less. WinPE has the majority of the features needed to do deployment. And was specifically designed to do so.

5: "It is by design too cryptic for the common customer..." That, is technically, correct. It is also by design that it is perfectly usable by the intended WinPE consumer. The point of my posts was to highlight the fact that nobody spent any amount of time trying to make WinPE hard to use. That didn't happen during WinPE's development.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...