40 replies to this topic

[larioteo]

@homes32 See it so:

The fact that it is nearly in every script active and that this scripts will for sure not change in near future. is also the fact that if you want to use someones work you need to implement the CAPI and if you rewrite it for your project you will get attacks "why not say thanks" blablabla.

And i have already shared something, maybe you should take a look before attacking also me. I see you in the middle of this the oven and reboot and i also known that i will get from you an answer.

If CapiC is to remove than just do it, why to wait? Otherwize there will be more scripts manipulated by the holders of this commands to make the appscripts dependet on it.

Look at Win7PESE nearly every script is changed by lancelot to add "IniVariables" compability, So also nearly the whole project is now a mess cause it depends more and more in useless commands.

ReadEnv is nice, but to let it go in nothing and to define the VistaCAPI variables would solve a lot of compability problems. The project knows all the info that readenv is reading so it can be deactivated and the (as example) VistaPECfg is or can be same as Win7PECfg and so on.

The command is in my eyes deleteable, only the section is needet so winbuilder can call it and dont throws errors. The worsest thing is that the work of JFX and others is now.

Look at this:
[Main]
Title=1 - Copy Files
Type=script
Author=NightMan, YahooUK, JFX, ChrisR
Description=Make folders and copy all basic files. This step is fundamental to add all needed system files.
Credits=All credits go to Microsoft for developing this Operative System and to everybody on the BootLand forums for helping on the debuggind and improvement of this script.
Version=031
Download_Level=0
Level=1
Selected=True
Mandatory=True
NoWarning=False
Contact=http://www.msfn.org/board/topic/149758-win7pe-se/
Date=2011.10.10
Depend=
Disable=
CertifiedBy=
Certification=
HistoryNotes=
History016=ChrisR - add bootmgr.exe.mui in boot%distlang for display language at startup
History017=rpaz - Lancelot - adjust copy of KBD*.DLL files checkbox Add all Keyboards
History017=rpaz - added needed file to allow tray icon control (Hide/show/notifications)
History018=ChrisR - add mscms.dll
History019=Lancelot - no duplicate options in menu.lst
History020=ChrisR - comment bootres.dll for Vista start bar for fast boot (instead win7 startup animation) post 71 http://www.boot-land...ndpost&p=110874
History021=Dera's fix for distlang : post 201 http://www.boot-land...ndpost&p=113307
History022=Homes32 - Moved mount check for install.wim into 01-PreConfig
History023=ChrisR - add blbres.dll, blb_ps.dll required for recovery environment in standard files copy
History024=Homes32 - Added shortcut generation and config for Windows Recovery Env Tools, Cleaned up interface
History025=JFX - sfc.dll - lz32.dll - crtdll.dll can be added to base files http://www.msfn.org/...post__p__956891
History026=Lancelot - AdmTools_CheckBox hidden from interface - reported causing double shortcut appears along with mmc (+adding manual names....). (tip: better add any adm. tools through mmc script) // code cosmetics (quotes removed etc etc)
History027=Dera - Add Windows Time service w32time
History027b=ChrisR : retrieve Time Zone Information from install.wim in offline system hive, for system locale auto
History028=Lancelot IniVariables added
History029=ChrisR - Font control panel - set the registry permission on W32Time service - ifsutil.dll dependence of xcopy,...
History030=ChrisR - Additional Font (from Install.wim) commented, Preferred an additional Fonts script (Reason: reg font entries have localized names) http://theoven.org/index.php?topic=206
History031=ChrisR - Reorganization of sections - Improved echo messages - Copy only used bootsrc mui files for standard file copy.


Inivariables wasn't needet that the script runs good. so i think that i am not far away with my thinking that it is forced to be used.

Also i see in your script clearlock (nice application respekt)
ReadEnv,SourceType
Select_Case,%SourceType%,XP|W2003
If,%Case%,BIGGER,0,Begin
// We are (lovingly) using an XP/2003 based project
Echo,"XP/2003 Based Project Detected."
If,Not,ExistFile,%target_win%Fontslucon.ttf,CopyOrExpand,%source_win%lucon.ttf,%target_win%Fonts
End
Else,Begin
// otherwise we are (hopefully) using a Vista/Win7 project
Echo,"Vista/Win7 Based Project Detected."
If,Not,ExistFile,%target_win%Fontslucon.ttf,CopyOrExpand,%source_win%Fontslucon.ttf,%target_win%Fonts
End
// needed for displaying non .bmp images - LiveXP doesn't include this.
Require_FileQ,asycfilt.dll

