Ship a 64 bit Windows client
Due to bug 5422 and lack of time, we will do this later.
I was doing performance testing for bug 5618 and though it would be fun to see how much 64-bit on Windows would give us. These tests were done using decperf and DRC's rfb files on the Windows 10 machine (i3-4170 3.7 GHz). On average the 64-bit version was 18% faster (15% for the old single threaded code).
We have identified the following steps: * Modify Makefile to first build 64-bit binaries and then, using 32-bit NSIS generate a 32-bit installer for the 64-bit application. This requires an updated .nsi.in script. * Don't forget about the client-customizer! * Verify package signing. * Add copies to the client bundle. * Update documentation, at least on the web, check the TAG as well. * Do a complete client test. Maybe test against both 32-bit and 64-bit server? * Build 64-bit NSIS installer. We might have to upgrade NSIS to version > 3 for this (bug 5422). We can't generate a 64-bit installer with 32-bit NSIS. * Consider upgrading NSIS (despite if it was needed in the previous step).
(In reply to comment #3) > * Build 64-bit NSIS installer. We might have to upgrade NSIS to version > 3 > for this (bug 5422). We can't generate a 64-bit installer with 32-bit NSIS. > Upgrade of NSIS to version 3 does not add support for creating 64bit installers. There are some patches from mingw to build using mingw64 environment but thats only what I could find. No build support for 64bit installers.
We've tested the installer and customizer in all 32-bit/64-bit combinations and made sure it always picks the right version of the client to install. Branding and settings.reg was also tested.
We had a look at handling migration of settings when users switch from 32-bit to 64-bit, but it turns out we don't have to do anything. HKLM\SOFTWARE is split between 32-bit and 64-bit, but HKCU\SOFTWARE is shared. So any settings written by the 32-bit client will be read by the 64-bit client, and vice versa. See Microsoft's documentation on shared and redirected keys: https://msdn.microsoft.com/en-us/library/windows/desktop/aa384253(v=vs.85).aspx
At releaes, remember to update to downloads page to explicitly handle the 64-bit case of the universal installer, either by having a separate "64-bit" link that points to the same installer, or a "32/64-bit" link to it. The drawback of the latter alternative is that it may be interpreted as "32-bit also works on 64-bit OS:es".
Tested Windows x64 client on Windows 10. The following was tested and everything worked as expected. The entries with leading '-' was not tested. ✓ Verify that options are saved ✓ Verify that client loads config file specified via command line ✓ Verify that you can end an existing session ✓ Verify that start command works as expected - Verify that you can shadow a session ✓ Verify that you can select a initial session size - Multiple session ✓ Verify automatic behavior ✓ Verify ask behavior and that the available actions in UI works as expected ✓ Verify server side session restriction behavior ✓ Verify that smartcard and password SSO works as expected. Check using the - tools tl-sso-password and tl-sso-token-passphrase ✓ Verify that default logging level is ok ✓ Verify that logging level 5 (-d 5) gives debug logging for all subprocesses (pulseaudio, ssh etc.) and ThinLinc client application ✓ Verify that the options dialog from the ThinLinc client and the options dialog from the F8 menu after the session started are in sync with regards to window size, layout, and strings/translations. ✓ Package signature ✓ Authentication methods ✓ Password ✓ Smart card ✓ Public key ✓ Kerberos (see ThinLinc/Kerberos; for setup hints) 2 3 ✓ Clipboard ✓ Local devices ✓ Sound ✓ Drives - Serial ports 1 ✓ Printing ✓ Smart card readers ✓ Multi monitor handling - Check for stray temporary files
Added release note about 64-bit Windows client
