rsync for Windows, native port
tl;dr: I worked with Claude to build a Windows native port of rsync, you can
find it here: https://github.com/nuket/rsync-windows/releases.
The porting log is explicitly shared too: WINDOWS-PORT.md so you can see everything that was deliberated and done.
And all of the Windows shim sources are public: https://github.com/nuket/rsync-windows/tree/windows-cmake-port/win32.
How I Did It
rsync is a command I always missed on Windows, especially going
back and forth to fetch Yocto build artifacts from Linux servers when doing
embedded systems work.
Upstream never adapted their sources to work on Windows without Cygwin or MSYS2, and understandably their time is very limited.
The Windows folk managed to port ssh and scp, but left it at that, which
left a lot to be desired.
I've been using Claude experimentally for a while now, so instead of kvetching
about the fact that no one else was building rsync, I went ahead and set Claude
onto the task, to build a port that modified as little of the upstream sources
as possible while building an easily rebased set of native sources that could
slot in where needed to get rsync working.
If you touch it, you might break it; and if you break it, you own it.
The basic idea is to use a handful of macros that you can then retarget using a single compile time define, and the Windows shims are then selected as what rsync compiles in.
By default, the rsync on Linux uses all of its original functions, and none of
the Windows-specific shim functions are attempted.
We keep #ifdef _WIN32 from polluting the original codebase and we keep all
of our customizations separate. The shim source files are only ever built on Windows,
and there are no added preprocessor costs to the Linux side.
All of this separation allows Claude to rebase the shims more easily, because the Windows code is not interspersed with Linux code.
I also had Claude switch to use CMake instead of the standard autoconf / automake setup,
which is a little more user friendly, not that anyone is editing this stuff by hand
anymore, anyways.
More Better Plus Plus
As a bonus, Claude also helped to enable and test a number of standard exploit mitigations: Control Flow Guard, CET shadow stack, strict /GS, Spectre v1 hardening, ASLR, DEP, and a System32-only DLL search path.
This should help in case the server sends back malformed output either unintentionally or intentionally.
I'm not sure whether the Cygwin or MSYS2 builds ever offered these mitigations.
And, the executable is built as a static executable, so it doesn't need any additional DLL files to run.
The only thing I would have liked to do is compile a version runnable all the way back to Windows XP, but that requires having a build server with the older toolset available.
Bootnotes
Claude is a pretty stunning tool to work with. It doesn't always get it right, but its aim is pretty good.
With a certain amount of guidance, it can take a large amount of tedious work and cut right through it.
In this case, it enables a Windows port that takes a fraction of the time to build and maintain.
- ← Previous
Benchmarking armv8 Instruction Sets