CopyOrExpand?

Is it now enough to say only with these two lines:
If,Not,ExistFile,%TargetDir%WindowsFontslucon.ttf,If,ExistFile,%SourceDir%Windowslucon.ttf,CopyOrExpand,%SourceDir%Windowslucon.ttf,%TargetDir%WindowsFonts
If,Not,ExistFile,%TargetDir%WindowsFontslucon.ttf,CopyOrExpand,%source_win%Fontslucon.ttf,%target_win%Fonts

or also it is possible as every one knows to retrieve the fileversion of an dll like "kernel32.dll" or some libs apps else and to know which os version is in.

Require_FileQ is as i saw only for Win7PE_SE project made and also makes your script bindet on it.

Last but not leas from BGInfo script:
Hive_Load,HKCU
RegWrite,HKLM,0x4,"%reg%SoftwareSysinternalsBGInfo","EulaAccepted","1"
RegWrite,HKLM,0x2,"%reg%SoftwareMicrosoftWindowsCurrentVersionRunOnce","BGInfo","#$q%PE_Programs%%ProgramFolder%runBGinfo.exe#$q#$s%StartMode%#$s%RefreshInterval%"
Hive_Unload,HKCU


This command is also not needet to make a standalone script and it is also not that less code to write:

RegHiveLoad,Temp,%SourceDir%WindowsSystem32Configdefault
RegWrite,HKLM,0x4,"TempSoftwareSysinternalsBGInfo","EulaAccepted","1"
RegWrite,HKLM,0x2,"TempSoftwareMicrosoftWindowsCurrentVersionRunOnce","BGInfo","#$q%PE_Programs%%ProgramFolder%runBGinfo.exe#$q#$s%StartMode%#$s%RefreshInterval%"
RegHiveUnload,Temp

As i remember XP, Vista and Seven and the server editions are storing the default hive in the same folder, so it is also not neccassary to make the script working on all projects.

I dont critizize your work or your usage of the Capi it is your script and you can make it how you wish, but to say that i am the bad cause i want to show you guys what is going in wrong direction and many think so, is not that funny in my eyes.


I am forced cause if i want to add a script without editing it, it is not possible to have a project without capi. So everything needs to be changed and we are (the new devs) forced to use it, cause nearly everything above 50% what is available doesnt run without it.

When i provide something to the public, than i want that it is improved and not changed and messed with something like that. For me it is not important to have a name here, i dont need thanks or to be famous. I am as you all a little guy that can code and its for me a hobby not work as for you all.

We can work togheter to improve something or work against all and add such commands only to make as example the winbuilder slower.

When the day comes that capi will have only usefull commands than i will maybe rethink and do something for this community, but nowadays

The Oven is fighting against the devs here and why i should use my time to help somewhere where it is not sure how the future will like.

For me it is important that my project have a future so in my hands it will for sure have, but what is with the appscripts, if i remove capi and someday comes an update than i must change it again, and again, again....

It would be better that app scripts are as i said before "STANDALONE" you can add your own little command collection in the one script. And everyone would be fore sure happy.

It would also work if the capi would be readable and in modules splittet, so an appdev can decide what functions he need and just copy and paste it in his script so the script has the module of the Command collection and it would be also standalone. Or modules that are addable to winbuilder and everyone can decide what to add.

CAPI isnt a real api or sdk, it is a one file command collection and redirection. To splitt everycommand in one file and to give US project devs the possibility to add what we want would make me as example more happy, and it would be for sure more readable instead of this endless file.

Also to see what command is executed and redirected you must go sometimes to 3-5 sections to see what it is realy doying, many redirections and so on. If you want i can invest my time to search errors in it, there are for sure a lot of them, searching bugs is easy but not interessting, cause the devs making it have anyway isolated it that nobody can get easy in. Look at projects like webkit, there are some rules for all, not do it as you like, a good structure never harmed anybody. So i will let it and wont fight a lot with you around, my time i will spend to remove that crap from nearly everyscript that i want to use. Realy nice, there are weeks needet to clean a project from capi.

