Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
src/main/java/hudson/plugins/cygpath/CygpathLauncherDecorator.java
http://jenkins-ci.org/commit/cygpath-plugin/f2d22f019b9184a98dff79dccb3972a5d3a283fd
Log:
[FIXED JENKINS-7303] made to work on 64bit Windows

I added a comment under JENKINS-20364, but it is somewhat relevant also for this issue, so I'm copying parts of it here.

I'm not sure the change made in JENKINS-7303 actually fixes anything (did someone test this?). The "Wow6432Node" subkey seems to be implementation detail of Windows registry and the application code should not care about it. Instead, it should use the relevant access bit (as described above). Also, my tests have shown that with current code, 64bit JVM running on 64bit Windows can access "HKEY..WARE\Cygwin\setup".

The problem is with 32bit JVM running on 64bit Windows: it looks up "HKEY..WARE\Cygwin\setup" but Windows translates that into "HKEY..WARE\Wow6432Node\Cygwin\setup" (which is missing). And, when it tries to access "HKEY..WARE\Wow6432Node\Cygwin\setup", Windows probably translates that into "HKEY..WARE\Wow6432Node\Wow6432Node\Cygwin\setup" which is also missing. So 32bit JVM running on 64bit Windows has no access to "HKEY..WARE\Cygwin\setup" unless it specifies the special KEY_WOW64_64KEY flag.

I'm not sure if the other scenario of 64bit JVM running on 64bit Windows trying to look up "HKEY..WARE\Wow6432Node\Cygwin\setup" works or KEY_WOW64_32KEY flag should be used instead (covering the case when "HKEY..WARE\Cygwin\setup" is missing but "HKEY..WARE\Wow6432Node\Cygwin\setup" exists). Should probably test that.

Assuming that the fix made here actually works (otherwise it would have been re-opened long ago), my second comment can be ignored – 64bit JVM running on 64bit Windows looking up "HKEY..WARE\Wow6432Node\Cygwin\setup" probably works. The problem is that this fix does not work for 32bit JVM running on 64bit Windows (see my comment on JENKINS-20364 for details).

Useful reading:
http://windowsitpro.com/systems-management/whats-wow6432node-under-hkeylocalmachinesoftware-registry-subkey
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384129(v=vs.85).aspx

Reopening as the solution does not work for 32bit JVM running on 64bit Windows. I'm not sure if this should be solved here or under JENKINS-20364. Feel free to resolve if JENKINS-20364 seems more appropriate.

It seems, from the above, and reading the provided links, that the current implementation of directly looking up in the SOFTWARE\Wow6432Node\ is not actually a recommended way of doing it, as \Wow6432Node is an implementation detail, and may break compatibility in the future (or past?).

Also, in our investigation, we have found that the whole Wow64 registry translation seems extremely fragile, and gives rise to al sorts of confusion, and the mapping is not even the same on different versions of windows.

We are currently investigating a situation where two machines seem to behave differently. Both are running 64 bit java (as reported by java -version in Execute shell), and both have only a 64bit Cygwin installed, and referenced in Software\Cygwin\setup[rootdir]. One of them finds cygpath just fine, the other doesn't, and the main difference between these machines is that one is running Win 7, the other Win Server 2012.

On both machines we have tried running
reg query HKLM\Software\Cygwin\setup /v rootdir /reg:32
— ERROR: The system was unable to find ....

reg query HKLM\Software\Cygwin\setup /v rootdir /reg:64
— rootdir REG_SZ c:\cygwin64

If we run
reg query HKLM\Software\Cygwin\setup /v rootdir
without the view specifier, we get the positive answer, but if we run it in a 32bit command prompt, we get the error.

Our temporary conclusion is that the current code seems to work on a 2012 Server, but not on a Win 7 box.

I am not an experienced plugin dev, so I might be missing the obvious, but couldn't the plugin start
with:

• checking for a CYGWIN_HOME environment variable before it starts messing around in the registry?
• just trying the path, as it might actually be set up just fine?

This Env var might not be set by default by the cygwin installation, but it is easy to set and control, either directly on the slave machine or through Jenkins and would also make it much easier to force the use of a specific installed cygwin. (e.g. if you have both cygwin and cygwin64 on the slave).

Any comments?

I completely agree that the plug-in should first check the environment (e.g. CYGWIN_HOME and then PATH) since it is easy to set up in Jenkins node configuration and does not depend on x86/64 issues. Only if the environment is not set up, it should default to the registry.
Note that setup-x86.exe and setup-x64.exe are recording the root directories in the same registry key under /reg:32 and /reg:64 respectively, and if both systems are installed on the same computer, then it is likely but not necessary that user would prefer Cygwin64.
Therefore the reasonable sequence would be: environment variables, then reg:64, then reg:32.

I also agree the plug-in should check the environment for CYGWIN_HOME and then PATH.

Currently I have setup the cygwin64 with following configuration passed to the setup-x86_64.exe(since I do not have admin privileges on my System)  : 

// code placeholder
> setup-x86_64.exe --no-admin

In this case the cygwin setup does not even create registry entries which has been hard-coded here.

This also results in various plugins to malfunction.

Below are my configuration (batch file) for  running Jenkins on Windows 7 64-bit.

@rem jenkinsSetup.bat

set CYGWIN_HOME=C:\cygwin64
set PATH=%CYGWIN_HOME%\usr\local\bin;%CYGWIN_HOME%\usr\bin;%CYGWIN_HOME%\bin;%PATH%

java -jar jenkins.war

I have created a job with CMake plugin and the plugin is unable to locate the cygwin setup.

Where as the cygpath is available in PATH environment variable.

Also the CMake plugin is passed the windows path due to this issue, which leads to incorrectly configured projects which are unable to build using tools from cygwin environment.

Kindly update the cygpath plugin to handle the CYGWIN_HOME and PATH variable check to configure it properly.

-Ameya