76 replies to this topic

[larioteo]

To verify the os architecture a autoit script is not needet that i mean, i takes a little bit of time to execute the workaround...

There are many scripts that do so, and every time they search for the architecture, which costs time...

Edited by Darijo, 18 May 2011 - 12:43 PM.

[ChrisR]

If you change your posts after a reply, the reply does not mean anything.

Why are you trying so hard, to found what is not well done for you, You must be right

[Brito]

I give up. Apparently a perfect PE to most, depends on the right names for scripts and variables and pretty code, while the project does not necessarly needs to create a useable PE, it seems.

Complexity always grows to a point where allowing "ugly" code and wrong names stalls development. On the current situation, we don't have pretty code, we don't have right names, we don't even have a result than can be called usable.

Some seem to enjoy and defend this situation, but I am quite sure that you don't like it as well.

Why do you think, there are batch and Autoit scripts used in some of the scripts?
Wimb even abandoned WB all together.

There are many features that should not be provided by WinBuilder. After so many years whinning for advanced scripting, by now we should have had enough features to make everyone happy. But look how difficult it is for a single person to upgrade the engine or project to a more recent version..

The same apply for Wimb's work. He coded his own tool and matches his own expectations: fine. We are creating a tool to match the expectations of many people and we are also aware that wb should not be a shoe aiming to fit everyone's feet. Trying to bulk too much functionality is what got us in the mess at the first place.

My apologies. I am very picky about keeping the code simple/readable for others to build upon, and I would like to see more people following this practice.

[homes32]

Unpack is useful, that was the reason why I have created it: http://goo.gl/mC4k4

If you use 30 lines of code to replace the use of unpack, then something is definitively wrong. I would also prefer 30 lines of code that I can read, than one single line code that is plain hieroglyphs to me..

That is also one of the reasons why each command should be kept as simple as possible, cramming up too much functionality per each command makes life harder on everyone.

I was referring to the expanded unpack pedrole15 wrote that adds download/unpack
consider a real-life example:
the following code is from my BlueScreenView script v1
not 30 lines but in the 20's and quite simple.

[Download]

If,NotExistDir,%GlobalTemplates%\%ProgramFolder%,DirMake,%GlobalTemplates%\%ProgramFolder%

Echo,"Downloading %ProgramTitle%..."

WebGet,%DownloadURL%,"%GlobalTemplates%\%ProgramFolder%\%ProgramTitle%.zip"

If,ExistFile,"%GlobalTemplates%\%ProgramFolder%\%ProgramTitle%.zip",Begin

Run,%ScriptFile%,Unpack

Else,Begin

// something didn't work.

DirDelete,%GlobalTemplates%\%ProgramFolder%

DirDelete,%Target_Prog%\%ProgramFolder%

Exit,"Failed downloading %ProgramTitle%!!"

End

End



[Unpack]

Echo,"Processing files..."

ShellExecute,Hide,#$q%Tools%\7z.exe#$q,"x -y #$q%GlobalTemplates%\%ProgramFolder%\%ProgramTitle%.zip#$q -o#$q%GlobalTemplates%\%ProgramFolder%\#$q"

If,ExistFile,%GlobalTemplates%\%ProgramFolder%\%ProgramEXE%,Begin

FileDelete,"%GlobalTemplates%\%ProgramFolder%\%ProgramTitle%.zip"

Else,Begin

Exit,"Failed to unpack %ProgramTitle%!!"

End

End

with CAPI the same job can be done with just 3 lines of code

If,NotExistDir,%GlobalTemplates%\%ProgramFolder%,DirMake,%GlobalTemplates%\%ProgramFolder%

Echo,"Downloading %ProgramTitle%..."

// common api download/unpack

Unpack,%DownloadURL%,URL,%GlobalTemplates%\%ProgramFolder%,%GlobalTemplates%\%ProgramFolder%

if I was a new/inexperienced app script developer I know which method I would choose...