You guys can believe that i will never share my scripts, than after a month i see History0X= Lancelot added inivariables support
This would be the death end. To improve bugs ok but to add useless functions is only time loose. The devs mostly are concentrating on how to make a native old script more unative and dependent on the capi.

Never change a running system is the goal. if a script works wihout new commands, than let it work as it was and fix maybe some bugs.

Edited by Darijo, 25 November 2011 - 06:38 AM.

[Wonko the Sane]

When the day comes that capi will have only usefull commands than i will maybe rethink and do something for this community, but nowadays

The Oven is fighting against the devs here and why i should use my time to help somewhere where it is not sure how the future will like.

... and the devs fighted and still fight against the guys in The Oven, and this war started and continued and will continue for no meaningful reason ....

It would be better that app scripts are as i said before "STANDALONE" you can add your own little command collection in the one script. And everyone would be fore sure happy.

It would also work if the capi would be readable and in modules splittet, so an appdev can decide what functions he need and just copy and paste it in his script so the script has the module of the Command collection and it would be also standalone. Or modules that are addable to winbuilder and everyone can decide what to add.

CAPI isnt a real api or sdk, it is a one file command collection and redirection. To splitt everycommand in one file and to give US project devs the possibility to add what we want would make me as example more happy, and it would be for sure more readable instead of this endless file.

You have a vision that is queerly suimilar to that i get from the Outside of the Asylum:

The CAPI is from what I can understand a variation of the Windows .DLL mechanism, which has ALREADY failed (raise your hand whoever never suffered form versioning nightmare?) even if it was "governed" by a central power (Microsoft).

To translate the concept in my dinosaur's technical language, instead of invoking a command, you invoke *something* that contains the command and that "forwards" the call to that command.
This has the advantage that you don't need a myriad of little files, and everything is "kept in order" inside a big "container" (and at each release this container grows in size)

But if NOONE keeps everything inside the container "in order and tidy", there is a problem.
And if more different people independently add, remove or modify the contents, we have a bigger problem. (CHAOS )

At this point it would be better to "split" each command inside the CAPI into a single .script file and give to the actual project/single .script Author the responsibility of adding it inside his/her project/.script, sure there will be some duplications, but at least things should work...

If you prefer, I find the source of the issues being not revolving around whether the CAPI needs to be rewritten or bettered (which is needed anyway ) , but rather around the way the CAPI (or anything "common") should be managed (please read as "Definitely not how currently it is NOT managed").

Wonko

[homes32]

@homes32 See it so:

The fact that it is nearly in every script active and that this scripts will for sure not change in near future. is also the fact that if you want to use someones work you need to implement the CAPI and if you rewrite it for your project you will get attacks "why not say thanks" blablabla.

thats the downside of using someone elses work. its the same way with any other lanuguage...if you want to modify somone elses program you must uses the libraries that they used or remove them and replace with custom code.
It's not my job to tell someone what libries to use or not to use. you come accross as saying "I want to use someone elses work but I don't want the CAPI commands in it, so they should write it differnt so I can use their code without doing any extra work"
...it is the same as saying "Jo Schmoe writes his programs in VC.NET. I want to modify his program for my own use but I don't want to use the .NET runtime. therefore Jo Schmoe should rewrite his program to not use .NET so I can modify it to my liking."

I hope this is not your attitude.

And i have already shared something, maybe you should take a look before attacking also me. I see you in the middle of this the oven and reboot and i also known that i will get from you an answer.

I wasn't attacking you. I was encouraging you to contribute. your link creater has nothing to do with CAPI code though so it is irrevelent in this discussion.

If CapiC is to remove than just do it, why to wait? Otherwize there will be more scripts manipulated by the holders of this commands to make the appscripts dependet on it.

Look at Win7PESE nearly every script is changed by lancelot to add "IniVariables" compability, So also nearly the whole project is now a mess cause it depends more and more in useless commands.

ReadEnv is nice, but to let it go in nothing and to define the VistaCAPI variables would solve a lot of compability problems. The project knows all the info that readenv is reading so it can be deactivated and the (as example) VistaPECfg is or can be same as Win7PECfg and so on.

