16 replies to this topic

[online]

Hi all!

I have some questions about topic title that are not very clear for me...

1. Why not provide a Downloads specific section for VistaPE-Beta 010?

2. Is a script created for 008 version compatible with last version (010)?

3. About RunFromRAM option: I see that new sintax provides for this type of string

RunFromRam,%pCheckBox1%

, but it seems to me that it doesn't work like previous one.
If CheckBox is or is not ichecked seems to me that then program folder creation occurs always in "X:\Program Files" directory...
Furthermore I saw some scripts in new version that show the following sintax (that I've always use with success):

If,%pCheckBox2%,Equal,true,SET,"%DestDir%","Program#$sFiles\%OutDir%"

If,%pCheckBox2%,Equal,false,SET,"%DestDir%","Programs\%OutDir%"

If,%pCheckBox2%,Equal,true,SET,"%LinkDir%","%SystemDrive%\Program#$sFiles\%OutDir%"

If,%pCheckBox2%,Equal,false,SET,"%LinkDir%","y:\%OutDir%"

System,RefreshVars

and now I am a bit confused...

4. About RegHive the issue is the same: I see

RegHiveLoad,WB-Software,%RegSoftware%

and then also

RegHiveLoad,Tmp_software,"%HIVE_HKU%"

And my confusion is increasing...

Where I'm wrong?
Every suggestion is a lot appreciated!

[TheHive]

Hi all!

I have some questions about topic title that are not very clear for me...

1. Why not provide a Downloads specific section for VistaPE-Beta 010?

2. Is a script created for 008 version compatible with last version (010)?

3. About RunFromRAM option: I see that new sintax provides for this type of string

1 and 2 are good questions.
Maybe Nuno can create two VistaPE Download sections for scripts. One for 10 and one for 9. That is if they are not compatible to each Vista Projects.

[pscEx]

1 and 2 are good questions.
Maybe Nuno can create two VistaPE Download sections for scripts. One for 10 and one for 9. That is if they are not compatible to each Vista Projects.

I see it quite different:
Since some days VistaPE seems to be a 'foreign' project which

• is moved from here and became 'third party'
• resides at a server w/o physical connections to boot-land.net (as far as I understood)
• can still be download by the standard WinBuilder download mechanism
• must still be 'compiled' by WinBuilder.

For me, the organization of VistaPE download servers is not longer in Nuno's responsibility.

Peter

[Brito]

XP and Vista based projects are merging to a common script format - which is excellent to join forces and avoid having to write a separate script to work with a single project.


This might be confusing at the moment but it will soon make more sense in a couple of months when this new API is well implemented.

The basic goal was to create a new script method that would make our scripts work regardless of the project where they are placed - this also extends any script to work under present day Windows OS's and future ones to come.

-------

If you look on the download section here on boot-land - the section where old VistaPE specific scripts are is now called VistaPE 09.

The new scripts for VistaPE > 010 are all found inside the "Application scripts" category - it's no longer a specific section for VistaPE because this new format makes scripts compatible across all projects that support this new api.

--------

This means that all scripts inside this section work both on VistaPE, LiveXP and NativeEx all the same and without any changes.

But also means that older scripts (both on LiveXP and VistaPE) are no longer compatible on the newer versions - but the good news is that they can easily be converted.

Just post the script you wish to convert and I'll help you..


----------

Much of this was discussed here: http://www.boot-land...?showtopic=2707

This new api is meant to seriously simplify the life for everyone creating new scripts - only a few lines are needed in most cases.

Here's a list of available functions (most are self explaining but don't hesitate to ask in case of doubt):

[variables]

%ProgramTitle%=My Program

%ProgramEXE%=myProgram.exe

%ProgramFolder%=My_Program





[process]

; Use these examples to see how these commands can be applied inside your app scripts



Add_Shortcut

Add_Shortcut,StartMenu

Add_Shortcut,StartMenu,Games

Add_Shortcut,QuickLaunch

Add_Shortcut,AutoStart

Add_Shortcut,Desktop



require_file,myLibrary.dll



unpack

unpack,AnotherFolder



hive_load,HKU

reg_add,0x1,"%reg%\Classes\filetype","test","1"

hive_unload,HKU





associate_file,html

associate_file,html,open,c:\test.exe

associate_file,html,open,c:\test.exe,/run=%2

associate_file,html,edit

associate_file,html,icon,c:\test.exe

associate_file,html,icon,%systemroot%\System32\Shell32.dll,-153

[phox]

This new api is meant to seriously simplify the life for everyone creating new scripts - only a few lines are needed in most cases.

Here's a list of available functions (most are self explaining but don't hesitate to ask in case of doubt):

[variables]

%ProgramTitle%=My Program

