Cygwin DLLs being modified somehow?

Andrey Repin
Tue Feb 24 11:09:00 GMT 2015

Greetings, Michael DePaulo!

>> I have a counter-question. Any objection you have to distribute your
>> application as part of Cygwin infrastructure?
>> You can still keep your NSIS installer, assuming you change it to download
>> appropriate setup.exe, and you could offer an option to make portable
>> installation from live system, knowing well that it's already rebased and
>> ready to work.

> Good question :)

> tl;dr: We would have to port a lot of other code from native win32 to Cygwin.

Not necessarily. It's not a rule that "everything should be cygwin", but I
guess, in your case it may make life actually easier for you.
Cygwin is more POSIX, than Windows, and your code would have fewer "ifdefs".

> 1st of all, note that X2Go Client itself (x2goclient.exe) uses libssh
> to authenticate and tunnel the nx-libs traffic. (nxagent on the X2Go
> Server,  nxproxy on the X2Go Client) traffic. OpenSSH is used for our
> folder and printer sharing feature specifically.

> 2nd, nxproxy and openssh are only 2 of our Windows components.  We
> also have the following native win32 executables/components (plus all
> their native win32 libraries):
> 1. x2goclient.exe
> 2. VcXsrv
> 3. PulseAudio
> 4. PuTTY

> 1. x2goclient.exe I assume we are keeping as a native win32 executable
> because we want to have it use the user's %USERPROFILE% for the user's
> config files, ssh known_hosts, etc. If we could make a cygwin port of
> x2goclient.exe use %USERPROFILE%, that would be great.

With release of 1.7.34, it is already possible.
Please refer to documentation at

> I would also need to package libssh for Cygwin. Cygwin only has
> libssh2. Fortunately, I am in contact with upstream libssh and they
> are very helpful. (Note: libssh is being actively developed, despite
> the competing "libssh2" existing.)

> The x2goclient source code is also full of ifdefs for Linux vs Windows
> vs Mac that I would need to fix for cygwin.

> 2. VcXsrv could be replaced with Cygwin XWin. However, I've tried it
> and there are some integration bugs between nxproxy and Cygwin XWin
> that I/we need to resolve 1st.

> I really want to move from VcXsrv to Cygwin XWin anyway, even if
> x2goclient remains native win32, because the upstream VcXsrv developer
> has only responded to 1 bug report / pull request I ever sent him. (He
> even ignores bug reports and pull requests like "CVE-2013-6462 in
> libXfont 1.4.6").

Sounds bad.

> He also does git updates to the latest master branch versions of X11
> libraries, rather than stable releases.

> In contrast, the Cygwin X11 devs (Jon Turney for example) are very responsive.

> Also, I need to do some performance testing (of Cygwin Xwin vs VcXsrv)
> 1st. I intend to package gtkperf for Cygwin.

> 3. PulseAudio could probably be easily switched to the cygwin version.
> I haven't tried though.

Please do try it. There was issues with it in the past, I recall, and I don't
rememeber, if they all were resolved.

> (I am maintaining PulseAudio Windows builds on the OBS. I need to
> release 6.0 and discuss listing them on the PulseAudio website.)

> 4. PuTTY is used as a replacement for libssh when the user selects to
> use Kerberos/GSSAPI authentication. In reality, this is Microsoft SSPI
> authentication, which we do want to use. We want users to be able to
> authenticate with their Windows Kerberos ticket, and Cygwin MIT
> Kerberos does not appear to support this. (Neither does libssh.) PuTTY
> does though.

This is an interesting question, that you should investigate further.
I'm very interested in GSSAPI/SSPI auth myself, and will need it soon'ish.
Would be a shame to be limited to putty.

>> And Cygwin users, who also happened to be users of your app, will benefit from
>> NOT having to solve conflicts between multiple Cygwin1 DLL's.

> So you are suggesting we install Cygwin to the system-wide location
> like C:\Cygwin\ rather than a subfolder like C:\Program Files
> (x86)\x2goclient\Cygwin\ (with /bin, etc underneath it?)

> I also do not understand this issue fully. I am unable to find a good
> article on the web (via DDG or Google) that explains it. I think I
> have experienced it though. Having multiple cygwin1 DLL files in RAM
> causes them to conflict with eachother? Wouldn't cygwin executables
> would search for cygwin1.dll according to %PATH%?

They do search them according to Windows loader rules, which imply %PATH%
search amongst other locations, but as with any indirect system, it prone to
crash in the slightest sight of misconfiguration.
So, yes, you CAN have multiple Cygwin1 dlls in the system, and they will not
conflict with each other, provided you took enough care to separate the
environment in which they are used.
Still, it is better to avoid such scenarios, if possible.

Andrey Repin ( 24.02.2015, <06:17>

Sorry for my terrible english...

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list