-See \fBUNSUPPORTED FEATURES\fR.
-
-The \fB/scroll\fR and \fB/log\fR switches from Microsoft's version imagex are
-not planned to be implemented. Note that to scroll the output in the UNIX shell
-you can just pipe the output into \fBless\fR(1).
-
-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.
-
-See the documentation for each command; in some cases they do not do exactly the
-same thing as imagex.exe.
-
-Obviously, this version of imagex is free software but Microsoft's version is
-not.
+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 addition, I have added additional useful features
+when appropriate.
+
+.IP \[bu] 4
+Because Microsoft designed the WIM file format to accomodate Windows-specific
+and NTFS-specific features, wimlib must have two separate image capture and
+application modes (although the \fB@IMAGEX_PROGNAME@\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.
+
+Note: the above applies to UNIX builds. On the Windows builds of wimlib, there
+is only one image capture and application mode, similar to Microsoft's ImageX.
+
+.IP \[bu]
+Microsoft's version 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. This version 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]
+\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]
+\fB@IMAGEX_PROGNAME@ apply\fR supports keeping files hard-linked or symlinked
+across WIM images when extracted from a WIM. So you can, for example, extract
+different versions of Windows from an install.wim without using much extra
+space. (Note: this functionality is only available in UNIX builds of wimlib.)
+
+.IP \[bu]
+\fB@IMAGEX_PROGNAME@ capture\fR supports combining multiple separate directories
+and files together in a configurable way to create a WIM image.
+
+.IP \[bu]
+wimlib's XPRESS compressor is better than Microsoft's.
+
+.IP \[bu]
+wimlib supports multithreaded compression, which can make it much faster to
+create compressed WIM files.
+
+.IP \[bu]
+\fB@IMAGEX_PROGNAME@ capture\fR supports a special mode where UNIX file modes,
+owners, and groups are stored. (Note: this functionality is only available on
+UNIX builds.)
+
+.IP \[bu]
+\fB@IMAGEX_PROGNAME@ mount\fR and \fB@IMAGEX_PROGNAME@ mountrw\fR are much faster than
+Microsoft's versions for some reason. I don't know what they have their program
+do that takes so long to simply set up a mountpoint. (Note: this functionality
+is only available on UNIX builds.)
+
+.IP \[bu]
+\fB@IMAGEX_PROGNAME@ mount\fR supports mounting an image from a split WIM, but
+Microsoft's software does not. (Note: this functionality is only available on
+UNIX builds.)
+
+.SH LOCALES AND CHARACTER ENCODINGS
+
+On Windows, wimlib 1.3.2 and later works in UTF-16LE, and there should be no
+problems with character encodings.
+
+On UNIX, wimlib works primarily in the locale-dependent multibyte encoding,
+which you are strongly recommended to set to UTF-8 to avoid any problems.
git://wimlib.net / wimlib / blobdiff