The command is in my eyes deleteable, only the section is needet so winbuilder can call it and dont throws errors. The worsest thing is that the work of JFX and others is now.

I am in agreement with you. But I am not the release controller of the CAPI so there is really nothing I can do about it except encourage people not to use the commands.

Also i see in your script clearlock (nice application respekt)
ReadEnv,SourceType
Select_Case,%SourceType%,XP|W2003
If,%Case%,BIGGER,0,Begin
// We are (lovingly) using an XP/2003 based project
Echo,"XP/2003 Based Project Detected."
If,Not,ExistFile,%target_win%Fontslucon.ttf,CopyOrExpand,%source_win%lucon.ttf,%target_win%Fonts
End
Else,Begin
// otherwise we are (hopefully) using a Vista/Win7 project
Echo,"Vista/Win7 Based Project Detected."
If,Not,ExistFile,%target_win%Fontslucon.ttf,CopyOrExpand,%source_win%Fontslucon.ttf,%target_win%Fonts
End
// needed for displaying non .bmp images - LiveXP doesn't include this.
Require_FileQ,asycfilt.dll

CopyOrExpand?

Is it now enough to say only with these two lines:
If,Not,ExistFile,%TargetDir%WindowsFontslucon.ttf,If,ExistFile,%SourceDir%Windowslucon.ttf,CopyOrExpand,%SourceDir%Windowslucon.ttf,%TargetDir%WindowsFonts
If,Not,ExistFile,%TargetDir%WindowsFontslucon.ttf,CopyOrExpand,%source_win%Fontslucon.ttf,%target_win%Fonts

or also it is possible as every one knows to retrieve the fileversion of an dll like "kernel32.dll" or some libs apps else and to know which os version is in.

good catch. that is very old code from the 1st versions of this script years ago. Since then I have used the fileversion of hall.dll to determine OS version.
I will update the code for the next release of this script.
thank you.

Require_FileQ is as i saw only for Win7PE_SE project made and also makes your script bindet on it.

Require_FileQ is not only for Win7PE_SE it will work on other projects.
In any case I normally use Require_File. ChrisR made the Change to Require_FileQ when he uploaded the script to the Win7PE_SE server as the Require_FileQ command is slightly faster, but less robust.

Last but not leas from BGInfo script:
Hive_Load,HKCU
RegWrite,HKLM,0x4,"%reg%SoftwareSysinternalsBGInfo","EulaAccepted","1"
RegWrite,HKLM,0x2,"%reg%SoftwareMicrosoftWindowsCurrentVersionRunOnce","BGInfo","#$q%PE_Programs%%ProgramFolder%runBGinfo.exe#$q#$s%StartMode%#$s%RefreshInterval%"
Hive_Unload,HKCU

This command is also not needet to make a standalone script and it is also not that less code to write:

RegHiveLoad,Temp,%SourceDir%WindowsSystem32Configdefault
RegWrite,HKLM,0x4,"TempSoftwareSysinternalsBGInfo","EulaAccepted","1"
RegWrite,HKLM,0x2,"TempSoftwareMicrosoftWindowsCurrentVersionRunOnce","BGInfo","#$q%PE_Programs%%ProgramFolder%runBGinfo.exe#$q#$s%StartMode%#$s%RefreshInterval%"
RegHiveUnload,Temp

As i remember XP, Vista and Seven and the server editions are storing the default hive in the same folder, so it is also not neccassary to make the script working on all projects.

At one time it was nessicary for compatability between projects to use Hive_Load
this has been resolved and I have started moving back to using RegHIveLoad in my scripts....It just takes some time to update them and get them released.

I feel you have good intentions and I would be happy to work with you to help make things bettter. But complaining about CAPI and saying nobody should use it is not making anything better and is only going to cause division. Doing something positve to improve it is better in the long run, but it is not something that happens over night.

regards,
Homes32

[MedEvil]

At one time it was nessicary for compatability between projects to use Hive_Load

When was HiveLoad ever necessary for compatibility?
It was solely introduced to make writing of app script easier.

[homes32]

When was HiveLoad ever necessary for compatibility?
It was solely introduced to make writing of app script easier.

you forget that PE1 based projects keep the System hive in %target_sys%SETUPREG.HIV
and PE2/3 projects keep the System hive in %TargetDir%windowssystem32configsystem

