Bugzilla – Bug 3231
Ship a 64-bit Windows client
Last modified: 2017-09-26 16:38:43
You need to
before you can comment on or make changes to this bug.
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
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
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:
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
✓ Smart card
✓ Public key
✓ Kerberos (see ThinLinc/Kerberos; for setup hints) 2 3
✓ Local devices
- Serial ports 1
✓ Smart card readers
✓ Multi monitor handling
- Check for stray temporary files
Added release note about 64-bit Windows client