WinMerge: folder filters, ignore rules, and a Windows-only build chain

DownloadDeps.cmd then BuildAll.cmd, with the architecture passed on the command line

Everything a WinMerge build needs is a Windows toolchain, and the entry points are batch scripts that take the target architecture as an argument. A fresh checkout should bring the submodules along, fetch the third party libraries, and then build one architecture at a time.

git clone --recurse-submodules https://github.com/WinMerge/winmerge
cd winmerge
DownloadDeps.cmd
BuildAll.cmd [x86|x64|ARM64]
# or
BuildAll.vs2022.cmd [x86|x64|ARM64]
# or
BuildAll.vs2017.cmd [x86|x64|ARM|ARM64]

The 64 bit build leaves the program at Build\X64\Release\WinMergeU.exe, and choosing another architecture means looking in a different output folder:

Build\X64\Release\WinMergeU.exe

The 2017 script accepts ARM as well as ARM64, while the 2022 script lists x86, x64 and ARM64 only. Beyond git, the build expects Visual C++ MFC and ATL, the Windows 10 SDK, Inno Setup 5.x and 6.x, 7-Zip, Python, Pandoc, and MSYS2 with po4a and diffutils.

Two or three text files side by side, with inline differences inside the line

File comparison opens two or three text files next to each other and marks what changed line by line. Inline differences within a line can be shown as well, so an edit buried inside one long line does not force you to read the whole line as replaced. Syntax highlighting covers many programming languages and file formats, which changes what the mark-up is telling you: a changed identifier sits apart from changed punctuation and from changed string data. The same comparison window can write a patch file in normal, context, or unified diff format.

The comparison surface described in the documentation is text. It does not name a viewer for binary files, images, or spreadsheets, so a comparison pointed at those formats has no documented way to show you what changed inside them. If most of your diff work is binaries, folder listings and patch output do not stand in for a breakdown the documentation never promises. Filter and ignore settings, covered next, apply whatever the file happens to be.

Filter expressions decide which parts of a tree are never visited

A folder comparison reports which files differ, which are missing, and which exist only on one side. That report is only as wide as the filter in front of it: filter expressions include or exclude files and folders by name, path, size, timestamp, and other attributes. Filter definitions live in the Filters directory, beside the ones that ship with the program.

Excluding a folder keeps its contents out of the comparison, so a build output folder or a directory of generated assets never reaches the report. Check the filter before you trust a clean result, not after.

Ignore rules can report a file as unchanged when its bytes moved

Whitespace differences, case differences, and lines matching regular expressions can all be ignored. For XML, JSON, and generated code that is often what you want. It is also the shortest path to a wrong answer, because two files that are byte different get reported as equal.

If your workflow treats an empty diff as proof that nothing changed, ignored whitespace will contradict your version control history or a checksum computed elsewhere. Case folding does the same thing to identifiers that differ only in case, which matters wherever a name is a key. These settings belong to the comparison session rather than to the files themselves, so they join the filter as something to verify whenever a result surprises you. Three ways to hide a difference, each enabled once, hide a great deal.

Archive support is 7-Zip wearing a WinMerge folder tree

Using 7-Zip, WinMerge compares files inside many archive formats as if they were ordinary folders. The bridge is the ArchiveSupport/Merge7z directory of DLLs, and those DLLs are required to build WinMergeU.exe rather than optional. A standalone installer for the DLLs is included as well. 7-Zip appears separately in the list of tools the build needs, so archive comparison is a chain of two dependencies: one for the build and one for run time.

The format list is whatever 7-Zip already handles. WinMerge adds nothing to it, and the README does not say what happens when a comparison is pointed at a format 7-Zip cannot read, or at one that asks for a password. The archive item is also written as a comparison capability: the merging description covers files and folders and does not mention writing back inside an archive, so treat read inside archives as the stated scope.

The Explorer context menu comes from a directory the build does not link in

Windows Explorer integration adds a comparison entry to the right-click context menu, and that entry comes from the ShellExtension directory rather than from the main program. Plugins form a separate layer again: the Plugins directory holds runtime plugin DLLs and scripts. BuildTmp is scratch space and is safe to delete; Build is where the executables, libraries, and manuals end up.

The practical consequence is that the right-click entry depends on the shell extension, not on WinMergeU.exe alone. Color schemes, translation files, and filters likewise sit in their own directories.

Every script at the repository root ends in .cmd or .bat

BuildAll.cmd, BuildAll.vs2017.cmd, BuildAll.vs2022.cmd, BuildBin.cmd, BuildInstaller.cmd, BuildManual.cmd, BuildTranslations.cmd, CreateRelease.cmd, runastyle.bat, runcppcheck.cmd: the entry points are Windows batch files, and the project files beside them are Visual Studio solutions. The toolchain is Visual C++ MFC and ATL with the Windows 10 SDK, either Visual Studio 2017 on the v141 toolset or Visual Studio 2022 or later on MSVC v143 or newer. Windows XP support for C++ is listed as an option on the 2017 path.

There is no macOS or Linux path in that list, and no cross-platform project file to build instead. A reader looking for an install on Ubuntu or a copy for macOS will not find one here, and this repository is not the place that would supply it, because nothing in it compiles off Windows. Contributors on those systems have to reach a Windows machine or a Windows virtual machine before any of these scripts run.

Version numbers come from SetVersion.cmd and Version.in

The repository root carries Version.h, Version.in, and SetVersion.cmd, so the version string is fed into the build rather than typed into a single source file by hand. Releases come out under the 2.16 line: v2.16.60 on 2026-10-27, v2.16.59 on 2026-10-04, and v2.16.58.2 on 2026-08-27. The default branch, master, took a push on 2026-11-01, so the line is worked on between releases rather than left still.

CreateRelease.cmd and UploadToVirusTotal.cmd sit next to the build scripts, and appveyor.yml in the root configures the continuous builds whose artifacts page the documentation links to. The changelog lives at Docs/Users/ChangeLog.md, the whole documentation tree opens from Docs/index.html, and translation status is tracked in Translations/TranslationsStatus.md. If a behavior changed, that changelog is where the answer lives, and it is versioned alongside the code.

Editorial conclusion

WinMerge earns its place on a Windows machine for text files, for folder trees whose filters you actually understand, and for archives 7-Zip can already open. Leave it alone if you need a macOS or Linux build, a documented spreadsheet diff, or a scripted interface, because the repository documents none of those. Before you trust an empty result, check the filter expressions, check the ignore rules, and check whether the file is binary at all.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. WinMerge/winmerge on GitHub