The investigation in SOW-0032 showed the Windows build runs in the MSYS
shell with /usr/bin/gcc linking against msys-2.0.dll (Cygwin POSIX
emulation, LP64), while /ucrt64/bin/rustc produces UCRT-linked LLP64
objects. The mismatch is harmless for the trivial smoke crate but blocks
any non-trivial in-process Rust use. Since the project intends to write
"a lot of Rust code", the rwin worktree pivots from a one-shot smoke PR
to the full UCRT64 migration: switch the C side to /ucrt64/bin/gcc so it
shares the same C runtime and data model as Rust, drop the bundled MSYS2
root from the installer, and end with the smoke crate re-enabled on
Windows to validate the migration.

This commit only sets up the pivot:

- packaging/windows/compile-on-windows.sh: pass -DENABLE_RUST_DEMO=Off
  so Windows CI is not noised by Rust-toolchain output while migration
  phases iterate. The override will be removed at the end of the
  migration (Phase 7 of SOW-0033). Linux/macOS keep the default-on
  smoke build.
- CMakeLists.txt: clarify the smoke option's comment to point at the
  Windows opt-out path during the migration.
- SOW-0032: status paused; sub-state explains the pivot and the
  resume condition.
- SOW-0033: new, in-progress, with a filled pre-implementation gate
  and an 8-phase plan from shell switch through installer slim-down
  through final smoke re-enable. Implementation gated on user
  confirmation of phase sequencing.

No source code is migrated in this commit.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The Windows MSYS2 shell defaults to MSYSTEM=MSYS, which makes the C side
of the agent link against msys-2.0.dll (Cygwin POSIX emulation, LP64).
The Rust toolchain at /ucrt64/bin/rustc produces UCRT-linked LLP64
objects. The mismatch blocks in-process Rust FFI and forces the
installer to ship the entire MSYS2 root just to provide msys-2.0.dll.

This commit pins the Windows build to MSYSTEM=UCRT64. The C compiler
and all runtime DLLs now come from the UCRT64 toolchain, matching the
Rust toolchain. Other MSYS2 environments (MSYS, MINGW64, CLANG64) are
deliberately rejected with a FATAL_ERROR so the failure mode is loud
rather than silent.

Changes:

- packaging/windows/{build,install-dependencies,invoke-msys2,package}.ps1:
  set $env:MSYSTEM = 'UCRT64' before invoking msysbash so /etc/profile
  picks the UCRT64 PATH (adds /ucrt64/bin, /ucrt64/lib/pkgconfig, etc.)
- packaging/cmake/Modules/NetdataPlatform.cmake:
  - drop CYGWIN and MSYS CMAKE_SYSTEM_NAME branches; only Windows now
  - require MSYSTEM=UCRT64 at configure time, FATAL_ERROR otherwise
  - collapse CLion include_directories branches to ucrt64 only