%ProgramEXE%=myProgram.exe

%ProgramFolder%=My_Program

[process]

; Use these examples to see how these commands can be applied inside your app scripts



Add_Shortcut

Add_Shortcut,StartMenu

Add_Shortcut,StartMenu,Games

Add_Shortcut,QuickLaunch

Add_Shortcut,AutoStart

Add_Shortcut,Desktop



require_file,myLibrary.dll



unpack

unpack,AnotherFolder



hive_load,HKU

reg_add,0x1,"%reg%\Classes\filetype","test","1"

hive_unload,HKU

associate_file,html

associate_file,html,open,c:\test.exe

associate_file,html,open,c:\test.exe,/run=%2

associate_file,html,edit

associate_file,html,icon,c:\test.exe

associate_file,html,icon,%systemroot%\System32\Shell32.dll,-153

This solution is enough only for single level Start Menu shortcuts.

To preserve Apps folder configuration in Start Menu shortcut structure
a multilevel shortcut configuration is necessary.

This is double level example:

[Variables]

%ProgramTitle%=sCDWriter

%ProgramEXE%=sCDWriter.exe

%ProgramFolder%=%ParentItem%\sCDWriter

%ParentItem%=CD&DVD

%DestDir%=Program#$sFiles\%ProgramFolder%



[Process]

DirMake,"%TargetDir%\%DestDir%"

ShellExecute,Hide,"XCOPY","#$q%FBox_Source%\*.*#$q #$q%TargetDir%\%DestDir%#$q /e /y"

Add_Shortcut,StartMenu,%ProgramFolder%

If,%pCheckBox1%,Equal,True,Add_Shortcut,Desktop



[Interface]

TextLabel_Source="Source folder",1,1,261,17,87,25,8,Bold

FBox_Source=%BaseDir%\Projects\Programs\CD&DVD\sCDWriter,1,13,253,43,206,28,dir

pCheckBox1="Add shortcut on desktop",1,3,19,191,200,18,True

For multilevel introduction of more Parent Items is necessary.

In Vista type of scripts, generated with MakeScript, used variables are:

%Executable%=sCDWriter.exe
%OutDir%=CD&DVD\sCDWriter
%PName%=sCDWriter

Are those interchangeable with:

%ProgramTitle%=sCDWriter
%ProgramEXE%=sCDWriter.exe
%ProgramFolder%=sCDWriter?

Pedro Le should adapt MakeScript to new api and sctructure.

This script generator should be put in "Tools" folder
and started by selecting "Create script" in WinBuilder.

[online]

@ Nuno and @ phox

Thank you so much!


Sooner or later (thank you all for helping) I should wish reach perfection...









OT/"vanity" /btw: hey, Nuno: what do you think about this?

[Brito]

Phox, adding a parent item would break away flexibility inside the script itself.

The part that should be improved is api.script itself to correctly identify the multilevel folder structure.

%ProgramFolder%=%ParentItem%\sCDWriter
%ParentItem%=CD&DVD
%DestDir%=Program#$sFiles\%ProgramFolder%

A code like the one you've posted will make your app script static again don't you think?

[phox]

Phox, adding a parent item would break away flexibility inside the script itself.

The part that should be improved is api.script itself to correctly identify the multilevel folder structure.
A code like the one you've posted will make your app script static again don't you think?

I agree if api is addapted accordingly and MakeScript too!

What about compatibility of variable names from VistaPE and LiveXP?

[Brito]

I agree if api is addapted accordingly and MakeScript too!

What about compatibility of variable names from VistaPE and LiveXP?

This was already introduced in the latest versions nativeEx, liveXP and VistaPE projects - all present app scripts can be exchanged between each other without changes.

There are still some rough edges needed to solve regarding read only media vs rewritable media but this is still under discussion.

App scripts are no longer static to VistaPE nor LiveXP - from here forward it's the respective project who will adapt itself to the script and not the script who will need to use each project custom variables.

It's much simpler to modify and continue to improve a script.project and api.script files than it would be re-writting hundreds of app scripts available. (also worth mentioning that this way we're assuring that app scripts can be recycled and used for years and years without changes)

Imagine it as the CSS stylesheet on the HTML world - it's much simpler to modify the template rather that it would be modifying the style manually on each page, wouldn't it?



If we want to install an app script on our computer - just adapt the settings on script.project and off you go installing your program inside your own windows or even an offline windows (great for unattended installs).

MakeScript only needs to use the proposed api functions and variables as it is already doing.

------

Peter also created a very important feature that allows to install DLL and OCX files on the target OS and now we get scripts that rival with features that don't even exist on professional .MSI installers since these scripts have no restrictions regarding where they can be installed.

