The NXLogin ZIP file contains just the NXLogin components plus a Cygwin build of nxproxy for convenience. This build of nxproxy has been made according to this configuration. In case you want to build it yourself or need a modified build, you need the NX open source components which are available from the X2go project as NoMachine have discontinued their development.

The ZIP file can be extracted in any directory of your choice.

To actually get a running tool, you either need to have a Cygwin installation already on the system, which NXLogin will default to use if it's in the PATH and no other Cygwin binaries are in its program directory; or you need to download a minimal Cygwin installation and place it in the contrib/cygwin subdirectory of the NXLogin folder.

Option 1 – already existing Cygwin installation

If you already use a Cygwin installation on your machine, your best bet is to not place additional Cygwin utilities in the NXLogin directory, because

• Using multiple different versions of cygwin1.dll can cause problems
• There will be confusion regarding where /tmp is located, which is used by the Cygwin X11 library to maintain server sockets. (This might not be that much of a problem if you use TCP X11 communication even on the thin client)

In any case, your Cygwin installation needs to use versions of libraries that are compatible with those that were used to build nxproxy. If that is a problem, it's best to compile your own nxproxy as described above and place it in contrib/nx in the NXLogin program directory.

The following tools are needed by nxproxy and the NXLogin code in your Cygwin installation:

• xorg-server (unless you're planning to use a third-party X server on the thin client, such as Exceed)
• xset
• xauth
• libpng12
• libjpeg8
• openssh

In case you need X11 core fonts, you can also install the appropriate font packages. But note: It is almost always better to instead run a font server on the remote side and configure your connections to use it, because core fonts will only be available if they match exactly on the thin client and the remote server, which might not be the case if they are installed independently.

Option 2 – new minimal Cygwin installation

To provide a new installation of Cygwin that has all necessary binaries, use the Cygwin setup program to install all of the tools that are mentioned above. An example command line to achieve this is (paste this into a CMD window or Cygwin Terminal without line breaks, substituting a suitable mirror):

setup -q -n -R c:/temp/cygwin_root -l c:/temp/cygwin_packages -s ftp://ftp.your-mirror.com/pub/cygwin/ -P libpng12,libjpeg8,openssh,xauth,xset,xorg-server

You can then move the components of your new Cygwin root directory into the contrib/cygwin directory in your NXLogin program folder. (Don't move the etc/passwd and etc/group files, at least not without checking the paths, IDs etc. in there.) It is necessary to ensure a working /tmp directory is available to this installation. So either create tmp in contrib/cygwin (this directory will be written to, so unlike other directories in the NXLogin tree, it needs to be user-writable), or place a link (can be in Cygwin format, i. e. created with the Cygwin ln program) there that points to an external directory that has the necessary ACLs (don't just symlink to "/tmp", that will not work).

Defining default connection settings

The NXLogin tools use connection definition files in XML format that are the serialized form of instances of the ClientConnectionSettings class. Normally, users specify such files as arguments to NXLogin.exe and NXLoginW.exe. The files can be created by invoking NXLoginW.exe without arguments, which will launch a GUI. You can also write them by hand, by looking at the ClientConnectionSettings source code in order to get an idea about what properties are supported.

The NXLogin command-line executable (NXLogin.exe) also supports being called without such a connection file, in which case a limited number of properties can be specified using command-line arguments. In this mode of operation, all properties that were not specified on the command line are read from an optional site-default file that must be called default.nxlogin and is placed in the NXLogin program folder. If that file is not there, compiled-in defaults will be used which may not be what you want. One particular default setting when invoked without configuration file is that NXLogin.exe will never start its own X server on the thin client, but expects that one is running already and the DISPLAY variable is set to point to it.

nxagent installation is already covered in the NoMachine documentation. However, I usually apply the following patch to nxagent 3.x that works around certain issues when using the nxagent window along with other windows on an already-running X11 display.

• nx-X11+nofs+noungrabmouse.patch – this does two things:
  • Disables nxagent's default behavior to assume fullscreen mode when no window manager is detected, because that causes problems when the X server running on the thin client is Exceed 2007.
  • Keeps the mouse grabbed when the user drags something across nxagent's window borders. That way, nxagent will notice if the user releases the mouse button outside the window. The default implementation doesn't notice that, so when reentering the nxagent window, it acts as though the drag operation wasn't finished, which is very irritating.

  Update note 2015-10-04 – this file has been updated for GCC compatibility (needed when building on Linux)