A suggestion for Reg2WBS and/or ConvRegToInf

It surely would be nice if one or both of these tools automatically detected hardcoded paths and output them as RegAddBoot commands ...

It surely would be nice if one or both of these tools automatically detected hardcoded paths and output them as RegAddBoot commands ...

I think that since a while Reg2WBS is translating hardcoded paths to variables (If you choose the 'API style' option)

But I do not understand the connection to RegAddBoot.

Peter

I think that since a while Reg2WBS is translating hardcoded paths to variables (If you choose the 'API style' option)

Reg file:

[codebox]IniRead,%API%,Main,Version,%apiVersion%If,%apiVersion%,SMALLER,18,Halt,"API version 18 or higher needed!"Hive_Load,Defaultreg_add,0x2,"%reg%\Software\Safer Networking Limited\SpybotSnD","Path","%PE_Programs%\Spybot - Search & Destroy\"Hive_Unload,Default[/codebox]If one enters this into a script, the result in a VistaPE registry is:[codebox]RegAddBoot,"HKCU",0x1,"Software\Safer Networking Limited\SpybotSnD","Path","%PE_Programs%\Spybot - Search & Destroy\"[/codebox]Then the result in a VistaPE registry booted on a system with two hard disks and one CD drive is:[code]E:\Programs\Spybot - Search & Destroy\[/code]
and Spybot can see where it is installed!

And, even better, it now works in LiveXP too! (with API v20 or something near that).

So my question is: why must this translation be done manually?

JonF, why do you rather want a bunch of operation being executed at boot up instead of during build?
Is your VistaPE booting up too fast?
If the variable %CDDrive% is not defined in VistaPE, then this has to be fixed, imo.

The registry-stuffing part is nearly instantaneous.

How would you handle apps that do not accept 0x2 registry entries? There are some, although I don't remember what they are at the moment. I don't think we should be changing the type of registry entries. Spybot expects 0x1.