Coding app scripts became a complex task without reason to be that way. The simpler an app script is, the more odds for survival in the future. You are now enjoying what we have been defending since a long time.

If there wasn't so much flexibility on winbuilder and respective API, I am sure that the end user results would be better. Many people would complain but they would follow a standard path to create projects and scripts that could be improved and reused by others.

So, everyone complains that user experience is bad and we are aware of this fact but have no way of making developers follow standards or even rules that they don't "like".

most app scripts I have seen are simple, you are familiar with my work and know that my app scripts are kept as simple as possible as well, however some of the apps are not so simple and require services, extensive registration, dependencies, etc. that must be considered. this all adds to the work the app script must do if the program is to so much as start in PE. Also adding to complexity is the effort to avoid encoding (often large and/or frequently updated) applications into the app script itself. the apps are download from the programs website and must be unpacked from the installer, often containing x86/x64 specific files which must then be sorted out depending on the architecture of the PE being built. see my wireshark/winpcap script for a good example of this.

Yes a script should be seperate developed and not bindet on others this would it make much easier for the developer of the script itselves, if something doesn't work as expected he could improve his code on his own, and have not to wait, the bugs are fixed in the capi.

nobody is forcing anyone to use the api. most do because it IS easier than writing redundant code. if something doesn't work as you need/expect either fix the problem or do what you do when coding C++ or any other language. hook the api and write your own handler. use only the functions that you need and write your own code to do the rest. simple.

And yes the winbuilder naming of scripts is terrible, 1- ... 3- .. 9- ... as filename no problem but why in the WinBuilder, makes this not as easier as it is, when i read 1-50_optimizations i have no idea what the dev menat with this, than under that comes 3-postconfig and 4-iso where is the 2-?? or the build has no default shell integrated some parts are splittet in seperate scripts that are still important for a fine running pe.

I see you did not take my advice and spend time learning why things are done the way they are.
the numbers in from of the scripts are essential to make the scripts run in the correct order (winbuilder processes scripts in numaric-alpha order withen the level assigned). it wouldn't do to create the ISO before the final configuration of the build is done now would it???
the build has a default shell. its called Explorer, which is exactly what Microsoft named it.

I give up. Apparently a perfect PE to most, depends on the right names for scripts and variables and pretty code, while the project does not necessarly needs to create a useable PE, it seems.

@Darijo
Do me the favour and just write a bunch of scripts or, if you prefer, have a private discussion with Nuno, about how things work in WinBuilder. At the moment a lot of your comments show, that you have no real idea about imposed limitations.

Why do you think, there are batch and Autoit scripts used in some of the scripts?
Wimb even abandoned WB all together.

THANK YOU!

So i give you one example why everything has no sense in this way. Maybe you understand me yet, i was thinking you are a good Developer.

Is it not easier, to use the Variable that is built in Winbuilder? Or are you only talking here to protect the developer "lancelot"? I see no sense in your postings.

The PreConfig Script checks the Local OS Architecture with an external Autoit Script, that is on the fly created, and that generates an Ini-File, where than at least WinBuilder reads the Variable. You think WinBuilder can't do that, no it can do that since 077RC2 or even more, i have started trying the WinBuilder since this Version and this possibility was there.

you are wrong. the preconfg script uses an autoit script to detect the source CD language. the last time I checked Winbuilder can't do a While loop and the alternative was to write about 80 lines of
If,ExistFile,%BootSRC%\Windows\System32\<somelanguage>\bcdedit.exe.mui,Set,%DistLang%,<somelanguage>
which is not efficient in at all.

No of course not, for you not, but for an starter sure, i cannot believe it that it take days to remove all unaccessary stuff from the scripts, it is to much that is no needed.

