93 replies to this topic

[Galapo]

I'm wondering why all these new script updates that have RegAddBoot commands added? I realise that this is for inter-project compatibility, but I think it is up to the individual project to get these scripts functioning without all the updates: http://www.boot-land...?...ost&p=58161.

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.

Thoughts?

Regards,
Galapo.

[Lancelot]

I totally agree with you Galapo,

I hope PE2 - PE3 admins (Mex Real Qnx, yahoouk, joshua, JonF) and PE2 - PE3 users give some idea for a better solution.

[online]

I realise that this is for inter-project compatibility

I think that is a great topic to detail: I was an "old" VistaPE user, but now I'm a LiveXP one and as far as I remember the RegAddBoot command was useful under VistaPE in order to avoid hardcoded path.
I'm interested: is that compatibility from different projects actually possible de facto also for more "difficult" script or it is only a sweet wish?

[Arvy]

If I recall correctly, the "old" VistaPE originally had several loading configuration options for "Force All to RAM", "Mount Programs Folder as Drive Y:", etc., so that you could end up with individual applications either collected all together or scattered amongst locations that could be determined only during the boot process. And, to further complicate the situation, some could be located under a "Programs" folder on the boot drive while others were loaded under the WIM's "Program Files" folder. Since I don't have access to a WAIK platform at the moment, I'm not sure about all of Vistacapi's current options and, of course, Mickey$oft's incessant whims and whimsy constitute a whole other development factor for all concerned.

Frankly, IMO, a full "cross-scripting" goal, especially if it includes any "backward compatibility", appears much like a valiant but practically impossible dream, and the LiveXP project might best adopt a "lead by example" approach. It gets very tricky for other projects with program location options that are variable by the end users with no consistent relationship to %SystemDrive% or other pre-determined environment variables. In the circumstances, I'm happy if LiveXP's own RegAddBoot/ExpEnvVar features are fully capable of handling the cases where particular applications can't deal with 0x2 (REG_EXPAND_SZ) registry entries.

That's merely my own POV, of course -- perhaps overly pessimistic. Maybe Windoze own %ProgramFiles% variable could be "tweaked" somehow to compensate.

[Lancelot]

it is only a sweet wish?

Frankly, IMO, a full "cross-scripting" goal, especially if it includes any "backward compatibility", appears much like a valiant but practically impossible dream,

Currently, If you copy Apps scripts of LiveXP to VistaPEcapi or VistaPEcapi to LiveXP, they work
(Thanks to JonF a loot)

just tested with copying LiveXP apps to VistaPEcapi, after 7za.exe copied to %tools% of vistapecapi, build finished successfully, minor bugy with startup of vistapecapi which can be avoided by unselecting startup option of mounstorpe and multires.


dream or sweet wish is coming true, the Problem is unneccary regaddboot lines. Regaddboot lines should only be used for particular applications which can not deal with 0x2 (REG_EXPAND_SZ) registry entries. (Arvy ) but they are also used by pe2-pe3 projects to overcome %cddrive% (not run from ram applications)





This (%cddrive%) requires the interest of pe2-pe3 admins and advanced users for a permanent fix, any idea ????

[Arvy]

So, is there anything to prevent the establishment and propagation of a Windows environment variable for %ProgramsDrive% (like %SystemDrive%) that is usable within scripts and/or via ExpEnvVar as needed? In that case, you'd just have to get agreement on its consistent usage.

[Galapo]

So, is there anything to prevent the establishment and propagation of a Windows environment variable for %ProgramsDrive% (like %SystemDrive%) that is usable within scripts and/or via RegExpVar as needed? In that case, you'd just have to get agreement on its consistent usage.

Exactly! This is what I tried to get VistaPE to adopt a year or so ago. Hopefully this idea will work in practice but it will require implementation and testing by PE2 and PE3 projects.

Regards,
Galapo.

[Arvy]

Perhaps we're both too simple-minded, but it certainly seems logical and even obvious. It would appear, IMO, to have some major practical advantages over sacrificing project advancements for the sake of "lowest common denominator" compatibility.

In fact, it almost seems like something that should be an integral part of the core infrastructure and thus capable of being used by all projects. I don't mean the actual EnvVar setting and propagation process, which could only be done during the initial stages of a build's boot-up. But a common trigger/flag item for that process could allow any project whatever manipulative flexibility might be needed for various options. Based on that trigger, maybe something like EarlyStarter (or even earlier CurrentControlSet Session Manager?) could handle the flag discovery and EnvVar setting.

