24 replies to this topic

[TheHive]

Layout used at this time on the Sandbox.

WinBuilder\Archive\Addons
MiscSettings.Script
ramdisk.Script
USBSticks.Script
DisplayProperties.Script
dos16bit.Script

WinBuilder\Archive\Apps
go2pdf.Script
mspaint.Script
notepad.Script
regedit.Script
Taskman.Script
wordpad.Script
calculator.Script
CDWriter.Script

WinBuilder\Archive\autoTweaks
autoLocalization
autoLocalization.Script
autoUPX.Script
localeFolder.Script

WinBuilder\Archive\Build
MkISOfs.Script
ProjectInfo.Script
ScriptLog.Script
WinSxS.Script
BootfromRAM.Script
EmptyHive.Script


WinBuilder\Archive\Shells
Explorer.Script
CMD.Script

WinBuilder\Archive\Tools
CDRecord.Script
qEmu.Script
RegEditWB.Script

WinBuilder\Archive\Tweaks
autoruns.Script
shortcut.Script

WinBuilder\PicoXP\Build
PicoXP-2-CopyAndExpand.Script
PicoXP-3-Hives.Script
PicoXP-4-TXTsetup.Script
Freedos32-Resources.Script
PicoXP-1-MakeDirs.Script


WinBuilder\Projects\Standard\Build
Standard-1-MakeDirs.Script
Standard-2-CopyAndExpand.Script
Standard-3-Hives.Script
Standard-4-TXTsetup.Script

[TheHive]

Proposed layout by phox:

WinBuilder\Archive\Addons
DOS16bit.Script
Notepad.Script
RamDisk.Script
RegEdit.Script
TaskMan.Script
USBSticks.Script


WinBuilder\Archive\Apps
CDWriter.Script
Go2PDF.Script

WinBuilder\Archive\autoTweaks
AutoLocal.Script
AutoUPX.Script
LocaleFolder.Script
autoUPX

WinBuilder\Archive\Build
ProjectInfo.Script
ScriptLog.Script
WinSxS.Script
EmptyHive.Script
MkISOfs.Script

WinBuilder\Archive\Shell
CMD.script
Explorer.script


WinBuilder\Archive\Tools
qEmu.Script
RegEditWB.Script
CDRecord.Script

WinBuilder\Archive\Tweaks
DisplayProperties.Script
MiscSettings.Script
ScreenResolution.Script
Shortcut.Script
AutoRuns.Script

[TheHive]

If we are going on that the following are addons to the OS and not applications I could go with this layout. If we consider Applications as those programs that are not from a regular XP OS install then the proposed layout for the following makes sense.

WinBuilder\Archive\Addons
DOS16bit.Script
Notepad.Script
RamDisk.Script
RegEdit.Script
TaskMan.Script
USBSticks.Script


So if we follow this pattern then the new scripts for Calculator, Paint, and Word Pad would fall in the addons category. Makes sense.


WinBuilder\Archive\Tweaks
DisplayProperties.Script
MiscSettings.Script
ScreenResolution.Script
Shortcut.Script
AutoRuns.Script

Why do you not consider the DisplayProperties.Script, MiscSettings.Script, and ScreenResolution.Script an addon. They add something to the OS. They dont Tweak it in anyway.


The rest of the layout appear the same to the one used now.
I still would like all actual Scripts to be in the Archive.

[Alexei]

Let's designate each folder to the scripts with specific property

I strongly believe, classification should be based on clear and simple idea.
I tried to look at things from PE's point of view and follow its build-run-use flow
This way it should be simpler to distribute upcoming scripts to proper folders.
Alexei
PS
I could have made some mistakes, please correct me, but not the idea

WinBuilder\Archive\Build - essential to build process (obligatory)
- ProjectInfo.Script
- ScriptLog.Script
- WinSxS.Script
- EmptyHive.Script

WinBuilder\Archive\Tools - optional to build process (any can be disabled)
- CDRecord.Script
- autoLocalization
- qEmu.Script
- autoUPX.Script
- localeFolder.Script
- MkISOfs.Script * optional for PE on HD
- BootfromRAM.Script
- RegEditWB.Script * ???

WinBuilder\Projects\PicoXP\Build - essential to PE startup (PicoXP)
- PicoXP-1-MakeDirs.Script
- PicoXP-2-CopyAndExpand.Script
- PicoXP-3-Hives.Script
- PicoXP-4-TXTsetup.Script
- Freedos32-Resources.Script

