93 replies to this topic

[Lancelot]

No, WIMs need to be mounted to a folder residing on an ntfs file system.

okey, fixing the idea to create a ramdisk to the first available drive letter and mount .wim to there.

you could just set %programfiles% variable to the mount location.

well LiveXP have environment variable joker to use, but others do not have this option available all the time (thanks to dera pointing this).

===>
Reminding, the problem is about writing apps scripts that work on all projects perfectly.

PE2-PE3 projects have their %ProgramFiles% located at %systemdrive% (inside .wim file) (X:\Program Files)
they also have a 2nd programfiles location where it points cd drive %cddrive%\Programs (LiveXP do not have this feature)
Also PE2-PE3 projects have other shells as an option (LiveXP do not have this feature)

The situation is, PE2-PE3 projects have 2 features that is not available AND for now not required by LiveXP. With having explorer as shell intact (which also writes in the defination of LiveXP ) environment trick seems to save the day for LiveXp but not for the others.

so question comes, will we be selfish when writing apps scripts ?

There are two vistape.cfg files, one in the root of %CDDrive% and one in %SystemRoot%\System32. The former contains non-run-from-RAM stuff, the latter contains run-from-RAM stuff. I don't know why there are two files, and I don't know if there's any difference between them

I previously check log file only "Edit: to see if things written on cfg", I will check if values written to registry, I need time

No, we can't modify the VistaPE loader. CTMag may someday write one of his own from scratch, but that's far in the future.

Maybe VistaPE is becoming a dinosaur...

