25 replies to this topic

[MedEvil]

When we started out or at least when i joined, the goal was to build a better PE and have our projects be easier to use.

I think we acomplished the first and if it only were, by our only competition giving up.

But with the second we failed miserably. In fact, the projects today are not only worst in this sense, then what we used to have, but are already reaching a point where BartPE projects start looking good again.

Does this complexity maybe lie in the nature of boot disk creation?

No it doesn't!

It is caused by a bunch of stupid design flaws like:
- Scripts with confusing names. Most prominent our BootSDI script.
- Scripts which do things, they shouldn't acording to their name. For instance, why do createISO, BootSDI, WimBoot scripts create ModelRam.exe?
- Script interfaces, which dump a wagonload of cryptic option on the user, instead of letting him simply choose, what his desired outcome is.
- Script interfaces, which look like they were hit by a bomb.
- My newest favorite, scripts which options work in concert but are not even in the same folder!

Without reading a handbook and i really mean BOOK, most if not all of our projects are not to be mastered.

One way out of this mess, without rewriting existing scripts, would be to use another absraction layer.
Making the old scripts invisible and adding a bunch of new scripts, which basicly just offer a clean and easy interface and then set the proper option for the 'worker scripts'.

[Wonko the Sane]

One way out of this mess, without rewriting existing scripts, would be to use another absraction layer.
Making the old scripts invisible and adding a bunch of new scripts, which basicly just offer a clean and easy interface and then set the proper option for the 'worker scripts'.

Adding a complexity layer that will be as poorly mantained and coded just as the existing layer is in order to simplify?

Then you'll have to need a book with instructions to read the BOOK (which not only doesn't exist, but that if it was existing would have wrong references, missing pages, wrong/crazy version numbers/names).

Oww, comeon!

We are exactly where we were heading:

All the advantages of Winbuilder when compared to Pebuilder (too basic/difficult to expand) and to UBCD4WIN (very good, but with "pre-fixed" contents) is (or should be) the freedom for each user to relatively easily "build" his own PE with some "easy to assemble" modular units, not unlike LEGO building blocks.

As is this goal is not reached.

One could as well have a few "monolithic" projects:
VistaPE
LiveXP
nativeEx
etc.
and use them like UBCD4WIN, with limited possibilities to customize it.

This Winbuilder behaviour is NOT friendly, which does not mean that anything is wrong on how Winbuilder it is currently setup, it's the claim that it is like it is in order to be more friendly that appears as a false statement.

Wonko

[MedEvil]

Adding a complexity layer that will be as poorly mantained and coded just as the existing layer is in order to simplify?

The idea is actually to circumvent a problem, that everybody refuses to fix.
Namely that functionality in scripts is not grouped by function but by developer.

Let's take CreateISO, BootSDI and WimBoot script for instance. Why 3 scripts? They all serve the same purpose.
We could replace them by a single script, which would require not more than 2 scrollboxes.
The first contains the kind of PE image that the user wants, like:
- PE plain on medium
- PE in ISO-Image in RAM
- PE in HDD-Image in RAM
- PE in WIM-Image in RAM

The second contains the type of medium:
- CDVD
- HDD
- USB CDVD
- USB Stick or HDD

To top it off a checkbox for 'write to medium' and we have saved another 2 scripts.

That are all the informations needed for the script to set everything else properly up.

If we want to really go overboard, we can have an advanced section, where the user can choose folder and image names.


There is really no need to offer every possible combination of options, including the unusable ones.


btw. Scrollboxes the most underused item in the interface, while they make for such sleek and easy to understand intefaces.

[MedEvil]

Here a little comparison of the standard Boot-Land design vs something i created for EvilPE.


Besides the size of the interfaces, the biggest difference is that the first tells you, what it will do, when you check something, while the second tells you, what the result will be, if you check something.

[Wonko the Sane]

The idea is actually to circumvent a problem, that everybody refuses to fix.
Namely that functionality in scripts is not grouped by function but by developer.

That would be nice , but wouldn't solve the modelram.exe issue you pointed out, unless I am missing something.