then remove it and let us know how your build turns out...
I believe you will find there is much you do not know about why a script is written the way it is. there is always room for improvements but you cannot jump headfirst into a new language and expect to rewrite an operating system right off the bat. nor do you go in and tell the developers they should have used the std: c library instead of a more flexible and robust alternative. ,you must first learn the ins and outs of the tools and the language used, their quirks, bugs, history, etc. before you will have any success.

Complexity always grows to a point where allowing "ugly" code and wrong names stalls development. On the current situation, we don't have pretty code, we don't have right names, we don't even have a result than can be called usable.

Some seem to enjoy and defend this situation, but I am quite sure that you don't like it as well.

There are many features that should not be provided by WinBuilder. After so many years whinning for advanced scripting, by now we should have had enough features to make everyone happy. But look how difficult it is for a single person to upgrade the engine or project to a more recent version..

The same apply for Wimb's work. He coded his own tool and matches his own expectations: fine. We are creating a tool to match the expectations of many people and we are also aware that wb should not be a shoe aiming to fit everyone's feet. Trying to bulk too much functionality is what got us in the mess at the first place.

My apologies. I am very picky about keeping the code simple/readable for others to build upon, and I would like to see more people following this practice.

I really don't believe that the name of the api has anything to do with anything. call it the super-duper-multi-project-api for all I care. it won't make any more difference than calling a horse an equine.

Do we really need to keep going over this every couple of months? It has already been pointed out many times, with examples that the API code "mess" and "hieroglyphics" as you so artfully put it is due to winbuilders syntax and feature set. it was not our choice to call parameters #1 #2 #3 etc. or to require messy escape chars such as #$c #$s #$p all over the place. these are all rules enforced by winbuilder. it is also not by developers choice that many lines of StringFormat,Split or StringFormat,Trim, PackParam, etc. are needed to isolate components in a commandline/parameter/string. winbuilder does not provide a way to read these into a nice clean array. I'm not saying winbuilder should go adding all the features of a full blown programming language, I am saying that the winbuilder language is unsuitable for high level programing, making a job requiring few lines of simple clean code in another language into 10 lines of "messy code" to achieve the same result in wb script. Being picky about code readability is fine. I am quite particular about my code formatting/commenting/etc and can understand that. but one must also be realistic in their views considering the capabilities of the language.

[MedEvil]

@Nuno
I have always been one, who puts functionality above all else.
If i had the choice, between a well documented easy to read program, which is sluggish and resource hungry, and one that's not documented at all and writen in the most obfuscated code, but perfrorms snappy and uses barely any resources.
I would choose the second and complain about the first.

btw. Remember i tryed twice, once alone and once with Peter, to convince people to write scripts acording to a guideline we published. To this day, noone but the creators, ever complied with it.

@Darijo
If you read here since a year, you should know by now, that i would never defend Lancelot, unless he really 110% deserves it. Besides, i didn't knew, that you were talking about him.
Else it seems, that you just can't believe that the developers had good reasons to do what they did, no matter, how many devs are telling you so.
So i stop aggravating you and wait, till you see the light, on your own.

[pscEx]

you are wrong. the preconfg script uses an autoit script to detect the source CD language. the last time I checked Winbuilder can't do a While loop and the alternative was to write about 80 lines of
If,ExistFile,%BootSRC%\Windows\System32\<somelanguage>\bcdedit.exe.mui,Set,%DistLang%,<somelanguage>
which is not efficient in at all.

Here a bit of creativity is missing.

WinBuilder can leave a loop. That is logically the same as a While statement.

If,<some condition>,Loop,BREAK

Peter

[pscEx]

BTW:
One sample of exiting a loop (from my Speccy.Script):

[variables]

...

%LangList%="1031,1033,1034,1036,1037,1038,1040,1041,1045,1049,1051,1052,1053,1055,1059,1066,1067,1079,2070"

%LocaleList%="00000407,00000409,0000040A,0000040C,0000040D,0000040E,00000410,00000411,00000415,00000419,0000051B,0000041C,0000041D,0000041F,00000423,0000042A,0000042B,00000437,00000816"

