24 replies to this topic

[pscEx]

please, see introducing post http://reboot.pro/to...er-2013-syntax/

 

public RegHeader(String filePath)

 

RegHeader level:

public void buildStorage()
public RegKey buildTree()
// this statement wraps the above two statements
// you can use it,when the root key is not needed
// in project scripts root key is usually not needed
public void open()

public void setAllowValOverwrite(boolean val)
public void setAutoCreateKey(boolean val)

 

public boolean hasError()
public HiveError getErrorCode()

public String getErrorText()

public static enum HiveError {

        Success, NoKey, NoVal, KeyExists, ValExists, NoHive, HiveInUse, InvalidData, IOError, NoMulti, MultiExists, NoMultiType, OverWroteDiff
}

 

public boolean createKey(String parentKey, String newKey)
public boolean deleteKey(String keyPath)
public boolean existKey(String keyPath)

public RegKey readKey(String keyPath) {
 

public boolean fetchOpen(String otherHivePath)

public boolean fetchKey(String key, boolean allowKeyOverWrite)

public void fetchRelease()

 

public boolean importReg(String regName)

public void commit()

public void release()

 

RegKey level:

public boolean createValue(String keyPath, String valName, int type, Object value)
public boolean modifyValue(String keyPath, String valName, Object value)
public boolean deleteValue(String keyPath, String valName)
public boolean existVal(String keyPath, String valName)

public int getValueType(String keyPath, String valName)
public String getValueString(String keyPath, String valName)
public byte[] getValueRaw(String keyPath, String valName)
public boolean createValueRaw(String keyPath, String valName, int type, byte[] newBytes)
public boolean modifyValueRaw(String keyPath, String valName, byte[] newBytes)
public boolean modifyValueMulti(String keyPath, String valName, String value, int insertIndex)

public boolean regExport(String theExport)
public boolean regExport(File theExport)
 

Example:

String trgString = "V:\\WB Test\\run\\output\\wim-boot\\Windows\\system32\\config\\default";
RegHeader defaultHive = new RegHeader(trgString);
if (defaultHive.getErrorCode() != RegHeader.HiveError.Success) {
    System.out.println(defaultHive.getErrorText());
} else {
    defaultHive.open();
    defaultHive.setAutoCreateKey(true);
    defaultHive.setAllowValOverwrite(true);
    if (!defaultHive.existKey("Software\\Dino\\ValueTypes")) {
        result = defaultHive.createKey("Software\\Dino", "ValueTypes");

        if (!result) {
           System.out.println(defaultHive.getErrorText());

        }
    }
        File fetch = new File(sourceHivesDir, "DEFAULT");
        String fetchString = fetch.getAbsolutePath();
        defaultHive.fetchOpen(fetchString);
        defaultHive.fetchKey("Control Panel\\International", true);
        defaultHive.fetchRelease();

    defaultHive.commit();

    defaultHive.release();
}

A more detailed example can be found in the Win7PE project, StartupCode plugin, plugin_wim.bsh script.

[sbaeder]

Good to see you are publishing some of the syntax.  Also good to see progress on this.

 

While I have no real objection to the syntax, I have recently been using a system where the interface is more along the lines of AddUpdate as a single function.

 

For example, do you really need to have both of these functions?

 

public boolean createValue(String keyPath, String valName, int type, Object value)
public boolean modifyValue(String keyPath, String valName, Object value)

 

You could also do it as a single function name where the type is "required" if it needs to be created, and is checked for compatibility if non-NULL and the key exists.  *BUT* as I said, it is just a matter of preference when dealing with a rich environment.   It does put more code into the library routine, and makes it a bit harder to determine intent.  On the other hand, there are times when you don't want to code the "If it exists then modify else create" code in the application.

 

But then nothing would stop you from making a library that wrapped these functions with that same sort of logic to make a CreateModify routine if the lower level routines mentioned above exist.

 

Again, Good Luck with this effort!!!

 

Scott

[paraglider]

How are REG_MULTI_SZ values handled? Are you using unicode?

[paraglider]

I agree with sbaeder should only be a need for one setValue function which either creates or replaces. Would be nice to have an append / prepend option for reg_multi_sz values.

[pscEx]

But then nothing would stop you from making a library that wrapped these functions with that same sort of logic to make a CreateModify routine if the lower level routines mentioned above exist.

 

 

I wanted to avoid any unwanted actions to be performed by WinBuilder.

always ceate brings an "false" return value, if the item already exists.

always modify brings an "false" return value, if the item does not exist.

 

You remember the WinBuilder 82 functions when it was possible, that an un-cooperative script overwrotes something a different script did previously.

 

You are right, the script developer can write his own "createOrModifyVale" function inside library.bsh.

But then is he responsible for the result, not the WinBuilder functionality.

 

Peter

[pscEx]

Would be nice to have an append / prepend option for reg_multi_sz values.

 

Suggestion:

public boolean modifyMultiValue(String keyPath, String valName, Object value, int index)

index: where to insert, -1 for append

Peter

[pscEx]

 Are you using unicode?

 

When you like Russian newspapers:

result = defaultHive.createValue("software\\Dino\\ValueTypes", "Unicode_String", 0x1, "\u041f\u0440\u0430\u0432\u0434\u0430");

 

Peter

[paraglider]

So bsh scripts cannot be encoded in unicode and the registry functions write directly in unicode without using hex strings? I was hoping that unicode would become a none issue with the new winbuilder.

[paraglider]

To my mind its better if scripts are self contained and don't depend on other scripts. So if a script requires a registry setting it should set the registry value without having to worry if the registry value already exists. If a script overwrites registry value X with X then that is not a problem. If it overwrites registry value X with Y then that is something of interest.

[paraglider]

After all the win32 registry api does not differentiate between add and update of values.

[pscEx]

After all the win32 registry api does not differentiate between add and update of values.

 

By design, for WinBuilder a Windows API does not exist.

WinBuilder does what is reasonable to create valid WIN data in WIN files.

(Which syntax is "reasonable" may be topic of discussion)

 

Peter

[pscEx]

So bsh scripts cannot be encoded in unicode and the registry functions write directly in unicode without using hex strings? I was hoping that unicode would become a none issue with the new winbuilder.

 

Please tell us, how e.g. javascript or vbscript handle this.

 

Peter

[Wonko the Sane]

OT (as often happens), the bsh extension or acronym appears to me as sounding not particularly well. 

 

I sincerely hope that it is just that and there is no connection with the contents.

 

Wonko

[pscEx]

Look here:

 

http://www.beanshell...shcommands.html

 

and not here:

 

http://www.allacronyms.com/BSH

 

Peter

[sbaeder]

and just to be clear, I am not opposed to the current philosophy w.r.t. the design of the API.  It is a point of view and I respect it.  Of course there are others that are also valid, and while often some are seen as "better" than others (even by a majority), that doesn't necessarily void the original point of view (based on a valid philosophy).

 

There is a lot to be said of the KISS principal here as well as the opportunity to build other "frameworks" on top of the underlying abstractions.

 

It is an ambitious undertaking, and I give "props" to PSC and Nuno (and by extension the entire community)!

 

Scott

[Brito]

So bsh scripts cannot be encoded in unicode and the registry functions write directly in unicode without using hex strings? I was hoping that unicode would become a none issue with the new winbuilder.

 

I don't how far this would work without issues, perhaps later you can try and let us know what exactly is working or not. On the current structure, I know you can write settings to XML files with unicode data just fine.

 

 

Beanshell allows using Java source code snippets and libraries. To convert the data, you just need to grab and adapt some code snippet around the web such as:

public static String toJAVA (String zawgyi) {
    String output = "";
    char[] charArray = zawgyi.toCharArray();

    for (int i = 0; i < charArray.length; i++) {
        char a = charArray[i];
        if ((int) a > 255) {
            output += "\\u" + Integer.toHexString((int) a) + "--";
        } else {
            output += a;
        }
    }       
    return output;
}

Source: http://stackoverflow...o-ascii-in-java

 

Not a perfect solution but you can already store the unicode data inside an XML file and then read the data to write on the registry as needed. Like I said, unicode might as well be supported but attention has been given to other details.

 

Writing/handling XML files is quite a simple task inside winbuilder. Here is an example of how to setup a Settings object and then write/read data from this object:

 

        File myFile = new File("test.xml");
        Settings myXML = new Settings(myFile, "My description of XML file");
        myXML.write("testKey", "testValue");
        String test = myXML.read("testKey"); 

 

To specifically write unicode strings, you can edit the XML file using an appropriate text editor. For e.g. notepad plus should suffice.

 

 

[pscEx]

Syntax in first post updated.

 

Peter

[pscEx]

Are you using unicode?

 

A test would have answered your question - sorry, cou cannot yet perform the test

 

What I did:

 

I installed greek support in my XP x86.

 

In the test script, I made an input line using greek for the value.

(The image link is nearly invisible, but click onto it)

 

Result in RegeditEx:

 

As a result:

Unicode is fully supported

 

Peter

 

EDIT:

To convince unbelievers:

[pscEx]

Updated first post.

• Added some "What's wrong" information.
• Added setAllowValOverwrite and setAutoCreateKey

 

Peter

[pscEx]

Updated first post

• added "modifyValueMulti" method

Peter

[Wonko the Sane]

Nice .

Re-inventing (portable but with hardcoded \System32\config) hot water, one degree at the time.

 

Wonko

[pscEx]

Try one minute to understand:

 

Here is a portable programm which can work on "any" host , handling Windows Registry Files.

 

And Billy the Door has hardcoded that these files are in system32\config.

 

BTW: It is correct, that hot water is already known and can only be re-invented. But I do not know a program which e.g on Linux or Mac OS handles Windows Registry files.

 

Please increase my knowledge and tell me the list of such programs.

 

Peter

[Wonko the Sane]

The fact that is portable is very nice (and that is the actual "core" of the re-invention ), the fact that it is hardcoded to \System32\config\ is IMNSHO completely senseless.

 

If you think about it a little , one of the main aspects of the thingy being written in java and more loosely a good 3/4 to 4/5 of your contributions to the Community are about FREEING OURSELVES by the senseless limits and obstacles that MS put before us, giving us OPTIONS that were not available before, allowing us to have a further degree of FREEDOM.

 

And you go hardcoding a path?

 

If it helps, the Offline Registry library (which is made by MS) DOES NOT have a hardcoded path for it's target registry file.

 

You are being - for no apparent reason - più realista del re. (which translates to "katholischer als der Papst sein"):

http://forum.wordref...d.php?t=2520847

 

 

Wonko

[pscEx]

If it helps, the only 'hardcoded' system32\config in this topic is this:

Example:

String trgString = "V:\\WB Test\\run\\output\\wim-boot\\Windows\\system32\\config\\default";
RegHeader defaultHive = new RegHeader(trgString);

Can you please explain the community, how an application can acccess a registry, when it does not tell the real path to it?

 

Peter

[Wonko the Sane]

  

Can you please explain the community, how an application can acccess a registry, when it does not tell the real path to it?

 

I thought that the contents of this thread will be reflected in (or are parallel to) the evolution of the tool:

http://reboot.pro/to...8642-regeditex/

where you stated that the tool is and will only be able to use Registry files placed in a given fixed directory structure of the type \Windows\System32\config or \System32\config and the said tool has been actually referenced to in the present thread, sorry if this is not the case , the comments are to be intended about the limitations artificially introduced in RegeditEx (and that may - or may not - apply to the "scriptable version").

 

Wonko