ShortcutsPE

Hi Galapo,

 

My mind became full like a full refrigator before I thought this idea, I am glad you like 

Do not worry "much" about testing, I am verrry aware there are too many tests which would take a lot time....
Only being carelfull would be enough and easy for now. In anyway, when we come near end we will make a looot of tests :>.

btw news: 7zip 9.20 now official, while waiting you I was (&and am) working on current 7zip script to update,
than probably I will leave and continue with shortcut tomorrow :).

and:
runfromcd have folder option as parameter #1
I feel better something like: RunFromCd,TrueFolder,<targetfolder>

and further
If,Not,#1,Equal,True,Begin
-->
If,#1,Equal,TrueFolder,Begin
.....

what you think ?

runfromcd have folder option as parameter #1
I feel better something like: RunFromCd,TrueFolder,<targetfolder>

and further
If,Not,#1,Equal,True,Begin
-->
If,#1,Equal,TrueFolder,Begin
.....

what you think ?

Sounds like a great idea to me!

Maybe we could just have RunFromCd,Folder,<targetfolder>?

Regards,
Galapo.

Test CAPI for the most part seems to be working fine.

One issue I've encountered: forcing all apps to run from RAM at ProgramFilesPE isn't working. Forcing all to run from CD is working.

Regards,
Galapo.

Hi Galapo,

I am not sure if you forget, or if you did intentionally.
If intentionall:
Than you get the 1st price at first time having an argument without leaking info
If not than reminding:
Current capi under development (not published)  have
%Capi_RF_Script%=
%Capi_RF_Method%=MyMethod
to let project admins use their methods freely.

Well this was made by foreseeing pe2/3 admins will need future adjustments when they develop their projects further, and this will keep backward compatibility, since meaning of RunFromRAM and RunFromCD always same ;) whatever coded.

edit: hence you do not need to add If,..blabla in capi....

See you 

Yep, I saw no need to give such a good secret away to Peter just yet.

Besides, this idea is much better than his idea of replacing CAPI wholesale. Like I said, if he wants to do that, just define %API% to whatever the project should use.

The 'If,EXISTVAR' would only be needed under current published CAPI if some PE1 project doesn't want to support the two 'xxxIsoScript' scripts.

Oh dear, Peter is sure after LiveXP blood!    

Regards,
Galapo.

Good 

The 'If,EXISTVAR' would only be needed under current published CAPI if some PE1 project doesn't want to support the two 'xxxIsoScript' scripts.

no need to, both scripts are shareable to both projects, and capi already there ready for all pe1.
IF a pe1 project do not have this options (or equalavants) just defining an empty-hidden script would be enough. In the end they will (may) improve themselves needing same variables ;).
Anyway, this will even not needed with next capi  which is coming slowly with all other thigns that are connected each other.....

Peter always have troubles to follow anyone who leads before him, if he can not, he renames ;) or wait an oppurtinity (wide range of tactics) to rename.
The oldest I know (and to me a comical) example is, after waiting for years, finding oppurtinity with PEx64  to rename hasherfrog+Vadikan's hiderun.exe to the bugy hiderun_ex.exe
That is the reason he has the only project that can not support wow64 since JFX is the absolute leader known around on PEwow64 supporting.

Oh dear, Peter is sure after LiveXP blood!    

Very boring, and time consuming after 9 months.
Btw, I guess you also notice "SVN content" thingy in post, I also remember same post back to wb080 times (9months), it is a message to Nuno ;) saying "I have the latest and I have the power, do not ever think touching me". God knows why Nuno ......

Anyway, time to continue work :>

Btw, I guess you also notice "SVN content" thingy in post, I also remember same post back to wb080 times (9months), it is a message to Nuno ;) saying "I have the latest and I have the power, do not ever think touching me". God knows why Nuno ......

Yes, I saw that and concluded exactly the same as you.

Regards,
Galapo.

Hi Galapo,

after thinking widely in past 2 days, I changed some ideas about runfromxxx

these values can later be included in projectinfo, or not, up to project, but I feel it is easier to put them at script.project as begining, since using projectinfo is only adding one step to use iniread..

initial idea is following (RFDF=Run From Default , RFRM=Run From Ram , RFCD=Run From CD)

%RFDF_Drive%=#$pSystemDrive#$p
%RFDF_Programs%=Program Files
%RFDF_TargetDir%=%TargetDir%
%RFDF_Target_prog%=%RFDF_TargetDir%\%RFDF_Programs%
%RFDF_PE_Programs%=%RFDF_Drive%\%RFDF_Programs%

%RFRM_Drive%=#$pRMDrive#$p
%RFRM_Programs%=Program Files RM
%RFRM_TargetDir%=%ProjectTemplates%\FromRM
%RFRM_Target_Prog%=%RFRM_TargetDir%\%RFRM_Programs%
%RFRM_Programs%=%RMDrive%\%RFRM_Programs%

%RFCD_Drive%=#$pCDDrive#$p
%RFCD_Programs%=Program Files CD
%RFCD_TargetDir%=%ProjectTemplates%\FromCD
%RFCD_Target_Prog%=%RFCD_TargetDir%\%RFCD_Programs%
%RFCD_PE_Programs%=%CDDrive%\%RFCD_Programs%



probably having %RFDF_TargetDir% value created with programfilespe script with ,permanent will be more secure. (with some others...)

Above organisation puts RFRM and RFCD files out of targetdir, which will be copied at create iso stages, due to create iso script (bootsdi-createiso-wimboot decide how to...)

Practically,
Well no need to create everything suddenly, we are here to organise shortcut, and runfromxxx is a side job to tidy up old dusts
I guess for Gena having
%RFRM_TargetDir%=%TargetDir%
%RFCD_TargetDir%=%TargetDir%
will fit the current organisation

