22 replies to this topic

[pscEx]

freeHive scans the registry's HKEY_LOCAL_MACHINE for subkeys.
If it finds a subkey different from the 'known' subkeys

• 'HARDWARE'
• 'SAM'
• 'SECURITY'
• 'SOFTWARE'
• 'SYSTEM'

it assumes that this is a hive which is left from an erroneous WinBuilder run and unloads this hive.

The program can be found in the download area and http://nativeex.boot...ve/freeHive.zip

It can be included in one of the first scrips of a project, maybe into script.project

Peter

The 'basic' code:

Status := RegQueryInfoKey(HKEY_LOCAL_MACHINE, nil, nil, nil, @childNum, nil, nil, nil, nil, nil, nil, nil);

  if Status = ERROR_SUCCESS then

  begin

	for p := childNum - 1 downto 0 do

	begin

	  Status := RegEnumKey(HKEY_LOCAL_MACHINE, p, PChar(childName), DefValueSize);

	  value := PChar(childName);

	  if &#40;AnsiCompareText&#40;value, &#39;HARDWARE&#39;&#41; <> 0&#41;

		and &#40;AnsiCompareText&#40;value, &#39;SAM&#39;&#41; <> 0&#41;

		and &#40;AnsiCompareText&#40;value, &#39;SECURITY&#39;&#41; <> 0&#41;

		and &#40;AnsiCompareText&#40;value, &#39;SOFTWARE&#39;&#41; <> 0&#41;

		and &#40;AnsiCompareText&#40;value, &#39;SYSTEM&#39;&#41; <> 0&#41; then

		RegUnLoadHive&#40;HKEY_LOCAL_MACHINE, value&#41;;

	end;

  end;

BTW: RegUnLoadHive is one of my own functions, I already use in regRedirect.

[Alexei]

freeHive scans the registry's HKEY_LOCAL_MACHINE for subkeys.
If it finds a subkey different from the 'known' subkeys

• 'HARDWARE'
• 'SAM'
• 'SECURITY'
• 'SOFTWARE'
• 'SYSTEM'

it assumes that this is a hive which is left from an erroneous WinBuilder run and unloads this hive.

The program can be found in the download area and http://native.boot-l...ls/freeHive.exe

It can be included in one of the first scrips of a project, maybe into script.project

Peter

The 'basic' code:

Status := RegQueryInfoKey(HKEY_LOCAL_MACHINE, nil, nil, nil, @childNum, nil, nil, nil, nil, nil, nil, nil);

  if Status = ERROR_SUCCESS then

  begin

	for p := childNum - 1 downto 0 do

	begin

	  Status := RegEnumKey(HKEY_LOCAL_MACHINE, p, PChar(childName), DefValueSize);

	  value := PChar(childName);

	  if &#40;AnsiCompareText&#40;value, &#39;HARDWARE&#39;&#41; <> 0&#41;

		and &#40;AnsiCompareText&#40;value, &#39;SAM&#39;&#41; <> 0&#41;

		and &#40;AnsiCompareText&#40;value, &#39;SECURITY&#39;&#41; <> 0&#41;

		and &#40;AnsiCompareText&#40;value, &#39;SOFTWARE&#39;&#41; <> 0&#41;

		and &#40;AnsiCompareText&#40;value, &#39;SYSTEM&#39;&#41; <> 0&#41; then

		RegUnLoadHive&#40;HKEY_LOCAL_MACHINE, value&#41;;

	end;

  end;

BTW: RegUnLoadHive is one of my own functions.

I disagree Initially the same solution came to my mind, but then I found that it may do a lot of harm if user's registry has other hives under HKLM (that's registry on builder's PC, it may have anything inside).
As I already mentioned WB better create designated subtree where WB would keep a list of created sub-trees (i.e. hives). Something like:
HKLM\WBTempHive1\ keys and values
HKLM\WBTempHive2\ keys and values
HKLM\WBhives\
Key=WBhives
Key=WBTempHive1
Key=WBTempHive2
I believe this is a reliable solution not hard to implement

Alexei

[pscEx]

I disagree Initially the same solution came to my mind, but then I found that it may do a lot of harm if user's registry has other hives under HKLM (that's registry on builder's PC, it may have anything inside).

