-
-While similar to Microsoft's "imagex.exe" program, this program is designed for
-UNIX-based systems and by the nature of the platform cannot be exactly the same
-as Microsoft's version.
-
-In particular, because Microsoft designed the WIM file format to accomodate
-Windows-specific and NTFS-specific features, we must have two separate image
-capture and application modes (although the \fBimagex\fR subcommands for the
-modes are the same): one for general image capture and application, and one for
-the capture or application of an image specifically from/to an NTFS volume.
-
-Some features, such as the ability to keep files hard-linked across WIM images
-when they are extracted from a WIM, are not available in Microsoft's version of
-imagex. Also, this version of \fBimagex\fR lets you mount an image from a split
-WIM read-only, while Microsoft's version does not.
-
-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