[JonF]

Exactly! This is what I tried to get VistaPE to adopt a year or so ago. Hopefully this idea will work in practice but it will require implementation and testing by PE2 and PE3 projects.

I'm all for it ... but I don't have the right to change any VistaPE loader code. Ctmag has his own based on Nightman's but he can't share source with others, and I've decompiled NightMan's but haven't tried to build it. It's a conundrum.

[Galapo]

So what loaders are used by which projects? That is, what is processing these RegAddBoot entries in win7pe and VistaPE-Leopard etc?

Scripts should have to be modded in these projects to get them working but should be able to be used as supplied by the developer. I hate seeing my app scripts in the LiveXP project folder being butchered with unnecessary RegAddBoot lines and corresponding reg_add lines having been commented out. It add unnecessary stuff happening at boot-time which can all be done at build-time. RegAddBoot should really only be used when a specific app can only have a hard-coded path which needs to be added to registry at boot.

Thanks,
Galapo.

[Lancelot]

I have 1 good idea for midway,


1)
a new api "RegAddBootIf"

giving example:

RegAddBootIf,HKLM,0x2,Software\EasyBoot Systems\UltraISO\5.0,,%PE_Programs%\%ProgramFolder%

If the source is PE1 (api type 1)
OR
If %RegAddBootIfSet%=NO
capi transfers to==>

reg_add,0x2,"%reg%\EasyBoot Systems\UltraISO\5.0","","%PE_Programs%\%ProgramFolder%"

Else====>

RegAddBoot,HKLM,0x2,Software\EasyBoot Systems\UltraISO\5.0,,%PE_Programs%\%ProgramFolder%

2)
We can be selfish between projects.

[Galapo]

1)
a new api "RegAddBootIf"

giving example:

RegAddBootIf,HKLM,0x2,Software\EasyBoot Systems\UltraISO\5.0,,%PE_Programs%\%ProgramFolder%

But the problem with this is that we still have this unnecessary 'RegAddBootIf' call, the substance of which should be processed by reg_add unless a specific application requires a hard-coded path which needs to be entered at boot-time.

Is it at all possible to modify the api, eg:

[ApiVar]

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



[reg_add_%API_TYPE%]

Run,%API%,Set_Api_Type,#1,#2,#3,#4,#5,#6,#7,#8,#9

Run,%API%,reg_add_%API_TYPE%,#1,#2,#3,#4,#5,#6,#7,#8,#9



[reg_add_1]

//for LiveXP



[reg_add_2]

//For win7 etc, do some tests for %cddrive% and swap to RegAddBoot call if found

Trouble is, this wouldn't work for the following because of the amount of parameters:

Hive_Load,HKCU

reg_add,0x3,%reg%\Software\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop,Taskbar,0c,00,00,00,08,00,00,00,02,00,00,00,00,00,00,00,b0,e2,2b,d8

,64,57,d0,11,a9,6e,00,c0,4f,d7,05,a2,22,00,1c,00,0a,10,00,00,1a,00,00,00,01,00,00

,00,00,00,00,00,00,00,00,00,00,00,00,00,4c,00,00,00,01,14,02,00,00,00,00,00,c0,00

,00,00,00,00,00,46,81,00,00,00,11,00,00,00,80,f3,5d,ea,f2,35,c4,01,00,c0,3b,92,58

,35,c4,01,00,32,58,eb,f2,35,c4,01,00,00,00,00,00,00,00,00,01,00,00,00,00,00,00,00

,00,00,00,00,00,00,00,00,53,02,14,00,1f,50,e0,4f,d0,20,ea,3a,69,10,a2,d8,08,00,2b

,30,30,9d,19,00,2f,42,3a,5c,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

,00,4c,00,31,00,00,00,00,00,a9,30,27,93,11,00,54,45,4d,50,00,00,20,00,03,00,04,00

,ef,be,a9,30,61,92,a9,30,00,00,14,00,00,00,54,00,65,00,6d,00,70,00,00,00,14,00,18

,00,00,00,06,00,ef,be,53,00,59,00,53,00,54,00,45,00,4d,00,00,00,14,00,66,00,31,00

,00,00,00,00,a9,30,61,92,10,00,44,4f,4b,55,4d,45,7e,31,00,00,4e,00,03,00,04,00,ef