- packaging/windows/compile-on-windows.sh: drop the explicit
  -DRust_COMPILER=/ucrt64/bin/rustc; Corrosion finds rustc/cargo on
  PATH under UCRT64 (see Corrosion's FindRust.cmake)
- packaging/windows/clion-msys-{msys,mingw64}-environment.bat: deleted
- packaging/windows/clion-msys-ucrt64-environment.bat: added as the
  sole supported CLion developer entry point

This commit does not migrate any C source code; the next CI run is
expected to fail on the cygwin_conv_path() call sites and POSIX header
mismatches. Those failures define the work for Phases 3 and 4 of
SOW-0033.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Linux developers need a local way to validate Windows builds without
waiting on GitHub CI, especially while iterating on SOW-0033 (the
UCRT64 migration) where many phases will produce expected breakage
that needs to be observed and fixed in short cycles.

packaging/windows/LOCAL_DEV_LINUX.md walks through:

- Setting up a Windows 11 VM with quickemu/QEMU/KVM (one-time cost,
  ~1 hour to first boot).
- One-time Windows tweaks (long paths, OpenSSH server, default-shell
  -> PowerShell, the admin authorized_keys ACL gotcha).
- Installing MSYS2 inside the VM by running the repo's own
  install-dependencies.ps1 over SSH (one command from the host).
- Mounting the host's worktree into the VM at Z:\ via SSHFS-Win, so
  the host editor and the VM build see the same files live and the
  VM's build artifacts land directly under the host's build/ dir.
- Driving the VM from a Linux shell (or from an LLM assistant like
  Claude Code) via SSH, with a small wrapper script.
- A .claude/settings.json snippet that allowlists the wrapper, so a
  coding assistant can run ./packaging/windows/dev-vm.sh build, read
  the resulting errors, edit on the host, and re-build -- the VM is
  just another subshell from the assistant's perspective.

packaging/windows/dev-vm.sh is the wrapper the walkthrough references:

- build, package, deps, shell -- canned actions that map to the
  existing .ps1 entry points in packaging/windows/.
- run -- '<ps>' -- run an arbitrary PowerShell command.
- msys -- '<sh>' -- run an arbitrary command in a UCRT64 login bash,
  matching what build.ps1 sets up.

Defaults are overridable via VM_HOST and REPO_IN_VM env vars so each
developer can target their own VM without editing the script.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

First CI run on draft PR #22535 surfaced two distinct failures unrelated
to the C source migration:

1. Windows build: NetdataPlatform.cmake rejected CMAKE_SYSTEM_NAME=MSYS
   even with MSYSTEM=UCRT64 set, because packaging/windows/compile-on-windows.sh
   hard-coded /usr/bin/cmake -- which is the MSYS-runtime cmake and
   always self-reports as MSYS regardless of $MSYSTEM. Setting
   MSYSTEM=UCRT64 changed PATH for gcc/pkg-config but the absolute path
   to cmake bypassed it.

2. Linux source-tarball builds across all distros, plus the LibreSSL
   and Clang Checks jobs, failed with `rustc not found in PATH`. Root
   cause: the previous default ENABLE_RUST_DEMO=On in CMake forced
   Corrosion to require rustc in every build environment, including
   ones that never needed a Rust toolchain.

Fixes:

- packaging/windows/compile-on-windows.sh: /usr/bin/cmake -> cmake so
  PATH (with /ucrt64/bin in front under MSYSTEM=UCRT64) resolves to
  the UCRT64 cmake.
- packaging/windows/msys2-dependencies.sh: install
  mingw-w64-ucrt-x86_64-cmake and mingw-w64-ucrt-x86_64-ninja so the
  UCRT64 build tools are actually present.
- CMakeLists.txt: flip ENABLE_RUST_DEMO default to Off. The smoke crate
  stays in tree; opt in per build. compile-on-windows.sh still passes
  -DENABLE_RUST_DEMO=Off explicitly during the migration (will flip to
  =On at Phase 7 to validate Rust on Windows end-to-end).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous follow-up commit (bffb496) successfully switched the
Windows build to the UCRT64 cmake, confirmed by CI: CMAKE_SYSTEM_NAME
now reports Windows and _nd_windows_config() is reached.

One step deeper, a new error surfaced:

  CMake Error at packaging/cmake/Modules/NetdataPlatform.cmake:16:
    CMAKE_INSTALL_PREFIX must be set to /opt/netdata, but it is set to
    C:/msys64/opt/netdata

Root cause: the UCRT64 cmake is a native Windows binary; when given
-DCMAKE_INSTALL_PREFIX=/opt/netdata on the command line, it interprets
the path as MSYS2-mounted POSIX and canonicalises it to the equivalent
native Windows path C:/msys64/opt/netdata. Both forms refer to the
same on-disk install location -- only the string differs from what
the MSYS-cmake would have kept verbatim.

Fix: relax the equality check to accept either the exact /opt/netdata
(Linux and MSYS-cmake) or anything ending in /opt/netdata (UCRT64-cmake
canonical form).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Previous attempt at finding protoc via plain `find_program(NAMES
protoc.exe protoc)` returned NOTFOUND under MSYSTEM=UCRT64 even
though `mingw-w64-ucrt-x86_64-protobuf` was installed and provides
/ucrt64/bin/protoc.exe. PATH propagation from the bash login shell
through to the native-Windows cmake.exe binary is apparently not as
reliable as one might hope; the standard PATH-only search missed
the bin directory.

Add an explicit HINTS pointing at $ENV{MINGW_PREFIX}/bin. MSYS2's
/etc/profile sets MINGW_PREFIX to /ucrt64 under MSYSTEM=UCRT64,
and the UCRT64 cmake canonicalises that to the Windows-native
C:/msys64/ucrt64/bin form. Improve the FATAL_ERROR diagnostic to
include the searched HINTS and the value of MINGW_PREFIX so the
next failure (if any) gives us the actual bash->cmake env state
to debug.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous find_program attempt with HINTS at $MINGW_PREFIX/bin
returned NOTFOUND even though the mingw-w64-ucrt-x86_64-protobuf
33.5-4 package archive demonstrably ships protoc.exe at exactly that
location (verified by inspecting the .pkg.tar.zst contents:
ucrt64/bin/protoc.exe is there alongside protoc-gen-upb.exe,
libprotoc.dll, etc.).

The MSYS2 ucrt64 cmake toolchain appears to configure
CMAKE_FIND_ROOT_PATH_MODE_* in a way that masks /ucrt64/bin from
find_program even when explicitly hinted there. Rather than fight
find_program's filtering rules, just check the well-known path
directly with set + EXISTS. The MINGW_PREFIX env var is set by
MSYS2's /etc/profile to /ucrt64 (we already verified this from the
previous FATAL_ERROR diagnostic in CI).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ash on Windows"

