23 replies to this topic

[Lancelot]

previous topic
http://www.boot-land...showtopic=10199
was closed (and I recently replied but now deleted them with not knowing why it is closed ??!!!! no explanation anywhere ?????).

here are my 2 replies (2nd written first here). 2nd reply includes a question in the end.

***

See here:
http://www.boot-land...?...ost&p=71514

Please look more closely to the link you pointed

When testing Alberich, I found an issue in the (older) DIPE version modified by Alberich.

%HKLM%=RegWrite,"HKLM"
%HKCU%=RegWrite,"HKLM"

For Macro definitions the percent is not allowed.

Since WB 076 lines like

%HKCU%,0x4,"WB-default\Software\Microsoft\Windows\CurrentVersion\Applets\SysTray","HotPlugFlags","2"

are not processed.

and the codes I wrote on my previous post:

[Variables]
testvar=Run,%ScriptFile%,test

(Some markup changed by me to point to important locations)

For Macro definitions the percent is not allowed.

I did not define macro with percent like in the example of Alberich (or like some of thunn's scripts).

Anyway, I learn another thing now, macros can not be defined with setting variables during process. I need another day to rewrite my scripts from begining. I am lucky, I wrote scripts recently and it requires only 1 day to fix working scripts to work further for today. If I was writing scripts with using that method for a long while, it would be a nightmare, but it is not. For me case closed.



------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------


***

[*]All users are happy because they now can use WB 078 SP6 as 'LiveXP official version' rather than WB 077 RC2.

I guess you mean next release and if there is no other "unexpected" changes. (unexpected by the script authors). Currently wb078sp6 can not be adviced by me to any new users since it has download bug and I still do not know what will be (if there will be !?) log warnings on next release.

[*]Lancelot is happy because he saved many hours by not writing correct syntax into 3 LiveXP scripts and replace commas by the escape #$c.

I am always a happy man, but I am not happy to see you writing things without reading my posts or replying my questions or concerns. Please check my posts at current and previous topics to see what I've done with these 3 scripts and my concerns about the subject (not the scripts). Well I know you will not do a check on that way, and probably will try to keep mocking with some unrelevant bases.

What would make me (and I guess other none delphi coder script authors) happy is having "trustable" and "logical" script writing rules to follow.

Since you've made some changes, it will be nice to have a new wbtrash to make tests to see what are the rules NOW to follow.
Can we have a fresh trash ????

[Wonko the Sane]

...and I thought there were limits about beating dead horses....



Wonko

[Brito]

This is actually one of the reasons why only stable versions should be used in production projects..

This way you only need to worry about the next stable that are released once or sometimes twice per year instead of being afraid of these volatile beta/SP versions.

[MedEvil]

Stable versions?
I don't think, we ever had anything, that could be named stable, in the original meaning of the label.
No, stable, Beta, RC, SP, those are all just names around here, without any meaning.

RC means usually a feature freeze and that only bugs get fixed. This goes double for SP.
So how can a SP sport new problems?

While using LiveXP recently for finding a problem a user had with NaughtyPE, i stumbled across a script, which had a 3 digit version number!
How can there be over 100 errors in a single script and why the heck get they fixed on by one?

The problem imo is as usual the community itself. There is no appreciation for stable here. Just for new!

[Lancelot]

This is actually one of the reasons why only stable versions should be used in production projects..

Hi Nuno,
I guess we passed that point long while ago. (Related to this, reminding there was also some discussion topics about how stable versions should be released)
Theorically you are right,
But the living truth is:
"Stable version is the version that works without critical errors."
Here is the short story for the proof:
As far as I remember wb078 had critical errors which avoids us to use in the project, and capi improvements forced us to get to use up to wb077rc2. (I guess wb078 never be a long time release for any project). And up all wb078 versions (which are called stable) are not suitable for livexp. For now we can say wb078sp6 is the only working wb078 for building LiveXP but download mechanism fails to update the project. I do not want a new user to struggle with the issues of a new wb version so I stay on the safe side for now.

ps: To make livexp work with new wb078 series (where all scripts written correctly) I made tons of tests to find out a reproducable way (small zip packages) for psc. I do not know or understand the details, but some changes made on wb codes cause deathly fails. After a long chase for weeks, some fixes starting from wb078sp4_rev2 to wb078sp6 releases at last scripts working. Lots of time spend by me to find reproducable ways and more time by psc to find what is hapening with debugger. No changes made on relevant scripts, and now we can say 078sp6 is working like wb077rc2 (or previous) releases. I leave conclusions from this good story to you.

ps: I've always make tests with any new wb release which always resulted with a critical or disturbing bug of wb, not script. To clear any misunderstandings, I have a great desire to update wb version which result me reporting lots of things quickly. I guess psc knows this too but I guess others do not.



Maybe you understand the topic reason wrong since it is a bit long topic (ehm, current one is the continue topic).


Here is a short summary version of what've been going on for a long while:
psc made lots of improvements on wb to make it work faster and having lots of new features.
Everybody happy with new features, speed improvement comments may change, here is mine:

At one point, psc started to clear rules for the script usage, this caused old projects (wb074 and even wb076 based projects which are prepared with stable releases) failure during build.
**For me, since usage became more clear and since old wrong syntax usage throw an error on log, I've fully support new releases with clear rules and made changes through all scripts when introduced. I could easly spend some days to fix lots of scripts and live happly with faster wb process and with having more clearance what is wrong and right about script writing.

After these improvements finished, I see psc start to work on variable-comma usage,
First step
psc encourage people to use esc charecters (#$c , #$s ...) instead of double quotes, leaving decision to user and he updates his nativeex projects removing lots of double quotes to process faster.
Since this decision left to the end user, I like the idea and removed many double quotes on many scripts but not like psc, I also keep some double quotes to have readbility. Scripts process faster, I am happy.

Second step,
psc start to work on variable-comma usage more deeply, and I guess (without being a delphi coder) he think making some new rules with removing some loops in code (these are probably there to increase flexibility and to suit common sense usage with double quotes) will make wb faster.

This second step has 2 bad side effects which I tried to explain on topics.
1) It does not fit common sense on some cases. (found 1st by JFX and than continued with 2nd ...). This cause error on script since script was working with all stable releases but not the latest one and first look to script does not show anything wrong with syntax.
2) Currently wb078sp6 do not throw a warning or error for some cases (which were working untill now with stable releases).psc wrote he fixed this and I asked a trash version to test but no response from psc yet. Currently I can not advice any user for any project to use wb078sp6 for now because there will be no warning or error on log for these cases (where undefault options of project or individual active apps scripts used) for now with wb078sp6.