You are wrong!
If there is a 'normal' key, let me call it BLABLA, then the RegUnLoadHive BLABLA lets the program crash. It really only removes loaded hives and cannot delete valid keys.

In the first version I had a 'try' block for that, but I thought that having an additional regular key is not possible with current XP and W2003
Try to create a subkey under HKLM with reg.exe, regedit.exe or a home made program! If you have success, you are a candidate for the next Nobell Award!

Peter

[pscEx]

As I already mentioned WB better create designated subtree where WB would keep a list of created sub-trees (i.e. hives). Something like:
HKLM\WBTempHive1\ keys and values
HKLM\WBTempHive2\ keys and values
HKLM\WBhives\
Key=WBhives
Key=WBTempHive1
Key=WBTempHive2
I believe this is a reliable solution not hard to implement

Sorry, I got the bug assigned and can only use 'external' procedures. I do not have any access to WinBuilder source.

If you have a look into my remarks in the bug tracker, I recommend that my temporary solution has to be replaced by an internal WinBuilder solution.
And there your suggestion is one possible way.

But in this topic that is OFFTOPIC.

Peter

[Brito]

And what about all the unattended project building?

Imagine the fun when you are in the middle of building a multi-project-multiple-one-ISO-boot result or something similar?

----

On a serious note - some people already complained on slow registry write operations and now we would have to add logging to slug things - what happened if I decided to write a registry key on the host hives to change some setting inside the host windows itself - would our code also be safe and secure enough to avoid these slips?

----

Everything can be added and I would like to see safe and stable hive loads - but somehow this sounds like an open invitation for bringing a new storm of bugs to solve.

While we don't progress more indepth to this matter - each project/script needs to worry about this question.

So far the recently introduced api is a good help because it will let us change the api functions to previously unload a hive if we are attempting to load another hive under the same name or simply unload all hives before building a ISO or finishing a project and doing a global hive cleanup.

[Alexei]

@Nuno,
There are many reasons to take in consideration when we decide what should be in WB and what in scripts.
To some extent position "all things that can be done by scripts should be in scripts" is reasonable, but it has a disadvantage of creating more dependencies and worsen performance.
On phylosophical note, WB is universal, but that makes it very tolerable to anarchy. Here comes an idea: we add "Pragma=" under the "[main]" to specify the level of anarchy allowed in the script. Why? If script modifies other script it may be OK for "core"-scripts, but should not be allowed in application scripts, etc.
Anyway, some initialization script should be automatically called (similar to, for ex., "login script").
Regarding making hives: again, depending on special script setting (such as "RealHives=") WB can choose a Registry sub-trees or .reg fileswith following merge at final build stage. There are many possibilities here, but we should remember that "free cheese = mouse trap"

Alexei

[pscEx]

And what about all the unattended project building?
Imagine the fun when you are in the middle of building a multi-project-multiple-one-ISO-boot result or something similar?

Very rarely in the middle of an unattended build somebody hits the 'Stop' button

While we don't progress more indepth to this matter - each project/script needs to worry about this question.

Anyway, some initialization script should be automatically called (similar to, for ex., "login script").

Suggestion:
The main section of a script contains two keys:

OnEntry=Run,%ScriptFile%,Section

OnExit=Run,%ScriptFile%,Section

If present, this command(s) are performed on every entry / exit of the script, regardles it is a normal run via [process] or an external run / exec into any section.
Just for clearness: Exit is not only end of the section, exit are also the 'Halt' and 'Exit' commands and the 'Stop' button.

So far the recently introduced api is a good help because it will let us change the api functions to previously unload a hive if we are attempting to load another hive under the same name or simply unload all hives before building a ISO or finishing a project and doing a global hive cleanup.

For the current issue, this is a good alternity!

Peter

[Alexei]

Suggestion:
The main section of a script contains two keys:

OnEntry=Run,%ScriptFile%,Section

OnExit=Run,%ScriptFile%,Section

Is it suggestion for a new WB functionality or to developers to use this feature?
Anyway, if WB crashes scripts may be hardly possible to run
Anyway, at least one entry has to be added to WB ini: TerminatiedOK=Yes/No to signify if verification/recovery is needed (i.e. OnExit was not performed).

Alexei

[MedEvil]