,be,a9,30,61,92,a9,30,00,00,14,00,00,00,44,00,6f,00,6b,00,75,00,6d,00,65,00,6e,00

,74,00,65,00,20,00,75,00,6e,00,64,00,20,00,45,00,69,00,6e,00,73,00,74,00,65,00,6c

,00,6c,00,75,00,6e,00,67,00,65,00,6e,00,00,00,18,00,48,00,31,00,00,00,00,00,a9,30

,61,92,10,00,44,45,46,41,55,4c,7e,31,00,00,30,00,03,00,04,00,ef,be,a9,30,61,92,a9

,30,00,00,14,00,00,00,44,00,65,00,66,00,61,00,75,00,6c,00,74,00,20,00,55,00,73,00

,65,00,72,00,00,00,18,00,4e,00,31,00,00,00,00,00,a9,30,19,93,10,00,41,4e,57,45,4e

,44,7e,31,00,00,36,00,03,00,04,00,ef,be,a9,30,19,93,a9,30,00,00,14,00,00,00,41,00

,6e,00,77,00,65,00,6e,00,64,00,75,00,6e,00,67,00,73,00,64,00,61,00,74,00,65,00,6e

,00,00,00,18,00,42,00,31,00,00,00,00,00,a9,30,1a,93,10,00,4d,49,43,52,4f,53,7e,31

,00,00,2a,00,03,00,04,00,ef,be,a9,30,1a,93,a9,30,00,00,14,00,00,00,4d,00,69,00,63

,00,72,00,6f,00,73,00,6f,00,66,00,74,00,00,00,18,00,52,00,31,00,00,00,00,00,a9,30

,1a,93,10,00,49,4e,54,45,52,4e,7e,31,00,00,3a,00,03,00,04,00,ef,be,a9,30,1a,93,a9

,30,00,00,14,00,00,00,49,00,6e,00,74,00,65,00,72,00,6e,00,65,00,74,00,20,00,45,00

,78,00,70,00,6c,00,6f,00,72,00,65,00,72,00,00,00,18,00,48,00,31,00,00,00,00,00,a9

,30,1a,93,11,00,51,55,49,43,4b,4c,7e,31,00,00,30,00,03,00,04,00,ef,be,a9,30,1a,93

,a9,30,00,00,14,00,00,00,51,00,75,00,69,00,63,00,6b,00,20,00,4c,00,61,00,75,00,6e

,00,63,00,68,00,00,00,18,00,00,00,10,00,00,00,05,00,00,a0,1a,00,00,00,75,01,00,00

,00,00,00,00,00,00,00,00,e0,06,00,00,00,00,00,00,16,00,00,00,00,00,00,00,00,00,00

,00,16,00,00,00,00,00,00,00,01,00,00,00,01,00,00,00,aa,4f,28,68,48,6a,d0,11,8c,78

,00,c0,4f,d9,18,b4,0c,03,00,00,e0,0c,00,00,00,00,00,00,16,00,00,00,00,00,00,00,00

,00,00,00,16,00,00,00,00,00,00,00,01,00,00,00

Hive_Unload,HKCU

Regards,
Galapo

[Lancelot]

But the problem with this is that we still have this unnecessary 'RegAddBootIf' call,

I made many builds with all active 3 pe2-pe3 projects including VistaPEcapi these days to understand how things goes there about this subject, maybe it is not that much unnecessary, As far as i understand pe2-pe3 projects also needs additional RegAddBoot command (& option).

This is all about the method, Writing already used method:
IF an "unknown drive letter" exists for a specified program at initial boot AND IF one do not want to use environment variables for a reason*, than required registry and shortcuts must be created at boot time.

reason*= A known reason is not wanting to add anything to environment variable to keep it intact. Another reason is source code can not be modified .

This case is not valid for LiveXP since we do not have a %CDDrive% (or %OtherDrive%) option on "Program Files PE" script. (also we mostly use settings drive etc.) (ps*:Maybe this can be required in future)



Many things to write about this, Trying to keep as short as possible:

As far as I understand (If i am wrong, please someone correct me):
RegAddBoot lines still writes values to vistape.cfg whether "Run From Ram" option selected or not.
This line
RegAddBoot,HKLM,0x2,Software\Classes\7-Zip.7z\shell\open\Command,,"#$q%PE_Programs%\%ProgramFolder%\7zFM.exe#$q #$q%1#$q"
added to vistape.cfg (similar to ExpEnvVar.txt)
In reality, this is not needed if "Run From Ram" option selected, value should be written to registry at build time because %SystemDrive% is a known environment variable.
ALSO :
One can make cd (or usb etc) drive letter Y:
Than either "Run From Ram" option selected or not, value should be writen to registry at build time because Y: is known.