ps: things did not happen at that order chronologicaly and these are not all summary, but the essential points about the current subject. I wrote this way to increase understanding.


btw, some people understand my posts with wrong perpective.
Before writing on topics I had a day conversation with psc about my concerns. I already made the required found* updates 4 or 5 days ago and psc knows this. psc opened a topic here (not me) and the topic also proved some of our advanced script authors reacted the way I tried to explain with my concerns.

Anyway, I feel these topics are good since it somehow clears the script writing methods with NEW versions of wb.
By the help of these topics, I feel all our advanced script authors (and an intermediate user me) will quickly check the codes discussed on topics with new version of wb either officially or trashly published. (I asked for a new trash for that reason). That is the reason horse is alive because nobody-1 knows the new results.

[Brito]

Maybe it's time to turn the page and publish a new stable.

What do you and other developers think about this?

[Lancelot]

Maybe it's time to turn the page and publish a new stable.

What do you and other developers think about this?

For me, time is not important anymore. More important is what will be the surprises inside, a trash version maybe nice for tests before deciding the release but this is not very important too.

All up to you.

[sbaeder]

Being relatively new here, but having been involved in software development and release management (among many other "operations" type jobs in complex software), I would tend to agree. There is always a fine line between performance enhancements and backwards compatibility.

If we (as a community) have a large collection of well supported "projects" (i.e. the ones included in WB as web sites by default), it seems to me that for a "release", it should be possible to "assume" that it has been tested against those scripts.

I would also think that we should have clear rules about "beta" (and maybe even "experimental" or development releases) where things could be a bit unstable and not fully tested, Release Candidate builds where as mentioned above the content is assumed to be ready, but needs some last minute bug squashing, Stable Released versions, and then service packs to fix critical bugs.

If we need more people to sign up to be testers, then lets put out a call, and see if we can get some folks (I would be willing as an example) to volunteer.