Anyway, at least one entry has to be added to WB ini: TerminatiedOK=Yes/No to signify if verification/recovery is needed (i.e. OnExit was not performed).

Nice idea! A second program watching WB and cleaning up after crash, would also be possible.

[Brito]

On the newer beta I'm already using several open instances of the same wb executable open at the same time.

It is possible to edit/run a script using the standalone editor, run a project in unattended mode and also launch projects in the unattended mode allowing several different projects running at the same time.

Writing any settings to winbuilder.ini would reflect on the other instances and become a bit confusing to sort out which one uses which.

But following the idea posted above by MedEvil - this also means that WB can now clean up the trash created by other wb instances.

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

Peter also raised a good argument - if someone presses the stop button while the hives are loaded there isn't much protection to ensure that these hives or any locked files aren't properly clean and leaves our project "dirty"

How about adding support for a new section inside our projects?

As suggested, maybe a [OnExit] section would be looked inside the respective script.project file whenever a user presses the stop button.

Each script file could also contain this section which would be executed before the [OnExit] section from script.project - this would allow to add a general procedure to clean up the whole project with minimal interference on app scripts and other already created scripts and also add enough space for individual script which require very specific clean up actions.

----------

Assigning a value to OnError on each [Main] section of both script.project and optionally the script itself could also be done - please let me know your opinions about which method you think it's better.

[pscEx]

On the newer beta I'm already using several open instances of the same wb executable open at the same time.

Is this possible?

• Instance #1: RegHiveLoad,"WB-Setup","%target_sys%\setupreg.hiv"
• Instance #2: RegHiveLoad,"WB-Setup","%target_sys%\setupreg.hiv"
• Instance #2: RegHiveUnLoad,"WB-Setup"
• Instance #1: RegHiveUnLoad,"WB-Setup"

Assigning a value to OnError on each [Main] section of both script.project and optionally the script itself could also be done - please let me know your opinions about which method you think it's better.

That makes sence if an unique error description (at least identifyer number, better the command and a list of arguments too) is delivered, e.g.
#1: error number
#2: line number
#3: command
#4: number of command arguments
#5: command argument #1
#6: command argument #2
#7: command argument #3
#8: command argument #4
#9: other command arguments

Peter

[Brito]

That is an excellent idea!

Only unsure about arguments handling - it might become messy having so many arguments and avoid comma confusions to split each argument but maybe this can be solved with special comma handling within wb to make it easier to handle.

One simpler idea would be creating #a1..#a9 variables that would directly represent each one of the possible arguments and making these vars acessible inside the [OnExit] section.

Do you like this layout?

#1: script file where error occured
#2: line number
#3: command
#4: number of command arguments

Do propose changes/improvements!



---- Edit ----------------------------------

Forgot your first question -- sorry!

Running several instances can make very unpredictable results with hives that's why each project should be as hive-safe possible.

In the example you mention this would likely happen:

• Instance #1: RegHiveLoad,"WB-Setup","%target_sys%\setupreg.hiv" --> Hive loaded
  
• Instance #2: RegHiveLoad,"WB-Setup","%target_sys%\setupreg.hiv" --> Ignored, WB-Setup key already in use
  
• Instance #2: RegHiveUnLoad,"WB-Setup" --> Hive unloaded
  
• Instance #1: RegHiveUnLoad,"WB-Setup" --> Ignored, no WB-Setup on host

Using a standard app scripts API it's much harder to make mistakes because each call to the registry requires hive unloading which can be preceded with proper hive unloading if necessary - could also be done inside wb but this way we can control this process inside any project in the future if needed. API needs to be smart..

Edited by Nuno Brito, 08 November 2007 - 12:21 PM.

[MedEvil]

Each script file could also contain this section which would be executed before the [OnExit] section from script.project - this would allow to add a general procedure to clean up the whole project with minimal interference on app scripts and other already created scripts and also add enough space for individual script which require very specific clean up actions.

I would prefer, if the cleanup did not happen in the script, but in WB. This way, noone can not get it right.
Something like, remove all hives, unlock all files.
Less general things will probably have to stay in the hands of the script developer.

[MedEvil]

That makes sence if an unique error description (at least identifyer number, better the command and a list of arguments too) is delivered, e.g.
#1: error number
#2: line number
#3: command
#4: number of command arguments
#5: command argument #1
#6: command argument #2
#7: command argument #3
#8: command argument #4
#9: other command arguments

