-
-See \fBUNSUPPORTED FEATURES\fR.
-
-The most important difference is that this version of \fBimagex\fR cannot
-capture and restore Windows images losslessly because file permissions and
-alternate file streams are ignored. This is because Microsoft designed the WIM
-format to be specific to their NTFS filesystem and the Windows security
-model/API, which is difficult to support in a non-Windows program. You can
-still create images of Windows PE, however.
-
-See the documentation for each subcommand of \fBimagex\fR; in some cases they do
-not do exactly the same thing as imagex.exe.
-
-Some features, such as the ability to keep files hard-linked when they are
-extracted from a WIM, are not available in Microsoft's version of imagex.
-Also, doesn't seem to be an equivalent of \fBimagex join\fR in Microsoft's
-version; you would have to use \fBimagex.exe /export\fR, but that doesn't let
-you export all images at once.
-
-Microsoft's version has some weird limitations, like it won't let you extract a
+Although \fB@IMAGEX_PROGNAME@\fR shares some similarities with Microsoft's
+implementation of ImageX, this section lists some 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]
+wimlib's XPRESS compressor is slightly better than Microsoft's (in terms of
+compression ratio).
+.IP \[bu]
+wimlib's LZX compressor is slightly worse than Microsoft's (in terms of
+compression ratio), but it's still better than XPRESS compression.
+.IP \[bu]
+\fB@IMAGEX_PROGNAME@ capture\fR defaults to LZX ("maximum") compression for new
+WIMs, as opposed to Microsoft's software which defaults to XPRESS ("fast")
+compression.
+.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).
+.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]
+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