For pe2/3 projects,
In FUTURE, only putting RFCD out of targetdir, will be enough to get green button on scripts work nicely after build. (which is not possible currently when script used without runfromram=true)
anyway, for today, it is simpler to follow current organistion

Back to Gena,
I feel this values better be added at top of
4 ProgramFilesPE.script

IniRead,%ProjectInfo%,TargetStrings,sProgram_Files,%prog%
Set,%RFDF_TargetDir%,%TargetDir%,Permanent
Set,%RFDF_Programs%,"%prog%",Permanent
Set,%RFRM_Programs%,"%prog% RM",Permanent
Set,%RFCD_Programs%,"%prog% CD",Permanent
....


with above organisation, runfromram code on capi would be something very simple like below

Set,%Target_Prog%,%RFRM_Target_Prog%
Set,%PE_Programs%,%RFRM_PE_Programs%
Set,%AtCD%,False
Set,%AtRam%,True


well this is first half, keeping short ;) so far what you think

Very good planning and work! Makes for much easier implementation between projects.

Thanks,
Galapo.

Hi Galapo,

I feel my thoughts come to verrrrry mature level now, after thinking a lot of cross and future expandibilty situations......
I updated capi, script.project and programfilespe now, not tested but will help to ease things..

Added RunFrom, api:
There are situations never considered so far, like RunFrom Writeable, or Runfrom Usb (or External or Portable) and maybe more in future.....
these potential addings will increase runfrom api's a lot in time..... so RunFrom, added as expansion api slot today + easier to test arrangements with these.
previous RunFromCD and RunFromRAM kept same for now, later RunFromCD1 and RunFromRam1 can be ported to RunFrom,CD RunFrom,Ram (api1) etc..

for runfrom,cd of folder, I split the organisation (to speed up), check [RunFrom_INFO] in capi


The only thing not organised is %RMDrive% which is a dynamic value due to the selected "create image" method.
For now I set it to static %RAMDriveLetter%,
One easy way I suggest is,
%RMDrive%=#$pRMDrive#$p
adding %RMDrive% to environment variables with the selected "create image" method, with bootdi and wimboot it will be %SystemDrive% , with createiso it will be %RAMDriveLetter% OR %SystemDrive% .....

I hope you like the idea which I highly believe it will simplfy a lot of things...... (I do not think such addition to env. var. today will hurt, besides it can be removed later too... only I feel better to simplify things since sadly we are working on bad foundations )


Well, lots of ideas in mind for things related to runfromxxx, but I do not want to focus on them or write long here, all I want is tidy up runfromxxx to get a nice organisation of runfromxxx, things can be improved later. 

shortly: now runfromxxx is more ready for tests, share ideas and minor improvments, sorry for being so much late besides all other excuses, you know I changed organisation many times thinking to get clear view.

I hope you like things so far, after we get over this hill, some more road on shortcut way.....
See you.

Thank you very much for your hard work on this!

I really hope to be able to get to testing this week all the things you've done. Without looking into it,  I think using an %RMDrive% environment variable is a good idea.

Regards,
Galapo.

Time Galapo time...

so I leave this runfromxxx thingy now, and move to study buildmodel-shortcut ....

I came here for 2 hours now, time to go.... come-go-come-go... at last all will finish nicely :)

See you 

Hi Galapo,

since I can not spend full time, here are things for shortcut for you when you find time:


%Shell% has no importance for shortcut creation,
%Shell% variable is there to say "Default Shell" to the build, practically have no Importance If you do not use a shell swapper utility.
Any shell (bblean, GeoShell, LiteStep, ReacotOS Explorer ... even cmd.exe ) that can use .lnk files can be used generally.
.lnk is the main method , FreeShc.exe is the submethod...

It was pe1 absolutely wrong organisation using "%shell%" variable linked to shortcut creation.

hence Explorer better removed from sections and other shortcut related places
[Add-Shortcut-2-LNK-Buildtime-Explorer-FreeShc.exe


Reminding: pe2/3 world %shell% used by loader or swapper (ex: peshellswapper) to set default shell.
Giving example, each shell added to the build adds itselff to loader or swapper, the one that has "default" checkbox selected also added as default.
There is naturally no relation between %shell% and shortcut creation on pe2/3 world.

ps:
again reminding,
since there are (as far as I find) only 2 shells that do not use .lnk files (bsexplorer and nu2menu),
one can also convert all .lnk properly to these shells configuration file (or files ;)) near end of the build.
as you know, nightman made a shortpath, and add all shortcut info to a seperate configuration file (boottime config file), and when loader selects shell (and at boot time default shell), due to selected shell shortcuts generated.


shortly:
better remove -Explorer- from sections..... hence make shortcut centro independent from %shell%




%API_TYPE% used with section, which is good for speed,
besides keep in mind, %TargetProfilesUserDir% is the key point to support different api types with any tool targeting .lnk creation at build time.

Gena
%TargetProfilesBaseDir%=....\Workbench\Gena\UserData\TargetProfiles
%TargetProfilesUserDir%=....\Workbench\Gena\UserData\TargetProfiles\Documents and Settings\Default User

W7PESE
%TargetProfilesBaseDir%=%TargetDir%
%TargetProfilesUserDir%=%TargetProfilesBaseDir%\Users\Default

VistaPE-Capi & Leopard
%TargetProfilesBaseDir%=%TargetDir%
%TargetProfilesUserDir%=%target_win%\System32\Config\SystemProfile




Also,
please re-check runfromxxx organisations I'd made so far.
See you.