In the unattended world it's also common the use of "Addons" which are packages that install silently on the host system. They are mostly used by nlite and other programs and will install themselves when Windows is being installed on the computer.

Now imagine the power of these app scripts - you can literally integrate them inside the Windows Install files and create a new DVD that installs windows and already includes all these apps installed. Instead of waiting an extra hour to see everything installed you substancially decrease the needed time to install - which is a real time save when doing several of these installs a day.

It has nothing to do with VistaPE or liveXP - but it's another feature that can be explored soon and this is one of the reasons why only generic values are used and a good argument to keep only using the bare minimum - which also helps others understand quickier how to create their own scripts since this template will become fairly stable and flexible to use throughtout the years to come.

We're really growing to a "universal" method..

[phox]

This was already introduced in the latest versions nativeEx, liveXP and VistaPE projects
- all present app scripts can be exchanged between each other without changes.

Folder structure in "Program Files" and "Start Menu" shortcuts scructure,
should mirror folder structure of "Apps" in all Projects to benefit from UniScripts!

MakeScript only needs to use the proposed api functions and variables
as it is already doing.

Api and MakeScript should support multilevel (presently three levels),
folders/shortcuts structure.

MakeScript v14 doesn't do it correctly:

1. Vista type:

[Variables]

%Executable%=Ghost.exe

%OutDir%=Ghost

%PName%=Ghost

%ParentItem%=BackUp

%DestDir%=Program#$sFiles\%OutDir%

%LinkDir%=%SystemDrive%\Program#$sFiles\%OutDir%



[SetVariables]

Set,"%DestDir%","Programs\%OutDir%"

Set,"%LinkDir%","y:\%OutDir%"



[Process]

If,%CheckBox_RunFromRAM%,Equal,True,Run,%ScriptFile%,SetVariables

System,RefreshVars

DirMake,"%TargetDir%\%DestDir%\Ghost"

// FileCopy,"%FileBox_Source%\*.*","%TargetDir%\%DestDir%\Ghost"

ShellExecute,Hide,"XCOPY","#$q%FileBox_Source%\*.*#$q #$q%TargetDir%\%DestDir%\Ghost#$q /e /y"

TXTAddLine,%ES%,"!CD\%DestDir%\%Executable%,%ParentItem%\%PName%.lnk,!CD\%DestDir%","Append"



[Interface]

Bevel_1=Bevel_1,1,12,21,12,171,39

CheckBox_RunFromRAM="Run from ram (boot.wim)",1,3,33,23,168,18,False

Bevel_Source=,1,12,233,12,243,69

TextLabel_Source="Source folder",1,1,261,17,87,25,8,Bold

FBox_Source=F:\F\Programs\BackUp\Ghost,1,13,253,43,206,28,dir

2. Api type:

[Variables]

%ProgramEXE%=Ghost.exe

%ProgramFolder%=Ghost

%ProgramTitle%=Ghost

%ParentItem%=



[Process]

RunFromRam,%CheckBox_RunFromRAM%

Add_Shortcut,StartMenu,%ParentItem%

Add_Shortcut,Desktop

DirMake,"%TargetDir%\%WorkDir%\Ghost"

// FileCopy,"%FileBox_Source%\*.*","%TargetDir%\%WorkDir%\Ghost"

ShellExecute,Hide,"XCOPY","#$q%FileBox_Source%\*.*#$q #$q%TargetDir%\%WorkDir%\Ghost#$q /e /y"

Process_log



[Interface]

Bevel_2=Bevel_2,1,12,21,12,171,39

CheckBox_RunFromRAM="Run from ram (boot.wim)",1,3,33,23,168,18,False

Bevel_Source=,1,12,233,12,243,69

TextLabel_Source="Source folder",1,1,261,17,87,25,8,Bold

FBox_Source=F:\F\Programs\BackUp\Ghost,1,13,253,43,206,28,dir

Both ask for “ParentItem” and I doubt that they are compatible.

[Brito]

Well.. that's a good and bad thing about everything being customizable here..


Instead of that bulky code I would use something like this:

[Variables]

%ProgramEXE%=Ghost.exe

%ProgramFolder%=Ghost

%ProgramTitle%=Ghost





[Process]

Add_Shortcut

Unpack

On this case to make things simple I'd just recommend on the script interface to add all binaries for ghost inside the script.

One might not prefer to encode their files inside the script - but as I've said - everything is possible to match the developer preferences.

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

Parent Item is redundant and risks to make scripts static. Imagine that you call it "BackUp" while I prefer a folder called "Imaging" - I download 15 scripts with imaging solutions - should I modify 15 scripts to use a new Folder name in the Start Menu or simply modify the folder name where the scripts are placed?

