]> wimlib.net Git - wimlib/blobdiff - doc/imagex.1.in
Update docs
[wimlib] / doc / imagex.1.in
index 1431ad388d342cd508671f21ae0831514bbcf57f..c694dd33c733318115c189862f40849c547884c5 100644 (file)
@@ -42,7 +42,8 @@ There is a separate manual page for each \fBimagex\fR command.
 
 .SH SUPPORTED FEATURES
 
-The following general features are currently supported:
+The following general features are currently supported (note: this is not a
+complete list):
 
 .IP \[bu] 3
 Create a stand-alone WIM from a directory or NTFS volume (\fBimagex capture\fR)
@@ -87,31 +88,39 @@ when appropriate.
 
 .IP \[bu] 4
 Because Microsoft designed the WIM file format to accomodate Windows-specific
-and NTFS-specific features, \fBimagex\fR 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.
+and NTFS-specific features, wimlib 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.
+
+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, although it won't actually run on Windows anyway.
+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 some
-bugs for compatibility purposes.
+same bugs in wimlib, although in some cases I have had to work around bugs for
+compatibility purposes.
+
+.IP \[bu]
+wimlib's \fBimagex\fR offers the extra command \fBimagex 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 \fBimagex\fR offers the extra commands \fBimagex optimize\fR and
-\fBimagex join\fR to easily remove holes in a WIM or join the parts of a split
-WIM, respectively.
+wimlib's \fBimagex\fR also offers the command \fBimagex join\fR, which lets you
+easily join the parts of a split WIM.
 
 .IP \[bu]
 wimlib's \fBimagex 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.
+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 \fBimagex capture\fR supports combining multiple separate directories
@@ -126,12 +135,34 @@ create compressed WIM files.
 
 .IP \[bu]
 wimlib's \fBimagex capture\fR supports a special mode where UNIX file modes,
-owners, and groups are stored.
+owners, and groups are stored.  (Note: this functionality is only available on
+UNIX builds.)
 
 .IP \[bu]
 wimlib's \fBimagex mount\fR and \fBimagex 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.
+do that takes so long to simply set up a mountpoint.  (Note: this functionality
+is only available on UNIX builds.)
+
+.IP \[bu]
+wimlib's \fBimagex 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.
 
 .SH WARNING