But how would you do it in practice?
I mean "merging" the functionalities of existing .scripts into one OR wrapping existing .scripts into a new .scripts that "sends" settings to the "original internal"?
As I see it, but of course I may be wrong, EITHER way the mantainer of the merged .script needs to update it as soon as the the original .script developer changes something, lest the wrapper may not work properly.

In other words we have some issues that can be attributed mainly to:

• "poor" coding
  
• "poor" GUI design
  
• "poor" integration/assembly of single .script in projects
  
• "poor" mantaining of the .script or project

(no offence intended to any of the good .script or project developers, of course , everyone does his best to contribute)

The "usual" remedies for the above problems are:

• set coding "standards"
  
• set GUI design "standards"
  
• solved by the above two
  
• more time and resources dedicated

Points #1÷#3 are the ones that should require the smallest effort (in terms of time), whilst #4 requires additional resources (which I don't think we have), just like writing a "wrapping" .script.

I guess that if some "standards" are set and, little by little, updated .scripts are "converted" to the "standard", we can have in a reasonable amount of time, and with efforts distributed among all contributing members, something better.

Otherwise someone needs to take care of "fixing" what other people write, and most probably this will lead to a similar "fight" as the recent comma/quotes/whatever.

I don't know.


Wonko

[MedEvil]

That would be nice , but wouldn't solve the modelram.exe issue you pointed out, unless I am missing something.

When things get grouped by functionality, the creation of ModelRAM.exe would move automaticly outside those scripts into an own one. If you mean how an interface script would fix it. Not by itself.

But how would you do it in practice?
I mean "merging" the functionalities of existing .scripts into one OR wrapping existing .scripts into a new .scripts that "sends" settings to the "original internal"?
As I see it, but of course I may be wrong, EITHER way the mantainer of the merged .script needs to update it as soon as the the original .script developer changes something, lest the wrapper may not work properly.

I actually though that, if scripts get merged, they keep being treated as one and not as seperate.
BootSDI and BootWIM for instance are both from nikzzzz and they already can create ISO.

As for interface and worker scripts, neighter side can by itself make changes that affect the other script.
This is called cooperation or to use the bad word, planning.

In an ideal world, the interface scripts were the job of the project maintainers, while they would be freed from fixing worker scripts. Unless they created those too.

I guess that if some "standards" are set and, little by little, updated .scripts are "converted" to the "standard", we can have in a reasonable amount of time, and with efforts distributed among all contributing members, something better.

There is no way in heaven or hell that this can work.
All long term processes always have as a result what the majority does. It's like trying to push an elefant to move somewhere, that doesn't want to move. You just waste all your energy without result.
You need to create, in an instant, the new situation. Take a needle and pick the elefant in the butt and he will move. Costs you hardly any time and effort to reach your goal.

Otherwise someone needs to take care of "fixing" what other people write,

We already have that. It's called a project maintainer.

[Wonko the Sane]

We already have that. It's called a project maintainer.

Sure , we have the "role" but do we have a sufficient number of mantainers (or do the existing mantainers have enough time to contribute)?

I see there are more unfinished/not updated/maintained projects then trees in a forest.

Heck we don't have anymore an updated LIST of them:
http://www.boot-land...?showtopic=4696





Wonko

[MedEvil]

Sure , we have the "role" but do we have a sufficient number of mantainers (or do the existing mantainers have enough time to contribute)?

That's a long standing problem. Maybe we should start charging people.
They could pay in money or time.

[Galapo]

- Scripts which do things, they shouldn't acording to their name. For instance, why do createISO, BootSDI, WimBoot scripts create ModelRam.exe?

Um, they don't. They simply process %PreISOScript%. If modelram.exe is being created, it's because a prior script has added that to %PreISOScript%. If you don't want any pre-ISO processing, such as building madelram.exe, then you'll need to modify some scripts to overcome this and do away with how %PreISOScript% functions in your project.

Regards,
Galapo.

[MedEvil]

Um, they don't. They simply process %PreISOScript%.