This reverts commit 300ee73.

pipe2(fds, O_CLOEXEC) is a Linux extension to POSIX. macOS has no
pipe2 and the existing code already falls back to plain pipe() there;
Windows has neither. Our common.h pipe() macro routes to UCRT's
_pipe(fds, 65536, _O_BINARY), so plain pipe() works fine.

The O_CLOEXEC bit on Linux is a thread-pipe initialisation
convenience -- these notification pipes are used purely for in-process
thread signalling, never inherited by spawned children -- so dropping
it on Windows is correct. Extend the existing __APPLE__ gate to
include OS_WINDOWS.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Two standalone executables are POSIX-only:

  * nd-run is a privilege-drop helper that uses <grp.h>, getpwnam(),
    setresuid(), libcap, etc. -- none of which translate to Windows
    (account model is SIDs and ACLs there, and netdata.exe runs as a
    Windows service under a configured service account).

  * spawn-tester exercises the SPAWN_SERVER_VERSION_NOFORK fork+exec
    path via raw fcntl / pipe / socket primitives. Windows uses the
    SPAWN_SERVER_VERSION_WINDOWS path (CreateProcess + named pipes),
    which is a different implementation and is exercised through
    netdata.exe directly.

Wrap both `add_executable` blocks in `if(NOT OS_WINDOWS)`. Linux,
macOS, and FreeBSD builds unchanged.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

O_NOFOLLOW is the POSIX <fcntl.h> open flag that makes open() fail
when the trailing path component is a symlink. UCRT64 omits it
because POSIX symlinks don't exist on Windows (NTFS reparse points
are reached through entirely different APIs, not the open() file
model).

