+wimlib 1.3.0 has added experimental support for Windows builds. These builds
+include both the "wimlib" library (built as a DLL) and the "imagex" executable.
+
+The Windows builds use native Win32 calls when appropriate to handle alternate
+data streams, security descriptors, and reparse points.
+
+Windows support currently has the following limitations:
+
+- It relies on the Cygwin UNIX-compatibility layer. You do not, however, need
+ to have the Cygwin distribution installed to run it, as I have posted a ZIP
+ file on SourceForge that contains the build of wimlib along with the DLLs
+ needed for it to run. Please note that these DLLs are free and open source
+ software; see http://www.cygwin.com/ for more details.
+
+- Mounting WIM files is not supported. On Windows there is no equivalent of
+ FUSE, which I used to get mounting working on Linux and BSD, so I would have
+ to program a "Filesystem Filter" driver with Microsoft's eccentric API.
+
+- wimlib's API is not compatible with Microsoft's WIMGAPI, although they offer
+ some of the same functionality.
+
+So to be clear:
+
+"imagex capture", "imagex append", and "imagex apply" will work on Windows and
+have the added advantage of saving and restoring alternate data streams,
+security descriptors, and reparse points.
+
+"imagex delete", "imagex dir", "imagex export", "imagex info", "imagex join",
+"imagex optimize", and "imagex split" are all portable and should work the same
+way on Windows as on UNIX.
+
+"imagex mount", "imagex mountrw", and "imagex unmount" will NOT work on Windows.
+
+So on Windows, why would you want to use wimlib's ImageX instead of Microsoft's?
+Well, here are a few reasons:
+
+- wimlib can be freely distributed; there is no need to download a 1.8 gigabyte
+ "Windows Automated Installation Kit".
+- wimlib offers fast multithreaded compression, so making WIM images can be much
+ faster.
+- wimlib is free software, so you can modify and/or audit the source code.