WinBuilder\Projects\Standard\Build - essential to PE startup (Standard)
- Standard-1-MakeDirs.Script
- Standard-2-CopyAndExpand.Script
- Standard-3-Hives.Script
- Standard-4-TXTsetup.Script
- autoruns.Script * other scripts may rely on it

WinBuilder\Archive\autoTweaks - optional to PE startup/features (PE can run without them)
- MiscSettings.Script
- ramdisk.Script * not needed with PE on HD
- USBSticks.Script
- DisplayProperties.Script
- ScreenResolution.Script
- shortcut.Script

WinBuilder\Archive\Shells - provides minimal PE environment
* more logically would be WinBuilder\Projects\Standard\Shells
- Explorer.Script
- CMD.Script

WinBuilder\Archive\Addons - maintanance of running PE
- notepad.Script
- regedit.Script
- Taskman.Script
- dos16bit.Script

WinBuilder\Archive\Apps - applications needed by users
- go2pdf.Script
- mspaint.Script
- wordpad.Script
- calculator.Script
- CDWriter.Script

[phox]

I like the modified layout of WB folders used
in WinBuilder_Sandbox_Latest.zip.

To make it uniform across all folders, I have just adapted
names and levels of some .Scripts to group them better:

[attachment=552:attachment]

Please check my SandBox and if acceptable apply it in the future.

[pscEx]

I like the modified layout of WB folders used
in WinBuilder_Sandbox_Latest.zip.

To make it uniform across all folders, I have just adapted
names and levels of some .Scripts to group them better:

[attachment=552:attachment]

Please check my SandBox and if acceptable apply it in the future.

Can you post again with the original name (w/o -phox) that I can compare by program?

Peter

[phox]

Can you post again with the original name (w/o -phox) that I can compare by program?

Peter

I can’t. I have difficulties with my connection.
It took me half one hour to upload that one!

[Alexei]

everybody
I'm afraid, we would not be able to find a reasonable solution to "how to distribute scripts to folders", unless we find and agree on the criteria/idea/logic of distribution.
I believe, it's not a matter of personal preferences, so all feelins about "if it's right or wrong" should be put aside.
I proposed simple logic, i.e. to follow PE's build-run-use sequence, also separate essential scripts from optional.
You may have better ideas behind your "distribution plans".
Can you please share them?
The we discuss advantages/disadvantages of each and simply apply the best one to create best "distribution".

Alexei

[TheHive]

proposed simple logic, i.e. to follow PE's build-run-use sequence, also separate essential scripts from optional.

I would agree to that.

[TheHive]

Can we also cover the Level applications should take.

I just downoaded the WinBuilder_Sandbox_Latest because it was mentioned here and some apps are at different levels. Should they all have the same level or does it matter what level they are in?

[Brito]

Can we also cover the Level applications should take.

I just downoaded the WinBuilder_Sandbox_Latest because it was mentioned here and some apps are at different levels. Should they all have the same level or does it matter what level they are in?

It would likely be a good idea to also redefine/organize how these levels should be categorized..

Here's an idea:

Levels

1 - Preprocess info (where all informations are gathered)
2 - Build (basic building scripts - create folders, copy/expand, winsxs)
3 - Base (shell, shortcuts, ramdisk/FBWF options..)
4 - Settings and Drivers (all tweaks and drivers)
5 - Applications (added programs like CD-burn, editor, tools..)
6 - PostProcessing (autoUPX, cleanup)
7 - ISO creation (mkisofs, RAM boot..)
8 - PC Emulation (Qemu, vmware, virtualPC)
9 - Burn ISO
10 - Project Tools (hive editing, target tweaking..)


More levels can be added if needed, althought it will also mean decreased performance when organizing scripts in the navigation window.

[Alexei]

It would likely be a good idea to also redefine/organize how these levels should be categorized..

Here's an idea:

Levels

1 - Preprocess info (where all informations are gathered)
2 - Build (basic building scripts - create folders, copy/expand, winsxs)
3 - Base (shell, shortcuts, ramdisk/FBWF options..)
4 - Settings and Drivers (all tweaks and drivers)
5 - Applications (added programs like CD-burn, editor, tools..)
6 - PostProcessing (autoUPX, cleanup)
7 - ISO creation (mkisofs, RAM boot..)
8 - PC Emulation (Qemu, vmware, virtualPC)
9 - Burn ISO
10 - Project Tools (hive editing, target tweaking..)
More levels can be added if needed, althought it will also mean decreased performance when organizing scripts in the navigation window.