apps.plugin's apps_plugin.c sets `procfile_open_flags = O_RDONLY |
O_NOFOLLOW` as a defence-in-depth measure when running as root.
Define O_NOFOLLOW as 0 on Windows so the OR is a no-op -- the open
proceeds without symlink protection, matching what we'd do anyway
given S_IFLNK is also stubbed (Windows reparse points are not
reachable through the POSIX file-mode path).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

apps.plugin (apps_output.c), daemon/pulse (pulse-daemon.c),
exporting (send_internal_metrics.c), and unit_test.c call getrusage()
with struct rusage to report the agent's own user/system CPU
consumption. UCRT64 has neither the function nor the struct.

Provide struct rusage with the full POSIX field set (so any caller
compiles regardless of which field it reads) and an inline
getrusage() backed by GetProcessTimes(). The Win32 call gives us the
process's user and kernel FILETIME ticks (100 ns); we split each
into seconds + microseconds and write to ru_utime / ru_stime. Other
rusage fields (maxrss, page faults, IO blocks, voluntary /
involuntary context switches) stay zero -- they have no direct cheap
Win32 equivalent, and the self-stats charts that read them just
report zero on Windows. RUSAGE_SELF / RUSAGE_THREAD / RUSAGE_CHILDREN
constants are also provided.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

is_filename() in apps_pid.c uses statvfs() to confirm that a leading-slash
path lives on a real filesystem (`/path`-style POSIX paths). UCRT64 has
neither statvfs nor struct statvfs.

On Windows the GetFileAttributesW block immediately above already
handles native paths (`X:\`, `\\server\share\`, `//server/share/`),
so the statvfs path was unreachable in practice on Windows. Wrap the
block in `#if !defined(OS_WINDOWS)` so it compiles. Comment makes the
gating intent explicit.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

POSIX wcscasecmp() is the wide-string counterpart to strcasecmp().
UCRT64 doesn't expose the POSIX name but ships Microsoft's
_wcsicmp() with identical signature and semantics (case-insensitive
wide-string compare returning <0 / 0 / >0).

windows-events.plugin's source-name dedup calls wcscasecmp() on the
event-log channel names. Alias it via macro so the call site compiles
without per-platform branching.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

claim/main.c is a standalone Windows-only .exe (NetdataClaim) -- the
GUI/CLI claim-token launcher. It includes <windows.h> plus a few
standard C headers but does not include libnetdata/common.h, so the
wcscasecmp alias added there one commit ago doesn't reach this file.

Repeat the same alias inline. _wcsicmp is the UCRT equivalent with
identical signature and semantics.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

daemon.c performs POSIX daemonization (fork + setsid + setuid + chown
of run/log directories) and POSIX scheduling priority changes
(sched_setscheduler with SCHED_BATCH/SCHED_IDLE). On Windows the agent
runs as a service hosted by the SCM -- none of these apply. Privileges
are configured via ACLs at install time; scheduling priority is
controlled via SetPriorityClass/SetThreadPriority, not POSIX sched_*.

UCRT64 doesn't declare any of: chown, dirfd, unlinkat, getuid, geteuid,
getgid, getegid, setuid, seteuid, setgid, setegid, setgroups, fork,
setsid, sched_getparam, sched_setscheduler, struct sched_param,
SCHED_OTHER/SCHED_BATCH/SCHED_IDLE.

Stub everything as no-ops in the OS_WINDOWS block. Stubs:

  * chown/fchown -> return 0 (already-stubbed fchown was a hint)
  * dirfd -> return -1 (callers handle "no dir fd")
  * unlinkat -> forwards to unlink() ignoring the dir fd; relative
    paths resolve to CWD, which matches what daemon.c expects when
    the dir fd was supposed to be a parent it had cd'd to anyway.
  * get*id / set*id / setgroups -> succeed silently as the running
    process is effectively root in the Windows-service model.
  * fork / setsid -> return -1 with ENOSYS. daemon.c calls these
    only when -D is set on the command line; that flag is never used
    by the Windows service-host wrapper.
  * sched_* -> succeed silently with priority 0.

Effect on Windows: daemonization is a series of successful no-ops,
the service host then proceeds with its own startup. Linux/macOS/
FreeBSD code paths are untouched -- the real POSIX functions stay
in scope via the system <unistd.h>.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

…ram shim

Previous commit re-declared struct sched_param and sched_setscheduler
in the OS_WINDOWS block, conflicting with the definitions that
winpthreads ships in <sched.h> (transitively included via <pthread.h>).
gcc rejected the duplicates with "redefinition of 'struct sched_param'"
and "conflicting types for 'sched_setscheduler'".

