Count arguments bug

Hi, ied206
A Bug occurs when a command has an optional argument, example:
Manual:

Code: [Select]

RegCopy,HKLM,MainKey,(*Key*) (*key* Optional. ex: search for *microsoft.vc80* in SideBySide\Winners subfolder and copies it)Script Win10XPE\Core.script

Code: [Select]

RegCopy,HKLM,Tmp_System\ControlSet001\Services\AppinfoLog:

Code: [Select]

<Errors>
- [1] Error in Script [Build Core] (Win10XPE\Core.script)
[Error] Error - Command [RegCopy] can have [4] ~ [5] arguments (RegCopy,HKLM,Tmp_System\ControlSet001\Services\Appinfo) (Line 197)
Regards, Nikzzzz.

Hi Nikzzzz

Code: [Select]

RegCopy,HKLM,MainKey,(*Key*) (*key* Optional. ex: search for *microsoft.vc80* in SideBySide\Winners subfolder and copies it)
I developed this macro for the need of Win10XPE project
But since, the RegCopy idea has been taken up by ied206 and Homes32. I had seen lately, trying to understand the same errors.
And it is now written natively (using Reg Query also, I believe) in PEBackery with another syntax, more general and I understand for the name and for the syntax.
But sadly it is not compatible with my macro which has the same name.
RegCopy Commands

Code: [Select]

RegCopy,<SrcKey>,<SrcKeyPath>,<DestKey>,<DestKeyPath>[,WILDCARD]

Hi,ChrisR.
Thanks for the explanation.
I was able to build Win10XPE Project in PEBakery, renaming your macros to Reg_Copy in all scripts.

Regards, Nikzzzz.

It would have been better if I had been informed about RegCopy
Well, anyway, I'll do the same by renaming the RegCopy macro, I chose RegCopyKey
However, there are still some flaws, different behavior vs WB to set interface values in the Main plugin.

 

But since, the RegCopy idea has been taken up by ied206 and Homes32. I had seen lately, trying to understand the same errors.

And it is now written natively (using Reg Query also, I believe)

RegCopy was implemented back in March for nightly builds and make a public debut in the June beta4 release. The first iteration used Reg.exe COPY however with the addition of the WILDCARDS flag it was rewritten in C# so it doesn't depend on external binary's.

As Chris pointed out the syntax is slightly different then his macro, as we chose to maintain consistency with the rest of wb/PEBakery Registry commands.

Maybe adding a compatbility option to turn on/off specific commands would work in this case (while it would be difficult to implement in current design, though). Any more ideas?

For Win10XPE part, I am still working on this issue, comparing log produced by WinBuilder and PEBakery. Sadly it is being delayed because of fixing other regressions (like Win10PESE build failure issue), but I believe it would be fixed soon.

Maybe adding a compatbility option to turn on/off specific commands would work in this case (while it would be difficult to implement in current design, though)

I do not think that this is good, on the contrary, the addition of such options can cause new problems.
A small edit of the project for PEBakery compatibility is not a problem and takes little time, сompatibility with WinBuilder will not be lost.
By the way, another small bug:

Code: [Select]

TXTAddLine,TextFile,StringLine,PLACE,LineNumberWrong number of arguments.

I do not think that this is good, on the contrary, the addition of such options can cause new problems.
A small edit of the project for PEBakery compatibility is not a problem and takes little time, сompatibility with WinBuilder will not be lost.

I agree with nikzzzz. This would cause more trouble then it's worth. In this case a small update to a single project has resolved the issue.

This was one of the reasons I tried pushing CAPI/Macro library/etc to Adopt a  method to decern their macros from core commands, a good example being AutoIt's practice of prepending an underscore for UDF functions. Not forced, but encouraged because it prevents situations like this from occuring.

By the way, another small bug:

Code: [Select]

TXTAddLine,TextFile,StringLine,PLACE,LineNumberWrong number of arguments.

From the pebakery manual:

WinBuilder's implementation of TxtAddLine allowed for an Action called Place which would allow the developer to specify a line number where the text should be inserted. This feature was depreciated in PEBakery due to lack of perceived usefulness.

The PLACE argument was not brought over from wb due to the fact that it was difficult to precieve a use case for inserting a line of text into an arbitrary location of a file. especially since neither pebakery nor wb have any search commands to gain context for inserting to a file. Such a use would require a static file with a format known  to the author (to be sure the line was always at the same/correct place in the file) and in that case they could just as easily use TxtReplace with a placeholde template..

Would you like to see this brought back? Can you demonstrate a case where this would be useful?

Would you like to see this brought back?

No, the function is not particularly necessary, it is easily solved by other methods.
I just did not know that it was not implemented, so I reported the bug.

However, there are still some flaws, different behavior vs WB to set interface values in the Main plugin.

I found out the reason why Win10XPE's selecting source button is not working in Win10PESE.
I discussed the details in github issue tracker.

To be short, PEBakery had a different policy about the relationship with interface controls and variables.

1. PEBakery treats TextLabel as an immutable control, like WebLabel. WinBuilder treats it as a mutable control like TextBox.
2. In PEBakery, Visible command uses the value stored in memory. In WinBuilder, it lookup the value from script file.

