36 replies to this topic

[pscEx]

In current alpha versions there have not been any new concerns / remarks / suggestions / bug reports for more than two weeks.

That seems to be the right time to publish WinBuilder 081 RC1 now.

Download at: http://winbuilder.net/request.php?53

Have fun and success!

Peter

[Galapo]

No success for LiveXP recommended build, I'm afraid. Build is even worse than using 081 alphas. With alphas, project would nearly boot to desktop. With RC1, the project doesn't even generate an ISO!

To me, it seems that the steps towards the new WB stable is like previous WB stable versions -- crucial backwards compatibility is lost once again. This means that for project maintainers another round of script updating (depending on project size, this task can be quite massive) will be necessary in order to support the latest WB.

My appeal: please, please, please introduce backwards compatibility. I for one do not have the time to go through the entire project again updating scripts due to a lack of backwards compatibility by WB. I've lost track of how many times I've had to do this in the past and this time I simply don't have the time to do this. 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.

Thanks,
Galapo.

[pscEx]

No success for LiveXP recommended build, I'm afraid. Build is even worse than using 081 alphas. With alphas, project would nearly boot to desktop. With RC1, the project doesn't even generate an ISO!

To me, it seems that the steps towards the new WB stable is like previous WB stable versions -- crucial backwards compatibility is lost once again. This means that for project maintainers another round of script updating (depending on project size, this task can be quite massive) will be necessary in order to support the latest WB.

My appeal: please, please, please introduce backwards compatibility. I for one do not have the time to go through the entire project again updating scripts due to a lack of backwards compatibility by WB. I've lost track of how many times I've had to do this in the past and this time I simply don't have the time to do this. 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.

Thanks,
Galapo.

Not building the ISO is the result of not allowing PERMANENT change of system constants.
Did you ever try in a compiler source code to change the value of a constant?

I think that I rebuilt the backwards compatibility.

All of your complains about coma, quote and escape are no longer a theme.

Peter

[Galapo]

I think that I rebuilt the backwards compatibility.

No, because if that were the case, then we'd be able to drop the new WB into our projects and have them build correctly. But that is not the case. Therefore, my appeal once again: please can we have the new WB work with the projects we have today without having to go through a script updating process to work with the new WB. I do not think this is an unreasonable request. I doubt others will think that this is not unreasonable also.

Thanks,
Galapo.

[Galapo]

Not building the ISO is the result of not allowing PERMANENT change of system constants.

But %ISOFile% is not a system constant. It is a variable and is listed as such in the WB wand.

I see no gain in changing the behaviour of %ISOFile% to a constant rather than a variable. What is the reasoning for this? It's a significant matter because it breaks backwards compatibility?

Thanks,
Galapo.

[pscEx]

But %ISOFile% is not a system constant. It is a variable and is listed as such in the WB wand.

I see no gain in changing the behaviour of %ISOFile% to a constant rather than a variable. What is the reasoning for this? It's a significant matter because it breaks backwards compatibility?

Thanks,
Galapo.

%Variables% are defined in the [Variables] section(s), or implicitelly by some commands like Set, StrFormat, ...
Constants are defined anywhere else or querioed from the OS environment.

programVars, programConst: TVariablesManager;

  projectVars, projectConst, projectMacros: TVariablesManager;

  scriptVars, interfaceVars, scriptParams, scriptMacros: TVariablesManager;

It is a question of processing speed to make the logical differences.
In every script processing the 'known' variables / constants / macros can be copied and have not to be evaluated again from the files.

To make this 'visible-for-dummy-user', I'm going to separate %Variables% and %Constants% in the magic wand.
(Until magic wand needs a tutorial to be understood ... The advantage would be that we do not need a syntax manual any more )

This code in script.project is the root of ALL troubles LiveXP has with WB 081 and later:

//History57+

//rewriting info from script.project back in case other Create Image scripts used.

IniRead,%ProjectDir%\script.project,Main,ISOfile,%ISOFileInScriptProject%