so in the past writing scripts for use in both PE1 and PE2/3 that needed access to the system hive had to check for the project type and then load the correct hive.
With CAPI the check was done automatically.
now projects have a global %RegSystem% variable pointing to the hive so some processing time can be saved by using navite syntex

RegHiveLoad,Tmp_System,%RegSystem%

instead of calling CAPI and still be cross compatiable between PE1<->PE2/3

[pscEx]

now projects have a global %RegSystem% variable pointing to the hive so some processing time can be saved by using navite syntex

Did you have been the last 4 years on the moon?
This has been proposed by Nuno in 2007
http://reboot.pro/27...dpost__p__18178

Peter

[homes32]

Did you have been the last 4 years on the moon?

sometimes I wonder...

[sbaeder]

CAPI isnt a real api or sdk, it is a one file command collection and redirection. To splitt everycommand in one file and to give US project devs the possibility to add what we want would make me as example more happy, and it would be for sure more readable instead of this endless file.

If you mean the script file that implements the current API standard, I would agree...BUT, as Nuno has said above in this posting, and we have hashed out here on the forum many times, the first step is to get some control of this by documenting the behavior and the syntax of the "API"...not CAPI or CapiC or whatever you want to call it.

I believe we have done that. Is it perfect - OF COURSE NOT. There is always room for improvement. But, as others here have said, it's intent is to extend the functionality of the core engine, and to improve the ability to share scripts..

Already, there has been way too much energy expended here in argument. Put the "politics" aside, and let's move forward!

Scott

[larioteo]

@homes32 thank you now we are i think on the same line and understand each other
Yes i know that your scripts are very clean and thanks for the update i like that, less work for people like me

It is true that the whole capi isnt so bad, i understand it quietly now, otherwize i would not find out the useless stuff like CapiC in the syntax what it is exactly doing. And as i seen this i must say for me this file is dead, cause it is realy developed in last time to kill the builder that it is based on. This is a little bit scary would you use something that is primaly developed now to kill the main programm that you are working with? When you start a new project it is less work to think about it, should i should i not. And if i change the appscripts and clean them off then another one will come and say hey that is all my work so i am only reading the files for me as information, to be sure that nobody is attacking me that i have stolen his work.

I also prefer the reg import method for standard registry keys that are missing in the boot wim and as you know there arent many possibilities to take them different as the others there are to 100% the same with some changes. Values that i wanna be master of them i take out and set them manually as like the search funktion of the start menu in the folder options, it are only 3 keys that are needet to be set in my thinking so i also taken the other keys and everything is the same. If i do than puglish it, the one that done it in another script will say hey this is my work.

I am making an PE3 with explorer as base (nothing extra) so all the functions and components of standard windows will be addet in script. also standard shorcuts that windows makes, for me it is not needet cause of the cool function start search how they are sortet in the menu, i let them as windows does after installation.

So the PE will be realy near the look and feel of a standard installation. And for user settings i have only one little script with settings that are in my eyes needet to make the pe superb.

First the default merge of the registry than the changes. so i have in builder the standard things to change quick that i want, and all other things that happens behind arent on my mind than they should work as they are. and so on.

I have big plannings around, but it needs as you all know much time to make the core and the base for the app scritps, windows pe consist now for me over 3500 files that are to check also the registry hives that need to be checked are a big deal and much work.

I would prefer a system with extra commands that are file based and modular as we know it from many other free projects.

I want only to make one thing clear, the capi is a good idea but it was messed cause of a childish war of 2 sites, and this is realy not the future.

[pscEx]

I want only to make one thing clear, the capi is a good idea but it was messed cause of a childish war of 2 sites, and this is realy not the future.

Tell me any war which is initiated by two sides at the same time.
Usually there is an agression, and a reaction.

For my projects the ( C )API is no issue.
My projects realize the "White Paper" of the official documentation with their own fast routines.
What is not described in the "White Paper", is not performed and marked as warning.

App scripts which do exceed the syntax of the "White Paper" are not suited to be included in my projects.
I do not think that this is an issue for me. It can be an issue for the authors, when they want that their scripts are used by many people.

Peter

[larioteo]