Um, they do! Which part of CreateISO tells the user that this script processes %PreISOScript% and does lots of stuff that has nothing to do with, let's say, creating an ISO?

If you don't want any pre-ISO processing, such as building madelram.exe, then you'll need to modify some scripts to overcome this and do away with how %PreISOScript% functions in your project.

Galapo you miss the point. There should be no need to edit a script because this functionality does not belong in a CreateAnything script. It belongs into a CompleteProject script.

Or to put it differently, the volume knob of your living room radio does not belong on the oven in your kitchen. And that should be clear by default and not require some tinkering from you to fix.

[Galapo]

Um, they do!

CreateISO does not create modelram.exe. There is noting in CreateISO to do with modelram.exe. All I can see is this:

[Process-Initial]

If,%pCheckBox2%,Equal,True,Run,%ScriptFile%,Add-FBWF

If,%pCheckBox3%,Equal,True,Run,%ScriptFile%,Add-2k3files

If,ExistFile,"%PreISOScript%",Begin

FileCopy,%PreISOScript%,%ProjectTemplates%

If,ExistFile,%ProjectTemplates%\%PreISOName%,Run,%ProjectTemplates%\%PreISOName%,Process

End

Else,Begin

If,ExistFile,%ProjectTemplates%\%PreISOName%,Run,%ProjectTemplates%\%PreISOName%,Process

End

For anything to do with modelram.exe, you'll need to look into '4 - BuildModel.Script'.

Galapo you miss the point. There should be no need to edit a script because this functionality does not belong in a CreateAnything script. It belongs into a CompleteProject script.

Like I said, CreateISO has nothing to do with modelram.exe. That issue lies elsewhere. If you don't want modelram.exe being created by %PreISOScript%, then that's up to you to figure out a more appropriate way this can be achieved that suits you. Or get Peter to tackle the issue since '4 - BuildModel.Script' is written by him. Anyway, depending upon project settings, buildmodel.exe isn't always created. That relies upon project settings set at !Fundamentals.Script.

Or to put it differently, the volume knob of your living room radio does not belong on the oven in your kitchen. And that should be clear by default and not require some tinkering from you to fix.

I have no idea what you're going on about. If you want something fixed the way you like it, then fix it and show us and we can adopt your improvements. Otherwise I cannot see how your "little rant" will achieve anything.

Regards,
Galapo.

[pscEx]

@Medevil!

If you during last three weeks would have had a look into the latest nativeEx XP and Win7 development, you would have seen, that the complete Build-Image part of both projects now are identical, reorganized scripts.

And before building an image of any kind, the PostConfigEx script is executed mandatory, which at the end of configuration prepares building of the PE image.
PostConfigEx contains e.g. building of ModelRam.exe, if applicable.

When downloading, the scripts are physically on both servers, on my development system with both projects there are only links from nativeEx_Win7 to nativeEx_barebone.


Peter

[MedEvil]

You guys understand that this was just an example, do you?

@Galapo
It doesn't matter if the code itself is in script A or if the script calls script B, which contains the code. By linking script B has become part of script A.

@Peter
Great! Now you only have to fix the rest of the project too.

[pscEx]

@Peter
Great! Now you only have to fix the rest of the project too.

I think that I decide what I have to do!
And nativeEx_barebone AND nativeEx_Win7 already ran well before I started the consolidation.

Peter

[MedEvil]

And nativeEx_barebone AND nativeEx_Win7 already ran well before I started the consolidation.

Wow! One of these days i really have to try nativeEx.

[Galapo]

@Galapo
It doesn't matter if the code itself is in script A or if the script calls script B, which contains the code. By linking script B has become part of script A.

I disagree. This is not about scripts being linked, but about which script creates modelram.exe. And that script is not CreateISO. It is '4 - BuildModel.Script' adding a line to %PreISOScript%. Until you convince me otherwise, I see little point continuing this discussion.

Regards,
Galapo.

