66 replies to this topic

[ChrisR]

the remarks are not specifically for you Al_Jo, you have the merit of making and to be constructive . I know that you like tiny and light, so maybe better to use bsexplorer than explorer shell.

In your screenshot, Yes, some scripts could be disabled by default or leave the choice to the user to disable.
For now I prefer a solution a little between the two to have a fairly complete Win7Pe at first start. but it is also good to have a second build slight.
DirectX, Audio, Diver package installer, Pstart, Regshot2 will be disabled by default right now.
by cons removed MS Visual C++ runtimes for example would prevent a lot of application (portable or not) to work.
An other example, Superfinder is a voluntary addition because the integrated search function do not work.

Anyway choices in one direction or the other could be criticized or discussed.

[paraglider]

Everyone's opinion on what is a clean project will be different.

Some will always use explorer some will never use explorer.

Some like me will never use internet or audio from PE. Both of these can add significant bloat to a PE.

It will be impossible to satisfy everyone.

My view is that it is ok to have none MS apps in a build. However the programs themselves should not be embedded in the script. They should either be copied from a local installation or downloaded on demand from the program authors website.

[MedEvil]

That's not true App Scripts that a User don't need, why should they be includet? Is a little bit of searching for App Scripts to hard? Definitely no.

So searching for an app script is not hard, but unticking a box is?

many people are still using BartPE, cause the WinBuilder Projects are blown with unaccessary Software, and other stuff.

Yeah right. and 5 years ago many people claimed to still used BartPE, because it had more features than winbuilder project.
If BartPE is so great, why don't you build your Win7PE with it?

It's a stupid discussion. Download just what you need or build a project with just what you want, by unticking or deleting scripts. Nobody is forced to download a project completely and then also use it that way.
Projects are presented that way, so that fresh users will get a usable project, with the least possible effort.

btw. The more minimal a project is intended to be, the more ordinary users will whine, that they can't use any own applications with it. Have a look at our fantastic CLI project.

Regarding easier Apple products. This is nonsense. Have you ever looked under the hood of any Apple OS or just at the shiny GUI?
Shiny GUI = ready build PE
Under the hood = Winbuilder

For reference use M$ windows embedded and tell us again winbuilder is complicated.

[larioteo]

Hej come down from your trip, ok?

Could you realize that some people don't wont to download a 100MB Package and to try costumize it, than it fails hundret of times. A package like aj_jo ones is fantastic 12MB and i press play and have a minimal build. What is wrong with this, not everybody have time to study what is realy importand with that complex scripts here.

You could maybe imagine that you do not have to use such projects, there are many for you and a single project for people like us. It is wrong, should every project be blown up, i don't think so.

The Pictures from aj_jo shows exactly why many people even don't give WinBuilder a try, to much and complex scripts. There are sometimes facelifts neccessary, because everybody have a other sense of a perfect project.

Why adding opera? Do we realy need it in a Preinstallation Environment? Do we nead SuperFind, for our machines? Do we need unused Scripts?

Edited by Darijo, 11 May 2011 - 02:38 PM.

[homes32]

Hej come down from your trip, ok?

Could you realize that some people don't wont to download a 100MB Package and to try costumize it, than it fails hundret of times. A package like aj_jo ones is fantastic 12MB and i press play and have a minimal build. What is wrong with this, not everybody have time to study what is realy importand with that complex scripts here.

You could maybe imagine that you do not have to use such projects, there are many for you and a single project for people like us. It is wrong, should every project be blown up, i don't think so.

The Pictures from aj_jo shows exactly why many people even don't give WinBuilder a try, to much and complex scripts. There are sometimes facelifts neccessary, because everybody have a other sense of a perfect project.

Why adding opera? Do we realy need it in a Preinstallation Environment? Do we nead SuperFind, for our machines? Do we need unused Scripts?

unchecking those scripts takes less time than you did to write your last post.