This is a great community and a great tool! But to be more useful to more people, we need to get a bit more disciplined in the releases...(and/or being clear about acceptable syntax, etc...)

Anyway, that's my $0.02

[amalux]

Just to reiterate what's already been said, the only 'stable' release is the one that turns out to be stable! For a whole host of reasons this is not fully knowable at release time. Practices that can greatly improve 'major' release stability are release candidates, pre-tested by advanced users in known builds. Recently (first time?) I was included as part of a pre test for 078sp6 which passed with flying colors my initial tests, unfortunately, I missed a rather obvious, cosmetic glitch. I'm embarrassed about that but the build is still 'perfect' otherwise and I would love to see that little blemish removed and use it as my next stable release (I may anyway). I don't think it's fully appreciated (by some) how rare these near perfect gems are; in recent memory there have been only 3 that I am aware of, 076hf (not official title, released as a 'hotfix' immediately following the official 076 release), 077rc2 and now 078sp6. I'm hoping the next release (sp7? 079?) will not be back to 'unusable' status for me, time will tell. I'm not about pointing fingers or complaining for the sake of argument, I'm sure everyone involved wants the same positive outcome for this wonderful, one of a kind product that so many have worked so hard (in there own ways) to improve. I also don't think many advanced users and developers remember the devastating effect of downloading a first project with high expectations, only to have that project crash with incomprehensible errors or just poor pre-configuration, leading to disappointment and annoyance. Many, at this point will simply not bother with further testing, thinking 'winbuillder not ready for prime time'; this is unacceptable for what, we know, is the Cadillac (Rolls-Royce?), state of the art boot disk builder!