IniWrite,%ProjectInfo%,Project,BootISO,%ISOFileInScriptProject%

Set,%ISOfile%,%ISOFileInScriptProject%,Permanent

//History57-

Why not simply use %ISOFile% instead of IniRead from a file?
Answer: Because LiveXP creates it's own %ISOFile%

History99=Lancelot new permenant variable IsoFile

Why can a serious programmer use a predefined variable (constant) as variable for his app / script / project ?


About IniRead have a look at http://www.boot-land...?...ost&p=98306

The bug fix about 'multiple IniRead / IniWrite' causes an incompatibility which must be handled by program change.
BTW: You gave a 'Thanks' to that post.

Peter

[Galapo]

%Variables% are defined in the [Variables] section(s), or implicitelly by some commands like Set, StrFormat, ...
Constants are defined anywhere else or querioed from the OS environment.

But even in batch such constants can be over-ridden:

Microsoft Windows XP [Version 5.1.2600]
© Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>echo %windir%
C:\WINDOWS

C:\WINDOWS\system32>set windir=d:\windows

C:\WINDOWS\system32>echo %windir%
d:\windows

C:\WINDOWS\system32>

It is a question of processing speed to make the logical differences.
In every script processing the 'known' variables / constants / macros can be copied and have not to be evaluated again from the files.

This can hardly be about processing speed. Because 077rc2 does not make this distinction and yet it processes scripts at twice the speed!

I repeat: please, please, please introduce backwards compatibility. Why are we being forced to have to again go through a round of script updating to be compatible with the new WB because the new WB won't be backwards-compatible.

Like I said above, in my opinion we should be able to drop the new WB into our current 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.

Thanks,
Galapo.

[Galapo]

Why can a serious programmer use a predefined variable (constant) as variable for his app / script / project ?

Simple: because it was never considered to be a constant (until now, hence the illegitimacy of the lament) but rather a project variable which a project can make use of as they wish.

Why can't it be up to a project to decide whether to treat it as a strict constant or as a variable?

Thanks,
Galapo.

[Galapo]

BTW: You gave a 'Thanks' to that post.

I gave a "thanks" to say thanks for your hard work in development, not necessarily to endorse everything that you do or write.

Regards,
Galapo.

[pscEx]

Why can't it be up to a project to decide whether to treat it as a strict constant or as a variable?

Why do my Delphi or VisualStudio compiler not allow me to overwrite constants?

Peter

[Galapo]

How can you expect project developers to support the idea of having WB stable versions which are not backwards-compatible?

Thanks,
Galapo.

[paraglider]

At least 2 projects use ISOFile and give the option of modifying the iso name to include the target architecture. Six scripts in win7pe_se 5/18/2010 version use the ISOFile variable so its not a simple change to use a different variable.

I tried moving the ISOFile variable definition from [main] to [variables] in script project. Still get the same error.

[pscEx]

I tried moving the ISOFile variable definition from [main] to [variables] in script project. Still get the same error.

Right, because WB checks for some 'Internal defined' strings like [Main]ISOFile=

At least 2 projects use ISOFile and give the option of modifying the iso name to include the target architecture. Six scripts in win7pe_se 5/18/2010 version use the ISOFile variable so its not a simple change to use a different variable.

Using TextPad I today changed for LiveXP:

• Search for %ISOFile%
• Change to %BurnISO%
• Add 'Set,%BurnISO%,%ISOFile%' at a propriate place, e.g. in [process] of script.project.

Less than 2 minutes!

Peter

BTW: The error message with 'Global' I fixed.

[paraglider]

No saying it cannot be done. But I don't own the project so changing it locally just makes it more difficult to upgrade to newer versions.

Even if I was the project owner it would take more than 2 minutes for winpe_se. I would have to rezip the project and re-upload the 13MB file. Then create a new post announcing the availability of a new version. The latest version was only announced yesterday. That takes much more than 2 minutes.

[Galapo]