I think Alexeis idea was more to set a flag, for cleanup after a crash, than to implement proper error handling.

[Alexei]

I think Alexeis idea was more to set a flag, for cleanup after a crash, than to implement proper error handling.

Yes, I was talking about "worse case scenario" when WB crashes unexpectedly and script's "On-exit" was not called. From this position, "next start recovery" is preferable (it's like automatic checkdisk on a next start after BSOD).

Alexei

[pscEx]

One simpler idea would be creating #a1..#a9 variables that would directly represent each one of the possible arguments and making these vars acessible inside the [OnExit] section.

That is what I meant

Running several instances can make very unpredictable results with hives that's why each project should be as hive-safe possible.

In the example you mention this would likely happen:

* Instance #1: RegHiveLoad,"WB-Setup","%target_sys%\setupreg.hiv" --> Hive loaded
* Instance #2: RegHiveLoad,"WB-Setup","%target_sys%\setupreg.hiv" --> Ignored, WB-Setup key already in use
* Instance #2: RegHiveUnLoad,"WB-Setup" --> Hive unloaded
* Instance #1: RegHiveUnLoad,"WB-Setup" --> Ignored, no WB-Setup on host

Using a standard app scripts API it's much harder to make mistakes because each call to the registry requires hive unloading which can be preceded with proper hive unloading if necessary - could also be done inside wb but this way we can control this process inside any project in the future if needed. API needs to be smart..

We should have a variable %PID% which is filled by WinBuilder at start.
The scripts (or API) can add %PID% to hive names, as well as to temp files and wherever applicable.
(Temp files are also not thread safe )

Peter

[pscEx]

Yes, I was talking about "worse case scenario" when WB crashes unexpectedly and script's "On-exit" was not called. From this position, "next start recovery" is preferable (it's like automatic checkdisk on a next start after BSOD).

Alexei

In this case the recovery work depends on the individual project.
Why not, as step #1, let a project do:

• In the very begin of the project having a script which
  • looks for e.g. 'started' in script.project
    If 'started' is defined, do the 'checkdisk'
  • writes 'sarted' to script.project
• In the very last having a script which removes the 'started'

In the second step WinBuilder can do this work and in case 'checkdisk' is necessary, it calls 'CheckDisk.Script' of the project.

This would also handle crashes occuring during process of a single script (which is not included in step 1)

The advantage of this is that we can get experience with this stuff, w/o any primary change of WinBuilder

Peter

[Alexei]

The advantage of this is that we can get experience with this stuff, w/o any primary change of WinBuilder

I agree, for now it should be OK, though universal project-independent solution is preferable because it can be done once and for all Unfortunately, it could be hard to begin working on such solution after fixing the problem on a script-level

Alexei

[pscEx]

Following a suggestion of Lancelot (and logically avoiding Alexei's concerns), I added a feature:

freeHive.exe can be started with an optional argument.

The argument is interpreted as folder, and only hives which physically reside in this folder or subfolders, are dismounted.

Therefore a simple WinBuilder command line could be:

ShellExecute,Hide,%Tools%\freeHive,"%TargetDir%"

That unmounts hives left from a broken build of only the current project.

All other mounted hives are not affected.

Many thanks to Lancelot for the idea, and Karyonix for the key-hint!
That's team work!

Peter

[was_jaclaz]

To keep things together, this is the related thread for the above:
http://www.boot-land...?showtopic=9318

jaclaz

[pscEx]

To keep things together, this is the related thread for the above:
http://www.boot-land...?showtopic=9318

jaclaz

To hold things together, I wrote a link to this topic in the topic you mention.

This is the 'technical' page and IMO must not necessarily contain links to topics about this main page.

Peter

[was_jaclaz]

To hold things together, I wrote a link to this topic in the topic you mention.

This is the 'technical' page and IMO must not necessarily contain links to topics about this main page.

Peter

We have of course different views on how to "hold things together".
If someone gets on the other topic, he may learn HOW to do it AND (getting here) get the program that does it.
If someone gets here, he may get the program that does it BUT would NEVER learn HOW to do it (without my cross-link).

jaclaz

[pscEx]

Peter