(and %CDDRive% isn't defined in the environment of LiveXP either. But in LiveXP the RegAddBoot line gets translated to 0x1 "X:\Program FIles\Spybot - Search & Destroy\" at build time. So %CDDrive% is superfluous.)

Whats wrong with %SystemDrive% or even X:? No reason not to use xp+Sp2 or later as the source when X: is guaranteed.

In VistaPE X: is not guaranteed. VistaPE boots part of itself from RAM, using a WIM file transferred from the CD to RAM, which winds up mapped as X: and contains a Program Files folder that contains some, but usually not all and often almost none, of the application programs. The remainder of the application programs are found in the Programs folder on the CD. In early versions of VistaPE the CD drive was mapped as Y:. In later versions it's mapped after the fixed drives are all mapped. Which letter is, of course, not known at build time.

Nominally the script programmer has control over where the program goes, CD or WIM, except there's a global setting to force all the programs into the WIM file.

NightMan's choice for how to handle this is to provide a RunFromRAM API function. Its argument is true or false. If the global setting is in effect then RunFromRAM,False is ignored and treated like RunFromRAM,True. One way or another, after RunFromRAM is called then %PE_Programs% is set appropriately for use in shortcuts and registry entries (but not for copying or manipulating directories or files).

But that still leaves the issue of how to handle registry entries that contain absolute paths to the application's directory. NightMan created the RegAddBoot function for this situation. (I hope its function is obvious). It's the script programmer's responsibility to use RegAddBoot where required. Of course, since the LiveXP API didn't recognize RegAddBoot, for cross-project scripting you needed to create each such registry entry twice, once with Reg_Add and once with RegAddBoot.

Now pedrole has put RegAddBoot into the LiveXP API. So we can write cross-project scripts that use only RegAddBoot. But none of the automatic translation tools translate into RegAddBoot. So we have check the output of the automatic translation tools and re-translate as required. It seems to me that there should be a solution that doesn't require this manual and fallible task.

Of course, you could question some of the design decisions that people have made. (I could put forth a few comments on the seeingly inconsistent naming of various functions and variables with or without underscores). But that's where things stand today.

#1
Because I found (and still find) Vista a terrible and unnecessary OS, I wrote Reg2WBS for use in nativeEx based projects only.

Asked by Pedrole, Nuno et others to convert the nativeEx dependent paths into symbolic paths like %PE_Programs%, I did so. This gives other projects the ability by using their APIs to translate into their specific paths.

If eg. VistaPE has troubles with that, it is the unability of the VistaPE API, not caused by %PE_Programs% itself.

#2
If some apps cannot understand 0x2 correctly, that is their problem.

If in registry e.g I would not translate '0x1, ... X:\Programme\Gemeinsame Dateien' to '0x2, ... %CommonProgramFiles%', the script would run on German systems only.

I do not think that this is the goal of your selection.

#3
RegAddBoot: I understood your suggestion now and will try to add as option (But that cannot solve #2 completely)

@Pedro: Can you please explain exactly:

• When it can be used
• What has to be done

Peter

I understand. Although for VistaPE I always pack the programs into boot.wim so never noticed the problem.

It should be possible however to mount a second wim from x:\<somedir> using imagex so the programs could always be accessed via x:.

I have never found automatic replacement of drives with environment variables to work for me. Sometimes I will run from ram disk with a different directory. Even if I run from the boot drive I still find that its ok to replace some registry entries with environment variables but others do not work. Only ones that seem to work consistently are the COM registry entries in HKCR. I also almost never install a program to c:\program files.

It should be possible however to mount a second wim from x:\<somedir> using imagex so the programs could always be accessed via x:.

But X: is already taken by the boot WIM.

And mounting a second WIM kind of defeats the purpose of not running everything from the boot WIM.

I have never found automatic replacement of drives with environment variables to work for me. Sometimes I will run from ram disk with a different directory. Even if I run from the boot drive I still find that its ok to replace some registry entries with environment variables but others do not work. Only ones that seem to work consistently are the COM registry entries in HKCR. I also almost never install a program to c:\program files.

That's why I prefer the hardcoded 0x1 entries that RegAddBoot produces, and I don't much like MedEvils' suggestion of a %CDDrive% environment variable.

If in registry e.g I would not translate '0x1, ... X:\Programme\Gemeinsame Dateien' to '0x2, ... %CommonProgramFiles%', the script would run on German systems only.

I do not think that this is the goal of your selection.

I understand. And there are some problems that we just cannot work around. Yes, that is not the goal of my question.

I don't know much about NativeEX. Does it support the "new API", and if so does it have its own api.script separate from LiveXP's api.script? If there's a third, fourth, ... version of api.script out there we should prbably continue to do both Reg_Add and RegAddBoot in scripts intended to be as cross-project compatible as possible.

Thank you JonF for requesting this, I would also love to see this function added to reg2WBS but lack the understanding to argue for it intelligently, as you have. RegAddBoot is the single greatest challenge in creating cross-compatible scripts and it would be wonderful to see it automated in this way!

Peter, I understand your frustration with Vista; I share it! I only try to make my scripts compatible as a concession to those that like it or need it for some reason and in the hope that future releases of VPE will prove more stable and useful. Like it or not, VPE is there and it's not going away anytime soon.

I don't know much about NativeEX. Does it support the "new API", and if so does it have its own api.script separate from LiveXP's api.script? If there's a third, fourth, ... version of api.script out there we should prbably continue to do both Reg_Add and RegAddBoot in scripts intended to be as cross-project compatible as possible.

nativeEx is the core of LiveXP.
Very simplified: If you download nativeEx_barebone_075 from my signature and add a lot of app, you will get LiveXP.

nativeEx_barebone_075 has always the latest API, sometimes a newer one than LiveXP, because LiveXP may have a WinBuilder version which not yet supplies the lates API.

Peter

nativeEx_barebone_075 has always the latest API, sometimes a newer one than LiveXP, because LiveXP may have a WinBuilder version which not yet supplies the lates API.

Note: sometimes it can be other other way round, too. LiveXP currently is using the latest version of the api, v.22. Which means nativeEx is a couple of versions "behind" at v.20.

@Pedro: Can you please explain exactly:

* When it can be used

Here's an example from the IZArc script:

RegAddBoot,HKLM,0x1,Software\Microsoft\Windows\CurrentVersion\App Paths\IZArc,,%PE_Programs%\%ProgramFolder%\IZArc.exe

If this was written as a 0x2 entry at build-time with %PE_Programs% filled out as, say, '%SystemDrive%\Program File', the app fails to run as it requires a 0x1 entry without environment variables. This is a good example of where RegAddBoot may be used.

Regards,
Galapo.

@Jonf,

What you do is create 2 wims boot.wim, programs.wim. At boot time you use imagex to mount programs.wim at x:\Programs. The advantage of this is that programs.wim is not loaded into ram so the mechanism uses much less memory than if all files were packed into boot.wim. All files in programs.wim are thus accessed via x:\Programs. Only requirement is that whatever directory you use as the mount point on x: must be empty.

Note: sometimes it can be other other way round, too. LiveXP currently is using the latest version of the api, v.22. Which means nativeEx is a couple of versions "behind" at v.20.

Sometimes the acessability of the server makes the difference between theory and practical result difficult to syncronize
The current nightly 075 beta x is rather old. And when it has been upload, API 20 was actual.

Inspite in this forum wb 075 beta y is officially not known, it exists on my personal server (url in my signature).

And y contains API 22

Peter

Here's an example from the IZArc script:

RegAddBoot,HKLM,0x1,Software\Microsoft\Windows\CurrentVersion\App Paths\IZArc,,%PE_Programs%\%ProgramFolder%\IZArc.exe

That's clear.
But I do not know whether I can use it 'at every 0x1 reg entry' or 'only if certain %variables% like %PE_Programs% are used'

Peter

But I do not know whether I can use it 'at every 0x1 reg entry' or 'only if certain %variables% like %PE_Programs% are used'

My guess would be that some RegAddBoot 0x1 entries are needed if in the case of %PE_Programs%. But that is because the app can't tolerate 0x2 entry.

But this is a different issue to that raised by JonF. I do not know why this isn't able to be used:

Hive_Load,Default

reg_add,0x2,"%reg%\Software\Safer Networking Limited\SpybotSnD","Path","%PE_Programs%\Spybot - Search & Destroy\"

Hive_Unload,Default

If the reason is that given, namely that Spybot doesn't know where it is because %CDDrive% isn't a defined variable, then why on earth is the api translating %PE_Programs% into an undefined variable? Seems to me I agree with Peter that it is an issue with the VistaPE api.

Regards,
Galapo.

Does anyone know with which crappy library the applications are written, that can't handle 0x2 registry entries?

What you do is create 2 wims boot.wim, programs.wim. At boot time you use imagex to mount programs.wim at x:\Programs. The advantage of this is that programs.wim is not loaded into ram so the mechanism uses much less memory than if all files were packed into boot.wim. All files in programs.wim are thus accessed via x:\Programs. Only requirement is that whatever directory you use as the mount point on x: must be empty.

OK, I get it now.

I bet that would be a major rewrite of the VistaPE project.

Problem is that none of the advapi32 registry access functions automatically expand environment variables in a value when its read even if the type is REG_EXPAND_SZ. You have to call a second win32 api function ExpandEnvironmentStrings to do that.

However sometimes if you indirectly access the registry e.g. via a CoCreateInstance call to create a COM object then the COM subsystem does expand environment variables. Windows subsystems seem to be inconsistent in their automatic expansion of environment variables in registry values.

paraglider, the problem is not entirely if the registry string get's expanded or not.
Allmost all applications work fine with variables in 0x2.
Some prefer variables in 0x1.
So far only 2 apps, which have problems with variables of any kind in the registry are reported. IZARC and Spybot.
Which suggests rather, that those two do something wrong, than that Windows is at fault here.

I don't know if Spybot has a problem with 0x2 where it expects 0x1. All I know is that it can't handle %CDDrive%\... if %CDDrive% isn't defined. That's not doing anything wrong.

I don't know if Spybot has a problem with 0x2 where it expects 0x1. All I know is that it can't handle %CDDrive%\... if %CDDrive% isn't defined. That's not doing anything wrong.

And who is the bad boy writing %CDDrive% and not defining it in the registry as environment?

Back to the topic's title:

I think that can neither be defined by Reg2WBS nor by ConvRegToInf.

Peter

I think that %CDDrive% is converted to the right value ( E:\ or else) at boot time , but i don't know wich process do that
there is probably something wrong or missing in this process ,or order of process not well set

Pedro