Zoom Windows 64-bit client

Many Windows users of Zoom may have downloaded the 32-bit Zoom client. We have observed that manually reinstalling the Zoom 64-bit Windows client can significantly help avoid choppiness of Zoom audio/video under high CPU usage. In most cases, it’s good to use the 64-bit version of a program for a 64-bit CPU and operating system. For Zoom as with many other programs, if the 32-bit version is installed, the updater doesn’t go to 64-bit version. The user typically has to manually once reinstall the 64-bit version of the program and from there on the updates stay at 64-bit program. Latency-sensitive 32-bit Windows programs may not work as well as 64-bit programs on 64-bit Windows due to WOW64 emulation for 32-bit programs on 64-bit Windows.

CMake presets build options

CMake presets can have specific build preset option for particular build tools. This CMakePresets.json shows example build presets for Ninja. The preset name “ninja” in this example is arbitrary. As usual, the presets help avoid copying script parameters and the possibility of typos in duplicated script code, whether for CI or developers themselves.

For example, to have ninja “explain” why a target is dirty:

cmake --build --preset explain
  "version": 2,
  "configurePresets": [
    "name": "ninja",
    "generator": "Ninja",
    "binaryDir": "${sourceDir}/build"
      "name": "explain",
      "configurePreset": "ninja",
      "nativeToolOptions": ["-d", "explain"]
      "name": "keep",
      "configurePreset": "ninja",
      "nativeToolOptions": ["-d", "keeprsp", "-d", "keepdepfile"]
      "name": "stats",
      "configurePreset": "ninja",
      "nativeToolOptions": ["-d", "stats"]

Git pull HTTPS, push SSH

For many public Git repos, using HTTPS for “git fetch”, “git pull”, and other Git download operations has adequate security. A primary concern for downloading public Git content is verifying the content is genuinely from the desired author. A reasonable degree of confidence can be accomplished using HTTPS to download and verifying the author PGP signed Git commits. Git download operations over HTTPS are perhaps twice as fast as Git over SSH and use less CPU. Typically it is desired for Git to verify SSL certificates:

git config --global http.sslVerify true

When pushing Git commits, SSH can provide enhanced security. Since “git push” operations typically take longer than “git pull”, particularly where pre-commit hooks and PGP commit signing are used, SSH speed penalty on “git push” is often acceptable.

For developers there are speed benefits from a hybrid Git configuration where Git downloads use HTTPS and Git uploads use SSH. Git has intrinsic functionality for this setup in a global configuration. The one-setup setup below uses “https://” for the remote repo URL instead of “ssh://”. To upgrade existing local public repos, edit individual repo “.git/config” accordingly. This is a one-time config command:

git config --global url."ssh://github.com/".pushInsteadOf https://github.com/

git config --global url."ssh://gitlab.com/".pushInsteadOf https://gitlab.com/

This makes all GitHub and GitLab public repos push over SSH, unless overridden in a repo’s own “.git/config”. Confirm by git remote -v in a repo.

If experiencing problems on “git push”, check this matches the desired Git repo:

git config --get remote.origin.url

In particular, it must NOT have a trailing slash like repo/

CMake and Meson compiler option family

On Windows, compiler option syntax is generally MSVC-like or GCC-like. On Windows, the compiler option families are:

  • MSVC-like: Intel oneAPI (IntelLLVM), Clang-CL, Visual Studio
  • GCC-like: GCC, Clang, non-Windows OS}.

Meson and CMake can each detect compiler option family. In general, the “else” branch would have further nested “if” to handle compiler options with distinct syntax.

CMake uses the MSVC variable to detect compiler option family. More specific compiler option selection is often handled with an if-else tree for each compiler ID and / or check_c_compiler_flag().

cmake_minimum_required(VERSION 3.1)

project(Hello LANGUAGES C)

  message(STATUS "${CMAKE_C_COMPILER_ID} is MSVC-like")
  message(STATUS "${CMAKE_C_COMPILER_ID} is GCC-like")

Meson uses the .get_argument_syntax() property to detect compiler option family. Getting more specific compiler options can be done with an if-else tree for each compiler ID and / or the .has_argument() method.

project('hello', 'c')

cc = meson.get_compiler('c')

if cc.get_argument_syntax() == 'msvc'
  message(cc.get_id() + ' is MSVC-like')
  message(cc.get_id() + ' is GCC-like')

Detect Bash, zsh or other shell

A 5-way shell detect script can detect bash, csh, dash, ksh, or zsh. However, often we simply want to detect if the shell is Bash or something else. For example, in a Bash-dependent script we may thereby stop and recommend the user use Bash to avoid needing to test across numerous shells. There are a number of pitfalls in detecting a shell type so this method is not completely robust either, but has worked for our purposes. The key to this technique is that while different shells have distinct “if-else” syntax, most shells have “case-esac”.

CMake script relocate

When relocating / moving / renaming a CMake script within a project, it may be desired to leave a placeholder at the original script location until users know to use the new script path in the project. Many CMake scripts call other scripts in the project. In general, CMake scripts should use absolute paths, except for install() parameters. That is, CMake scripts should generally start file paths with CMake built-in absolute paths like CMAKE_CURRENT_LIST_DIR and CMAKE_CURRENT_FUNCTION_LIST_DIR. If the script directory is changed, the script references to paths within the project will of course also need to be changed.

Legacy users may take a while to start calling the CMake script at the new location. Note that making a softlink will NOT work in general because the path references would be from the placeholder script location, which in general is distinct from the new script location. To bridge this UX gap, create a trivial one-line script at the original script path like:


Git set executable file permission on Windows

When interacting between Windows and Unix filesystems using Git, setting a file to be executable takes a particular Git command from the Windows computer. With standalone Unix systems, just chmod +x myfile.sh is tracked by Git. However, with Windows Subsystem for Linux or Cygwin, this chmod +x change is not tracked if the file resides on a Windows filesystem and not within the WSL internal filesystem.

Windows file mode permission for executable aren’t as trivial as Unix-like chmod. Unix-like file systems such as Linux and MacOS need the executable bit set correctly to execute shell scripts and binary executables as expected. On Unix-like file systems, Git propagates the executable permission of files.

To add executable permission on Windows and for all other systems, use Git command:

git update-index --chmod=+x /path/to/exe

To remove executable permission on Windows and for all other systems, use Git command:

git update-index --chmod=-x /path/to/exe

Verify the change to executable permission by:

git status --porcelain=2

which will have output including:

1 M. N… 100644 100755 100755 … /path/to/exe

Measure joystick input lag on PC

Measuring controller / joystick input lag to a computer is not as trivial as one might think. We encourage at least skimming the references below, especially the Lagmeter readme to get background. In short, take a video camera or smartphone capable of 60 frames/second or faster and use an LED wired to the joystick input and video it and the computer display while pressing a button. Video display lag (put the monitor in “game mode” if available) and USB polling cadence are two of several significant factors in input lag. In difficult absolute measurement scenarios such as this, where so many confounding factors are present, a more useful metric may be relative delay measurements, for example wired vs. wireless controllers.


cURL build native Windows Schannel

cURL is a universal command line tool for network data transfer. Build cURL from source on Windows including native TLS support with Visual Studio and CMake. No external libraries are required for SSL using cURL native Windows Schannel. The build is done “static” to avoid the hassle of DLL path.


cmake --build build --config Release

Test the standalone “curl.exe” like:

build/src/Release/curl.exe -L https://hsts.badssl.com/