compatibility purposes.
.IP \[bu]
-wimlib's \fB@IMAGEX_PROGNAME@\fR offers the extra command \fB@IMAGEX_PROGNAME@ optimize\fR,
+\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]
-wimlib's \fB@IMAGEX_PROGNAME@\fR also offers the command \fB@IMAGEX_PROGNAME@ join\fR, which lets you
+\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]
-wimlib's \fB@IMAGEX_PROGNAME@ apply\fR supports keeping files hard-linked or symlinked
+\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]
-wimlib's \fB@IMAGEX_PROGNAME@ capture\fR supports combining multiple separate directories
+\fB@IMAGEX_PROGNAME@ capture\fR supports combining multiple separate directories
and files together in a configurable way to create a WIM image.
.IP \[bu]
create compressed WIM files.
.IP \[bu]
-wimlib's \fB@IMAGEX_PROGNAME@ capture\fR supports a special mode where UNIX file modes,
+\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]
-wimlib's \fB@IMAGEX_PROGNAME@ mount\fR and \fB@IMAGEX_PROGNAME@ mountrw\fR are much faster than
+\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]
-wimlib's \fB@IMAGEX_PROGNAME@ mount\fR supports mounting an image from a split WIM, but
+\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
-wimlib 1.3.0 has improved support for alternate character encodings.
-However, not everything has been well tested, and on UNIX you are strongly
-encouraged to use a UTF-8 locale so that you do not run into any problems.
-In particular, if your locale uses a character encoding that is
-not UTF-8, then you will not be able to open or capture WIM files containing
-files with paths not representable in the current locale's character encoding.
-
-Similar restrictions apply to the Windows-native build of wimlib, but
-unfortunately Windows does not support UTF-8 locales. So you will not be able
-to apply a WIM image containing files with names not representable in the
-current Windows code page, nor will you be able to capture a directory tree
-containing files with names not representable in the current Windows code page.
+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.
.SH WARNING