%IDList%="de-de,en-us,es-es,fr-fr,he,hu,it-it,ja,pl,ru,lv,sq,sv-se,tr,be,vi,hy,lv,pt-pt"

...



[SetLanguage]

Set,%LangDLL%,

If,EXISTVAR,%SourceLocale%,Run,%ScriptFile%,Find,%LocaleList%,%SourceLocale%,OUT:%LangDLL%

Else,If,EXISTVAR,%DistLang%,Run,%ScriptFile%,Find,%IDList%,%DistLang%,OUT:%LangDLL%

If,%LangDLL%,EQUAL,,Set,%LangDLL%,1033

ExtractFile,%ScriptFile%,Language,lang-%LangDLL%.dll,%Target_Prog%\%ProgramFolder%\lang



[Find]

Set,%ftmp%,

StrFormat,SPLIT,#1,#$c,0,%Num%

Loop,%ScriptFile%,Loop,1,%Num%,#1,#2

Set,#3,%ftmp%



[Loop]

StrFormat,SPLIT,#1,#$c,#c,%Item%

If,%Item%,EQUAL,#2,Begin

StrFormat,SPLIT,%LangList%,#$c,#c,%ftmp%

Loop,BREAK

End

Peter

[homes32]

BTW:
One sample of exiting a loop (from my Speccy.Script):

[variables]

...

%LangList%="1031,1033,1034,1036,1037,1038,1040,1041,1045,1049,1051,1052,1053,1055,1059,1066,1067,1079,2070"

%LocaleList%="00000407,00000409,0000040A,0000040C,0000040D,0000040E,00000410,00000411,00000415,00000419,0000051B,0000041C,0000041D,0000041F,00000423,0000042A,0000042B,00000437,00000816"

%IDList%="de-de,en-us,es-es,fr-fr,he,hu,it-it,ja,pl,ru,lv,sq,sv-se,tr,be,vi,hy,lv,pt-pt"

...



[SetLanguage]

Set,%LangDLL%,

If,EXISTVAR,%SourceLocale%,Run,%ScriptFile%,Find,%LocaleList%,%SourceLocale%,OUT:%LangDLL%

Else,If,EXISTVAR,%DistLang%,Run,%ScriptFile%,Find,%IDList%,%DistLang%,OUT:%LangDLL%

If,%LangDLL%,EQUAL,,Set,%LangDLL%,1033

ExtractFile,%ScriptFile%,Language,lang-%LangDLL%.dll,%Target_Prog%\%ProgramFolder%\lang



[Find]

Set,%ftmp%,

StrFormat,SPLIT,#1,#$c,0,%Num%

Loop,%ScriptFile%,Loop,1,%Num%,#1,#2

Set,#3,%ftmp%



[Loop]

StrFormat,SPLIT,#1,#$c,#c,%Item%

If,%Item%,EQUAL,#2,Begin

StrFormat,SPLIT,%LangList%,#$c,#c,%ftmp%

Loop,BREAK

End

Peter

thats a good example. thank you.
in any case the method in question was depreciated a while back and is only used if you check a box on the script interface called Detect Source DVD Language OLD School which is disabled by default. I don't know why the option was left as I generally don't have anything to do with the multi-language coding.
sometimes old code is left inside the script as documentation or because it has the potential to be useful to someone. sometimes its in case the new method does not work as expected it can be quickly reverted to. if this is the case it sometimes gets forgotten about.

[Brito]

My friends, everything is fine. It is ok to have divergent opinions.

The only thing that I ask is that everyone expresses their point of view and doubts. After all, we are also here to learn with each others.


Working together, I believe that we can really do a progress that benefits everyone involved. We should really discuss the state of the art as often as possible. Asking ourselves if other approaches are better or not for future and current codings is a good way to evaluate if we are on the right track or not.

Raising awareness to problems, helps developers understanding concerns about reducing script complexity and the value of reusing their scripts in other projects.