your questions have already been answered. the default script selection is taylored to fit the majority of the users. sure there are some scripts like directX and Aero themes, audio, etc that are "unnecessary" and should be disabled by default, others you complain about are just interfaces for tweaking existing windows functionality and only add a few KB of text to the registry. still other programs such as ShutdownPE and driver integration were made to solve specific problems with PE.
shutdownPE does what the old method does not;full localization, flush the disk cache (to prevent data corruption, especially if you are running from USB), integrate with the start menu (this was a huge requested feature), and provide eject option for CD (another big request), as well as being able to specify programs/scripts to run on shutdown, which is also requested and used by a portion on the user base.

driver integration is also very important to have; you might be surprised how many users have non-standard hardware/RAID controllers/etc. is it fair to make it any less convenient for THEM to get a working build??????

Visual C++ is required runtime for many programs, including popular antivirus software ( many people use WinPE as a malware/virus removal platform)
I do not want to go back to the Win7ResucePE days of dozens of topics about people not getting their scripts to work in PE because of visualC++/SxS problems/not being available.

suffice to say that nobody is forcing you to use anything. do what you want, tweak what you want, have fun, and appreciate that many people have spent 100's of hours of their free time to give you these projects and no cost, with their only compensation being the knowledge gained and the satisfactions of making something good that can be used by the community.

Regards,
Homes32

[sbaeder]

Everyone's opinion on what is a clean project will be different.

Some will always use explorer some will never use explorer.

Some like me will never use internet or audio from PE. Both of these can add significant bloat to a PE.

It will be impossible to satisfy everyone.

My view is that it is ok to have none MS apps in a build. However the programs themselves should not be embedded in the script. They should either be copied from a local installation or downloaded on demand from the program authors website.

YES!!! That is the KEY issue here...a few lines of scripting code is no big deal...Not a big burden or overhead. While it is good (at times) to have things embedded in the script, more often (especially for applications that update often), it is just as easy to have the script pull them off the net.

To me, the issue is more about core things that need to be more tightly embedded into the basic foundation, and things that can be added on top of a solid base. Maybe just improved documentation on what is really "optional" is all we need to help users select the right things.

I agree with ChrisR - what this project is trying to do is provide a balanced starting place, and also make sure to lay a good, solid foundation!

But there is always room for more "recipes" in the kitchen!

[homes32]

ShutdownPE is nice but not really needed. I use ChrisR’s “Reboot and shutdown” instead.
Driver Integration is important but can be unchecked until a user really needs it!
Using AviraAntivir, Sophos, ClamWin and SuperAntiSpyware without VisualC = no problems.

that main problems I was referring to with visual c++ was with newer versions of Avira (the script you link to is old Avira 8), although there are plenty of other programs that use it as well. Also havign the runtimes separate keeps app script developing clean and small as each app script does not need to include support bulky runtimes as well as the app itself. in the end it just depends on what programs you plan to use.

what you say about ShutdownPE is true. it does not NEED to be enabled in order to have a working PE. The point I was trying to make is that it (and other scripts) was included and enabled by default because a large portion of the user-base requested inclusion of the features it provides. the "reboot and shutdown" script was left in the project to give those like yourself and Darijo the option to save 400KB of space on your media if you so desired.

I am fine with having driver integration scripts unchecked be default as they don't do anything unless you actually provide them with drivers.

everybody should keep in mind:

• constructive feedback on what scripts should be selected by default and legitimate concerns about why featureX should be a separate download are good and appreciated.
• ranting and criticizing a project(s) because it was not custom tailored with only things you want to use is bad.

a lite "base only" distribution is not a bad idea, and using the build-in options in winbuilder's download center cold be done someday when there is time.

Regards,
Homes32

[Sevilho]

The debate on more or less seems a bit sterile and not very positive .

Most users Win7PE want, indeed, something simple to start.
But a lot of users want quickly, after, more function and choices to customize their Building.
Some would like even more and more function and application.
...

