72 replies to this topic

[pscEx]

Because they have to be cleaned at every run. If I put it on script.project I have to delete one by one the api entries wile now I just only have to delete this section and delte it from scrach.

My first idea was that every script should be able to write an api in thelist so it can be used by other scripts. If this happen it will be impossible to clean up completely.

I understand. You are right.

As you took the nativeEx core as base for your project, it seems to be easy for me to bring this API construction into nativeEx_barebone, add Nuno's LiveXP shortcut logic (add my own Copy_Expand) and offer a new API based nativeEx_barebone next days ...

@NightMan:
Think about adding your VistPE 009 beta API (I'll do so, too).
If there is no common base now, I think that it is impossible to join anywhen in the future.

Peter

[Nuno Brito]

Think about adding your VistPE 009 beta API (I'll do so, too).
If there is no common base now, I think that it is impossible to join anywhen in the future.

This would be

[NightMan]

ALL
May be first we generate common concept and only then make realization? Now we have many "common" API, but no one common ideas... Do you make API for core system or for program? What do you really need for add program to project? Program name, executable, source and destination folder, what next? We can do everything, but what we realy need and for what we do it?

[smiley]

ALL
May be first we generate common concept and only then make realization? Now we have many "common" API, but no one common ideas... Do you make API for core system or for program? What do you really need for add program to project? Program name, executable, source and destination folder, what next? We can do everything, but what we realy need and for what we do it?

Hm, Nighman you forgot the most important. Its shortcuts and autoruns! I'm sure than more will be needed in the future...

[NightMan]

Hm, Nighman you forgot the most important. Its shortcuts and autoruns! I'm sure than more will be needed in the future...

It's already presence in my API

[Nuno Brito]

ALL
May be first we generate common concept and only then make realization? Now we have many "common" API, but no one common ideas... Do you make API for core system or for program? What do you really need for add program to project? Program name, executable, source and destination folder, what next? We can do everything, but what we realy need and for what we do it?

At this moment it would be great to have an API for adding new programs.

Sorry for the delay in helping implementing and discussing this matter, lots of events happened at the same time and suddenly these sort of important things gets left behind..

A common API is more important now that ever, look at this example:

[variables]

%ProgramTitle%=Sudoku

%ProgramEXE%=sudoku.exe

%ProgramFolder%=Sudoku



[process]

Add_Shortcut,Desktop

Add_Shortcut,AutoStart

Add_Shortcut,StartMenu,Games and Fun

unpack

As minimum as possible and using very simple named vars, this is already added and working on XP/2003 projects but it's still missing VistaPE, Nighman - can you help on this part?

This is not meant to support every program, but think on the hundreds of small tools and applications that could be shared instantly created since we only need to add the new files and change the names on vars.


I know both VistaPE and nativeEx already have written API and their own way to work, but it's still too specific and we still need to double scripts to make a simple tool work on both projects.

Script levels are also different and VistaPE uses 5 while nativeEx based uses 4. Would it be possible to agree on start creating scripts based on level 5?

Just mentioning this level because I think it wouldn't make much difference for nativeEx based projects since the Finish scripts are all based on level 7 and this is right in the middle of the process (1..10).

For vistaPE the only change needed would be the adoption of an API.script written to work with VistaPE specific way of doing things.

We should start this sort of thing as soon as possible since a lot of people are already confused with all of this, what do you say?

[h7se]

This code from api.script .. LiveXP project

[AddShortcut]

echo,""

echo,"API - Creating a new shortcut for %programTitle%.. [%programFolder%\%programExe%]"

If,#1,Equal,,Set,"%shortcut_type%","DE"

If,#1,Equal,Desktop,Set,"%shortcut_type%","DE"

If,#1,Equal,StartMenu,Set,"%shortcut_type%","SM"

If,#1,Equal,QuickLaunch,Set,"%shortcut_type%","QL"

If,#1,Equal,AutoStart,Set,"%shortcut_type%","AU"

Run,%BuildModelScript%,Add-Shortcut,"%shortcut_type%\#2","#$pProgramFiles#$p\%programFolder%\%programExe%","%ProgramTitle%","-SW:#$pProgramFiles#$p\%programFolder%"

and this is the syntax used to create shortcut's

[variables]

%ProgramTitle%=Sudoku

%ProgramEXE%=sudoku.exe

%ProgramFolder%=Sudoku



[process]

Add_Shortcut,Desktop

Add_Shortcut,AutoStart

Add_Shortcut,StartMenu,Games and Fun

unpack

Now using Api's is it possible and how to create shortcut to any file outside %ProgramFiles% for example windows notepad
X:\I386\System32\Notepad.exe

[Nuno Brito]

This is good question since this API was only designed to add programs on the respective program.

A good solution doesn't involve changing anything on the current program script (script that is using the API) and apply the needed changes to support a new feature as the one you propose (also mentioned by Peter) on the api.script itself and if needed on wb as a new command to ease and speed the scripting task.

For example, on this case I miss an IF clause to check if a string is contained inside another given string and compare the path to check if %programfolder% isn't the target windows folder (or a subfolder) and if this is not the case then create by create by default a new folder under the program files directory - just a proposed solution since there are other ways, although I would also prefer to add this IF clause since I think it is well applied for this task (or others), don't you agree?


As I've mentioned earlier, a notepad or even any other OS internal file can be very specific to an OS, imagine you were trying to do a shortcut on the default help system from windows. Your API script would work on Win9x and Win2000/XP, but would fail under vista because they removed the old help system from their core.

And this is the reason why it meant to be used by simple third party programs who should be placed on the programs folder by default.

Of course this can be modified to include files on windows folder and this should be discussed further to be well implemented so please do put more questions so that we can all discuss how to solve them..

Not expecting to see an API script to add Office 2003 possible, but an API script to add Atlantis word processor would already make me very happy since I could place it on whichever project I wanted to use and see it work as expected..

[carfan]

This code from api.script .. LiveXP project

[AddShortcut]

echo,""

echo,"API - Creating a new shortcut for %programTitle%.. [%programFolder%\%programExe%]"

If,#1,Equal,,Set,"%shortcut_type%","DE"

If,#1,Equal,Desktop,Set,"%shortcut_type%","DE"

If,#1,Equal,StartMenu,Set,"%shortcut_type%","SM"

If,#1,Equal,QuickLaunch,Set,"%shortcut_type%","QL"

If,#1,Equal,AutoStart,Set,"%shortcut_type%","AU"

Run,%BuildModelScript%,Add-Shortcut,"%shortcut_type%\#2","#$pProgramFiles#$p\%programFolder%\%programExe%","%ProgramTitle%","-SW:#$pProgramFiles#$p\%programFolder%"

and this is the syntax used to create shortcut's

[variables]

%ProgramTitle%=Sudoku

%ProgramEXE%=sudoku.exe

%ProgramFolder%=Sudoku



[process]

Add_Shortcut,Desktop

Add_Shortcut,AutoStart

Add_Shortcut,StartMenu,Games and Fun

unpack

Now using Api's is it possible and how to create shortcut to any file outside %ProgramFiles% for example windows notepad
X:\I386\System32\Notepad.exe

question for clarification - if i am using lixexp 71b5 and wanted to run a batch file as the executable but point the desktop short to an .ico in the same directory how would i change the api and then do i add
the api text to the batch files script or what. i'm not sure how to use the api i script. i need simple explination. nativeex handles .ico redirect on its own from batch files script. liveex not handling this on its own. please help.

thanks
carfan

[h7se]

This is good question since this API was only designed to add programs on the respective program.

A good solution doesn't involve changing anything on the current program script (script that is using the API) and apply the needed changes to support a new feature as the one you propose (also mentioned by Peter) on the api.script itself and if needed on wb as a new command to ease and speed the scripting task.

For example, on this case I miss an IF clause to check if a string is contained inside another given string and compare the path to check if %programfolder% isn't the target windows folder (or a subfolder) and if this is not the case then create by create by default a new folder under the program files directory - just a proposed solution since there are other ways, although I would also prefer to add this IF clause since I think it is well applied for this task (or others), don't you agree?
.

i don't know but way not just use a relative path SystemDrive instead of ProgramFiles ?

As I've mentioned earlier, a notepad or even any other OS internal file can be very specific to an OS, imagine you were trying to do a shortcut on the default help system from windows. Your API script would work on Win9x and Win2000/XP, but would fail under vista because they removed the old help system from their core
And this is the reason why it meant to be used by simple third party programs who should be placed on the programs folder by default.

forget about notepad suppose someone want to place his App's in X:\MyApps

[Nuno Brito]

Carfan, this API doesn't cover (yet) those cases in particular, just a generic application. The feature you're asking is very specific and should be adressed with the specific project tools for this project in particular - buildmodel on this case.

i don't know but why not just use a relative path SystemDrive instead of ProgramFiles ?

And why wouldn't we use the Program Files folder?

This is a script meant for "basic" programs which are all placed by default under the Programs folder. If the program can't be placed there then chances are that it would be better to not use API at all and just work only on a fixed type of project.

This method is very simple to code and even more simple to work with, so why complicate with these often rare cases?

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


I thought wb was meant to be flexible, why should our scripts be written to run only on a single project?

[h7se]

Now using Api's is it possible and how to create shortcut to any file outside %ProgramFiles% for example windows notepad
X:\I386\System32\Notepad.exe

This is good question since this API was only designed to add programs on the respective program.

A good solution doesn't involve changing anything on the current program script (script that is using the API) and apply the needed changes to support a new feature as the one you propose (also mentioned by Peter) on the api.script itself and if needed on wb as a new command to ease and speed the scripting task.

For example, on this case I miss an IF clause to check if a string is contained inside another given string and compare the path to check if %programfolder% isn't the target windows folder (or a subfolder) and if this is not the case then create by create by default a new folder under the program files directory - just a proposed solution since there are other ways, although I would also prefer to add this IF clause since I think it is well applied for this task (or others), don't you agree?

i don't know but way not just use a relative path SystemDrive instead of ProgramFiles ?

And why wouldn't we use the Program Files folder?

LiveXP project .. Api.script

[AddShortcut]

echo,""

echo,"API - Creating a new shortcut for %programTitle%.. [%programFolder%\%programExe%]"

If,#1,Equal,,Set,"%shortcut_type%","DE"

If,#1,Equal,Desktop,Set,"%shortcut_type%","DE"

If,#1,Equal,StartMenu,Set,"%shortcut_type%","SM"

If,#1,Equal,QuickLaunch,Set,"%shortcut_type%","QL"

If,#1,Equal,AutoStart,Set,"%shortcut_type%","AU"

Run,%BuildModelScript%,Add-Shortcut,"%shortcut_type%\#2","#$pProgramFiles#$p\%programFolder%\%programExe%","%ProgramTitle%","-SW:#$pProgramFiles#$p\%programFolder%"

just an idea maybe i'm thinking in a wrong way but can't we can solve the problem by changing "#$pProgramFiles#$p with "#$pSystemDrive#$p in the last line

[pscEx]

Run,%BuildModelScript%,Add-Shortcut,"%shortcut_type%\#2","#$pProgramFiles#$p\%programFolder%\%programExe%","%ProgramTitle%","-SW:#$pProgramFiles#$p\%programFolder%"[/code]

just an idea maybe i'm thinking in a wrong way but can't we can solve the problem by changing "#$pProgramFiles#$p with "#$pSystemDrive#$p in the last line

In nativeEx I use %PE_Programs%
with %PE_Programs% = #$pSystemDrive#$p\<native programs folder name>

Peter

[Nuno Brito]

Then the nativeEx api.script should be adapted to work with %PE_Programs%..

[pscEx]

Then the nativeEx api.script should be adapted to work with %PE_Programs%..

If LiveXP uses the nativeEx_Core (see here), then %PE_Programs% is defined in script.project and you just have to change
the LiveXP api.Script accordingly.

Peter

[Nuno Brito]

Awesome..

[pscEx]

I have troubles with CAPI version 22.

In the nativeEx project, the UniversalVideoDriver.Script is not installed to PE.

CAPI gives the warning:

Run - Processing section: [Arch_check] From file: [%BaseDir%\Projects\nativeEx_barebone\Basic\Build\Common_Api.script]
[Parameter] with parameters: [x86]
[Success] IF - [x86] is equal to: [x86] evaluated string: [If,#1,Equal,x86,If,Not,%TargetWOW64%,Equal,x86,Exit,"%ProgramTitle% requires WOW64 for PE x64/IA64"]
[Success] IF - [%TargetWOW64%] is not equal to: [x86] evaluated string: [If,Not,%TargetWOW64%,Equal,x86,Exit,%ProgramTitle% requires WOW64 for PE x64/IA64]
[Warning] hostNIC requires WOW64 for PE x64/IA64
Run - Processed section [Arch_check] in file: [%BaseDir%\Projects\nativeEx_barebone\Basic\Build\Common_Api.script]

The source is x86 and therefore no reason to warn.

Appearently here CAPI uses the variable %TargetWOW64% which is only known in LiveXP.

For "Common API" that is a bug which must be fixed.

Peter

[pscEx]

Appearently here CAPI uses the variable %TargetWOW64% which is only known in LiveXP.

For those who do not know: LiveXP uses most core functions of nativeEx and therefore can be named as 'child' of nativeEx.

If you have a look into the list of members which saw this post today, there is also at least one of the developers which created this incompatibility.
I expected that he / she / they answered "Let's try to solve this incompability".
Ignoring is not a productive response!

And because an cooperating answer did not come, I decided to solve the incompatibility by changing the script in nativeEx and upload to the nativeEx server.
And from now on, LiveXP as nativeEx - child (due to this topic) becomes incompatible with parent.

Peter

[Wonko the Sane]

If you have a look into the list of members which saw this post today, there is also at least one of the developers which created this incompatibility.
I expected that he / she / they answered "Let's try to solve this incompability".
Ignoring is not a productive response!

Maybe 5 hours is a bit narrow time slot, and he/she had something to do in his/her real life that couldn't be postponed to start to try and help solving this problem.

I see that , as well as Rules, also the "common sense advice" ( specifically point #b ) has been wasted presses on the keyboard.

And because an cooperating answer did not come, I decided to solve the incompatibility by changing the script in nativeEx and upload to the nativeEx server.
And from now on, LiveXP as nativeEx - child (due to this topic) becomes incompatible with parent.

Hmm, what will be next?

I presume next step in this escalation of hostilities will be that each project will detect the presence on the user HD of the "other one" and put the PC to fire.

Coooome on peeps , is there really need for the exchange of such niceties?

I mean, fights from time to time are a good thing because soon after they are over (quickly) you are able to better appreciate peace. \V/



Wonko

[dera]

CAPI version 22 ???
i always thought that the author of the 'Common_Api.script' is Pedro Le 15
who seems is away for a while
and here the latest version is Version=21

[olegpov]

At me a presentiment of the beginning of the next war

For those who do not know: LiveXP uses most core functions of nativeEx and therefore can be named as 'child' of nativeEx.

If you have a look into the list of members which saw this post today, there is also at least one of the developers which created this incompatibility.
I expected that he / she / they answered "Let's try to solve this incompability".
Ignoring is not a productive response!

And because an cooperating answer did not come, I decided to solve the incompatibility by changing the script in nativeEx and upload to the nativeEx server.
And from now on, LiveXP as nativeEx - child (due to this topic) becomes incompatible with parent.
Peter

Peter you also are right and not right simultaneously:
Yes it is a bug in CommonAPI, yes incompatibility in projects, yes it is necessary to correct;
But those who can probably correct this mistake and place new scripts on a server now are borrowed by another matters and it is necessary to wait. If the person has seen your message it attention means has paid to it.

Appearently here CAPI uses the variable %TargetWOW64% which is only known in LiveXP.

At me a simple question why to not add this variable in the PARENTAL project?

[Wonko the Sane]

CAPI version 22 ???
i always thought that the author of the 'Common_Api.script' is Pedro Le 15
who seems is away for a while
and here the latest version is Version=21

Hey, dera, did you miss this one (for a bit of fun on CAPI versioning)?

http://www.boot-land...showtopic=10376

Wonko suggested a possible solution:
http://www.boot-land...?...10376&st=33
he even offered his build:
http://www.boot-land...?...10376&st=38
but unfortunately that version is lost forever and all that remains is the cover of
http://www.boot-land...?...10376&st=44
CAPI v16Alpha1rev2RC0.3*1/3.15.


Wonko

[pscEx]

At me a simple question why to not add this variable in the PARENTAL project?

Because PARENTAL project has a variable %SourceArch% for that, and CHILD project created a new variable

Set,%TargetWOW64%,%SourceArch%,PERMANENT

In Basic\Build\0 - OnProjectRun.script, inspite %SourceArch% is used 360 times in the "recommended" project configuration.
Sorry, I currently do not see any reason to use the LiveXP specific %TargetWOW64% in COMMON(?) api, when the same information in all nativeEx based projects is in %SourceArch%.

And sorry again: Also %SourceArch% should not be used in COMMON(?) api, because it may be unknown e.g. in Vista, Win7 etc. projects.
Here is just a mistake to define the LiveXP specific Arch macro in CAPI.
That macro should disappear in CAPI, and could be redefined in every project which wants to use it.
But please avoid in "Non-LiveXP" "universal" scripts like UniversalVideoDriver.Script which is originated in nativeEx and which is intended to be used through different projects.

Peter

[pscEx]

CAPI version 22 ???
i always thought that the author of the 'Common_Api.script' is Pedro Le 15
who seems is away for a while
and here the latest version is Version=21

Maybe it depends that for me I fixed already some bugs. Then I increase my version number, not to confuse with the official version.
And maybe I already suggested Pedro the fixed version anywhere ...

Peter

[olegpov]

Here is just a mistake to define the LiveXP specific Arch macro in CAPI.
That macro should disappear in CAPI, and could be redefined in every project which wants to use it.
But please avoid in "non-LiveXP" "universal" scripts like UniversalVideoDriver.Script which is originated in nativeEx and which is intended to be useed through different projects.

Peter

The wise answer, here I with you agrees 100 %