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...
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
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.
Click here to see original post
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.
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.