In order to delineate the boundaries of Tiny-Mini would be nice to collect statistics on what users are using the live disk.

Doing my 1 cent a common fund:). I only need to run HDDScan to find health of my hard drives.

In the future I would like to place on the live disk Skype (sandbox), because it turns out to be a potentially ideal peddler malware.

[pscEx]

One of my mottos is: Everything is a question of efficiency.
Let the user aside, who "academic" tries all options of the PE. Let's restrict ourselves to the users who really want to create a CD / UFD for emergencies.

(Maybe there are 90% of the first category, and 10% of the second one.
@Nuno: view counts, member counts, ??? counts
But IMO the commercial / productive power of the 10% is about 99%.)

And here e.g. Multimedia or MSI is not needed in 99.9% of all cases.

On the other hand: When I have to fix an emergency: Nobody demands to fix it in e.g. 24 hours with a CD / UFB from the stock.
I think, everybody will give me the 24 hours + 15 minutes to prepare an emergency CD / UFD which propably will have all the necessary tools.
If one tool is missing: sorry, another 15 minutes.

Who is sure that in a "supercallifragilisticexpiallegoric" CD / UFD there are ALL tools to fix the current issue?

Result:
Like Darijo and e.g. al_jo, I'm also a friend of a "minimized" factory setting.
An "I'm showing what all you can do with my project, inspite you'll never have the necessarity to use" might look great for ???, but it is not suited for professional admins.

Peter

EDIT: Some editorial adjustements

[Wonko the Sane]

If I may, the essence of the problem is the often "incremental" nature of these builds (or of the .scripts).

Ideally you should be able to have a really "barebone" base, and have any number of .scripts, each capable of being added BY ITSELF to this barebone base.

Often this is not the case, because of the complexity of dependencies/pre-requisites/whatever, so that if we call the "barebone" B , and we try adding .scripts C, D and E to it, the result is:

• B alone works
• B+C works
• B+C+D works
• B+C+D+E works
• B+E does NOT work (because *something* in C, or D or both is needed in order to have E working)

And sometimes this *something* is not explicited anywhere (not in the .script documentation/help - often not even existing, not evidenced in the winbuilder log at build time, etc.) so that there are quite a number of reports of people failing because - in perfectly good faith - removed from the build C and had as a result that E was not working.
On the other hand the actual .script developer - also in perfectly good faith - always tested E with C enabled and never had a chance to find the problem.

This is partially inherently due to the architecture of the actual Windows, we all know DLL and DLL versioning nightmares and more recently WinSXS or Side by Side ones, but by using the approach of "self-standing" .scripts tested ine by one and by themselves on a "ommon barebone" might be IMHO a turn into the right direction.


Wonko

[pscEx]

This is partially inherently due to the architecture of the actual Windows, we all know DLL and DLL versioning nightmares and more recently WinSXS or Side by Side ones, but by using the approach of "self-standing" .scripts tested ine by one and by themselves on a "ommon barebone" might be IMHO a turn into the right direction.

I have the feeling to become depressive!
Two years ago I tried to bring some rules how to write really "fully usable" scripts.
http://reboot.pro/81...dpost__p__69350
Unfortunatelly "ShutDown" with the next post:

... is wrong since all scripts can be made cooperative in time if required.

Until today the "if required" appearantly did not happen. Our users do not need simple, self supportant scripts (maybe with the exceptionj of Darijo and me).
Three years ago I published a tool "scanProject" which in a project can detect and log possible conflicts between scripts.
The resonance was "UNIQUE": One "congrats" by (was_)Jaclaz. Nobody had a question, nobody saw the necessarity to use.

Thanks, Darijo, for creating this topic.

Maybe it helps to ... ???

Peter.

[MedEvil]