It would be nice to see some simple, strait forward guidelines for pre-testing, release candidates tested by a group of advanced users (and maybe not so advanced) to get input. This has to be done in a formal way i.e. the way I was asked by Peter (at Lancelot's request), I really felt (for the first time) someone wanted my input. Maybe a simple checklist of what to look for, known (fixed) issues, new functions etc. This has to be kept really basic but thorough; if too stringent or complicated it won't work but if left to happenstance, the process tends towards chaos. I'm all for helping out any way I can but when it seems things are not heading towards a common goal, I tend to withdraw and work on 'my own stuff'; hopefully we can get together on improving this great resource. Let me know how I can help

[pscEx]

Can we have a fresh trash ????

Since some minutes you have it!

Peter

[Lancelot]

Since some minutes you have it!

Peter

Thanks Peter, since 10 seconds I got it

[Lancelot]

from history:

changed - RegWrite 0x1 tolerates syntax error (comma in string rather than escape)

but
tolerating tests by using codes provided by Galapo do not fit the expectation !? Here is the quote, please test.

Here's my opinion.

I would like this to throw an error since the use of commas in the variable %DisplayNameForWBSoftware% would make more parameters than what 0x1 tollerates:

Set,%DisplayNameForWBSoftware%,"test4,5"

RegHiveLoad,WB-Software,%target_sys%\config\software

RegWrite,HKLM,0x1,WB-Software\PSC,DisplayName,%DisplayNameForWBSoftware%

RegHiveUnLoad,WB-Software

I would like this to write test4,5 sucessfully because by the use of quotation WB is told that %DisplayNameForWBSoftware% is a single parameter (not a variable potentially consisting of more than one comma-separated parameter as in the example above):

Set,%DisplayNameForWBSoftware%,"test4,5"

RegHiveLoad,WB-Software,%target_sys%\config\software

RegWrite,HKLM,0x1,WB-Software\PSC,DisplayName,"%DisplayNameForWBSoftware%"

RegHiveUnLoad,WB-Software

With WB working in this way, the following would then be possible, which would write two value entries beneath the 0x7 key:

Set,%DisplayNameForWBSoftware%,"test4,5"

RegHiveLoad,WB-Software,%target_sys%\config\software

RegWrite,HKLM,0x7,WB-Software\PSC,DisplayName,%DisplayNameForWBSoftware%

RegHiveUnLoad,WB-Software

and this would write only one value entry beneath the 0x7 key:

Set,%DisplayNameForWBSoftware%,"test4,5"

RegHiveLoad,WB-Software,%target_sys%\config\software

RegWrite,HKLM,0x7,WB-Software\PSC,DisplayName,"%DisplayNameForWBSoftware%"

RegHiveUnLoad,WB-Software

Regards,
Galapo.

[pscEx]

For Macro definitions the percent is not allowed.

...

I did not define macro with percent like in the example of Alberich (or like some of thunn's scripts).

Just to explain for the record: You did!

%addfile%,test

The first word of a script command line is

• either a known command
• or a macro call which is substituted by something.
  The 'something' is defined in a [Variables] section and starts with a valid WB command.

And in the case of a macro call %addfile% is forbidden.

I think that I should add this to the WB manual.

Peter

[Brito]

Thank you Lancelot, sbaeder andamalux. Your thoughts on the matter are valid and very useful.

I guess that a few simple guidelines and organization might help everyone to understand what is going on

As mentioned, a plan for testing doesn't need to be strict or complex, just something that we can really use and perhaps put an end to those bugs that nobody likes.

I will talk with Peter and we can also try to devise a plan for 2010. If there is a good time for planning is January as we'll have the rest of the year in front of us and will give him less headaches to worry about.

This should hopefully ease the decision of using a "stable" (sorry if no better word found to describe it) winbuilder.exe that brings all the functionality that you need for the next 5 months.

Would this be ok with you guys?

[Lancelot]

And in the case of a macro call %addfile% is forbidden.

I think that I should add this to the WB manual.

Peter

I %100 agree to something like this on WB manual will be helpful,
"Macro definitions and Marco calls are forbidden."
(and by giving some small examples if possible)

put an end to those bugs that nobody likes.

I believe "important bug" train will end in year 2010 (and maybe within some weeks-months) as a result of great efforts of Peter.

we'll have the rest of the year in front of us and will give him less headaches to worry about.

Another good news, I will mostly not be around in 2010 to give headaches too

[pscEx]

tolerating tests by using codes provided by Galapo do not fit the expectation !? Here is the quote, please test.

I understood Galapo's intention.
But I have the difficulty that

• 'Tolerate' are just two additional lines of code which do not affect anything else and allow only the sample code you provided.
• Implementing Galapo's suggestion demands several code changes, which might affect other functionality.

Remember the 'RegWrite multiple strings' issue which has been fixed in WB 078 SP2.

fixed - RegWrite multiple strings with comma in argument

I'm very sure that this caused the issue which brought the discussion here.

Please allow me, in a SP make 'few lines changes' ONLY.

Peter

[Lancelot]

in a SP make 'few lines changes' ONLY.

I understand
For the future releases, I put a bug report (Bug ID 240) to remind.
With other words, for now all horses are death. Lets get the release to play with

[pscEx]

Peter

[Wonko the Sane]

With other words, for now all horses are death.

May they R.I.P.

Very unfortunate for the poor beasts but they have ended their sufference this way and so it's after all GOOD news: we should all rejoice.



Wonko

P.S.: I had to think a lot on how to write the above sentence without having parsing problems.
Just for the record, the original was:

Which is very unfortunate for the poor beasts, though they have thus ended their sufference, so that it's, after all, GOOD news and we should all rejoice.

or if you prefer:

Which is very unfortunate for the poor beasts#$c though they have thus ended their sufference#$c so that it's#$c after all#$c GOOD news and we should all rejoice.

[pscEx]

The second sentence is the ONLY right one!

Peter

[amalux]

Since some minutes you have it!

Peter

Will this be available to others?

[pscEx]

Will this be available to others?

Short answer: YES
Medium answer: If you have read ALL of my posts: YES
Full answer: I assume that you did not read ALL of my posts. So look into your PMs!

Peter

[sbaeder]

Would this be ok with you guys?

Sure thing! I fully support Peter's efforts here, and agree that in an SP, we should be looking for small changes to fix errors, and leave the major development for the next version number...
By working together, we can do wonderful things!

[pscEx]

Now we have the first big advantage:

The HoJoPE generated line

RegWrite,HKLM,"0x1","WB-Software\Microsoft\Cryptography\Defaults\Provider\Microsoft RSA SChannel Cryptographic Provider","0x00000000"

is senceless and may depend on a bug in hivesft.inf (Also Billy the Door sometimes makes mistakes).

Right now it has been skipped silently. Now the hive factory script aborts the build with an error message.

I have to deliver a new HoJoPE.exe ...

Peter