Yes psc that is right, but you are the only one that is using the advantages of the capi with different PE Types. All other projects are related to one PE version, so the existens of commands for older PES or newer, it depends normaly on which it is based, has only one goal to make the build slower.

The main part is:

There are different ways to think what is yet better what should be in what out.

Let us make a little comparision:

FileCopy, very usefull command it can copy files.

AddShortcut, very wide ranged (more bugs possible) it can add a shorctut for every PE version currently known but i would rather prefer a command that creates a shortcut and not a config file so as seen in autoit script language.

CreateShorctut(Name,Path,....); This would aslo work for any project the appscript developer would have to write if pe1x than create it here, if pe2x than create it there, and so on.

It would be like FileCopy a big global usefull command not dependet on any pebuild. The goal of the api is a different one as that from the builder. So it would be realy nice that the main programm that we are using can create shorcuts during script process, it is a missing feature that should be since years implemented.

Also the PE Builder has the power to check the system during runtime and to decide how the builder will run best on it. So the HostOSTools functions seen in many scripts would be also only an uncommented part in the file.

The Winbuilder have to know how it should execute the regedit exe file, it would be better if the builder says internal hey i am running on an x64 system i must copy the regedit.exe to the windows temp directory and execute it there it would be nice that we script developers dont must think about it how the system will interect if we use simple builtin os tools.

Also another thing, the builder should give us users more environment variables like system language and so on so we would have Variables that are Conastant in memroy like %BaseDir% ... and the only thing we need to do is to start the builder itself.

I know that Nuno everytime is saying no new features for the builder, but i think some things can be handeled much more better over native code and much more faster than over the pseudo language of the winbuilder script.

I am reading the registry for such informations but it would be very cool if winbuilder knows this after startup, everytime wihout extra coding needet. Also commands like AddShortcut don't need to be added, only a CreateShortcut that creates an lnk file in that directory that i want and with the info i want to type in. Nothing more nothing less.


A command of the api can be dependent on PE Types and so on, but winbuilder is still missing many of basics that are needet and provided by the os, the builder only must use it.

I would rather see such functions that the capi. So i can use the builder without any external tools and it would be much faster than a call.

Implement a funciton to mount wim files, or to extract 7z archives, that is that what we realy need. And then it is builtin and an complete environment to build a pe, the api can be what it is, a collection of command extensions but not the basic commands and so on.


Hopefully everyone understands me.

CreateLink as a Future, AddShorcut as an Function.
New Features can be used globaly for any future pe, current funcitons must be anyway suited for newer versions and so on.



Winbuilder must get basic functions so the API also would be smaller sized cause it can only internaly check if PE1 than to this if PE2 than to that and so on. But the future to create a lnk file should be provided by the builder also to compress files that are added in script, or to mount a wim image, that is all usefull, it is like the copyorexpand command, which is very usefull to dont have to think about it if it is compressed or not, such commands are the real helpfull thing.

On the other site with such a huge future list i can decide if my project should build on many pe builds than i use the capi, if it is only for one PE than also the api isnt needet in it. Appscripts that call addshortcut i can simply redirect only one script is needet to make everything working on any project, and the builder should do its work as before.

New version means new features and if it is at the beginning not compatible or there are new commands that reducing olds in 10 times, than it is my work as developer to get to the new builder version. To stay compatible means also to be slower and to stay with old bugs. So what is better is the View of the person who makes it.

Edited by Darijo, 26 November 2011 - 06:13 PM.

[sbaeder]

I feel that like many before you, you're mixing definitions. The API is a DEFINITION of functionality. The Common_API.script is an implementation of that functionality. As pscEx has said, he (as the author of a project) created his own implementation of the documented and "standard" commands. Other projects may choose to use their own implementation.

Yes, some things MIGHT be faster, and even things like adding a short cut might have other ways of being implemented. But, we have what I consider to be a pretty good set of commands - both native and extensions using the API. Does it really make sense to change the definition of "AddShortCut"??? Or are you more concerned with how it is implemented.

I will give as my example using something like "C" to do embedded programming. Using libc (the "C" standard library) that was written in "C" is fine for most jobs. But if you only had 2K of ROM, hand-coded assembly is probably faster and smaller. BUT, a lot harder for a person who is not an expert on the particualr instruction set to code.

