EnVar Plugin - Adds and removes environment paths

[JasonFriday13]

This plugin has been in development on and off again for about a year and a half, and it's finally ready for public release.

Basically this plugin allows you to check for environment variables, check for paths in those variables, add and remove paths, and delete environment variables.

Download from here: http://nsis.sourceforge.net/EnVar_plug-in.

If you have any problems, reply to this thread.

[JasonFriday13]

I have updated this plugin, as requested by a member of the community I have added updating the installer environment from the registry with a function.

Check it out at the wiki page: https://nsis.sourceforge.io/EnVar_plug-in.

[JasonFriday13]

I have updated this plugin, I rewrote most of it to use a double linked list to get around some memory issues, and I have added two more error codes (the error codes have changed order as a result).

Check it out at the wiki page: https://nsis.sourceforge.io/EnVar_plug-in.

[JasonFriday13]

I made another small update, now EnVar::update supports passing "null" as a RegRoot, which causes the named variable to be removed from the installer environment.

Check it out at the wiki page: https://nsis.sourceforge.io/EnVar_plug-in.

[broleke]

Hi,
I'm wondering if you are not getting a buffer overflow with some unicode locale handling.
When looking at the example from MSDN, we can see that there is a while loop for any allocation:
https://docs.microsoft.com/en-us/win...gqueryvalueexa
In your implementation, you assume that APPEND_SIZE and IS_UNICODE_AND_ODD function would allow to get a correctly sized buffer. I'm not sure about that.
Actually, I could observe some issue with German and Japanese ReadRegVar checks when checking for a given string in PATH.
What do you think?

[JasonFriday13]

MSDN also says this:

If lpData is NULL, and lpcbData is non-NULL, the function returns ERROR_SUCCESS and stores the size of the data, in bytes, in the variable pointed to by lpcbData. This enables an application to determine the best way to allocate a buffer for the value's data.

In older versions of the plugin I did use a while loop for allocation, but I have rewritten it to request the amount of space required and added a few more bytes on the end for a NULL terminator and maybe a semicolon if needed. APPEND_SIZE also changed, it was 4 bytes, now it's 4 TCHARs (4 bytes for ansi, 8 bytes for unicode). It's ok if the memory allocated is bigger than the data, it just means the end of the memory is unused.

I haven't tested any other languages than English, sorry. If you can provide a sample script that shows the problem, I can take a look at it.

[broleke]

Thanks for your feedback.
I'm checking if a given folder is already present in the PATH, using EnVar::Check

EnVar::Check "PATH" "$INSTDIR\bin"

In this case, PATH is populated with folders using Japanese characters (for instance the \ separator is written differently).

[broleke]

Another question (sorry for that : where should we get the release, from https://github.com/GsNSIS/EnVar/releases or https://nsis.sourceforge.io/EnVar_plug-in ?

[JasonFriday13]

The only place I release code is either on the nsis wiki or on sourceforge.

[edit] Version history is here: https://nsis.sourceforge.io/File:EnVar_plugin.zip.

[JasonFriday13]

This simple script works for me, I wonder what else is happening?

PHP Code:

Name "test1"

RequestExecutionLevel user

Unicode true
ShowInstDetails show

!addplugindir "."

Section
  ; using hkcu
  EnVar::AddValue "test1" "こんにちは、元気ですか"
  Pop $0
  DetailPrint "EnVar returned=|$0|"  
  EnVar::Check "test1" "こんにちは、元気ですか"
  Pop $0
  DetailPrint "EnVar returned=|$0|"
  SetAutoClose False
SectionEnd 


[Anders]

Chopping a string at arbitrary positions is what kills non-English Unicode support but as long as you only chop at basic non-alphabet ASCII characters like ; and | you should be alright.

The Japanese Yen is seen as the path separator in non-Unicode programs because the Japanese codepage has the Yen where \ should be. MSDN says WideCharToMultiByte converts both \ and the Yen to the same character on Japanese systems.

[broleke]

Thanks you both for your answer.
Jason, on the example, do you get the same behavior when checking at an existing PATH (HKLM) already populated with lots of stuff ?

[broleke]

thanks

[JasonFriday13]

At the moment I'm only checking for white space and semicolons at the start of the values, and only the semicolon to separate the values.

I attached a picture of a test with two different Japanese strings. I had to save the .nsi as a proper unicode file to get this result.

[broleke]

Jason, can you use your nsi file and update the call to EnVar::check to check for the PATH (HKLM), that would need to be fully populated first ?

[JasonFriday13]

That's exactly what I did for the screenshot.