I believe, so far, we don't have real problems with sequence of execution of the scripts.
However, in the future the situation may change.

In general, we should suppose scripts on one level be executed in any order, unless they are specifically named ("N-****", where N=0..9), it's also possible to reserve "_N-****"-names for "trailing" scripts on each level.

Regarding "dependency", I'm not sure if we should make execution (and display) sequence to take in account "dependency" of the
scripts. Performance and maintanance reasons say "no", but being strict, it should be "yes"
A good solution may be verification of script dependency at runtime (error if not all required scripts are done). If such error occures, developer can just rename the script

I like Nuno's idea, though I think we need more levels between 1 and 6 and trailing levels are kinda wasted. My suggestion would be somethoing like that:
0 - Preprocess info (where all informations are gathered)
1 - reserved for future use (macros, downloading, etc.)
2 - Build (basic building scripts - create folders, copy/expand, winsxs)
3 - reserved for future use
4 - Base (shell, shortcuts, ramdisk/FBWF options..)
5 - Drivers and optional features
6 - Finalization of the system (Tweaking, etc.)
7 - Applications (added programs like CD-burn, editor, tools..)
8 - PostProcessing (autoUPX, cleanup)
9 - Post-Build
- ISO creation (mkisofs, RAM boot..)
- PC Emulation (Qemu, vmware, virtualPC)
- Burn ISO
10 - Project Tools (hive editing, target tweaking..)
I'm not insisting on having reserved levels. It could be better distribution of scripts to levels 1-6, I just don't have enough knowledge to do it better
psc, what'd you think?

Anyway. it's not an issue for quick decisions
BTW, those levels do not correspond to the folder structure which in general is based on different approach