Does that invalidate the libraries definition? No. Similarly, look at the standard for "Linux" (the LSB). Many of the "standards" are NOT the bleeding edge. It is what is known as a trailing standard, based on what is in the majority of the major, participating distributions. It is helpful to software vendors, since if they want their software to run on many different distributions, they need to stick with what is widely supported. Does that mean that each distribution has to include the exact same revision of each library - NO. It is the API and behavior of the implementation that matter.

As for mor common "variables", I would agree that there is an area we could use some more "standardization"...So, like anything else, make a concrete proposal, let's discuss it here, and if agreement, we can add to the "docs" as something that should be standardized. In fact, I am working on something like that in the area of the "otherOS" stuff that started life here, and was extended in the Win7PE_SE project, but still isn't even "half-baked" yet - i.e. not even ready for initial discussion here.

Don't get me wrong - healthy debate is good...Ideological wars are not. Definition and behavior are important. Internal implementation isn't nearly as important.


Scott

[larioteo]

Ok you understood it quite as i wished, i cannot write it in english as i think.
The small word is calles standardization now we have the point.

The other thing you got me wrong, i said it should be rather the work of winbuilder to create a shortcut than of the capi, i mean only the part CREATE, so no external tools are needet to do so. In short words. Winbuilder should be able to Create LNK files. Nothing more nothing less.

[sbaeder]

On link files, I will think more about it, but tend to agree that it is something that could/should? be available. For now, I know that there was a tool/script being added to create arbitrary links, but maybe in the future (who knows)...

And yes, it is always difficult to communicate across not only language, but cultures - at least we try!

[larioteo]

The important thing is, like autoit script supports it, you can create invalid shortcuts that are at pestartup valid if you understand.

Link is not touched by windows until you press it, and later it is in pe3 anyway in wim compress windows starts and the links work withoug slow down on bootup. For me it is the better solution as on startup.

So that was what i meant, with my little tool i can create them currently on buildtime with config file, and later i plan also something what i wish in winbuilder, if winbuilder supprots it, than the tool isnt any more needet. Thats my goal no extra tools.

[pscEx]

The small word is calles standardization now we have the point.

Think about my conclusion:

• There is one CONSTANT definition of API syntax in the WIKI. This definition cannot be changed w/o forum discussion and agreement.
• To use the definition, every project is free to use a 'standard API' or define it's own one like <myProject>_Api.Script:
• To distribute "Common_API" scripts with "Common" in the name is forbidden. That tells the standard user, that this API implementation is valid for every project, what really is wrong.

The other thing you got me wrong, i said it should be rather the work of winbuilder to create a shortcut than of the capi, i mean only the part CREATE, so no external tools are needet to do so. In short words. Winbuilder should be able to Create LNK files. Nothing more nothing less.

Here you are wrong. *.lnk files are only valid, when the final PE has windows explorer as shell.
Have a look how this issue is handled in multiPE. Here an intermediate file containing the necessary information, is passed to %ActiveShell%. %ActiveShell% creates the shorcut it can understand and stores it to the target.
Example of an intermediate file:

[Created]

Program=shortcutParse

Version=1.2.2

Copyright=© 2007 Peter Schlang

Date=2011-Nov-20 153811062

Command=-C:V:MULTIPEWORKBENCHMULTIPE_XPUSERDATAPROJECTINFO.INI -O:V:MULTIPETEMPMULTIPE_XPSHCTEMP.INI -ST:SM. -SE:%BOOTMEDIA%@_@CD-OPERAOPERA.EXE -SL:CD-OPERA

Position=BootMedia



[Shortcut]

targetDir=V:multiPEWorkbenchmultiPE_XPUserData

modelDir=V:multiPEWorkbenchmultiPE_XPUserData

shortCutType=SM

shortCutName=CD-Opera

shortCutExe=%BootMedia%@_@CD-OperaOpera.exe

shortCutLocation=

shortCutToolTip=

shortCutParameters=

shortCutShow=

shortCutDir=

shortCutHotKey=

shortCutIconFile=

shortCutIcon=0

I several times gave examples, how to create shortcuts for e.g. xobelite as standard shell. I do not want to repeat here.
BTW: Everything done at build time.

@Darijo: Thanks for your engagement here. I think it will help to do a lot of enhancements.

Peter