On Fri, Aug 29, 2014 at 11:04 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Thanks for reporting your observed issue.
I close this bug as the problem seems to be related to your setup.
Launching X2Go Client always requires to cwd to its installation directory, otherwise its DLLs will not be found.
Hi Mike#1 and Ivan,
I believe I should fix this bug. I am going to re-open it.
Unless I hear new reasons otherwise, in about 10 hours I will:
- re-release the .zips for VcXsrv 1.14.3.2 http://code.x2go.org/releases/binary-win32/3rd-party/vcxsrv-modified-by-x2go...
- update the X2GoWinBuilder VM that handles nightly builds
- launch X2Go Client 4.0.2.1+hotfix-build4 with the fix.
This is why I believe I should fix this bug:
Every Windows program searches its own directory for DLLs, before searching the PATH and cwd. This is the design of Windows. We can fix X2GoClient being able to start successfully with your cwd being different by including VcXsrv\zlib1.dll. There is no need to register the DLL system-wide. And it's not a cygwin DLL anyway; its a native Windows binary built from the VcXsrv/VcXsrv-xp source tree.
On my system, I can launch X2Go Client successfully from another cwd. This includes x2goclient.exe, vcxsrv.exe, sshd.exe (cygwin) and nxproxy.exe (cygwin). The only reason vcxsrv.exe does work is that I have c:\gnuwin\bin\ZLIB1.dll in my PATH, where as most users likely do not have any zlib1.dll in their PATH. (I determined this using Dependency Walker.)
My manual build instructions state that I should include VcXsrv\zlib1.dll. During the manual build process, I included VcXsrv\xwininfo.exe instead of zlib1.dll.
We should provide vcxsrv.exe with its own zlib1.dll. It is VcXsrv-xp's own version of the file for reasons mentioned in #1.
Respectfully, -Mike#2
Control: reopen -1 Control: tag -1 - not-a-bug
Hi Mike#2,
On Fr 29 Aug 2014 14:40:59 CEST, Michael DePaulo wrote:
On Fri, Aug 29, 2014 at 11:04 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Thanks for reporting your observed issue.
I close this bug as the problem seems to be related to your setup.
Launching X2Go Client always requires to cwd to its installation directory, otherwise its DLLs will not be found.
Hi Mike#1 and Ivan,
I believe I should fix this bug. I am going to re-open it.
Unless I hear new reasons otherwise, in about 10 hours I will:
- re-release the .zips for VcXsrv 1.14.3.2 http://code.x2go.org/releases/binary-win32/3rd-party/vcxsrv-modified-by-x2go...
- update the X2GoWinBuilder VM that handles nightly builds
- launch X2Go Client 4.0.2.1+hotfix-build4 with the fix.
This is why I believe I should fix this bug:
Every Windows program searches its own directory for DLLs, before searching the PATH and cwd. This is the design of Windows. We can fix X2GoClient being able to start successfully with your cwd being different by including VcXsrv\zlib1.dll. There is no need to register the DLL system-wide. And it's not a cygwin DLL anyway; its a native Windows binary built from the VcXsrv/VcXsrv-xp source tree.
On my system, I can launch X2Go Client successfully from another cwd. This includes x2goclient.exe, vcxsrv.exe, sshd.exe (cygwin) and nxproxy.exe (cygwin). The only reason vcxsrv.exe does work is that I have c:\gnuwin\bin\ZLIB1.dll in my PATH, where as most users likely do not have any zlib1.dll in their PATH. (I determined this using Dependency Walker.)
My manual build instructions state that I should include VcXsrv\zlib1.dll. During the manual build process, I included VcXsrv\xwininfo.exe instead of zlib1.dll.
We should provide vcxsrv.exe with its own zlib1.dll. It is VcXsrv-xp's own version of the file for reasons mentioned in #1.
Respectfully, -Mike#2
Thanks for this explanation. Agreeing. Bug already reopened.
Greets, Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Michael DePaulo -
Mike Gabriel