In terms of "point of view":
Folder structure - how PE (being a person) may look at it.
Levels - how WinBuilder (being a person) may look at it.
In my opinion, it's most productive to look at things from software's (not developer's) position


Alexei

[smiley]

Levels

1 - Preprocess info (where all informations are gathered)
2 - Build (basic building scripts - create folders, copy/expand, winsxs)
3 - Base (shell, shortcuts, ramdisk/FBWF options..)
4 - Settings and Drivers (all tweaks and drivers)
5 - Applications (added programs like CD-burn, editor, tools..)
6 - PostProcessing (autoUPX, cleanup)
7 - ISO creation (mkisofs, RAM boot..)
8 - PC Emulation (Qemu, vmware, virtualPC)
9 - Burn ISO
10 - Project Tools (hive editing, target tweaking..)

I have created a new layout that works ok with the new categorizing system and looks great without the double folders in v52b1

Level 1 : Folder Build(Project info & core scripts)
Level 2 : Addons(no applications) & Shells
Level 3 : Applications - I have also added a subfolder in aplications named "windows applications"
Level 4 : Tweaks - This folder contains only boot from RAM and the autotweaks in a separate folder
Level 5 : Finalization(CreateIso script) - Tools (BurnCD, RegEditWB)
Level 6 : Emulation

[Alexei]

I have created a new layout that works ok with the new categorizing system and looks great without the double folders in v52b1

Level 1 : Folder Build(Project info & core scripts)
Level 2 : Addons(no applications) & Shells
Level 3 : Applications - I have also added a subfolder in aplications named "windows applications"
Level 4 : Tweaks - This folder contains only boot from RAM and the autotweaks in a separate folder
Level 5 : Finalization(CreateIso script) - Tools (BurnCD, RegEditWB)
Level 6 : Emulation

Yes, it looks good, but doesn't help doing things right
Your proposal may be fine for now, but then it may cause a lot of problems, hard and time-consuming to resolve. Do you want people to spend hours trying to understand what went wrong, then to spend more time discussing how to fix it?

What I mean, is that the most challenging job it to make future development to go smoothly. Unfortunately, it's common situation when efforts needed to hande growing project exponentially depend on its volume. We already need a lot of efforts to get sandboxig going...

Currently, WinBuilder is in its early days. A lot of functionality is missing in created builds.
Eventually, it would become close to Sherpya's "XPE". It would be many scripts to expand its functionality.
I can agree on putting all app-scripts together, as sequence of their execution is usually unimportant, but placing all "system" scripts together is wrong. We would end-up with Bart-like z,zz,zzz-named scripts, etc., i.e. the whole idea of level-controlled sequence would be lost

Also, there gonna be some scripts that override values set by other (basic) scripts. That is necessary because it's unrealistic to ask script developer to support every tiny thing others may need. Basically, it has to be a simple way to assure script A will run after/before script B. You have no support for that

In your proposal optional and essential scripts are mixed, so there is no simple way to understand what can be turned off. And that's even more important to developers then to end-users.

Number of developers is growing. They should have simple rules to choose Level and Folder. Those rules should guarantee their scripts would work as supposed I don't want them to waste their time resolving problems coming out of unexpected interference of the scripts.

I think, Folder-tree should be orthogonal to Levels-sequence.
I believe, one simple linear classification does not provide enough flexibility for future development
What you would do if script needs to be moved to a different level?
What about application script that may need do something in the middle of "system part"?
Let's look forward and get well organized now to avoid future problems

Sorry for wordy post. I think this issue is important and it needs elaborated analysis.


Alexei

[Brito]

Alexei is right, I've felt the same worries not very long ago since I've noticed that some scripts need to be very specific on the level of processing (shortcut script is an example of this..).

I'll be doing some tests performance/time to see how far more levels can be added.

On the other hand, maybe it would be a good idea to completely revise the current script level filtering.

The current order is:

Script Level --> Folder name --> Script filename

Maybe it should be:

Folder Level --> Script Level --> Script filename

Where a new sort of file "folder.project" placed on the root of each folder could add more instructions like the level in wich it should be placed inside the navigation window and even be used like a sort of "script.project".

All scripts found within would then be categorized according to the other scripts found on this folder instead of comparing them against all scripts from the project..

Would this be more flexible?

Probably I'll just make a beta for testing this sort of categorization,


As a side note: I'm also planning on adding profiles to winbuilder projects, this would also be a good way for users be able to select different results inside the same projects, imagine on a standard project, when a user only wants a 31Mb ISO while another one might wish to try a full version with all sort of drivers and programs.

A profile would allow to quickly (de)select scripts as required - it is still an idea, but can be added..

[TheHive]

A profile would allow to quickly (de)select scripts as required - it is still an idea, but can be added..

That sounds like a good idea.

[Alexei]

@Nuno,
In my opinion it should be

Script Level --> Script filename

I'll try to explain in form of Q&A
Q: We need levels to inforce necessary sequence of execution, but why we need folders?
A: As a rule, tree-like structure of folders is used to organize storage of the software components.
Q: Why we need to organize it?
A: Obviously, to know where to put and where to get
Q: How we currently organize our scripts?
A: We have Archive for basic/stable scripts, project folders under Projects, Test to place scripts we not sure with, etc. Actually, we classify scripts by their properties (that have nothing in common with execution sequence).
Q: Does it work well?
A: Mostly, but sometimes not.
Q: Why?
A: Because logic behind distribution scripts to folders is not very clear.
Q: What about distribution by execution sequence?
A: It's rather useless as organization factor, unless you remember on which stage particular script is supposed to run. Usually we remember other things, such as what the script does.

Moving script from folder to folder to control when it runs - very dobtful idea
I'd like to state my position once again: "Levels" and "Folders" are both needed, but they satisfy different needs:
- Levels - control execution sequence (execution in proper order).
- Folders - organized storage of the scripts (developer/user convenience).
I really don't understand why anybody may want to mix those very different functions


Alexei

[pscEx]

The 10 level suggestions of Alexei sounds good, but I have some concerns:

- the order of e.g. executing 'makedirs' before 'copy&expand' inside the 'build' level must be caused by naming!

- .scripts are allways executed before .links!

BTW

Alexei is right, I've felt the same worries not very long ago since I've noticed that some scripts need to be very specific on the level of processing (shortcut script is an example of this..).

That can be avoided by the script itself, as I already stored in sandbox (shortcut there has level 10)

I suggest:

For clear gui structuring we use the 10 levels proposed by Alexei.
For execution order we create a (project dependent) control file which defines the order of execution. Winbuilder executes the scripts following this order. Of course, if a script is not selected, is has to been skipped.
That means that no program logic, but only the user decides the order of execution!

Adding and removing scripts to/from project:
For the beginning, this control file has to be maintained by an editor. Later it is maintained by a GUI with drag'n drop or similar.

Peter

[smiley]

For clear gui structuring we use the 10 levels proposed by Alexei.
For execution order we create a (project dependent) control file which defines the order of execution. Winbuilder executes the scripts following this order. Of course, if a script is not selected, is has to been skipped.
That means that no program logic, but only the user decides the order of execution!

Adding and removing scripts to/from project:
For the beginning, this control file has to be maintained by an editor. Later it is maintained by a GUI with drag'n drop or similar.

I agree 100% with Peter

Edit: Let's collect all the suggestions and put a vote in the forum, so everyone can take part


John

[Alexei]

The 10 level suggestions of Alexei sounds good, but I have some concerns:

- the order of e.g. executing 'makedirs' before 'copy&expand' inside the 'build' level must be caused by naming!

- .scripts are allways executed before .links!

BTW
That can be avoided by the script itself, as I already stored in sandbox (shortcut there has level 10)

I suggest:

For clear gui structuring we use the 10 levels proposed by Alexei.
For execution order we create a (project dependent) control file which defines the order of execution. Winbuilder executes the scripts following this order. Of course, if a script is not selected, is has to been skipped.
That means that no program logic, but only the user decides the order of execution!

Adding and removing scripts to/from project:
For the beginning, this control file has to be maintained by an editor. Later it is maintained by a GUI with drag'n drop or similar.

Peter

Peter
I reserved Level 3 out of "common sence considerations", now we can use it for copy&expand
However, as those scripts are "very basic" we'll be fine with "N-***" naming
Regarding controlling the sequence by "control file", I have mixed impression.
Of course, it would be perfect "final solution" to the sequencing of scripts in a strict "corporate environment", but I can hardly imagine how it can work in our situation And I don't consider end-user can manage "the order of execution".
That's why I'm proposing modification of your idea, not as good, but more realistic:
optional control file that overrides Level+alphabet sequence as needed.
Same control and flexibility, but less work, agree?

Alexei

[pscEx]

I reserved Level 3 out of "common sence considerations", now we can use it for copy&expand

Alexei, I'm surprised. It is not your usual manner to reply such inconsiderately. level 3 can be used just in case of the sample level 2. What, when it appears in level x w/o a reserved neighbour level.

That's why I'm proposing modification of your idea, not as good, but more realistic:
optional control file that overrides Level+alphabet sequence as needed.

If it can be done w/o creating problems:

And I don't consider end-user can manage "the order of execution".

That brings me to another crasy idea:
The order list of all official scripts is anywhere downloadable on the WinBuilder server, maybe ion the sandbox.
When the (stupid) end user wants to add a new script inside his project, he uses an install program which
- downloads the script
- inserts it into the control file following the 'master list' on the server.

Peter

[smiley]

When the (stupid) end user wants to add a new script inside his project, he uses an install program which
- downloads the script
- inserts it into the control file following the 'master list' on the server.

Good idea!
There is another one: Why should we have a separate file for that job? It can be a section in script.project fie!

[pscEx]

There is another one: Why should we have a separate file for that job? It can be a section in script.project fie!

Why not?

Peter

[Alexei]

If it can be done w/o creating problems:

That brings me to another crasy idea:
The order list of all official scripts is anywhere downloadable on the WinBuilder server, maybe ion the sandbox.
When the (stupid) end user wants to add a new script inside his project, he uses an install program which
- downloads the script
- inserts it into the control file following the 'master list' on the server.

Peter

Your crazy idea smells very MS
Regarding script sequesnce. Section in project is OK with me, but I still prefer it to describe only deviations from "natural" Level+Alphabet order
BTW, how you gonna refer scripts in it? I'd choose "script file name" as most stable property of the script.
Anyway, the less references the better. That's why "only deviations" is preferable

Alexei

[pscEx]

Your crazy idea smells very MS

Maybe you are right. I'm workink with MS since DOS 1.0 (If you want, I can send a copy of the one 5-1/4 '' floppy)
But is'nt it is also a little bit useful?

For the rest of your post there is a difficulty in your 'non-native' and my 'non-native' English.
Please try to explain. maybe not to bore the forum, in a PM.

Peter