Ps. To prove my point, to overcome your problem, set Fundamentals script settings drive to systemdrive, build CreateISO with fbwf, you don't get modelram.exe being created with CreateISO. Nothing changed with CreateISO and yet modelram.exe is not created! Therefore, modelram.exe is something to do with another script!

[MedEvil]

I see little point continuing this discussion.

Dito.

[Galapo]

@MedEvil
Note that if you want to go with the PostConfigEx idea, that this will introduce an incompatibility with using WimPack. WimPack is currently run from %PreISOScript% and when used with BootSDI, this can only currently be run after BootSDI has performed some particular operations. WimBoot will also encounter issues. Now, nativeEx doesn't make use of either WimPack or WimBoot, so it doesn't really matter for that project if %PreISOScript% is run before any finalise scripts rather than during one of them. But for projects that do, then this cannot yet be adopted until someone has the time to carefully write a PostConfigEx script which works with such builds.

Regards,
Galapo.

[MedEvil]

Thanks for the warning, Galapo.
Interesting problem. Didn't knew it existed.

BootSDI and WimBoot work both fine without %PreISOScript%, if i use for test a prebuild NaughtyPE (CreateISO)

[Flyboarder]

Sorry for the post if everyone is considering this thread dead.

I have to agree with wonko:

In other words we have some issues that can be attributed mainly to:

• "poor" coding
  
• "poor" GUI design
  
• "poor" integration/assembly of single .script in projects
  
• "poor" mantaining of the .script or project

(no offence intended to any of the good .script or project developers, of course , everyone does his best to contribute)

The "usual" remedies for the above problems are:

• set coding "standards"
  
• set GUI design "standards"
  
• solved by the above two
  
• more time and resources dedicated

I do believe that coding standards need to be created but done so by the project maintainers. If winbuilder becomes to strict it will take away from what it allows us to do.

GUI design also needs to be addressed, please check out ScriptBuilder, this was my attempt to solve GUI standards for ShadowPE.

Agreed, the third point can be solved by the first two. But only if the first two are done well!

The final point is the most difficult to achieve. For the members who were following ShadowPE, you may remember when the site randomly went down, I simply didn't have the extra money to run the site so I closed it, I would love to open up a site for the project when I have the money for it.

I had a similar rant to this one with the other developer of ShadowPE over a year ago. That's why him and I started shadowPE.
Most (NOT ALL) projects have a spaghetti code. Most need to be completely rewritten to solve these issues as changes in the scripts seem to be hacked together.


Just my 2 cents

[pscEx]

Most (NOT ALL) projects have a spaghetti code. Most need to be completely rewritten to solve these issues as changes in the scripts seem to be hacked together.


Just my 2 cents

Currenty your 2 cents have a value of less than 0,5 cent

In our forum many script / project authors publish their "babies".

And a general ranting against "most" of them is just a statement of a complainer.

To come back to a value of 2 cents, you should try to classify in detail what (in your personal opinion) is good and what is bad.

Imagine, that the current projects are used successfully by many users.

Peter

[Flyboarder]

Please forgive my above post, it sounds like I am bashing the scripts/projects which was not my intent. I do recognize that current projects are used successfully, however many scripts realistically should be rewritten in order to fix the poor coding, gui's and add standards. This would force poorly written script to be redesigned. Which may not be a bad thing, and may pave a better path for our projects in the future.

But that is just my 0,5 cents

[pscEx]

Please forgive my above post, it sounds like I am bashing the scripts/projects which was not my intent. I do recognize that current projects are used successfully, however many scripts realistically should be rewritten in order to fix the poor coding, gui's and add standards. This would force poorly written script to be redesigned. Which may not be a bad thing, and may pave a better path for our projects in the future.

But that is just my 0,5 cents

But it really helps if you enumerate a 'bad' scripts list here (Even if it contains some I wrote )

Peter

[Wonko the Sane]

Flyboarder, though I am of course happy you agree with me , this induces me to disagree with you.

While it is well possible that some of the .scripts are written in "spaghetti code", there are several kinds of "code types", first classification:

• non-spaghetti code that is working
  
• spaghetti code that is working
  