I do not think VistaPE is becoming a dinosaur. In fact what VistaPE loader does is very similar to what LODR Loader on LiveXP (or the amalux's package Loader) does, it creates registry and adds shortcuts which is logical for this situation.

I feel problem is not about the loader, It is about general apps script writing with available options. It is obvious some situations do not require this portable approach where it should be distinguished by script. RunFromRam designed for that purpose on VistaPE. But not using RunFromRam does not require regaddboot on livexp ..... etc etc...

Edit

[Galapo]

okey, fixing the idea to create a ramdisk to the first available drive letter and mount .wim to there.
well LiveXP have environment variable joker to use, but others do not have this option available all the time (thanks to dera pointing this).

Dera's test would have been after the shell was started. If the loader in VistaPE etc runs before the shell, then the loader can set the variable before the shell is started and then the shell can make use of the variable when it starts.

Reminding, the problem is about writing apps scripts that work on all projects perfectly.

Yes, that's right -- but also to get them working without having to manually modify scripts from reg_add to RegAddBoot just because some projects can't handle this in a better manner yet.

PE2-PE3 projects have their %ProgramFiles% located at %systemdrive% (inside .wim file) (X:\Program Files)
they also have a 2nd programfiles location where it points cd drive %cddrive%\Programs (LiveXP do not have this feature)

That's not entirely true. LiveXP can have some programs left under '%systemdrive%\program files' and some in another location. This is handled by junctioning, no need to modify reg_add to RegAddBoot as entries still point to correct location by making use of %programfiles% variable.

Also PE2-PE3 projects have other shells as an option (LiveXP do not have this feature)

Yes, but as I wrote if the variable is set prior to starting the shell, then everything should be OK.

so question comes, will we be selfish when writing apps scripts ?

Well, hopefully we don't have to be. I've been trying to provide some workable alternatives. It a shame that the VistaPE loader can't be updated, that's a real blow for projects dependent upon it. Maybe a pre-loader can be run setting the variable and then starting the loader? Or maybe the api can handle it with modifications to reg_add, but I haven't been able to get it to work: http://www.boot-land...?...ost&p=84785.

Regards,
Galapo.

[Lancelot]

Dera's test would have been after the shell was started. If the loader in VistaPE etc runs before the shell, then the loader can set the variable before the shell is started and then the shell can make use of the variable when it starts.

Thanks a lot to clear my mind.

Well, hopefully we don't have to be. I've been trying to provide some workable alternatives. It a shame that the VistaPE loader can't be updated, that's a real blow for projects dependent upon it. Maybe a pre-loader can be run setting the variable and then starting the loader?

Now I see a bright light in the end of the tunel :>


@JonF

does Max_Real Qnx use same loader on Leopard intact as default ?

[Galapo]

does Max_Real Qnx use same loader on Leopard intact as default ?

vpeldr.exe in VistaPE CAPI has been compiled with v.3.2.10.0 of AutoIt.

vpeldr.exe in Leopard has been compiled with v.3.3 of AutoIt.

Is one ctmag's version, or has Max recompiled?

Regards,
Galapo.

[Lancelot]

There are two vistape.cfg files, one in the root of %CDDrive% and one in %SystemRoot%\System32. The former contains non-run-from-RAM stuff, the latter contains run-from-RAM stuff. I don't know why there are two files, and I don't know if there's any difference between them

I just figured that out, Still, VistaPE always writes when booting whether runfromram selected or not. , Besides this is a nice working precaution for situations where cd rom is not available. (ex: booting iso with grub4dos OR cdrom not availabe after bootup ), so the one at %systemroot% always works


Besides, this shows Galapo's solution and VistaPE loader design need one more thing to consider, Galapo's solution depends on the available cdrom drive so registry entries written at build, vistapeloader have a precaution:

My conclusion:
On VistaPE
When RunFromRam selected, SOME regaddboot lines must be fixed to be written to registry at build time.
When RunFromRam not selected, following the vistapeloader design all need to be done by %CDDrive% vistape.cfg . (Or we can have an option for with galapo's solution leaving decision to user)

I still feel regaddbootif ....

[Galapo]

Besides, this shows Galapo's solution and VistaPE loader design need one more thing to consider, Galapo's solution depends on the available cdrom drive so registry entries written at build, vistapeloader have a precaution:

If the cdrom isn't available, then programs located there won't work anyway, whether registry entries are correct or otherwise.

Regards,
Galapo.

[Lancelot]

If the cdrom isn't available, then programs located there won't work anyway, whether registry entries are correct or otherwise.

right, I guess the design made for such situation, this may effect registry organisation if something designed for that.

simple example: 7zip script set to runfromram, winrar script not set to runfromram . If all made when building and cdrom not accesable, than double clicking .rar files won't work since they point winrar which is unavailable. With the design of vistape loader when cdrom not available, double clicking .rar would work with 7zip.
ps: Also there will be some not working shortcuts around.

Maybe decision should be left to user since there seems to be an available option (add available registry at build time OR not) with design Maybe not by ignoring vistapeloader's precaution design .......

[Galapo]

PE2-PE3 projects have their %ProgramFiles% located at %systemdrive% (inside .wim file) (X:\Program Files)
they also have a 2nd programfiles location where it points cd drive %cddrive%\Programs (LiveXP do not have this feature)

We have these options:

1. Enable BootSDI and add 'RunFromCD,True' to top of ImgBurn.script [process] section -> result is most programs are located under %programfiles% in ram, but ImgBurn is located on CD.

2. Disable BootSDI and add 'RunFromRam,True' to top of ImgBurn.script [process] section -> result is most programs are located under %programfiles% on CD, but ImgBurn is running in ram from ramdrive.

In both these cases, there are two locations of programs in LiveXP. And this without having to alter reg_add commands to RegAddBoot to get scripts to work.

Regards,
Galapo.

[Lancelot]

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

post removed, I noticed something wrong, need to check

[Galapo]

section -> result is most programs are located under %programfiles% in ram, but ImgBurn is located on CD.

nope, we have ImgBurn located on ramdrive B:\ (settings drive) , at this situation CD is at a unknown drive letter.

No that is the case with 'RunFromRam,True'. With 'RunFromCD,True', programs are forced to run from CD. Well, that's the way it should work unless something has become broken.

Regards,
Galapo.

[Lancelot]

Well, that's the way it should work unless something has become broken.

nothing become broken, i noticed my wrong writing in 3 seconds and removed previous post but obviously i was late . Checking runfromcd with some ideas was always in my mind but honestly never found time yet ..
Trying to figure out how it works (I guess shc - shortcut combination makes shortcut works, ... and somehow (shc!) systemdrive first set to cddrive letter, than set back to real systemdrive or....), I noticed ExpEnvVar lines are written wrongly, probably I am newly learned runfromcd not available with regaddboot.

[dera]

Dera's test would have been after the shell was started.

so i tried to use this au3 made by pedrole15,
i used it via 'AddAutoRun' command
yes
VistaPE help says:
"Note: the programs from the autorun will be started during the boot process from "VistaPE Loader" after the default shell is launched"

[Galapo]

VistaPE help says:
"Note: the programs from the autorun will be started during the boot process from "VistaPE Loader" after the default shell is launched"

So that implies that the loader starts the shell and so if %CDDrive% variable is created before starting the shell like in my modified loader code above, everything should be fine. But trouble is, the loader is apparently proprietary and can't be modified...

Regards,
Galapo.

[dera]

i tried to compile pedrole15's au3 into cd.exe and to use:

winpeshl.ini
[LaunchApps]
cd.exe
vpeldr.exe

without success in BS Explorer


p.s.
i am only an amateur so maybe i have made something wrong
nevertheless seems if Explorer shell used then this env. var. expanded successfully when i also use
Galapo's 'BroadcastEnvChange.exe /broadcast'

[pscEx]

I've been playing around with the api to try to get this issue perhaps solved there. Here's what I currently have, but not working yet as entries aren't being added to the registry. Any ideas what's wrong?

[reg_add_%API_TYPE%]

 PackParam,1,%params%

 Run,%API%,Set_Api_Type,"%params%"

 Run,%API%,reg_add_%API_TYPE%,"%params%"

 

 [reg_add_1]

 RegWrite,"HKLM","#1"

 

 [reg_add_2]

 StrFormat,POS,"#1",#$pcddrive#$p,%str_test%

 If,%str_test%,Bigger,0,RegAddBoot,"#1"

 Else,RegWrite,"HKLM","#1"

Thanks,
Galapo.

What about asking the magic wand:
RegWrite,HKLM,0x1,Section,Key(Text),String

Or is the type part of the params?

Peter

[Galapo]

Hi Peter,

Here's what I have now:

[ApiVar]

reg_add=Run,%API%,reg_add_%API_TYPE%



[reg_add_%API_TYPE%]

PackParam,1,%params%

Run,%API%,Set_Api_Type

Run,%API%,reg_add_%API_TYPE%



[reg_add_1]

//PackParam,1,%params%

Message,"%params%"

RegWrite,HKLM,%params%



[reg_add_2]

StrFormat,POS,"#1",#$pcddrive#$p,%str_test%

If,%str_test%,Bigger,0,RegAddBoot,"%params%"

Else,RegWrite,HKLM,%params%

Testing with the following:

[Process]

Hive_Load,HKCU

reg_add,0x1,%reg%\Software\test,testing,test

Hive_Unload,HKCU

But nothing is added to the registry. Message,"%params%" shows that everything is there, including the '0x1'.

Thanks for any more hints.

Thanks,
Galapo.

[pscEx]

In the debugger the line

'RegWrite,HKLM,0x1,wb-hive\Software\test,testing,test'

appears and is written correct (and permanent).

wb-hive here is the default hive. Maybe you are thinking on the software hive.

Peter

[Galapo]

Strange. With the altered api command given it's not working for me. I'm using WB077rc2, will have to test 078sp4 in the morning.

Regards,
Galapo.

[pscEx]

But nothing is added to the registry. Message,"%params%" shows that everything is there, including the '0x1'.

Did you already try

System,SPLITPARAMETERS,ON

I think that the command was made for such purposes.

Peter

[JonF]

does Max_Real Qnx use same loader on Leopard intact as default ?

He uses the VistaPE v11 loader, which is very different from the v12 loader. I suppose it too could be decompiled, but again only NightMan has the rights.

But a pre-loader is an interesting idea. I actually have a post-loader running in VistaPE fixing one loader bug. Now all I need is time...

[Lancelot]

But a pre-loader is an interesting idea. I actually have a post-loader running in VistaPE fixing one loader bug. Now all I need is time...

And the light at the end of the tunel gets brighter Waiting for the good news

[Galapo]

Hi Peter,

Unfortunately, still not working for me.

Here's what I have now:

Common_Api.script

[ApiVar]

reg_add=Run,%API%,regadd_%API_TYPE%



[regadd_%API_TYPE%]

PackParam,2,%params%

Run,%API%,Set_Api_Type,#1

Run,%API%,regadd_%API_TYPE%,#1



[regadd_1]

System,SPLITPARAMETERS,ON

RegWrite,HKLM,#1,%params%

System,SPLITPARAMETERS,OFF



[reg_add_2]

StrFormat,POS,%params%,#$pcddrive#$p,%str_test%

System,SPLITPARAMETERS,ON

If,%str_test%,Bigger,0,RegAddBoot,#1,%params%

Else,RegWrite,HKLM,#1,%params%

System,SPLITPARAMETERS,OFF

This is the test script:

[Process]

Hive_Load,HKU

reg_add,0x1,"%reg%\test","testing","test"

Hive_Unload,HKU

Here's the log:
 log.7z   3KB   386 downloads

Thanks,
Galapo.

[online]

For LiveXP, my preference is for as few as possible boot-time registry additions to be made. Since LiveXP can handle this at build-time, that is what we should work towards getting working in other projects and getting away from needless RegAddBoot lines and leave such calls only to what is absolutely essential.

I regularly utilize(d) "RegAddBoot" function either under VistaPE (in the past) and under LiveXP (actually) for my scripts in order to avoid hardcoded path and I can not see any kind of issue in its use, so I wonder if there are technical reason for your statement or if it is a your preference at all.
Also I wonder how to smartly solve the double AppData (default User/All Users) different paths and the ProgramData (VistaPE) folder issues compared to LiveXP built.
Maybe a kind of "standard template" to add in scripts could be interesting to detail.
Many thanks for any contribution.

By the way, I think it would be useful if someone wrote a kind of "Basics White Book" (admitting that it was not already written ) about LiveXP fundamentals and the difference in concept against VistaPE (Win7PE?).

[Lancelot]

Also I wonder how to smartly solve the double AppData (default User/All Users) different paths and the ProgramData (VistaPE) folder issues compared to LiveXP built.

Lets go step by step in order not to distract the attention.

someone wrote a kind of "Basics White Book" (admitting that it was not already written ) about LiveXP fundamentals and the difference in concept against VistaPE (Win7PE?).

This requires a user who knows both platforms very well, and who have time and desire to write something like this. Maybe you

to avoid hardcoded path

There are rare situations where a hardcoded path required for stringvalue (0x1)
for others (and especially for associations) we can easly use multi-string value (0x2) where we can write variables.

This way is better since there will be less amount of reg addings during boot time.

Personally, when writing scripts I always check if i can write 0x2 instead of 0x1 (for the path included entries).
Reminding, this is not about making something work, this is about making something work with "the right and best possible way"
using regaddboot on various scripts only required since it was (currently "is") "the only available way" for interproject scripts,

I am waiting good news from JonF (preloader) which as a result We can easly revert back all regaddboot entries to reg_add 0x2 (where available)

[online]

@Lancelot
Sorry for the late reply (recently I'm very busy) and many thanks for your appreciated one...
I think that every script/program/driver has its own story, and at this moment I do not think that "0x2" (REG_EXPAND_SZ string) would be useful for all ones as "RegAddBoot" replacement.
Maybe it could be useful with some "simple" program/function (some program file type association?), but unfortunely it does not seem to me that it could be "widely" used.
It seems to me that there are some circumstances in which it does not make too difference if is used a "final" path as "%SystemDrive%\" rather than "X:\", but in other ones it does not seem so simple.
As matter of fact, in some circumstances a truncated path ("system32\..." rather than "%SystemRoot%\system32\...) seems to work fine, in other ones it does not work at all...
So, since I can not see any issue related to "RegAddBoot" function (when really needed, of course) I think that the more possible "default" and that the single script/program/driver behaviour observation is still our priority...

By the way, I think that "RegAddBoot" function is really a great function that does not deserve to be "criminalized"...