VistaPE writes to vistape.cfg all the time either with %CDDrive% or with %SystemDrive%


On the other hand (MUST / ABSOLUTE):
This line
RegAddBoot,HKLM,0x1,Software\EasyBoot Systems\UltraISO\5.0,,%PE_Programs%\%ProgramFolder%
Should be added to registry at boot time (with vistape.cfg or ExpEnvVar.txt) whether "Run From Ram" option selected or not.




Issue is:
RegAddBoot is used for different purposes at the same time which cause unnecessary things both on LiveXP and on VistaPE (This is all about non-flexibility of RegAddBoot , it is not about anything between projects) . We need to expand RegAddBoot feature so RegAddBoot serves better.

There are 2 usage,
"Absolute RegAddBoot" => WE MUST add registry at Boot
"Maybe RegAddBoot" ==> Depends


"Maybe RegAddBoot"
should write to registry at build time (reg_add) when RunFromRam selected OR when PE1 (ex: LiveXP) used.

AND we need an additional key as a permanent variable
so when usbDrive/CdDrive (simply The Drive) is known than reg_add used

else RegAddBoot used.



My idea is:
"Absolute RegAddBoot" (RegAddBoot)
"Maybe RegAddBoot" (RegAddBootIf)

and a permanent variable for RegAddBootIf which can be changed by a core script during build time.
%RegAddBootIfSet%=NO
%RegAddBootIfSet%=YES


What you all think, am I missing something ???

[dera]

maybe it is a little off topic
but i have a question regarding the %CDDrive% environment variable in VistaPE:
how is it possible to make it active e.g. in BS Explorer?
i mean i have tried to define this env. var. but i am not able to make it alive if not the Explorer shell used

[Galapo]

but i have a question regarding the %CDDrive% environment variable in VistaPE:
how is it possible to make it active e.g. in BS Explorer?
i mean i have tried to define this env. var. but i am not able to make it alive if not the Explorer shell used

Is the shell started before or after the environment variable is set? If after, then shells other than Explorer unfortunately don't process the environment change broadcast.

Regards,
Galapo.

[Galapo]

My idea is:
"Absolute RegAddBoot" (RegAddBoot)
"Maybe RegAddBoot" (RegAddBootIf)

and a permanent variable for RegAddBootIf which can be changed by a core script during build time.
%RegAddBootIfSet%=NO
%RegAddBootIfSet%=YES


What you all think, am I missing something ???

What I am trying so say is that only enties like the following need to be added at boot:

RegAddBoot,HKLM,0x2,Software\EasyBoot Systems\UltraISO\5.0,,%PE_Programs%\%ProgramFolder%

However, scripts have been changed like this:

//reg_add,0x2,"%reg%\Classes\TypeLib\{1CD46142-F3D3-4E46-87BA-7CC019142F9D}\1.0\0\win32","","%PE_Programs%\%ProgramFolder%\isoshell.dll"

//reg_add,0x2,"%reg%\Classes\TypeLib\{1CD46142-F3D3-4E46-87BA-7CC019142F9D}\1.0\HELPDIR","","%PE_Programs%\%ProgramFolder%\"

RegAddBoot,HKLM,0x2,"Software\Classes\TypeLib\{1CD46142-F3D3-4E46-87BA-7CC019142F9D}\1.0\0\win32","","%PE_Programs%\%ProgramFolder%\isoshell.dll"

RegAddBoot,HKLM,0x2,"Software\Classes\TypeLib\{1CD46142-F3D3-4E46-87BA-7CC019142F9D}\1.0\HELPDIR","","%PE_Programs%\%ProgramFolder%\"

That is not how I have supplied my script! The reg_add command is fine. If a project has troubles because of the location where it is placing files, then it should be up to the project to make this work -- not have each script modified so as to use RegAddBoot as a work-around. LiveXP does this with WimPack and the option of having programs folder in a user-specified location. Why can't this sort of thing happen in other projects too rather than having scripts manually modified from using reg_add to RegAddBoot?

