Add a method to parse a given environment block

[delphidabbler]

The TPJEnvironmentVars.GetAll method parses the current environment block. There is also similar code in demo1 that parses a generated block.

Between the two there's enough code to create a suitable method. TPJEnvironmentVars.GetAll could then be rewritten to use the new method to parse the current environment block.

[delphidabbler]

If issue #11 is implemented then it would probably be better to put this functionality in that class.

[delphidabbler]

Add additional method to check a block for validity would be useful, or at least an exception could be raised when parsing if an error is found.

Valid environment blocks have wide strings in name=value format, separated by wide #0 characters and terminated by a pair of wide #0 characters (#0#0).

E.g.

Question=42#0Answer=56#0Foo=Bar#0#0

[delphidabbler]

A couple of overloaded methods may be useful, one with a PChar block ans another with a Pointer block.

[delphidabbler]

Two different versions of the parse method could be useful:

1. Parse that returns an array of fully parsed TPJEnvironmentVar records.
2. ParseRaw that returns a string array containing the #0 separated raw strings so that any malformed environment variables can be seen.

[delphidabbler]

Wait for issue #11 to be started.

[delphidabbler]

Wait for issue #11 to be started.

Issue #11 started 3 September.

Parse method underway.

[delphidabbler]

Potential problem with ANSI environment blocks

The Parse method is being written to handle ANSI and Unicode environment blocks, because both types are supported in modern windows. Unicode blocks are distinguished when calling CreateProcess by passing the CREATE_UNICODE_ENVIRONMENT flag.

This raises the question of whether we can rely upon a process' environment block being Unicode? All processes that I've seen launched from modern Windows have Unicode environment blocks, but what about child processes explicitly launched with ANSI environment blocks? Does Windows convert them to Unicode before the process is started?

This is very important to know because the TPJEnvironmentVars.GetAll method assumes that its host process has a Unicode environment block and will fail if the block is ANSI. Therefore TPJEnvironmentVars.GetAll will fail on any process that has an ANSI environment block. That would be a major bug.

Given that Windows knows an environment block is Unicode because of the CREATE_UNICODE_ENVIRONMENT flag, is there a way testing for that flag? Note that this is only important if Windows doesn't convert ANSI environment blocks to Unicode.

Tests are required.

The potential problems with TPJEnvironmentVars.GetAll are now being addressed in issue #23.

[delphidabbler]

Need to be careful when parsing environment blocks obtained from OS because they can contain one (or more?) environment variables with no name, e.g. =bar.

Such variables need to be preserved for passing to child processes.

On the other hand, users should be preventEd from adding nameless environment variables.