46 replies to this topic

[pscEx]

To explain more, please read here.

The current stage looks like:

and it works well for nativeEx_Win7 and nativeEx_barebone.

Maybe there are opinions, suggestions etc. before a publish of the package.

Peter

EDIT 2010-JUN-16: Added latest GUI

[MedEvil]

I don't quit understand, will this replace the previous scripts or is this a script to operate the other scripts in a more user friendly way?

[pscEx]

I don't quit understand, will this replace the previous scripts or is this a script to operate the other scripts in a more user friendly way?

The previous "Finish", " Finalize", "Emulate" etc. scripts will become obsolete and can be deleted.
(Maybe you have a special script "E-mail the PE to the moon". I am sure there is a way to include that).

In the picture you see, that all current sub-scripts are not selectable to be processed.
Here you only once define your personal settings (usually once).
The unselectable scripts are processed from PEFactory, if applicable.

Peter

[MedEvil]

Yes, you're right, now i see it too.
Sorry, didn't pay attention to the other scripts. Didn't understand, that this was a whole package and not a single script.

Very nice effort!

[Galapo]

Maybe there are opinions, suggestions etc. before a publish of the package

Hi Peter,

Thanks for this. I do have two suggestions. First, it'd be great if PEFactory was compatible with WimPack. Second, it'd be great if it were compatible with RegFactory.

Also, since we can't test yet, I'm not sure if this suggestion has already been implemented. But it'd be great if the grub4dos option supported the current mechanism of adding and replacing items like with the DefineBootsector script.

Thanks,
Galapo.

[pscEx]

Thanks for this. I do have two suggestions. First, it'd be great if PEFactory was compatible with WimPack. Second, it'd be great if it were compatible with RegFactory.

I'l do some test what is possible.

Maybe we have to find a compatibility in the middle.

Also, since we can't test yet, I'm not sure if this suggestion has already been implemented. But it'd be great if the grub4dos option supported the current mechanism of adding and replacing items like with the DefineBootsector script.

I'm sure that the functionality of DefineBootsector.Script is fully or 99% contained in the PEFactory package.
Some functionality is decided "Automagically", some functionality like grub4dos skins, can be changed by the user.

Due Test: I think that tonight I'll publish a beta.

Peter

[Galapo]

I'm sure that the functionality of DefineBootsector.Script is fully or 99% contained in the PEFactory package.

Current functionality is:

MenuAdd_GRUB,grub4dos_entry,Prepend|Append|RemoveDefault

Supplied menu.lst entry can be prepended or appended to menu.lst. Alternatively, the default option can be overwritten by the one supplied if that is desirable.

Regards,
Galapo.

[pscEx]

Current functionality is:

MenuAdd_GRUB,grub4dos_entry,Prepend|Append|RemoveDefault

Supplied menu.lst entry can be prepended or appended to menu.lst. Alternatively, the default option can be overwritten by the one supplied if that is desirable.

Regards,
Galapo.

The current solution provides a custom grub4dos configuration. Sample here:

It is activated in the main grub4dos script:

The custom grub4dos script of LiveXP could contain:

[Process]

//use the already built menu.lst

FileCopy,<myMenu>,%MenuFile%

Peter

[Galapo]

Ok, thanks for the info. It might work as-is.

What about the file grldr? Would Grub4DosStandard.script overwrite one already supplied earlier in build?

Thanks,
Galapo.

[pscEx]

What about the file grldr? Would Grub4DosStandard.script overwrite one already supplied earlier in build?

Currently grldr is written in grub4dos.script, and overwrites already existing loaders.

If,EXISTDIR,%GrubDir%,ExtractFile,%ScriptFile%,Grub,grldr,%GrubDir%

Else,ExtractFile,%ScriptFile%,Grub,grldr,%PESourceDir%

If necessary, that can be changed, but I think that the current solution will give no issues.

Peter

[Galapo]

I think it gives an issue if someone wants to use a particular version. For example, I prefer a chenall build as it provides progress indication when ram-booting.

Regards,
Galapo.

[pscEx]

I think it gives an issue if someone wants to use a particular version. For example, I prefer a chenall build as it provides progress indication when ram-booting.

Regards,
Galapo.

The PEFactory is intended to be simple and fullfill 9x% of all cases without any "expert knowledge" of the user.
I do not want to create any GUI with tens of options.

In your case the project must maintain the attachement of grub4dos.script and change dynamically depending on some project options, like:

If,%CrazyOption%,EQUAL,TRUE,FileCopy,<loader_crazy>,%TempFolder%\grldr

Else,FileCopy,<loader_standard>,%TempFolder%\grldr

Encode,%Grub4DOSScript%,grub,%TempFolder%\grldr

Maybe it does not make PEFactory too complicated to add:
If,%ExistVar%,%MyGrubLoader%,<use this one>
Else,<Use the attached>
Peter

[Galapo]

The PEFactory is intended to be simple and fullfill 9x% of all cases without any "expert knowledge" of the user.

Ok, I was just providing this feedback because in the link you provided you've written: "PEFactory package is a solution to have ONE final PE build / test for ALL projects." I assumed "all" meant all, so was providing feedback from a LiveXP perspective. Currently I'm not sure PEFactory will work as it doesn't provide compatibility with currently implemented grub4dos options.

Regards,
Galapo.

[MedEvil]

I sure hope PEFactory will not turn into a LiveXP kinda script, where millions of options are thrown at the user.

[Galapo]

I sure hope PEFactory will not turn into a LiveXP kinda script, where millions of options are thrown at the user.