Maybe in these other projects reg_add can simply be transfered to a RegAddBoot. That way scripts can be left untouched. Or use an environment variable set before the shell starts. Or maybe do something similar to what WimPack does or something.

Regards,
Galapo.

[Lancelot]

**

LiveXP does this with WimPack and the option of having programs folder in a user-specified location. Why can't this sort of thing happen in other projects too rather than having scripts manually modified from using reg_add to RegAddBoot?

wimpack uses predefined variable, settingsdrive which is predefined as B: by project info (or systemdrive or hardcoded letter)

Here is something to do similar with LiveXP:
use wimboot with wimpack,
disable imdisk
define fundamentals--settings drive--%systemdrive% (&ramdrive letter --)

what to do to make this build work without using additional environment variable ????


**
If no interest to make common application scripts from vistape admins , regular users or advanced users continues

2)
We can be selfish between projects.

lines intentionally left with commented to revert back if no improvements made
Decision is up to you.

[Galapo]

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.

[Galapo]

Can't we just modify the loader (providing the shell is started afterwards)? Eg changing this

Func CORRECTPATH(ByRef $P_EXE, $CHECK_PATCH)

	$SYS32DIR = StringRegExpReplace(@SystemDir, "\\", "\\\\", 0)

	$WINDIR = StringRegExpReplace(@WindowsDir, "\\", "\\\\", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)%CDDrive%:", $CD_LETTER & "", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)%CDDrive%\\", $CD_LETTER & "\\", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)%SystemDrive%\\", "x:\\", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)%SystemRoot%", $WINDIR, 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!S32", $SYS32DIR)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!PFC", $CD_LETTER & "\\Program Files", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!PF", "x:\\Program Files", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!PDC", $CD_LETTER & "\\Programs", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!PD", "x:\\Programs", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!CD\\Program Files", "x:\\Program Files", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!CD", $CD_LETTER & "", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!WD", $WINDIR, 0)

	$P_EXE = StringRegExpReplace($P_EXE, "\\\\", "\\", 0)

	If ($CHECK_PATCH = 1) Then

		If FileExists($P_EXE) Then Return $P_EXE

		If FileExists($CD_LETTER & "\" & $P_EXE) Then Return $CD_LETTER & "\" & $P_EXE

		If FileExists($CD_LETTER & "\Programs\" & $P_EXE) Then Return $CD_LETTER & "\Programs\" & $P_EXE

		If FileExists($CD_LETTER & "\Program Files\" & $P_EXE) Then Return $CD_LETTER & "\Program Files\" & $P_EXE

		If FileExists("x:\Program Files\" & $P_EXE) Then Return "x:\Program Files\" & $P_EXE

		If FileExists("x:\Programs\" & $P_EXE) Then Return "x:\Programs\" & $P_EXE

	EndIf

	Return $P_EXE

EndFunc



Func DETECTCONFIG()

	$LETTER = DriveGetDrive("all")

	For $L = 1 To $LETTER[0]

		If (StringRegExp($LETTER[$L], "(?i)^(A|B):$")) Then ContinueLoop

		If (StringRegExp(DriveStatus($LETTER[$L]), "NOTREADY")) Then ContinueLoop

		$FILE = $LETTER[$L] & "\" & $CFG_FILE

		If FileExists($FILE) Then

			$POS = _ArraySearch($CONFIG_FILES, $LETTER[$L], 0, 0, 0, True)

			Select

				Case $POS = -1

				Case Else

					$CONFIG_FILES[$POS] = $LETTER[$L] & "true"

			EndSelect

			$CD_LETTER = $LETTER[$L]

			GUICtrlSetData($MESSAGE_SECOND, "Processing " & $FILE)

			READCONFIG($FILE)

			GUICtrlSetData($MESSAGE_SECOND, "")

			$CD_LETTER = False

		EndIf

	Next

EndFunc

to something like this:

Func CORRECTPATH(ByRef $P_EXE, $CHECK_PATCH)

	$SYS32DIR = StringRegExpReplace(@SystemDir, "\\", "\\\\", 0)

	$WINDIR = StringRegExpReplace(@WindowsDir, "\\", "\\\\", 0)

;$P_EXE = StringRegExpReplace($P_EXE, "(?i)%CDDrive%:", $CD_LETTER & "", 0)

;$P_EXE = StringRegExpReplace($P_EXE, "(?i)%CDDrive%\\", $CD_LETTER & "\\", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)%SystemDrive%\\", "x:\\", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)%SystemRoot%", $WINDIR, 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!S32", $SYS32DIR)

;$P_EXE = StringRegExpReplace($P_EXE, "(?i)!PFC", $CD_LETTER & "\\Program Files", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!PF", "x:\\Program Files", 0)

;$P_EXE = StringRegExpReplace($P_EXE, "(?i)!PDC", $CD_LETTER & "\\Programs", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!PD", "x:\\Programs", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!CD\\Program Files", "x:\\Program Files", 0)

;$P_EXE = StringRegExpReplace($P_EXE, "(?i)!CD", $CD_LETTER & "", 0)

	$P_EXE = StringRegExpReplace($P_EXE, "(?i)!WD", $WINDIR, 0)

	$P_EXE = StringRegExpReplace($P_EXE, "\\\\", "\\", 0)

	If ($CHECK_PATCH = 1) Then

		If FileExists($P_EXE) Then Return $P_EXE

		If FileExists($CD_LETTER & "\" & $P_EXE) Then Return $CD_LETTER & "\" & $P_EXE

		If FileExists($CD_LETTER & "\Programs\" & $P_EXE) Then Return $CD_LETTER & "\Programs\" & $P_EXE

		If FileExists($CD_LETTER & "\Program Files\" & $P_EXE) Then Return $CD_LETTER & "\Program Files\" & $P_EXE

		If FileExists("x:\Program Files\" & $P_EXE) Then Return "x:\Program Files\" & $P_EXE

		If FileExists("x:\Programs\" & $P_EXE) Then Return "x:\Programs\" & $P_EXE

	EndIf

	Return $P_EXE

EndFunc



Func DETECTCONFIG()

	$LETTER = DriveGetDrive("all")

	For $L = 1 To $LETTER[0]

		If (StringRegExp($LETTER[$L], "(?i)^(A|B):$")) Then ContinueLoop

		If (StringRegExp(DriveStatus($LETTER[$L]), "NOTREADY")) Then ContinueLoop

		$FILE = $LETTER[$L] & "\" & $CFG_FILE

		If FileExists($FILE) Then

			$POS = _ArraySearch($CONFIG_FILES, $LETTER[$L], 0, 0, 0, True)

			Select

				Case $POS = -1

				Case Else

					$CONFIG_FILES[$POS] = $LETTER[$L] & "true"

			EndSelect

			$CD_LETTER = $LETTER[$L]

			RegWrite("HKCU\Environment","CDDrive","REG_SZ",$CD_LETTER)

			EnvUpdate()

			GUICtrlSetData($MESSAGE_SECOND, "Processing " & $FILE)

			READCONFIG($FILE)

			GUICtrlSetData($MESSAGE_SECOND, "")

			$CD_LETTER = False

		EndIf

	Next

EndFunc

Regards,
Galapo.

[Galapo]

Here is something to do similar with LiveXP:
use wimboot with wimpack,
disable imdisk
define fundamentals--settings drive--%systemdrive% (&ramdrive letter --)

what to do to make this build work without using additional environment variable ????

Well, that's the limitation of using WimBoot. WIMs cannot be mounted to another mounted WIM image. As for the registry entries, they would be fine, just that the WIM image couldn't be mounted.

Regards,
Galapo.

[Lancelot]

Well, that's the limitation of using WimBoot. WIMs cannot be mounted to another mounted WIM image. As for the registry entries, they would be fine, just that the WIM image couldn't be mounted.

I guess you can mount .wim file as a drive letter (correct me if i am wrong)

If you follow this path with the first free available drive letter, than you get the situation of vistape where shortcuts and some of registry entries created at boot time. That is one of the reason I ask for RegAddBootIF...

[Galapo]

I guess you can mount .wim file as a drive letter (correct me if i am wrong)

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

If you follow this path with the first free available drive letter, than you get the situation of vistape where shortcuts and some of registry entries created at boot time. That is one of the reason I ask for RegAddBootIF...

But taking this as a working example, you could just set %programfiles% variable to the mount location. All would be working in LiveXP I think.

Regards,
Galapo.

[JonF]

RegAddBoot lines still writes values to vistape.cfg whether "Run From Ram" option selected or not.

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

[JonF]

Can't we just modify the loader (providing the shell is started afterwards)?

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...

[Galapo]

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.

That's very limiting on development, I must say.

Regards,
Galapo.