+Although \fB@IMAGEX_PROGNAME@\fR shares some similarities with Microsoft's
+implementation of ImageX, this section lists some of the many noteworthy
+differences between the two programs:
+.IP \[bu] 4
+\fB@IMAGEX_PROGNAME@\fR is supported on both UNIX-like systems and Windows;
+thus, some functionality was designed around this.
+.IP \[bu]
+The command-line syntax of the two programs is similar but not exactly the same.
+.IP \[bu]
+Because Microsoft designed the WIM file format to accomodate Windows-specific
+and NTFS-specific features, on UNIX-like systems wimlib must have two separate
+image capture and application modes (although the \fB@IMAGEX_PROGNAME@\fR
+commands for the modes are the same): one for image capture and application
+from/to a directory, and one for the capture or application of an image
+specifically from/to an NTFS volume.
+.IP ""
+Note: the above applies to builds of \fB@IMAGEX_PROGNAME@\fR for UNIX-like
+systems. On the Windows build, there is only one image capture and application
+mode, similar to Microsoft's ImageX.
+.IP \[bu]
+wimlib supports multithreaded compression, which can make it much faster to
+create compressed WIM files.
+.IP \[bu]
+\fB@IMAGEX_PROGNAME@\fR offers the extra commands \fB@IMAGEX_PROGNAME@
+extract\fR and \fB@IMAGEX_PROGNAME@ update\fR, which let you quickly extract
+files from or make changes to a WIM image without mounting it.
+.IP \[bu]
+\fB@IMAGEX_PROGNAME@\fR offers the extra command \fB@IMAGEX_PROGNAME@
+optimize\fR, which lets you easily remove wasted space in a WIM (which can arise
+after a WIM image is appended or mounted read-write). It also makes it easy to
+recompress a WIM file at the highest compression level.
+.IP \[bu]
+\fB@IMAGEX_PROGNAME@\fR also offers the command \fB@IMAGEX_PROGNAME@ join\fR,
+which lets you easily join the parts of a split WIM.
+.IP \[bu]
+For convenience, \fB@IMAGEX_PROGNAME@\fR automatically preserves the integrity
+table in WIMs that have one, even when \fB--check\fR is not specified.
+.IP \[bu]
+wimlib supports a special "pipable" WIM format (not compatible with Microsoft's
+software). This allows capturing and applying images directly to standard
+output or from standard input, respectively; this can be used to pipe images to
+or from a server over the network to implement fast filesystem imaging and
+restore.
+.IP \[bu]
+\fB@IMAGEX_PROGNAME@ capture\fR and \fB@IMAGEX_PROGNAME@ append\fR support
+options to optimize incremental backups and to create "delta" WIM files.
+.IP \[bu]
+wimlib (and \fB@IMAGEX_PROGNAME@\fR via \fB@IMAGEX_PROGNAME@ capture\fR)
+supports combining multiple separate directories and files together in a
+configurable way to create a WIM image.
+.IP \[bu]
+Microsoft's ImageX has some weird limitations, like it won't let you extract a
+WIM on a shared folder, and it requires some commands to be run only from
+Windows PE and not from regular Windows. \fB@IMAGEX_PROGNAME@\fR does not have
+these unusual limitations.
+.IP \[bu]
+There are bugs in Microsoft's WIM library and I obviously have not included the
+same bugs in wimlib, although in some cases I have had to work around bugs for
+compatibility purposes.
+.IP \[bu]
+wimlib (and \fB@IMAGEX_PROGNAME@\fR via \fB@IMAGEX_PROGNAME@ mount\fR) support
+mounting an image from a split WIM, but Microsoft's software does not. (Note:
+this functionality is not available in Windows builds of wimlib and
+\fB@IMAGEX_PROGNAME@\fR.)
+.SH LOCALES AND CHARACTER ENCODINGS
+WIM files themselves store file and stream names using UTF-16LE. On Windows,
+wimlib works in UTF-16LE, so conversions are usually not necessary and there
+should be no problems with character encodings.
+.PP
+On UNIX-like systems, wimlib works primarily in the locale-dependent multibyte
+encoding, which you are strongly recommended to set to UTF-8 to avoid any
+problems. You can alternatively set the environmental variable
+\fBWIMLIB_IMAGEX_USE_UTF8\fR to force \fB@IMAGEX_PROGNAME@\fR to use UTF-8
+character encoding internally, even if the current locale is not UTF-8
+compatible.
+.SH CASE SENSITIVITY
+By default, the case sensitivity of \fB@IMAGEX_PROGNAME@\fR differs somewhat
+between UNIX-like systems and Windows. WIM images may (but usually do not) have
+multiple files with the same case-insensitive name. Internally, wimlib
+stores filenames as case-sensitive, but on Windows paths
+actually provided by the user for use in a WIM image (e.g. for extracting,
+adding, renaming, or deleting files) will by default be treated as
+case-insensitive in order to get the "expected" behavior. This differs from the
+default behavior on UNIX-like systems, where such paths will be treated as
+case-sensitive. Note that with case insensitivity, a path component may in
+general be ambiguous due to multiple files or directories having the same
+case-insensitive name. In such cases, if there is a file or directory with an
+exactly matching name, it is chosen; otherwise, one of the case-insensitively
+matching file or directories is chosen arbitrarily.
+.PP
+The default behavior can be overridden by explicitly setting the environmental
+variable \fBWIMLIB_IMAGEX_IGNORE_CASE\fR to 1, in which case such paths will be
+treated case insensitively, or 0, in which such paths will be treated case
+sensitively.
+.PP
+Regardless of these settings, options and non-path arguments must be specified
+in lower case.
+.SH LICENSE
+wimlib and \fB@IMAGEX_PROGNAME@\fR are distributed under the GNU General Public
+License version 3 or later. Be aware this means this software is provided as-is
+and has no warranty; see COPYING for details.