I really recommend not using it..

[phox]

Instead of that bulky code I would use something like this:

[Variables]

%ProgramEXE%=Ghost.exe

%ProgramFolder%=Ghost

%ProgramTitle%=Ghost



[Process]

Add_Shortcut

Unpack

I fully agree with this, but MakeScript generates differently
and after that lot of manual corrections should be done!

On this case to make things simple I'd just recommend
on the script interface to add all binaries for ghost inside the script.

I principally don't include files in the script.
Besides, Ghost is commercial program.

Parent Item is redundant and risks to make scripts static. Imagine that you call it "BackUp" while I prefer a folder called "Imaging" - I download 15 scripts with imaging solutions - should I modify 15 scripts to use a new Folder name in the Start Menu or simply modify the folder name where the scripts are placed?

I really recommend not using it..

Again I fully agree, but api and MakeScript must be adapted for that.
Without that and support for multilevel shortcuts lot of manual work
must be done after script generation.

[pedrole15]

I fully agree with this, but MakeScript generates differently
and after that lot of manual corrections should be done!

Again I fully agree, but api and MakeScript must be adapted for that.
Without that and support for multilevel shortcuts lot of manual work
must be done after script generation.

Hi phox
I have made MakeScript for LiveXP at the begening
After i try to adapt it for VistaPE but it seem for me that nobody was using it so i never finish it
I have work to elaborate the api , Nightman have contact me and have make some change on it
So a new version 7 for liveXP is coming soon fully compatible with the new VistaPE 10
Now i start to rebuild MakeScript

PS : I am not an informatician just a Farmer
Not so good in english too
I go now milk my cow

Pedro

[phox]

Hi phox
I have made MakeScript for LiveXP at the begening
After i try to adapt it for VistaPE but it seem for me that nobody was using it so i never finish it
I have work to elaborate the api , Nightman have contact me and have make some change on it
So a new version 7 for liveXP is coming soon fully compatible with the new VistaPE 10
Now i start to rebuild MakeScript

Take your time, nobody is in a hurry.

PS : I am not an informatician just a Farmer
Not so good in english too
I go now milk my cow

Pedro

I would gladly change my English for your informatics knowledge.
And believe me, your English is much, much better than my French!

[online]

XP and Vista based projects are merging to a common script format - which is excellent to join forces and avoid having to write a separate script to work with a single project.
This might be confusing at the moment but it will soon make more sense in a couple of months when this new API is well implemented.

The basic goal was to create a new script method that would make our scripts work regardless of the project where they are placed - this also extends any script to work under present day Windows OS's and future ones to come.



it's no longer a specific section for VistaPE because this new format makes scripts compatible across all projects that support this new api.



This means that all scripts inside this section work both on VistaPE, LiveXP and NativeEx all the same and without any changes.


This new api is meant to seriously simplify the life for everyone creating new scripts - only a few lines are needed in most cases.

This is very interesting, and I'm sure that it will become much more interesting with the time...

Thank you!

[NightMan]

Is a script created for 008 version compatible with last version (010)?

YES!

About RunFromRAM option

Do you read documentation on my site?

If you need place program to RAM, you need write "RunFromRam,True", you can do it manually or use checkbox (RunFromRam,%pCheckBox1%)

About RegHive the issue is the same

All two commands is right and do same thing, but mount registry hives to different location ... see WinBilder documentation

Maybe Nuno can create two VistaPE Download sections for scripts. One for 10 and one for 9. That is if they are not compatible to each Vista Projects.

API from 009 version is dead, 009 version was only experimental for API and now we have very good common API for all projects based on WinBuilder and not really need more

is moved from here and became 'third party'

I need more faster commercial server and plane use this hosting not only for VistaPE project

resides at a server w/o physical connections to boot-land.net

YES

can still be download by the standard WinBuilder download mechanism

it's mechanism is perfect and VistaPE will be always use it

must still be 'compiled' by WinBuilder

WinBuilder is most greatest platform for this and i not plane do something different

For me, the organization of VistaPE download servers is not longer in Nuno's responsibility.

he (and you and other) can write to me and i can upload something or make ftp account for you and i plane special section on my site for script design with history control and many other functions

If you look on the download section here on boot-land - the section where old VistaPE specific scripts are is now called VistaPE 09.

it's not fully correct - many scripts written for 008 and can work with 010, and only some written for 009... i think we must rewrite all scripts with common API and place in VistaPE section only specific scripts...

Making new scripts
Any body read documentation? You can find answers about new API, compatibility and almost all other questions in it

[online]

Do you read documentation on my site?

Not yet...
Really, I am more able to write (?) in English rather than to read, but I will do it: I promise!

Thank you so much for your replies!