In our community, developers are free to adopt whichever ways of doing whatever and this won't change.

[larioteo]

@Nuno yes you are right, i am thinking also, but the others think i am only a bloody beginner, that don't even knows anything about building a pe.

@ChrisR i never said someting against you!?

It seems that every body protects Lancelot here, he could made some things good at the past, but nowadays he only comes here to say that psc is lying about everything he says, and that is the wrong way, isn't it?

Thank you medievil your are one of the most friendly persons here, saying that i am a bad developer cause i am trying to read such sh... as the capi and understand it, was the wrong way. I will give up you have won, make it better...

Edited by Darijo, 18 May 2011 - 05:20 PM.

[pscEx]

(Hi psc. F@ck off! LOL!)
Good luck, Nuno! Breathe deeply!

Thanks, Allanf, for your hint.
The "F@ck off" link is no longer available.

Peter

[pscEx]

Oops! Link updated. Send me a note.

Here the note: The current original WinBuilder betas are deleted from my f@cked off (or following your edit: --F.ck_Off) server. Maybe anywhere in the world there are copies.

[larioteo]

This even helps nobody, we will get and other wil just . OK?

Where to start?

So let us talk about the past. What happened here that the best developers, that creates PE's for every one happened. It is time to bury the hatchet (Kriegsbein begraben). Or should we concentrate in someone here?

I mean only a stupid user don't know what is here going behind the szenes, but we here discuessing what is gone wrong in the past and today, what could be made better?

Has anyone else some ideas and not only the defeating of coexisting scripts?
It is a lot of work for one person but if there more than one and a strict guideline the project would grow in nearly a month to the first stable.

[sbaeder]

Unfortunately a lot of this is the SAME OLD STORY !!!

Yes, the API /CAPI has some issues and could be better DOCUMENTED (both internally and for people to know how to use it)

That shouldn't be too hard, but it also need an OWNER (or at least a driver). Linux wouldn't have been a success if it wasn't for Linus (and now, a SMALL handful of people) reviewing and APPROVING everything that goes into it.

We had this discussion a year ago as well, and not much progress since then. But the bottom line is the current and active projects are doing OK...(at least INMSHO)...

The issue is where do we go from here - both with the TOOL, the PROJECTS, the APP scripts and the glue that holds them all together.

Scott

[Brito]

Should the API/CAPI be completely re-written (or abandoned all together)!? Years of hard work down the drain? That is the question.

Hi Allan,

If you note well, winbuilder.exe was left untouched for over a year and the current version in beta is focusing intensively on avoiding any previous work from getting wrecked: http://reboot.pro/14477/

Let's just focus our efforts in improvements that are at our reach right now, and this is a good example: http://reboot.pro/14538/

[paraglider]

Don't why people continue to say the capi is not documented. I have spent a lot of effort to document it in the winbuilder help chm ( http://wb.paraglider...m/winbuilder.7z ) and online at wb.paraglidernc.com/help

Function naming is inconsistant in the CAPI. It also appears recently to be going in a strange direction - single descriptive function names are being replaced with a generic function name with the first parameter selecting the function so now you have scriptinterface,write instead of a descriptive function name writeinterface.

[Brito]

I have spent a lot of effort to document it in the winbuilder help

Very good effort, the online version is handy and an enjoyable reading as well.

Found a minor typo at http://wb.paraglider...ister_File.html on the part "It will use an etry in". Perhaps a new topic should be made available for other people to also report any minor typos that they encounter?

Don't why people continue to say the capi is not documented.

Yep, I know what you mean. I've created a pinned topic at the "Developer notes" forum section to help raise awareness for the existence of this documentation: http://reboot.pro/14542/

Nevertheless all this, I still have serious concerns about some of the proposed commands and the packing of too much functionality on each, instead of keeping them simple.

[larioteo]

@allanf, yes it should be the very first thing, nothing...