This just proves the point that WB is intentionally not backwards compatible.

Please answer my question because I want to understand what's going on:

I see no gain in changing the behaviour of %ISOFile% to a constant rather than a variable. What is the reasoning for this?

Thanks,
Galapo.

[Wonko the Sane]

Why do I have this deja-vu feeling?

Knowing that spending my two cents will be once again perfectly unuseful :

psc, these two sentences:

In current alpha versions there have not been any new concerns / remarks / suggestions / bug reports for more than two weeks.

That seems to be the right time to publish WinBuilder 081 RC1 now.

Can be either logical or completely unlike logical.

Questions:

• is 081 RC1 EXACTLY latest alpha with only the name changed?
• how long has been out latest alpha unchanged with no new concerns / remarks / suggestions / bug reports, two weeks?
• has been latest alpha been tested by anyone on ALL the "main" projects successfully?

If the answer to ANY of the above question is "NO", logic is missing.
If the answer to ALL the above questions is "YES", then the release of RC1 is justified (but there wouldn't be so many complains)

Thank you anyway for the hard work you have put in the development of Winbulder.

@All
You have no idea how much this is saddening me , to see talented, good willing, nice people waste so much of their time in good faith and produce a malformed result.

Winbuilder had all the right characteristics to become the "ultimate" PE builder, with a moderate effort by the members of the Board, instead I see it, little by little, becoming a project with less and less usability.

@Galapo
I know you didn't ask for any advice, but I will give you some anyway:
It is seemingly of no use to start another "it should be done like this/No it should be done like that" kind of fight, just keep a given "stable" version together with LiveXP, surely working and ignore any new version until you and Lancelot are ready for a general overhaul of the whole project, then switch version. This way you won't spend time in sterile discussions nor waste it in changes that will most probably need to be redone. (while keeping the "users base" happy with a working project)
Just think about how we are used to "talk" to Microsoft: they deliver an OS or a SP or whatever and we have to adapt ourselves to what they give us, no way to have anything added or bettered or done they way it should be done or even properly documented. We have survived for years with this way to communicate with MS, we can survive with the same way, i.e. not communicating with the Winbuilder developer(s).



Wonko

[Galapo]

@Wonko
Thanks for the advice! This confirms to me what Lancelot and I have been discussing for the last couple of months. That is, stick with the WB version we know and avoid the update train.

I still kind of like the idea of having a project which is up-to-date in regard to compatibility with the latest WB version. I guess this has something to do with why LiveXP is far and away the most popular project at winbuilder.net.

Anyway, I'm tired of updating scripts just because of incompatibilities forced on me by newer WB versions. It's interesting that you raise the analogy of MS and their OS because here I got sick of much the same things and consequently find myself still with XP (I only just upgraded a desktop machine from 2k to xp because of a particular software incompatibility that I couldn't avoid).

Hopefully Peter will relax his stance and we'll get a backwards-compatible WB this time. Here's hoping, anyway.

Regards,
Galapo.

[paraglider]

That only works if everything is static in your PC environment. Buy a new piece of hardware and as time goes on you will find only win7 drivers are available. Buy a new software application and it only works in win7 x64. Etc.

Already win2008 r2 is 64 bit only. I know its a server os but it indicates the trend. Won't be too long before windows and applications are 64 bit only.

Same goes with winbuilder. New scripts will be produced that use features only available in the latest version of winbuilder.

[Wonko the Sane]

@Galapo
@paraglider

Sorry, but you both seem to be missing an aspect of my two cents.

I am not saying to NEVER update.
I am suggesting to update, but NOT continuously, rather periodically.

@paraglider
When what you describe so catastrophically will happen, LiveXP (being XP based) will be long dead, and the problem will be a NON-problem.

When new .script(s) will be produced that are incompatible with the winbuilder "attached" to LiveXP the .script(s) will be put "on hold" until next periodical update/overhaul and NOT included in the LiveXP project until then. (again a NON-problem, quite frankly I haven't seen ANY .script lately that provides something that is actually needed and that cannot already be had on a "standard" LiveXP ).


Wonko

[Galapo]

Yep, which is why things have remained static in my pc environment.

I'm not against new features being implemented to WB. I've never been against new features and if the new WB was backwards-compatible with added features I'd be sure to upgrade.

But this is about WB seeming to go out of its way to resist backwards compatibility. Why now decide that %ISOFile% is a constant and cannot be treated as a variable as in the past? Why can't project developers be consulted on issues like this? Why insist on this and consequently put out a WB version which is not backwards-compatible (this is only an example, I'm sure there's other areas where there is backwards incompatibility)? It just needlessly wastes the time of project developers. I should know because I've kept a large WB project compatible with the latest WB version for 2 or 3 years. It's fine if it's updating to obtain a needed new feature; it's the pits when its because WB has changed some syntax arbitrarily.

Regards,
Galapo.

[MedEvil]

Why exactly do we even have those trickle improvements / changes in WB?
If there is a reason to completely change the internal working, it would be best, to not release any version untill everything is properly implemented.
This way, there would only have to be once updates to all projects and then, there would be smooth sailing again.
Like we did it with WB068.

[Galapo]

@Wonko
Please note that your analogy of MS OS with WB is not entirely comparable. An operating system is an operating system and a batch processor is a batch processor. They're not the same thing. The thing with WB is that a new version comes out quite frequently (unlike the MS OS), meaning that compatibility upgrades to projects is frequent (this has been the case for every stable the last three years).

As far as the MS OS is concerned, there is of couse the batch language which may be comparable. Mostly, batch scripts created under 2k can be used on XP and above. That's not the case for WB scripts. Also, I have some cpp applications written for VS2005 and they still compile and work as expected under VS2010.

Or take AutoIt as another, probably better, example. It's a batch scripting type language the same as WB. AutoIt versions come out rather frequently. But it is only in the rarest of cases where a script has to be updated in order to support a new version. For WB, that's the order of the day -- another new WB version means another round of script updates in order to support it. That's been the case for every stable release since 074. I think that's unfair and unreasonable on project developers.

I'm still interested in knowing the answer to this question:

I see no gain in changing the behaviour of %ISOFile% to a constant rather than a variable. What is the reasoning for this?

Thanks,
Galapo.

[paraglider]

%BurnISO% is a terrible name for a variable that contains the name of the iso file. It sounds like a boolean indicating if I want to burn the iso to media or not.

I tried a much more sensible alternative - %ISOFileName%. That also appears to be a winbuilder constant as it results in exactly the same error. How many constants does winbuilder need for the ISO file name?

[pscEx]

I tried a much more sensible alternative - %ISOFileName%. That also appears to be a winbuilder constant as it results in exactly the same error. How many constants does winbuilder need for the ISO file name?

If you have a look into the magic wand, there is also %ISODir%.
That is a remainder of the time before StrFormat could extract name and path from a FullPath.
But can you imagine what would happen here (due to back compatibility) when somebody would remove such redundancies?

%BurnISO% is a terrible name for a variable that contains the name of the iso file. It sounds like a boolean indicating if I want to burn the iso to media or not.

I chose this name, because after creating an ISO, in most cases you burn a CD with it.
As Galapo stated:

On the other hand, %BurnISO% is truly a nativeEx variable!

Because nativeEx does not exist any more, this question is obsolete.
Developers should name on their personal opinion. Maybe they prefer JFX's vocabulary and call it "Idiot" or "BlowMe".
Maybe Wonko as expert for that ( ) helps to create a poll asking for:

• Is it really necessary that in different projects identical items have identical names?
• If yes:
  
• How many characters should the unique variable name have?
• Should it start with UC or LC?
• etc. etc.

Peter

[JonF]

I chose this name, because after creating an ISO, in most cases you burn a CD with it.

You should not confuse your opinions with facts. I burn CDs about once in 10-20 builds.