API futures 2011

Since we are like-minded about the need to improve app scripts, I would suggest Sbaeder to open a new topic where we can define a set of standards to be uphold on API commands.

If we don't, we will risk seeing app scripts moving away from the principles that make life easier for everyone who writes scripts.

OK... To summarize the discussion from another post (where we got a bit off the original topic), this is opened to discuss some thoughts and create an action plan for dealing with the "common" API.

As we start a new year, it seem only fitting that we go back and see if there are things to improve upon. Clearly, maintenance and enhancements to the API are important to all of us. Since when doing a clean up, it is difficult to catch all the places thigns are used (as per the recent discussion), it is probably a good time to discuss some alternatives to the current situation.

So, with that - let the comments (constructive discussion ONLY) begin...

Scott

API_PE1x
API_PE2x
API_PE3x


Wonko

(This suggestion is logically very equal to Paraglider's suggestion).
I have some concerns.

Let me try to explain my concerns on the "ShortCut" function.

Currently we have two, and only two different functionalities (%API_Type%s):

• XP, "Create shortcut during PE build" nativeEx buildModel functionaliy, invented by me.
  During introduction, XP has been the only possible M$ OS for the actual project.
• Vista/Win7, "Create shortcut during PE boot" functionaliy, invented by NightMan.
  During introduction, Vista has been the only possible M$ OS for the actual project.

Currently the API decides (by querying %API_Type%) about using "during PE build" and "during PE boot".
IMO the Project should decide, which shortcut creation functionality it wants to use.
(For experienced users: In my nativeEx_easyPE project, working with XP and Win7 sources, only the "Create shortcut during PE build" is used.)

My suggestion:
Move parts of the "hardcoded" [APIVAR] section of common_api_script into the individual project.script.
Then it is possible to define e.g.

Add_Shortcut=Run,%MyProject%,AddShortcut

Peter

(This suggestion is logically very equal to Paraglider's suggestion).

It is actually the SAME, that I already endorsed with the motto

"Common sense" applied to "common API"

As said in the original thread:

Wonko approves of this

but since we need to discuss it on a new thread, here it is re-peated.

The issue is that a "common something" cannot be "racist" or "classist" and check which projects uses it.

Another approach is having a single actually really "common" API and a "middleman" app/API/dll/whatever that does the functions stripped from the "common API" as they are "peculiar" or "specific" (as opposed to "common"), or, as you propose, including these stripped functions from the API and insert them in projects.


Wonko

You should read topics with more technical understanding. (That you read them carefully, is well known).
Maybe you should distinguish between "project makes a choice of API (e.g.) shortcut method" and "project writes it's own (e.g.) shortcut method".

So, with that - let the comments (constructive discussion ONLY) begin...

You persuaded me that my opinion is not constructive. I'm going to draw the consequences, and there is nothing more to be added by me in this topic.

Peter

a single API using additional parameters (today with %API_Type%) or multiple APIs by PE1-2-3 projects or for specific project APIs, we can discuss long, and nobody will completely right or wrong.
Just to take in consideration, there are common sense and then adjustments (limp). To have three Api's going to cause a risk of desynchronization of functions in the future, according to the author.
It is good to have scripts that can work in PE1-2-3 even if it is not always possible with the same APIs function.

It is good to have scripts that can work in PE1-2-3 even if it is not always possible with the same APIs function.

Yes, some people here are forgetting that the purpose of an API is to isolate an app script from the project where it is running.

If we want to add a shortcut, we ask to add a shortcut.

Nothing more, nothing more simple than that for app scripts.

[main]

Title=Sudoku

Description=The popular number game

Level=5



[variables]

%ProgramTitle%=Sudoku

%ProgramEXE%=sudoku.exe

%ProgramFolder%=Sudoku



[process]

Add_Shortcut,Desktop

Add_Shortcut,AutoStart

Add_Shortcut,StartMenu,Games and Fun

unpack

App scripts should be lightweight and portable.

For example, people requested support for specifying special icons inside the executable.

A far simpler solution would be adding a new variable as %icon% and point to an external icon image provided by the script author. This simple measure alone would have saved us from a very messy syntax that is now employed for icons.

So, let's keep the API circumscribed to a few commands with few switches to ensure that things are kept simpler.

This also makes the API simpler to manage and port to other projects in the future.

----------

I don't really want to hear about %API_type% inside an app script, this is not the way to code in the long run.

(This suggestion is logically very equal to Paraglider's suggestion).
I have some concerns.

Let me try to explain my concerns on the "ShortCut" function.

Currently we have two, and only two different functionalities (%API_Type%s):

• XP, "Create shortcut during PE build" nativeEx buildModel functionaliy, invented by me.
  During introduction, XP has been the only possible M$ OS for the actual project.
• Vista/Win7, "Create shortcut during PE boot" functionaliy, invented by NightMan.
  During introduction, Vista has been the only possible M$ OS for the actual project.

OK, for someone who hasn't really been doing this all that long, WHY is it that only the XP OS can do it at the build of the image? Or as you imply below, it could be done either way? (in any of the OSs we want to support - XP, Vista, 7)

Currently the API decides (by querying %API_Type%) about using "during PE build" and "during PE boot".
IMO the Project should decide, which shortcut creation functionality it wants to use.
(For experienced users: In my nativeEx_easyPE project, working with XP and Win7 sources, only the "Create shortcut during PE build" is used.)

I can understand WHY you might want to have it either way, but again, not sure that a script SHOULD care or that it is (as you suggest) a choice of the project and not the API - but even with that, is that a reason to make it be a part of the project?

My suggestion:
Move parts of the "hardcoded" [APIVAR] section of common_api_script into the individual project.script.

Seems to me that we should be able to pick ONE way of doing it - OR - make it somehow be a choice (i.e. two API calls?)

It also seems to me we should possibly have a way for a project to replace an API call (like a linker taking one routine from a local library, and the rest from some global library...

Anyway, this is a good thing to discuss - i.e. implementation details are sometimes just as important as the process of managing the API.

Scott

Peter,

I don't think anyone was saying your comments don't have any merit, but in the broader context (as the other later posts also state), we need to think about the consumer of the API, and for the most part, that is the APP scripts. Yes, the API functions are also useful for the base project scripts, but as Nuno stated

So, let's keep the API circumscribed to a few commands with few switches to ensure that things are kept simpler.

This also makes the API simpler to manage and port to other projects in the future.

I don't really want to hear about %API_type% inside an app script, this is not the way to code in the long run.

Hopefully we all agree on that...

i.e. we don't want APP scripts (or even projects??) from dealing with what "type" of a thing are they if at all possible. And a few good commands is what we need, and the list we have seems like a pretty good start...But, when I took a look at the current script,
it made my head hurt!...Do we really need over 4000 lines in a single file to define only 23 functions?

And maybe we have a way to allow a project - or even a script - to use their own implementation of a function, which (at least as I understand it) is nothing more than a subroutine call to a named section of a different file and we just treat the API as defined by %API% as the more globally applicable way...

So, there is room (I think) for an approach that has something like Peter suggested...

My suggestion:
Move parts of the "hardcoded" [APIVAR] section of common_api_script into the individual project.script.
Then it is possible to define e.g.

Add_Shortcut=Run,%MyProject%,AddShortcut

Peter

Thanks
Scott

Yes, I agree that parts of the API can be broken as needed across the project.

What really matters is that the app scripts remains agnostic to the project and don't worry themselves about any given project API implementation.

For example, people were using RegAddBoot inside app scripts to create shortcuts: http://reboot.pro/13529/ instead of relying on the standard API command of add_shortcut.

I've done a small diagram to help explain that it doesn't really matter if people use buildmodel, shortcuts.exe or any other way of building shortcuts as long that respect and understand the add_shortcut command on the other side at the app.script

Each project can have it's own implementation, just let app scripts be generic and don't depend on any single project type.


This way there is no need to write them again in the future just to match project of type X, Y or Z. I'm adding diagrams since there is some confusion regarding what type of commands should be on either sides of the API.

i.e. we don't want APP scripts (or even projects??) from dealing with what "type" of a thing are they if at all possible. And a few good commands is what we need, and the list we have seems like a pretty good start...

the apitype only needs to be defined 1 time in script.project it simply tells the api what functions to call. for example. Add_shortcut is done differently for XP and Vista/7 if you look in the [ApiVar] section for CommonAPI we see that the correct process for that project is called based on the value of APITYPE that is set in the script.project.

a PE1 based project like Galapo's LiveXP difiens %apitype%=1 in script.project and when CommonAPI is called for Add_Shortcut the "function" AddShortcut1 is called. likewise for Win7 AddShortcut2 would be called. there should never bee a need to change %apitype%

But, when I took a look at the current script,
it made my head hurt!...Do we really need over 4000 lines in a single file to define only 23 functions?

no.
there are actually 41 functions that can be called from the magic wand
~300 lines are definitions for the magic wand, context help, and pointers for calling the correct process for each (project)apitype
~500 lines are for the script interface options and the auto download/update function and the help file download/read
~500+ lines are documentation and revision history (which could probably be better placed in another file and encoded. but they need to stay with the API)

most of the bulk comes from the Unpack functions as there are lots of options (extract,unzip,download,etc.) and the wb script language is pretty clumsy and inefficient for complex scripting of functions, options, etc. as well as a lack of string processing functions such as handling Regular Expressions. resulting in the need to have a "function" for each possible combination of options.

another large chunk is handling of expansion/requirement of files as depending on the sourceArch files from wow64 are handled as well. for supporting 32bit apps in an x64 build. now before we get into a discussion about why anyone would want a x64 build with little to no benefits and more drawbacks over x86 PE builds remember that some people may only have a x64 windows cd supplied with their computer.

@ Nuno

I have never seen RegAddBoot used for creating shortcuts. and if it was used by someone that was their mistake, RegAddBoot was never designed for that.

the apitype only needs to be defined 1 time in script.project it simply tells the api what functions to call. for example. Add_shortcut is done differently for XP and Vista/7 if you look in the [ApiVar] section for CommonAPI we see that the correct process for that project is called based on the value of APITYPE that is set in the script.project.

a PE1 based project like Galapo's LiveXP difiens %apitype%=1 in script.project and when CommonAPI is called for Add_Shortcut the "function" AddShortcut1 is called. likewise for Win7 AddShortcut2 would be called. there should never bee a need to change %apitype%

But my quest for knowledge was does it have to be that way? Or was this (as Peter implied above) more of an implementation choice to do it as part of the build vs. part of the booting?

And even if it is something architectural between a PE1 vs. a PE2/3 project, isn't that something that could be figured out based on the "source" of the content being used.

there are actually 41 functions that can be called from the magic wand

Not sure how you count vs. how I count - but, let's not argue that...

~300 lines are definitions for the magic wand, context help, and pointers for calling the correct process for each (project)apitype
~500 lines are for the script interface options and the auto download/update function and the help file download/read
~500+ lines are documentation and revision history (which could probably be better placed in another file and encoded. but they need to stay with the API)

That's 1300+ off the top, but still a pretty big file that has to be loaded, and even parsed to get to all the routines any time they are accessed.

another large chunk is handling of expansion/requirement of files as depending on the sourceArch files from wow64 are handled as well. for supporting 32bit apps in an x64 build. now before we get into a discussion about why anyone would want a x64 build with little to no benefits and more drawbacks over x86 PE builds remember that some people may only have a x64 windows cd supplied with their computer.

OK - I don't understand that statement totally, so I need to go back to the code and try to "grok" it. But I do believe that an X64 based PE might be needed at some point, so it's important to handle it as clean as we can.

So, are you (as someone I have seen has a good background in all of this and a level head) suggesting that we split it? Find a way to group and manage smaller parts of it and assemble a "library" or something else???

the apitype only needs to be defined 1 time in script.project it simply tells the api what functions to call.

Sure, place this definition wherever a project author desires.

Just don't place this type of commands inside an app script.

I have never seen RegAddBoot used for creating shortcuts. and if it was used by someone that was their mistake, RegAddBoot was never designed for that.

It is a VistaPE inheritance since 2007 that is starting to be used on Win7PE as well.

We really don't need it inside any app script and I see that the diagram had the positive effect of demonstrating why.

most of the bulk comes from the Unpack functions as there are lots of options (extract,unzip,download,etc.) and the wb script language is pretty clumsy and inefficient for complex scripting of functions, options, etc. as well as a lack of string processing functions such as handling Regular Expressions. resulting in the need to have a "function" for each possible combination of options.

There will be no more "complex" scripting functions.

.script syntax is supposed to be simple. For regular expression processing and the such, use autoIt or any other compiled binary that works for your purposes.

We will not be adding more bulk to the engine. Saying "yes" to this kind of requests is what got us in this mess to begin with.

We need an simple and stable engine to build boot disks and that is what we'll deliver.

But my quest for knowledge was does it have to be that way? Or was this (as Peter implied above) more of an implementation choice to do it as part of the build vs. part of the booting?

And even if it is something architectural between a PE1 vs. a PE2/3 project, isn't that something that could be figured out based on the "source" of the content being used.

no it doesn't have to be that way, but it is the way that makes the most sense. it could be sorted out based on the source but they you are calling another function that would either have to be called every time you called an api funciton or set the var GLOBAL the fist time it is run. this is actually done if %apivar% is not defined (line 495: If,Not,ExistVar,%API_TYPE%,Run,%Api%,Set_Api_Type_Find_API_TYPE,#1,#2,#3,#4,#5,#6,#7,#8,#9) where it tries to guess the project type. either way having apitype manually set in script.project it the way that makes the most sense and requires the least amount of overhead. apitype is static and should never need to change!!!

Not sure how you count vs. how I count - but, let's not argue that...

_Calculate

Add_Asso

Add_Shortcut

Add_Pin

Add_URL

AddAutoRun

AddPostConfig

AddPreConfig

AddToPEShell

Arch

Ask_License

associate_file

CapiC

CheckCD

CopyProgram

ExtractAndRunc

ExtractAndRunx

hive_load

hive_unload

Compatibility

Not_Compatible

Process_log

reg_add

reg_del

RegAddBoot

Register_File

Require_FileQ

Require

Require_File

Unpack

RunFromRam

RunFromCD

ReadENV

RequireSysFile

ShowComponent

CopyDrv

Select_Case

RunOnce

InFSetup

GetInterface

WriteInterface

So, are you (as someone I have seen has a good background in all of this and a level head) suggesting that we split it? Find a way to group and manage smaller parts of it and assemble a "library" or something else???

I don't know that splitting it off is the right answer. then we go back to the old way of having separate api's for each project type which resulted in confusion and inconsistencies. that is why everything was combined in the 1st place. to have a single api where all the syntax was the same but different methods could be transparently used to achieve the results, based on the needs of the project.

the current api really isn't that bad. it looks like a mess to someone who hasn't spent some time working with it, but that is largely due to the limitations of wb's syntax and processing capabilities. if you spend some time understanding it it is actually pretty well organized considering this.
I don't think the leopard specific stuff should be in there though, as there is nothing common to the other projects about it.

Sure, place this definition wherever a project author desires.

Just don't place this type of commands inside an app script.

agreed. it has no place or reason to be in an app script.

It is a VistaPE inheritance since 2007 that is starting to be used on Win7PE as well.

We really don't need it inside any app script and I see that the diagram had the positive effect of demonstrating why.

I have never seen RegAddBoot used to make shortcuts. nor is is used in the common api to do so.
in fact the only time common api calls RegAddBoot internally is to register shell context commands

Run,%API%,RegAdd_boot_%Capi_RegAddBootMethod%,HKLM,0x2,Software\Classes\*\shell\#2#$s#4\command,,"#3 #$q#$p1#$q"

please provide a list of scripts of what you are referring to and if it is used in Win7PE_SE I will see that it gets corrected.
I'm all for removing redundant functions if they can be done better another way. personally I have only seen RegAddBoot used in rare situations where the normal reg_add method failed to work and RegAddBoot did work.

There will be no more "complex" scripting functions.

.script syntax is supposed to be simple. For regular expression processing and the such, use autoIt or any other compiled binary that works for your purposes.

We will not be adding more bulk to the engine. Saying "yes" to this kind of requests is what got us in this mess to begin with.

We need an simple and stable engine to build boot disks and that is what we'll deliver.

agreed. I didn't ask for more complex functions. I was only providing the reasoning behind the large amount of commands for various common api functions. I am still experimenting with converting more complex common api functions to autoit to see if it provides a reasonable alternative to using native wb script.

The same goes for defining if an app script should define preference to run in RAM or not. But that is the subject for another topic.

Click here to see original post

the reason behind this is simple. some programs need to reside on a writable location. on Vista/Win7 projects this writable location is on the system drive which is packed in a .wim file.
this works very well if the media is a CD/DVD as the .wim is loaded into RAM. (hence the term "run from RAM")

now consider that the media is not on a CD/DVD but rather a USB flash drive or external harddrive. these drives unlike a CD/DVD are writable and so it is not necessary to have them loaded into RAM to be mounted on writable partition. by choosing "run from disk" your program settings, virus definitions updates, etc. persist every time you boot instead of being lost on shutdown. you also have more free RAM available to the system because of a smaller .wim mounted, as well as the ability to update the program/virus definitions/etc by coping the files directly to the program folder without going through the hassle of mounting the .wim, updating files, and repacking the .wim.

the option is not needed for scripts that don't need writable program dirs, but for those that do the option is very nice for the reasons stated above.

OK, thanks - I was counting the top level things on the magic wand... ...But it looks as if a few you list are still MIA from the wand...

CheckCD         

ExtractAndRunx  *Ok, this is partly there in the wand, but somewhat cryptic *if you ask me)

ShowComponent   

But I humbly stand corrected in that there was a hidden (to me) hierarchy on the wand...

But and other question to learn more - is there any doc files on the API? if so, should they be linked to the API's interface?

I don't think the leopard specific stuff should be in there though, as there is nothing common to the other projects about it.

Again, as a relatively new follower (post the vista time frame), which sorts of things are "leopard specific" out of that list above...I take it from the comments made that something like RegBoot probably shouldn't be considered a "common" API level item.

I am still experimenting with converting more complex common api functions to autoit to see if it provides a reasonable alternative to using native wb script.

I guessing you mean to just execute it as an external command - right? So could be any sort of a compiled program - although something like autoit is a good choice here given what it was designed to do...

Again, thanks for the information - it's helpful (at least to me), and I will spend some more time with the API trying to understand it better...

Scott

Replacing a common api call with a execute of an exe may be ok for executing a command that is only executed a small number of times during a build. There is quite a large overhead in launching an exe.

I think a better idea would be for winbuilder to provide an api function to execute a function in a dll. Once a dll is loaded into the the winbuilder address space then its easy for winbuilder to ensure it stays loaded. An inprocess dll function has a much lower call overhead, except for the first load of the dll, than launching an exe.

I think a better idea would be for winbuilder to provide an api function to execute a function in a dll. Once a dll is loaded into the the winbuilder address space then its easy for winbuilder to ensure it stays loaded. An inprocess dll function has a much lower call overhead, except for the first load of the dll, than launching an exe.

Yes, this had been proposed before.

From my side I never tried such thing but perhaps Peter can help or we can see how this kind of feature can be implemented.

Please open a new topic at the requests subforum so that we can keep it in mind and update as development on this goal progresses.

Yes, this had been propose before.

From my side I never tried such thing but perhaps Peter can help or we can see how this kind of feature can be implemented.

Please open a new topic at the requests subforum so that we can keep it in mind and update as development on this goal progresses.

I thought already about it, but I gave up tryi8ng to make a fast enhancement.

The main reason is that delphi cannot pass strings to DLLs. You have to allocate memory, copy the string into it, and then pass the memory adress to the DLL.
The DLL again has to build the string from memory.

For one special case this may be the work worth.

But we need DLL call commands with variable number of arguments, with variable types of arguments, etc.

Peter

But and other question to learn more - is there any doc files on the API? if so, should they be linked to the API's interface?

yes there is some documentation. press the "Help by Paraglider" button on the Common_Api interface and look under the Common API tree. most of the functions are documented quite well by Pedro Le 15 the original author. there are a few things missing but they are mainly "beta" features. There is also various notes in the code itself if you are interested in how something works or why it was done the way it was. the code documenting is a work in progress and being worked on by lancelot, galapo, and myself.

Again, as a relatively new follower (post the vista time frame), which sorts of things are "leopard specific" out of that list above...I take it from the comments made that something like RegBoot probably shouldn't be considered a "common" API level item.

RegAddBoot is actually a good example of a common level command. it can be used in LiveXP/VistaPE/Leopard/Win7PE(_SE) although the implementation in the api code is different.

leopard specific functions are

CheckCD
RunOnce
InfSetup

I guessing you mean to just execute it as an external command - right? So could be any sort of a compiled program - although something like autoit is a good choice here given what it was designed to do...

sort of. although from what I have found and what Galapo has found is that like paraglider said. its not very efficient and has little if any speed improvements by the time you are done reading/writing values back and forth to .ini. also you have the issue of not being able to log to winbuilder's build log, which makes general troubleshooting difficult.

it really wouldn't matter what language the program or dll is written in. Autoit is nice because it is relativity easy to use and understand and is also free and requires no additional run-times or complex development environments. but if your going to make a dll c++ is really the way to go.

the reason behind this is simple. some programs need to reside on a writable location. on Vista/Win7 projects this writable location is on the system drive which is packed in a .wim file.
this works very well if the media is a CD/DVD as the .wim is loaded into RAM. (hence the term "run from RAM")

now consider that the media is not on a CD/DVD but rather a USB flash drive or external harddrive. these drives unlike a CD/DVD are writable and so it is not necessary to have them loaded into RAM to be mounted on writable partition. by choosing "run from disk" your program settings, virus definitions updates, etc. persist every time you boot instead of being lost on shutdown. you also have more free RAM available to the system because of a smaller .wim mounted, as well as the ability to update the program/virus definitions/etc by coping the files directly to the program folder without going through the hassle of mounting the .wim, updating files, and repacking the .wim.

the option is not needed for scripts that don't need writable program dirs, but for those that do the option is very nice for the reasons stated above.

I already suggested "Writable" as option rather than "In RAM" / "On CD" (http://reboot.pro/27...post__p__115109)
But unfortunatelly that has not been accepted by Galapo.

Let's think again about the "Writable" option!

Peter

It is a VistaPE inheritance since 2007 that is starting to be used on Win7PE as well.

We really don't need it inside any app script and I see that the diagram had the positive effect of demonstrating why.

I don't see how you create a registry entry with a drive letter that isn't known at build time without RegAddBoot.

RegAddBoot,"HKLM",0x2,"Software\Classes\*\shell\Edit with Notepad++\command","","%PE_Programs%\%ProgramFolder%\%ProgramEXE% #$q%1#$q"

RegAddBoot is actually a good example of a common level command. it can be used in LiveXP/VistaPE/Leopard/Win7PE(_SE) although the implementation in the api code is different.

Sorry but it is not a good example of how app scripts should be written.

You are using it for shell extensions and shortcuts while we already have reg_add and add_shortcut for that purpose.

It has been gradually been deprecated across active app scripts as demonstrated at:

[Registry_ShellContextMenu]

Hive_Load,Software

//RegAddBoot,HKLM,0x1,Software\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}\InprocServer32,,%PE_Programs%\%ProgramFolder%\7-zip.dll

Reg_Add,0x2,%reg%\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}\InprocServer32,,%PE_Programs%\%ProgramFolder%\7-zip.dll

//RegAddBoot,HKLM,0x1,Software\7-Zip,Path,%PE_Programs%\%ProgramFolder%

reg_add,0x2,%reg%\7-Zip,Path,%PE_Programs%\%ProgramFolder%

http://livexp.boot-land.net/LiveXP/Apps/File%20Tasks/Compression/7-Zip_File_Manager_SJL.script

I don't see how you create a registry entry with a drive letter that isn't known at build time without RegAddBoot.

You want to keep shortcuts flexible to adapt to new mediums and that is important. But understand that it should be the project itself to make that decision on a higher level and not the app script.

I'm not against creating shortcuts on boot time but I do am against seeing app scripts specifying them to be built in that specific way when we see it being misused so often.


If you force an app script to depend on RegAddBoot to create a shortcut, you are forcing project developers to also read the registry and only have a fixed format of data that may not be suited for their project at all.

To keep things flexible an option such as "RunFromRAM" equivalent for shortcuts would likely be a better approach than raw editing such things since we are trying to uphold an abstraction layer that gives freedom of implementation for project developers.


Imagine for example that a project author wants that each app script to be not only installed on the target OS that is being built but also wants shortcuts for launching them from pStart as portable apps or even create xoblite entries.

On this case, you are making everyone's life more difficult when avoiding add_shortcut that can be modified to suit a given project needs.

I hope this makes more clear why RegAddBoot should remain deprecated and not recommended for future specifications of the app script API.



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

I already suggested "Writable" as option rather than "In RAM" / "On CD"

The term is indeed strange but homes32 arguments describe accurately the reality.

There are advantages both on RAM usage and booting speed for placing "bulk" applications such as Open Office on the USB media rather than RAM.

If you specify simply as "writable", you're not being explicit enough since RAM loaded disks is also writable.

Edited by Nuno Brito, 05 January 2011 - 07:48 PM.

I don't see how you create a registry entry with a drive letter that isn't known at build time without RegAddBoot.

RegAddBoot,"HKLM",0x2,"Software\Classes\*\shell\Edit with Notepad++\command","","%PE_Programs%\%ProgramFolder%\%ProgramEXE% #$q%1#$q"

You are right!

But with 'nativeEx_easy??' I'm working on that. And because I'm an optimistic person: Wait a bit, and you'll have the solution.

Peter

If you specify simply as "writable", you're not being explicit enough since RAM loaded disks as also writable.

Isn't the argument that it has to be guaranteed to be "writeable" (for an application that needs to be able to write ini files, or ???) And yes, a USB media is writable, even if we call it "onCD" So what we are sort of talking about here is if it needs to be in the ramdisk image (taking a more PE2/3 view of things...not sure how you manage that in a PE1 environment?)

So for now, I am perfectly OK with those variables as is, since most of us understand what they mean...maybe just some better guidelines on them would be helpful.

You want to keep shortcuts flexible to adapt to new mediums and that is important. But understand that it should be the project itself to make that decision on a higher level and not the app script.

I wote "registry entry", not "shortcut". Do you want the project or WinBuilder to parse every registry entry to separate those which are known at build time and those which are not known at build time? Really? Or do you want the script developer who knows the answer to tell the project or WinBuilder what to do? How would you handle the example I gave without RegAddBoot?