Well, you could stop complaining and do some script updating yourself.

Regards,
Galapo.

[pscEx]

I added in the introducing .html (see first post):

To avoid misunderstandings:
PEFactory does not claim to put ALL existing projects into a "Run Basket".
Existing projects have to qualify themselves for beeing enlosed in the "Run Basket" and maybe do some changes to make this possible.
When they do not want to be included into the "Run Basket", there is no restriction that the projects remain like they are.
They just have not to use the PEFactory package.

Peter

[MedEvil]

Well, you could stop complaining and do some script updating yourself.

I'm not complaining, i just happen to disagree with the LiveXP philosophy.
Some people like, if they can tweak everything. I like easy to use.

[carloscape]

If you want to satisfy both, you could always add an Advanced Button where people can get more options.

[paraglider]

If you are not careful you finish up with what happened with win7pe_se. In the interest of making it easy to use - all the useful options get removed.

[pscEx]

Thanks for your comment!

I simultaniously agree and disagree

GUI options which some members call "Useful", confuse other members.

It is not so easy to find a suited compromise between the two sides.

Peter

[sbaeder]

To explain more, please read here.

Maybe there are opinions, suggestions etc. before a publish of the package.

Peter

After a fairly long break (playing with Android and new Nexus One)...seems like a good idea, but not sure implementation fits well since it is after the fact, and I would like to see more of this split into two parts...

Some of this needs to happen up front in the configuration of the project, and some of it happens at the end when you test the project or build the project into an ISO/USB, etc. This always seemed poorly implemented to me in the past on many projects, since some of the settings on grub (or even syslinux/isolinux or other boot managers) needs to happen at the start to set up the intial files that other things might write to.

Yes, from a programming point of view, they go together and probably need to be in a single "package" (i.e. a script file). But in terms of a "flow" presented to the user, there are things that happen at the start, and other things that happen at the end.

This is just another "issue" with Winbuilder in general - the conflict between presenting choices to the user and the organization of the code to implement things so you don't duplicate or complicate things.

I saw a similar issue when I was playing around with the code to bypass the WAIK and cache the images, etc. There were calls from one script into another - while that is a good thing to allow to prevent duplication - it made it a bit more difficult to manage (i.e. for me to follow what was going on), and in the end, I figured out it was so that the up front processing happened at the start, and the writing of the images happened at the end.

Not sure the above "rambling" makes sense or if there is a clear message of don't do A, but instead do B, just that making a single "package" to build the physical instantiation of the PE and to allow it to easily combine with other things is a good thing to do, just not sure ONE package will "rule them all" (or even 9x%)...

But, it's worth a shot...

[pscEx]

Thanks, sbaeder, for your comments, concerns and ideas!

Similar concerns and ideas caused me to develop this package.

The "package" should really be totally independent from the project. The project author only has to do one thing: Thell the package some fundamental values:
(current "state of art"
[codebox]Run,%BootManagerScript%,%ProjectTitle% [nativeEx_barebone] Set,%x8664%,%SourceArch%,PERMANENT Set,%ProjectType%,1,PERMANENT Set,%BootTMP%,NIL,PERMANENT Set,%WimApp%,NIL,PERMANENT [nativeEx_Win7] Set,%x8664%,x86,PERMANENT Set,%ProjectType%,4,PERMANENT Set,%BootTMP%,%ProjectTemp%\boot.tmp,PERMANENT Set,%WimApp%,NIL,PERMANENT [VistaPE_CAPI_v.12_(RC1b_common_API)] Set,%x8664%,x86,PERMANENT Set,%ProjectType%,2,PERMANENT Set,%BootTMP%,%ProjectTemp%\boot.tmp,PERMANENT IniRead,%ProjectInfo%,VistaInfo,Imagex,%WimApp%[/codebox] Because this is still in beta stage, maybe some other variable definitions may become necessary.

Tomorrow I'll publish a redesigned nativeEx_Win7 using the package.

BTW: It is already on the server and can be downloaded. But please allow me not to give a "preface of explanations, how to use" right now.

Peter

BTW2: e.g. the "Grub" issue is respected by adding a predefined / built menu.lst

[Galapo]

The project author only has to do one thing: Thell the package some fundamental values:

Given our discussion above, I fail to see how this could possibly be the "one thing" that a project maintainer has to do. For LiveXP, I've already explained how PEFactory in its current implementation is fundamentally incompatible. As explained, that's not necessarily a problem with LiveXP, just that PEFactory can't cover all the options without additional development on PEFactory.

Regards,
Galapo.

[pscEx]

As explained, that's not necessarily a problem with LiveXP, just that PEFactory can't cover all the options without additional development on PEFactory.

After the nativeEx_barebone theme is closed for me (The 'Main Customer' LiveXP is not able or refuses to update to WB 081 RC1 / 082):

What do you think is my goal for the next time?

Currently I'm in the last tests to let "Vista PE Capi" project (by JonF) work with PEFactory.

Peter

[Galapo]

Peter, this crucial post still remains unanswered: http://www.boot-land...?...st&p=100516

As previously stated, this should be the practice:

In my opinion, we should be able to drop the new WB into our projects and have them work. The only exception to this would be in the case of an actual script bug, or if there is agreement among WB development and project maintainers that a crucial syntax change necessitates not supporting backwards compatibility.

Now, I know you disagree. But the reality is that not doing this just gets people offside. I hope this isn't your underlying intention -- I really do hope that you desire a WB that works with other projects and actually supports other developers. At the moment, I don't feel that's the case.

Thanks,
Galapo.