mingw-w64's <sched.h> already provides:

  * struct sched_param
  * SCHED_OTHER / SCHED_FIFO / SCHED_RR
  * sched_setscheduler / sched_getscheduler / sched_yield /
    sched_get_priority_min / sched_get_priority_max

What it does NOT provide -- and what daemon.c actually needs:

  * sched_getparam (read the current priority)
  * SCHED_BATCH / SCHED_IDLE (Linux-only policies)

Include <sched.h> explicitly so the winpthreads pieces are in scope,
then add just sched_getparam() as a no-op stub and SCHED_BATCH/
SCHED_IDLE as fallback constants. Pure addition; no conflicting
redefinitions.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

… args

Two follow-ups exposed by this round:

1. signal-handler.c references SIGUSR2 (and SIGUSR1 under
   FSANITIZE_ADDRESS) in its signal-action table; signals.c's deadly
   list also needs SIGUSR2/SIGCHLD/etc. Previous round shimmed only
   the deadly-signal subset (BUS/SYS/XCPU/XFSZ); add the remainder
   (HUP/QUIT/USR1/USR2/CHLD).

   Renumber the existing SIGBUS/SIGSYS shims to glibc values to keep
   every SIG* macro distinct -- previously SIGBUS=10 collided with
   the glibc-style SIGUSR1=10. New layout follows glibc/Linux
   numbering throughout, chosen so each macro stays distinct from
   each other AND from the C-standard signals UCRT actually raises.

2. netdata_registry_get_dword / netdata_registry_get_dword_from_open_key
   declared their `out` parameter as `unsigned int *` but
   win_system-info.c (and any other Windows caller) passes `DWORD *`.
   Under LLP64 both are 32-bit but `unsigned int` and `unsigned long`
   are distinct types -- gcc rejects the implicit cast.

   Change the signatures and the function bodies to use `DWORD *`.
   RegQueryValueEx already expects LPBYTE there so the cast inside
   is unchanged. Also fix the length parameter from a hardcoded 260
   (which is FILENAME_MAX, not the size of a DWORD) to sizeof(DWORD).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

The previous `target_include_directories(... "/mingw64/include/ddk")`
literal worked under the MSYS cmake (a Cygwin binary that POSIX-
translated leading-slash paths transparently). Under the UCRT64
cmake we now use, there is no POSIX translation: `/mingw64/...`
gets interpreted as a Windows root-relative path and resolves to
<build-drive>:\mingw64\..., which never exists.

