Add Windows build workflow

[VA3THP]

Summary

I put this together while working on the last PR. It adds a GitHub Actions workflow for building QLog on Windows x64 with Qt 6 and MSVC.

It builds two artifacts:

• a staged Windows runtime artifact
• a Qt Installer Framework installer
  The workflow follows the same Windows target as devtools/windowsMake/make.bat: Qt 6.10.2, MSVC 2022, x64, Hamlib 4.7.0, OpenSSL, zlib, and QtKeychain.

What it does

• Runs on windows-2022
• Installs Qt 6.10.2 for MSVC 2022
• Uses vcpkg for OpenSSL and pthreads
• Builds zlib from source
• Builds QtKeychain from upstream source against the Qt installed by the workflow
• Downloads the official Hamlib 4.7.0 Windows package and generates the MSVC import library from its .def file
• Extracts OmniRig v1/v2 EXEs from public installer payloads so MSVC #import can read their embedded type libraries at compile time
• Builds QLog with qmake and jom
• Runs windeployqt
• Uploads the runtime and installer artifacts
  Direct downloads are version-pinned and SHA256-checked where used.

Dependency approach

The Windows build follows a similar pattern to WSJT-X: use a prebuilt Hamlib package on Windows and bundle the Hamlib runtime DLL with the artifact. Linux and macOS keep using their normal package-manager dependencies.

OmniRig is only needed on Windows for COM/type-library support. The workflow extracts the OmniRig v1/v2 EXEs from public installer payloads so MSVC #import can read their embedded type libraries. It does not run the OmniRig installers, and it does not bundle OmniRig with QLog.

QtKeychain is built from source against the workflow-installed Qt instead of through vcpkg, since the vcpkg port can pull Qt in as a dependency.

This keeps the CI build close to QLog's existing Windows build script and makes it work on a clean GitHub-hosted Windows runner.

Compatibility

This workflow builds a 64-bit Qt 6/MSVC package, so Windows compatibility follows the supported platforms for the Qt 6.10.2 MSVC 2022 build used here.

Validation

Tested on a private fork before opening this PR:

• Private Windows Build workflow completed successfully.
• The generated installer artifact was installed into a test directory.
• The installed QLog application launched and worked from that test installation.

[foldynl]

Thanks for the PR. I’ll leave it open for now, but I’m not going to merge it yet. Maybe once I gather a bit more courage.

It is not that I don’t find it useful. It is more about my caution regarding the Windows platform. I am aware that distributing an EXE file requires a higher level of protection against viruses, malware, and similar Windows “features”.

That is why I am very careful when preparing the EXE builds. The build is done on a Windows machine used only for QLog development, it is scanned for viruses very frequently, and the EXE is signed immediately after compilation. In short, I try to maintain the highest reasonable level of security during the whole preparation process.

I have considered moving the EXE build process to GitHub CI/CD several times. In principle, the base environment may be safe. I mean the operating system itself. But each build would still download various components from the internet, and I cannot easily check all of them for viruses or other Windows-related issues every time.

That is why I created devtools/windowsMake/make.bat, to make the local build process as easy as possible on my own machine.

So this is really not about me refusing to build it on GitHub. It is about keeping the whole process as controlled and secure as possible.

[VA3THP]

Thanks Ladislav, I understand the concern around Windows binaries.

I revised the workflow to reduce the amount of third-party setup code and make the dependency setup easier to review:

• The job runs on GitHub's hosted windows-2022 runner, the same hosted-runner model the existing Linux and macOS CI uses. MSVC is initialized by calling Visual Studio's own VsDevCmd.bat from that image.
• Qt is installed with aqtinstall, a Python package from PyPI pinned to a specific version in the workflow. It downloads from Qt's official download.qt.io infrastructure and verifies the checksums Qt publishes with each release.
• QtKeychain is built from its upstream source (frankosterfeld/qtkeychain, which Debian, Fedora, and Arch also track), pinned to version 0.14.3. It is not part of Qt's official Windows installer, so the workflow builds it against the same Qt version used for QLog.
• I added Microsoft Defender Antivirus scans for the staged runtime and final installer, plus SHA256 manifests for the uploaded artifacts. The artifacts are still unsigned, so I would treat them as CI build/validation outputs only, not as releasable binaries.

This PR still downloads the OmniRig v1 and v2 installer EXEs at build time, from pinned URLs with pinned SHA256s, and extracts their type libraries with innoextract so MSVC's #import can compile the existing OmniRig COM code paths. If you are uncomfortable with that, we could instead use checked-in generated declarations so CI does not need to fetch those installers or use innoextract at all. We could also add a warning-only runtime version check against the installed OmniRig version to help catch declaration drift without blocking compatible OmniRig installs.

Happy to address anything else, or continue the discussion outside of the PR comments if that is easier. No rush at all.