When I have to fix an emergency: Nobody demands to fix it in e.g. 24 hours with a CD / UFB from the stock.
I think, everybody will give me the 24 hours + 15 minutes to prepare an emergency CD / UFD which propably will have all the necessary tools.
If one tool is missing: sorry, another 15 minutes.

Wow, 24 hours to fix a single computer and people really pay that? Can i live in your world?

[pscEx]

Wow, 24 hours to fix a single computer and people really pay that? Can i live in your world?

You did not read my post carefully enough.
"e.g. 24 hours". And I already have had emergencies where a team of some people needed several days (ok, DEC assembler)

When you simply want to copy the latest backup image, you do not need a PE. Imaging apps provide a boot CD / UFD

Peter

[MedEvil]

but by using the approach of "self-standing" .scripts tested ine by one and by themselves on a "ommon barebone" might be IMHO a turn into the right direction.

Would you do me the favour and try to work a little with one or the other project and i don't mean use the build PE, but really dive into the project itself and see how it works under the hood.
Cause your opinion sounds very theoretical to me.

No script, no project is constructed like a machine, but rather patched together.

I ran a bunch of tests lately to optimize Win7PE_SE. Results: All Win7 projects have a couple of thousand duplicates. Thank god they all use Wim container!
At the same time, they have between 1500 - 2000 open dependencies.
No doubt the registry is in no better shape, but i don't know how to scan for that.

So your perfect idea collides right on it's very first step with reality.

If however, you would create a perfect Win7 barebones project, i would happily test and use it.

[Arvy]

Wow! What a tempest in a teapot! Some people seem to have misunderstood my suggestion as some kind of "back to less ... just plain stupid" idea about limiting winBuilder project options. In fact, it was nothing like that. To the contrary, let the project developers include any and all bells and whistles that they think might possibly come in handy for anyone under any circumstances at all.

My suggestion was really quite simple and seemed (to me at least) to make perfectly rational sense. Let end users make their own positive selections of non-essentials for inclusion in their own preinstallation environment builds rather than having some subset pre-selected arbitrarily based on some developer's notions about what the "average user" should want. Some may disagree with that approach, but I fail to see how it's any more "stupid" or irrational than the current situation whereby pre-selections for "out of the box" PE build inclusions often appear to be little more than accidental or whimsical.

And yes, as pscEx (formerly just psc) mentions, I recall very well when he himself was a very strong advocate for minimalist "out of the box" operability for winBuilder projects. Things seem to have changed somewhat since then.

[larioteo]

The positive aspekt is that a minimal project can be faster fixed, and if it is easy to handle, a lot of people could help in their free-time. I would help here, my problem is the free time, i am developing apps for bada and have no enough free time left to study everything.

BartPE is dead, that is why my extensions are all for nothing, one year work, for nothing, thats why i would like to join a community where i can help maybe with something. But to learn how is heavy with this complex scripts, alone the CAPI is not to understand if someone else would like to improve it.

We should get in a future where, one team makes the barebones, and the other all the stuff below, than we add it in a Super Project that is perfect. Why not?

The barebones nowadays aren't perfect, everybody knows that, and it takes a lot of time to handle all errors. because every script in a project must be testet, that takes a lot of time, the best is when changes are made and the system crashes, than the error search is not funny.

Imagine hundrets of people that helps in one project, that would be the best for everyone of us.

Edited by Darijo, 12 May 2011 - 06:53 AM.

[Wonko the Sane]

So your perfect idea collides right on it's very first step with reality.

Not really, it collides with the current reality, which does not mean that reality cannot be bettered.

I see no problem in a number of self-standing .scripts and a final "deduplicating" one, like the "scanproject" pscEx made.

I also pointed out some time ago - in my simplicity - an alternative approach, a pre-processor to solve dependencies (and duplicates) before bulding.

I do understand that the idea of "doing the right thing" brings with it MORE work for the good guys that develop .scripts, but I think that if suitable tools and some guidelines can be provided it would not be that much of overload.



Wonko