@paraglider, as i see lancelot removed your button for the help because he said it is yours and he hadn't the update yet in the new version, that i read on this suspect gena site, The Oven Cookers, i think everybody knows this site.

Why he don't left the new one? I have no idea, i have read it, and that is it for me.

And why isn't it includet as default, without online stuff?

[paraglider]

I am working on adding the missing functions. It is hard to keep up though.

I believe only functions currently missing are CapiC, Require, RunFrom, Add except for CapiC are no more than renames of the existing single function names so now instead of RunfromRAM, RunFromCD you have RunFrom,RAM and RunFrom,CD etc

CapiC is a strange one - for the most part it seems to duplicate functionality that already exists in the winbuilder api to copy / delete files / folders.

[ChrisR]

@paraglider, as i see lancelot removed your button for the help because he said it is yours and he hadn't the update yet in the new version, ........ the rest is not useful
.
And why isn't it includet as default, without online stuff?

Without taking part, This is not true, the button "Help by Paraglider is present in Capi script and for Information, it is included in Win7PE package.

I am working on adding the missing functions. It is hard to keep up though.

I do not know much chm files, except that they are constructed from .html pages.
There is also the function Add_Pin that is not integrated in the chm file.
Here the html file of this function, but not with the desired presentation, I think .

Thank you for your work on winbuilder help chm, it is an great help to end user and developer

Attached Files

•  Add_Pin.7z   2.1KB   350 downloads

[homes32]

I am working on adding the missing functions. It is hard to keep up though.

I believe only functions currently missing are CapiC, Require, RunFrom, Add except for CapiC are no more than renames of the existing single function names so now instead of RunfromRAM, RunFromCD you have RunFrom,RAM and RunFrom,CD etc

Personally I have little issues with this approach, as it allows for new features to be added without breaking syntax or creating dozens of new commands every time something needs updated. It also helps standardize a naming convention. Winbuilder uses a similar idea with the StringFormat and Retrieve commands. I would be very interested on hearing other concerns/opinions on this though. I know CAPI naming is not the greatest in some cases.

CapiC is a strange one - for the most part it seems to duplicate functionality that already exists in the winbuilder api to copy / delete files / folders.

CapiC was/is an experimental command stemming from this topic about using an external .exe to process API commands instead of using WB script.

[sbaeder]

I read the second linked thread and must ask if speed is still an issue? I thought it had been improved. To me the idea of blocking comments in a separate section is not a step forward. In-line would be better, especially when giving a quick description for obscure elements such as parameters #1, #2, #3, etc.

I would agree for some limited inline comments, but larger blocks of comments could/should be added to the code to better document it, and for that, blocking them into stuff that can be easily/quickly scanned seems reasonable.

We all need to remember, this is an interpreted system! So even something simple like putting the things used all the time at the top of the file can make a difference...maybe only a few seconds (or fractions of a second) each time the file is parsed, but over time, that can add up on each time we need to add a registry item or shortcut, etc.

But, a real "test" would help clarify!...

Scott

[Lewis]

Why do I get an email from reboot.pro telling me that this is a "hot" topic, then I come here and theres some dude called Wonko and pscEx getting into a war of words over something nothing to do with the PE environment?

Seriously, keyboard warriors, weapons down.

[Wonko the Sane]

Why do I get an email from reboot.pro telling me that this is a "hot" topic, then I come here and theres some dude called Wonko and pscEx getting into a war of words over something nothing to do with the PE environment?

Maybe because you just had a look at the first page of the thread (that was only to warm up the place )?

On following pages you may notice rather interesting discussions (actually related to "engineering a perfect PE", or more precisely on the possible ways to better the way the winbuilder, it's API or CAPI behave/work).

And the topic is "hot".

All in all, you were not completely misled by the email you got which, being an automated setting of the board, appears like having worked as designed.


Wonko

[paraglider]

@ChrisR,

Add_pin is in the chm. Has been for a couple of weeks.