11 replies to this topic

[Dramastic]

A nice script would be...

if when you have spent alot of time configuring a CD/DVD to be just right with all the many settings in WinBuilder that a backup of the configuration (and possibly the scripts too) were placed on the .ISO.

This way if you stumble across the CD/DVD months or years later and there is something you like on it or you want to make minor tweaks to it, you have a starting point.

Dramastic

[pscEx]

A nice script would be...

if when you have spent alot of time configuring a CD/DVD to be just right with all the many settings in WinBuilder that a backup of the configuration (and possibly the scripts too) were placed on the .ISO.

This way if you stumble across the CD/DVD months or years later and there is something you like on it or you want to make minor tweaks to it, you have a starting point.

In the nativeEx world there already exists a script !WBManager which saves and restores actual configuration under names you define.
Because it only stores selections and options, it can be used for every (?) project.

You only have to copy the configuration to %targetdir% in order to bring it to the CD

Peter

[pscEx]

I thought about it.

Tomorrow I'm going to do a small modification in my !WBManager script.
Today in Europe it's too late.

Peter

[Dramastic]

Sounds like most of the hard work is already done then. I can hardly wait to see what you come up with!

However I am wondering if saving the selections and options alone will be enough though - available options may change as new scripts are released? For example build version 10 of some.script may not have the same set of checkboxes as build version 20 of some.script.

Where is WinBuilder.Scripts.Archive.Org when you need it?

On the other hand scripts will probably take a fair amount of space on the disk if the scripts have attachments etc. - not that this matters to me as I have already had to move to DVD builds..

..and then there is always blue-ray right?


Dramastic

[pscEx]

However I am wondering if saving the selections and options alone will be enough though - available options may change as new scripts are released?

Exactly my concerns.

This would make it necessary to also store the scripts on the DVD ...
And the right version of WinBuilder to build it ...
But then maybe you cannot add a newer script which needs a newer version of WinBuilder ...

Peter

[Dramastic]

And the right version of WinBuilder to build it ...
But then maybe you cannot add a newer script which needs a newer version of WinBuilder ...

Good point which should be addressed, but this is true regardless of whether it is on CD/DVD or local though..

It might not be for everybody, but I think it has a place. I for one would like to be able to hand off a DVD to one of my colleagues that would both enable them to demo it and give them a working starting point.

- WinBuilder itself is pretty compact (< 1MB), so including it is probably not a big deal.
- I still have about 2.5--3 GB free on my DVD builds, plenty for any scripts (though I recognize this is going to be problematic for some).

- Regarding the Script updates not working with older WinBuilder versions such as might be on such a DVD, I guess it would then be a good thing that the original is read-only! However more seriously, perhaps it would be worth archiving the entire current WinBuilder Downloads collection (or perhaps individual projects) for the community just before any new release of WinBuilder..

Regards,

Dramastic

[Brito]

Having a sort of snapshot of all available scripts along with the current winbuilder seems a good idea.

Some years ago it was done because there were few scripts and projects, today this would become a huge task but still a very interesting one since so many features and scripts could be added.

Also, winbuilder doesn't run well from a read only location and will need IE installed on the OS - otherwise it will complain that it is unable to write settings on scripts.

Maybe this is something to consider fixing in the future, I'd like to see such collection available one day.

[cdob]

I'm used to add source files to BartPE since several years.

I'm using mkisofs

-duplicates-once -graft-points /source/=%PEBuilderRoot%

Files are not copied at build time.
Mkisofs read files from another directory and maps to /source/
Actually source files are not copied to hard disk at all, mkisofs output is piped to cdrecord: mkiofs | cdrecord -

What about adding winbuilder.exe, Tools directory and current Projects directory?

Can -graft-points be added to CreateISO.script?
How to set current Projects directory inside a .script?

[pscEx]

Can -graft-points be added to CreateISO.script?
How to set current Projects directory inside a .script?

Please explain an expert dummie what -graft-points really performs

Since the new variables handling I introduced in WB 075 beta, it is possible to change EVERY variable:
Set,%projectDir%,C:\foo
Livetime of the new value is the current script only.

Peter

[cdob]

@Peter
-graft-point is a kind of virtual rename and move.
Files and directories from any location at hard disk can be renamed and moved at CD.

http://cdrecord.berl.../mkisofs.8.html

If the option -graft-points has been specified, it is possi-
ble to graft the paths at points other than the root direc-
tory, and it is possible to graft files or directories onto
the cdrom image with names different than what they have in
the source filesystem.

Previous example as mkisofs command (not tested, just to clarify idea):

mkisofs %options% -graft-point %targetdir% /source/WinBuider.exe=%BaseDir%/WinBuilder.exe  /source/Projects/%ProjectName%=%ProjectDir% /source/Projects/Tools/=%BaseDir%/Tools/

This creates at CD:
%targetdir%
/source/WinBuilder.exe
/source/Projects/%ProjectName%
/source/Projects/Tools

[pscEx]

@Peter
-graft-point is a kind of virtual rename and move.
Files and directories from any location at hard disk can be renamed and moved at CD.

http://cdrecord.berl.../mkisofs.8.html

Previous example as mkisofs command (not tested, just to clarify idea):

mkisofs %options% -graft-point %targetdir% /source/WinBuider.exe=%BaseDir%/WinBuilder.exe  /source/Projects/%ProjectName%=%ProjectDir% /source/Projects/Tools/=%BaseDir%/Tools/

This creates at CD:
%targetdir%
/source/WinBuilder.exe
/source/Projects/%ProjectName%
/source/Projects/Tools

Understood! That makes a physical copy to %TargetDir% unnecessary.

Thanks!

Peter

[Dramastic]

That sounds like a great approach to accomplish this task. It will also be useful for me in ovoiding having to copy my 'custom' folder (very large) with every build..

Currently the "Create ISO" script (author=Open source community; edited by edborg; edited by psc - Version=31) that I am using has the following ShellExecute code:

ShellExecute,Open,#$q%Tools%\mkisofs.exe#$q,"-iso-level 4#$s-force-uppercase -volid #$q%pTextBox1%#$q -b %BootSect% -no-emul-boot -boot-load-size 4 -hide bootsect.bin -hide boot.catalog#$s-duplicates-once -o #$q%IsoFile%#$q #$q%targetdir%#$q"

Do I need to merge your code:

mkisofs %options% -graft-point %targetdir% /source/WinBuider.exe=%BaseDir%/WinBuilder.exe  /source/Projects/%ProjectName%=%ProjectDir% /source/Projects/Tools/=%BaseDir%/Tools/

with the above current code? Or can you run the -graft-point stuff by running it afterward as a separate command?

Finally, do you know if you can do a 'graft' ontop of other directories/files already in place? Because if you can do that it could have alot of other uses in reducing the build process times..


Dramastic