I have not actually used the new Winbuilder - yet! I plan to do so in the future when I have a little more time on my hands. Who knows, if I can figure out the scripting language I might even write a project or convert an existing one.
I don't want to have or start pointless arguments about which Winbuilder might be best. For those interested in some of my views about previous Winbuilder
projects in general see
here. WinBuilder is a method of automating/scripting - it's up to individual projects how the WinBuilder engine is actually used. I suspect this also applies to the new WinBuilder.
....
This was the first edition of a new generation, now it is time to start improving.
Now that I have establised that I haven't used it I'm going to stick my neck out with some questions/thoughts/observations (and possibly mad ramblings) - based on other posts in this thread and my own experiences creating boot disks using a number of tools (notepad.exe being one of them). I might even be able to contribute to starting to improve it!
I don't understand (or even need to understand) the discussion on Java and the security implications of using it. I personally choose to trust Nuno based on my own experiences of using his applications in the past. Lets face it winbuilder 082 could be used to seriously mess up a system if someone wanted to design a project/script to do so. Whilst I trust Nuno I am not sure that I would extend this trust to individual projects - however this applies equally to previous winbulder projects too!
....a few notable "followers" of popular wb projects messed up a simple standard way of writing app scripts for the sake of "betterness". In a single stroke hundreds of app scripts were broken after having worked for years across different projects, despite even using the same engine underneath. ...
....the so called common api / macro library is a nightmare and as you say the owners delete commands whenever they feel like it. I complained bitterly when they deleted the registry commands thus breaking about a hundred of my private scripts. However that is totally irrelevant to the new winbuilder and there was no need to bring old history up here yet again.
Is the new Winbuilder intended to introduce (enforce?) a common syntax to be used across all projects? If the answer to this question is yes, then good luck. And I am not being sarcastic - I really do wish you good luck and sincerely hope that this is achievable. Having a program script (plugin) that works across multiple projects would be a godsend for developers and (more importantly) end users - I just do not know if this is possible and will come on to the possible difficulties and reasons why later. To achieve any kind of common syntax you will need to provide some documentation - and the sooner the better so that the ground rules can be established before too many "Plugins" are written.
I suspect that this might not go down too well, but I would personally recommend introducing a system whereby projects/scripts/plugins should be "certified" or "approved" to ensure that some minimum standards and some kind of compatibility can be achieved. Any man and his dog can currently produce a project and or/program scripts using a legacy version of WinBuilder - I'm speaking from personal experience here as I have! This can be very confusing for the end user. Particularly as there is no guarantee of scripts working across projects and generally a lack of information about available options in some of the project scripts - no fault of Winbuilder as it is after all just the instrument being used to meet the end result. The new Winbuilder however give us an opportunity for a new beginning - a fresh start.
For developers - having a plugin/project certified as "WinBuilder Approved" could be an accolade to strive for. This would not stop other people producing their own projects/scripts/plugins - it would just ensure that that they are compatible if the author wants "Winbuilder Approved" status. I am not trying to be elitest, I just do not see any other way of ensuring some kind of WinBuilder "Standard". Winbuilder is a versatile tool and the two projects that I have personally developed have probably been completely incompatible with all existing scripts. In my defence I didn't even know that there was any kind of "simple standard way of writing app scripts" and have used a fantastic tool to meet my own needs. There is no harm in this approach now or in future and no way of stopping this due to the inherent versatile nature of WinBuilder. Just don't expect the resulting project/plugin to be "Winbuilder Approved".
As a starting point I would insist that any projects just work using the default settings. Knowing that a particular project has been "Winbuilder Approved" should hopefully give new users the confidence to give a project a go. The devil is in the detail - without adequate testing there is a risk of failed builds and consequently frustration and abandonment of not just the project being tested, but WinBuilder as a whole. Trust me - I've been there.
From an administrative point of view this has implications in terms of who will test and approve these plugins/projects and who will decide on approving them. This is however a large community and I would assume that there are enough people willing to volunteer for testing. Obviously there would need to be some kind of testing methodology to ensure consistenty.
To ensure any kind of future compatibility some consideration needs to be given towards a common syntax now. A brainstorming session would be useful. My own suggestion would be for consideration to be given towards having a list of approved "cores" that each plugin can be checked against - then any special commands for that particular project/core could be met.
At the present time I can think of at least 5 different "cores" - WinPE1x/2x/3x/4/5. Each with two distinct processor architectures - so at least 10 variables to cater for. Now here is one of my biggest issues with existing scripts. DEPENDANCIES. Or more accurately the lack of testing to ensure that dependencies are accurately checked. Part of the problem is that some programs might currently work in one project because of a different script that is also being used, or the core files simply being different, and a dependancy unknowingly being there. Take the same script to a different project with a different set of core files, or uncheck an unknown dependency in an existing project and you are up the creek without a paddle!
To ensure compatibility a core needs to be agreed upon as a development platform - in WinPE 2/3/4/5 this could simply be an unmodified WAIK build. If we can isolate the dependancies so that a program works on the most basic core file set then we can be more confident about them working in individual projects using the same core.
Using the legacy WinBuilder syntax this could be something like...
[process]
If,%CORE%,Equal,WINPE1x,Run,%ScriptFile%,WINPE1x
If,%CORE%,Equal,WINPE2x,Run,%ScriptFile%,WINPE2x
[WINPE1x]
Message,"This application does not work in WINPE1x. Sorry..."
Exit,"This application does not work in WINPE1x. Sorry..."
[WINPE2x]
If,%ARCHITECTURE%,Equal,x86,Begin
command
etc.
End
If,%ARCHITECTURE%,Equal,x64,Begin
Message,"This application does not work in a 64-bit environment. Sorry..."
Exit,"This application does not work in a 64-bit environment. Sorry..."
End
Just some things to think about.
Regards,
Misty