• non-spaghetti code that is NOT working , that can be divided into:
  
  • non-spaghetti code that once worked but now it doesn't anymore
    
  • non-spaghetti code that never worked
• spaghetti code that is NOT working , that can be divided into:
  
  • spaghetti code that once worked but now it doesn't anymore
    
  • spaghetti code that never worked

Obviously #1 is what every .script would belong to if this was a perfect world.

I personally have nothing to say about the "spaghetti code" #2, beauty is often in the eye of the beholder and who are we to say that some code is "SPAGHETTI" and NOT "TORTELLINI"?

The ones in #3 and #4 are quite different, first thing, unlike #1 and #2, they are NOT working, but the two subclasses are pretty much different:

#3.2 and #4.2 is quite obviously a loss of time, even talking about it is wasted time.

#3.1 and #4.1 have to be divided in further sub-classes:

• spaghetti code that once worked but now it doesn't anymore BECAUSE the Author used an officially undocumented workaround that by sheer luck did work on the particular version of Winbuilder used at the time
  
• spaghetti code that once worked but now it doesn't anymore BECAUSE the Author used an unofficially documented, but correct at the time, syntax that did work on the particular version of Winbuilder used at the time and was later, by design, removed
  
• spaghetti code that once worked but now it doesn't anymore BECAUSE the Author used a officially documented workaround/syntax that did work on the particular version of Winbuilder used at the time and was later, by design, removed

Now, like in every group of people, there are members that are more talented and some that are more expert, but you cannot expect everyone to be BOTH talented and expert (and thus write ALWAYS "good code").

In order to have Winbuilder .scripts nearing the objective of "good code" we need that all the items in points #3.1 and #4.1, little by little "migrate" into an "upper class".

So now we have to understand the reasons WHY they are currently in a "lower class" and WHAT caused it.

If you follow the above schematics, it is clear that most of the problems come when you sum an unexperienced, but willing , Author with the lack of a clear SYNTAX.

The remaining is due to either a premature (or not well thought about) change of the current working SYNTAX or by lazyness/vanishing of the Author that fails to update/better/make compliant again the .script with the newish version with changed SYNTAX.

Now, what is all in all the scope of going on with the Winbuilder project:

• building a PE? <- NO, we can do this since YEARS, even the first incarnation "batcher", before "openbuilder" created PE's.
  
• building a "better" PE? <- NO, we can do also this since YEARS.
  
• building a "better" PE in an "easier" way, without the need to chase plugins all over the internet, only to find out that they are not updated? YES!

How many .scripts are there around? Let's say a few hundreds, maybe 400? . How many members do we have? Several tens of THOUSANDS.
Even assuming that 90% up to 95% are only one-time-posters and leechers, 5% is still something like 3 of 4 members per .script.
You will concede that out of these at least one could "adopt" a .script - expecially the "simple" ones - and:

• keep it up-to-date
  
• post EXTENSIVE instructions on it's use
  
• make sure it is available AND listed in some sort of "directory"

Now, since I don't think that these people are only made of "selfish bastards", there must be a reason why they don't spend what? one hour per month to do the above....

And the only reason I can find is that something is missing in the organization of the site, in documented SYNTAX and in easy-to-start-with tutorials, besides the lacking of communication in the developing of the "engine".

Sure, they may produce some spaghetti code at first attempts, and maybe also at second and third attempt, but it will be WORKING spaghetti code , and little by little the code will be every time a little less "spaghetti like" and a lot more "proper code like", and this wil possibly better the name of Winbuilder, which may attract more members and from them a small percentage will learn to write a .script, and then a better written .script .....

Nothing against "spaghetti code", lot's about "no-code" and "no easy way" to learn how to write it, spaghetti or not, as long as it is working, it is findable, it is easy to run/build with, but we need to help these willing members.


Wonko

[MedEvil]

I don't think that the lack of support for the community is due to bad or unclear syntax.

Let's just look at the way easy job of reporting found issues. There is nothing hard or complicated about noticing and reporting.
Yet, project maintainers fix more issues without someone reporting them, than with.