Outcome: ntddk.h was being found via the implicit /ucrt64/include/ddk
fallback (the UCRT64 toolchain's default system include path), but
its `#include <wdm.h>` could not resolve because the explicit
"/mingw64/include/ddk" -I directive pointed nowhere on disk.

Use $ENV{MINGW_PREFIX} so cmake substitutes the real prefix the
toolchain is using (/ucrt64 under MSYSTEM=UCRT64, /mingw64 under
MSYSTEM=MINGW64). The DDK headers ship in the same upstream
mingw-w64-headers package and live under the same <prefix>/include/ddk
relative path in every environment; only the prefix itself differs.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Three POSIX file-ops UCRT64 doesn't ship:

  * fchmod(fd, mode) -- status-file-io.c uses it to set 0664 on the
    temp file before rename. Windows permissions are ACL-based, not
    POSIX mode bits; stub returns 0 so the call is informational.

  * fsync(fd) -- UCRT's _commit(fd) is the documented equivalent,
    same signature and same semantic (flush buffered modifications
    to disk). Forward via macro.

  * utimensat(dirfd, path, times[2], flags) -- POSIX *at-family
    timestamp updater with nanosecond precision. UCRT has _utime64
    (sec precision, path-based, no dir-fd). machine-guid.c calls
    utimensat(AT_FDCWD, path, times, 0); route through _utime64
    with sec-precision truncation. The persisted GUID-file mtime is
    diagnostic, not load-bearing, so the truncation is acceptable.

AT_FDCWD added as a sentinel value the stub ignores. Linux/macOS/
FreeBSD continue to use the real fchmod/fsync/utimensat from
<unistd.h> / <fcntl.h>.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Winsock declares recv() and send() with `char *` / `const char *`
buffer arguments; POSIX uses `void *` / `const void *`. C call sites
(libnetdata/socket/nd-sock.h's static inlines) pass `void *` directly
and rely on the implicit conversion -- which works in C with a warning
but is outright rejected in C++.

ml/ad_charts.cc includes nd-sock.h transitively and hit the failure:
"invalid conversion from 'void*' to 'char*'" on the recv/send calls
inside nd_sock_revc_nowait / nd_sock_peek_nowait / nd_sock_send_nowait.

Same fix pattern as get/setsockopt one commit ago: self-referencing
macros that cast the buffer arg to char * / const char *. C99 6.10.3
guarantees the inner recv/send resolve to the Winsock functions, not
the macros.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

UCRT64 has no POSIX unsetenv(). The documented Microsoft equivalent
is _putenv("NAME=") -- an empty value triggers the delete-the-variable
path. rrdhost-labels.c calls unsetenv() to remove a variable from the
process environment after reading it.

Wrap with the POSIX signature: validate that the name has no '=' (per
POSIX EINVAL), allocate a NUL-terminated "NAME=" string, and call
_putenv. Free the buffer before returning so we don't leak; UCRT's
_putenv copies the value internally and is safe to free after.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

POSIX XSI random()/srandom() are 31-bit linear-congruential RNGs;
UCRT64 has only C-standard rand()/srand() (15-bit per call).
dbengine-stresstest.c uses random() to pick chart/dim indices during
stress runs -- the reduced range from rand (RAND_MAX = 0x7FFF) is
acceptable for a stress-test helper, all the values consumed are
modulo'd to small bounds anyway.

Alias the names via macro. srandom takes the seed as a long; UCRT
srand takes unsigned -- cast in the macro.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

-rdynamic asks the linker to export all dynamic symbols so backtrace()
and friends can resolve them at runtime. ELF (Linux/FreeBSD) and
Mach-O (macOS) linkers support it; the mingw-w64 binutils ld variant
that the UCRT64 toolchain uses on Windows does not -- PE/COFF symbol
export works through __declspec(dllexport) or a .def file instead.

NetdataClaim.exe and windows-events.plugin.exe both failed to link
with "cc.exe: error: unrecognized command-line option '-rdynamic'".

Guard the add_link_options(-rdynamic) call with NOT OS_WINDOWS. The
compile-side frame-pointer / unwind-table flags are unchanged --
those work fine on Windows.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

UCRT64 has no POSIX link() (create hard link). Windows exposes the
equivalent through Win32: CreateHardLinkA(new, existing, NULL).
NTFS supports hard links natively.

The registry rotation in registry_db.c uses link(current, ".old")
followed by unlink(current) to do an atomic backup before writing
the new database -- if anything goes wrong mid-write, the .old copy
still exists. The same pattern works on Windows via the hard-link
equivalent.

Wrap CreateHardLinkA with the POSIX link() signature: int return,
0 on success, -1 with errno on failure. Map the common Win32 error
codes to POSIX errnos so the caller's `errno != ENOENT` test still
behaves correctly.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

POSIX shutdown(fd, how) takes SHUT_RD / SHUT_WR / SHUT_RDWR for the
direction. Winsock's shutdown() takes SD_RECEIVE / SD_SEND / SD_BOTH
-- same numeric values, different names. mingw-w64's <winsock2.h>
defines the SD_* names but not the POSIX SHUT_* aliases.

stream-receiver.c shutdowns the streaming socket with SHUT_RDWR.
Alias the three POSIX names via #define so the call sites compile
unchanged.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

POSIX 2008 added the st_mtim / st_atim / st_ctim struct timespec
fields to struct stat for nanosecond-resolution timestamps. UCRT's
struct stat predates this and exposes only the second-resolution
st_mtime / st_atime / st_ctime fields.

The existing #ifdef __APPLE__ ... #else branch picked st_mtimespec
on macOS and st_mtim everywhere else. Add an OS_WINDOWS branch that
reads st_mtime directly. Second precision is fine here -- the value
feeds an HTTP "Date" header that has only second resolution anyway.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

websocket-handshake.c sets the command-pipe read side to non-blocking
via fcntl(F_SETFL, O_NONBLOCK) so the poll-driven thread can drain
all signal bytes without a final blocking read. UCRT64 has no
fcntl(), and anonymous pipes from _pipe() aren't trivially switchable
to non-blocking under Win32 (SetNamedPipeHandleState applies to named
pipes; CRT-fd pipes have no documented per-fd toggle).

The websocket command pipe carries short, well-bounded signal bytes,
not a streaming workload. A blocking short-read of a single signal
byte is fine in practice -- the poll/nd_poll layer wakes the thread,
the read pulls one byte, the loop continues.

Wrap the fcntl() call with `#if !defined(OS_WINDOWS)`. Linux/macOS/
FreeBSD behaviour is unchanged.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

netdata.exe failed to link at the very end of the build with hundreds
of undefined references to Abseil symbols:

  absl::lts_20260107::status_internal::StatusRep::Unref()
  absl::lts_20260107::hash_internal::MixingHashState::kSeed
  absl::lts_20260107::hash_internal::CombineLargeContiguousImpl...
  google::protobuf::internal::ThreadSafeArena::thread_cache_
  ...

Root cause: the NetdataProtobuf.cmake Windows branch hardcoded
`set(PROTOBUF_LIBRARIES "-lprotobuf")` and stopped there. Protobuf 22+
links against Abseil; MSYS2's mingw-w64-ucrt-x86_64-protobuf (v33.x)
ships protobuf-config.cmake which declares the abseil deps as
transitive requirements of protobuf::libprotobuf. The bare `-lprotobuf`
linker arg pulled in libprotobuf.a only and dropped abseil on the
floor.

Switch the Windows branch to use find_package(Protobuf CONFIG REQUIRED)
-- same path the Linux branch already uses -- so the abseil deps come
along automatically through the protobuf::libprotobuf target. The
protoc.exe location detection stays unchanged (still uses MINGW_PREFIX
explicitly; find_program-via-package would still fail to locate it
under the CMAKE_FIND_ROOT_PATH_* policy on the MSYS2 ucrt64 toolchain).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

The Windows install step hard-coded three MSYS-runtime DLLs from
/usr/bin: msys-protobuf-32.dll, msys-yaml-0-2.dll, msys-uv-1.dll.
Those are the Cygwin-style libraries the MSYS shell build linked
against. Under MSYSTEM=UCRT64 we link against native Windows libs
from $MINGW_PREFIX/bin with different names -- libprotobuf-33.X.dll,
libyaml-0-2.dll, libuv-1.dll, plus libabsl_*.dll (the Abseil
dependencies that protobuf 22+ pulls in).

The hardcoded path made the install step fail with:

  file INSTALL cannot find "/usr/bin/msys-protobuf-32.dll"

Switch to a globbed list of $MINGW_PREFIX/bin/lib*.dll patterns
that covers everything netdata.exe / plugins are likely to load at
runtime. Glob rather than hard-list the abseil files: 40+ libabsl_*
DLLs exist and the set changes with each upstream release.
CONFIGURE_DEPENDS so cmake re-evals if the MSYS2 package set changes.

Coverage: protobuf + abseil, yaml, uv, openssl/libcrypto, libcurl
and its TLS-stack deps (gnutls, nettle, gmp, hogweed, tasn1,
unistring, p11-kit, libssh2, idn2, psl, nghttp*), the gcc/stdc++
runtime and winpthreads, plus the compression libs (zlib, lz4,
zstd, brotli) and pcre2.

Also relocate the ssl-cert directory copy from /usr/ssl (MSYS
location) to $MINGW_PREFIX/etc/ssl (UCRT64 location); curl looks
for ca-bundle there.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>