I solved the first problem by treating TextLabel as a mutable control. But the real issue is the second problem.
I designed PEBakery to read interface value from memory, for the sake of performance (Sluggish interface is a nightmare), but now this is causing the trouble.

ChrisR, may I ask other question?

- Summary
Win10XPE attempts to load hive %Gtemp%\Install.hives\DEFAULT into the registry.
But that hive seems to be created in the build, not being copied from the source.
Is this behavior intentional?

- Details
I implemented compatibility mode for Visible so PEBakery can build  Win10XPE successfully. However, I confronted another issue.

Here is an error log produced by PEBakery:

Code: [Select]

<Errors>
- [1] Error in script [Build Core] (Win10XPE\Core.script)
[Error] RegHiveLoad - Hive file [E:\WinPE_dev\Win10XPE\Temp\Install.hives\DEFAULT] does not exist (RegHiveLoad,Tmp_Install_Default,%Gtemp%\Install.hives\DEFAULT) (Line 389)
  |-> Referenced script [Macro] (Win10XPE\Macro.script)

By examining Core.script and Macro.script, I found SOFTWARE, SYSTEM, and DRIVERS in %Gtemp%\Install.hives\ are copied from install.wim. But DEFAULT is not copied/created before RegHiveLoad is called. I did not know WinBuilder creates empty registry hive if a path given to `RegHiveLoad` does not exist. That is why in the same condition, PEBakery throws an error. So PEBakery should be patched.

Did you create empty DEFAULT hive for a specific purpose, or is this a mistake?

Here is a message I had received from ChrisR
Just a little FYI if it takes a while for him to respond..

It's hard for me to find time currently.
Summer vacation in August is coming and I've got a lot of things to finish before.
I hope it'll be little better in September with less travel (tiring).
Take care

Thanks, James. I eventually got PEBakery to build Win10XPE, so I can wait.

+
As a reminder, another subtle issue I had found:

AOMEI Partition Assistant_XPE_File.script use %Version% as a local variable. It shadows WinBuilder's internal value 082.

Code: [Select]

Set,%History%,History%Script_Version%
Set,%Version%,%Script_Version%
If,%Script_Version%,SMALLER,100,Set,%Version%,0%Script_Version%
If,%Script_Version%,SMALLER,10,Set,%Version%,00%Script_Version%
If,%Script_Version%,SMALLER,100,Set,%History%,History0%Script_Version%
If,%Script_Version%,SMALLER,10,Set,%History%,History00%Script_Version%

Since PEBakery's default policy does not allow overriding fixed variables, it caused a problem.
The policy can be turned off with the compatibility option, but I suggest to rename that variable from the script.

A lot of time was put into Converting and Rewriting the WinPESE ( PC Packed and Innounp ) Plugins to work with XPE (Both use WinBuilder)

I am sure that any of those Four Plugin Creator's CAN be converted to work with PEBakery and used to create PEBakery Plugins..

Thus no need for compatibility option's.........

Title=AOMEI Partition Assistant Pro
Type=XPEPlugin
Description=AOMEI Partition Assistant Pro Version 7.0.0.0
Author=KYHI
Date=2018.06.03
Credits=
Contact=
Version=002
Level=5
Download_Level=2
Selected=True
Mandatory=False
NoWarning=False
History001=KYHI Initial XPE Plugin Created 2018.06.03
History002=Dell - Auto Updated Container v7.0.0.0 - 2018.06.03

The Initial Plugin (Version=001) Was Created with an Empty Container File..
(Version=002) Was Created When The Plugin Was First Run By User.

For Smaller Distribution Size, There Are Several XPE Plugin's Written to Download and Encode the Container File Script on First Run
And Most Of Those Plugins Also Give The User The Option To Auto-Update The Container File If a New Program Version Is Released..
Thus the plugin will become (Version=003)

Version=001 > Is The Distribution Plugin Usually Included In Project -

I think you may have misunderstood the comment. It has nothing to do with the Version=xxx line.

the variable

%Version%

(for context see highlight in red below) needs to renamed to something else if you want to use scripts like this in PEBakery without toggling the compatibility option.

Set,%History%,History%Script_Version%
Set,%Version%,%Script_Version%
If,%Script_Version%,SMALLER,100,Set,%Version%,0%Script_Version%
If,%Script_Version%,SMALLER,10,Set,%Version%,00%Script_Version%

Reasoning:
Winbuilder allows overwriting of fixed (constant) variables (%Version% is actually system variable set by winbuilder that contains the engine version, eg. 082. As this variable was relied upon by several projects PEBakery always sets %version% to 082 so those projects work in PEBakery). This is problematic for a number of reasons, so PEBakery does not allow overwriting of system variables by default. you must turn on the compatibility option (and in doing so accept the risk of clobbering your variables). The plugin creator "plugins" can be fixed by renaming the variable to something else.

eg.

Set,%History%,History%Script_Version%
Set,%Ver%,%Script_Version%
If,%Script_Version%,SMALLER,100,Set,%Ver%,0%Script_Version%
If,%Script_Version%,SMALLER,10,Set,%Ver%,00%Script_Version%

For further technical reading check out these docs or if your using a nightly build docs

regards,
Homes32

%Version% needs to renamed to something else if you want to use scripts like this in PEBakery

Actually you missed the point...
But for sake of argument - The variable has been changed inside the XPE Plugin Creator