Update README, README.WINDOWS, NEWS
authorEric Biggers <ebiggers3@gmail.com>
Sun, 28 Apr 2013 03:49:14 +0000 (22:49 -0500)
committerEric Biggers <ebiggers3@gmail.com>
Sun, 28 Apr 2013 03:49:14 +0000 (22:49 -0500)
NEWS
README
README.WINDOWS

diff --git a/NEWS b/NEWS
index d3d9de7..9cd71e0 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -11,7 +11,7 @@ Version 1.3.3:
        compressed, sparse, and encrypted files.
 
        The Windows build now supports capturing and applying WIM images from
-       filesystems other than NTFS.
+       filesystems other than NTFS (with some reduced functionality).
 
        Added support for "reparse-point" fixups (i.e. fixing up of symbolic
        links).  See docs for --rpfix and --norpfix flags of `wimlib-imagex
diff --git a/README b/README
index 5cd3915..750f3af 100644 (file)
--- a/README
+++ b/README
@@ -5,8 +5,8 @@ and mount files in the Windows Imaging Format (WIM files).  These files are
 normally created by using the `imagex.exe' utility on Windows, but this library
 provides a free implementation of ImageX for UNIX-based systems.
 
-wimlib 1.3.0 has added experimental support for Windows.  See the file
-"README.WINDOWS" for more details.
+wimlib 1.3.0 and later have support for Windows.  See the file "README.WINDOWS"
+for more details.
 
                                   WIM FILES
 
@@ -218,9 +218,8 @@ wimlib's `configure' script:
 
                                  PORTABILITY
 
-wimlib has mostly been developed and tested on x86_64 (64-bit) GNU/Linux.
-
-It has been tested on x86 (32-bit) GNU/Linux occasionally.
+wimlib has primarily been tested on Linux and Windows (primarily Windows 7, but
+also Windows XP and Windows 8).
 
 wimlib may work on FreeBSD and Mac OS X.  However, this is not well tested.  If
 you do not have libntfs-3g 2011-4-12 or later available, you must configure
@@ -230,10 +229,6 @@ load the POSIX message queue module (run `kldload mqueuefs').
 The code pays attention to endianness, so it should work on big-endian
 architectures, but I've never tested this so do not expect it to work.
 
-As of wimlib 1.3.0, there is experimental support for Microsoft Windows.  I
-expect it to work on Windows Vista and later, although I have only tested it on
-Windows 7.  See README.WINDOWS for more information.
-
                                   REFERENCES
 
 The WIM file format is specified in a document that can be found in the
index a496827..09f9624 100644 (file)
@@ -1,29 +1,33 @@
                                   INTRODUCTION
 
-wimlib 1.3.0 has added experimental support for Windows builds.  The Windows
-build consists of both the "wimlib" library (which can be built as a DLL) and
-the "imagex" executable.
+wimlib 1.3.0 has added experimental support for Windows builds.  The support has
+been further improved in later versions.  The Windows build consists of both the
+"wimlib" library (which can be built as a DLL) and the "wimlib-imagex"
+executable.
 
 The Windows build of wimlib uses native Win32 calls when appropriate to handle
-alternate data streams, security descriptors, and reparse points.
+alternate data streams, security descriptors, reparse points, encrypted files,
+compressed files, and sparse files.
 
 Mounting WIM files is not supported on Windows.  Also please note that wimlib's
-"imagex" is NOT intended to be command-line compatible with Microsoft's
+"wimlib-imagex" is NOT intended to be command-line compatible with Microsoft's
 "imagex", and wimlib is NOT intended to be API compatible with Microsoft's
 WIMGAPI.  They are similar, though.
 
                                 NOTES ABOUT IMAGEX
 
-"imagex capture", "imagex append", and "imagex apply" will work on Windows and
-have the added advantage of saving and restoring alternate data streams,
-security descriptors, and reparse points.
+"wimlib-imagex capture", "wimlib-imagex append", and "wimlib-imagex apply" will
+work on Windows and have the added advantage of saving and restoring
+NTFS-specific data, such as alternate data streams, security descriptors, and
+reparse points.
 
-"imagex delete", "imagex dir", "imagex export", "imagex info", "imagex join",
-"imagex optimize", and "imagex split" are all portable and should work the same
-way on Windows as on UNIX.
-
-"imagex mount", "imagex mountrw", and "imagex unmount" will NOT work on Windows.
+"wimlib-imagex delete", "wimlib-imagex dir", "wimlib-imagex export",
+"wimlib-imagex info", "wimlib-imagex join", "wimlib-imagex optimize", and
+"wimlib-imagex split" are all portable and should work the same way on Windows
+as on UNIX.
 
+"wimlib-imagex mount", "wimlib-imagex mountrw", and "wimlib-imagex unmount" will
+NOT work on Windows.
 
 So on Windows, why would you want to use wimlib's ImageX instead of Microsoft's?
 Well, here are a few reasons:
@@ -31,12 +35,17 @@ Well, here are a few reasons:
 - wimlib offers fast multithreaded compression, so making WIM images can be much
   faster.
 
-- wimlib can correctly save and restore alternate data streams, which
-  Microsoft's ImageX sometimes captures incorrectly due to a bug.
+- Whenever possible I have included improved documentation and informational
+  output compared to Microsoft's software.
+
+- wimlib can correctly save and restore some combinations of data that
+  Microsoft's ImageX runs into bugs on --- for example, uncompressed files in
+  compressed directories, or files with alternate data streams and multiple
+  links.
 
 - wimlib is free software, so you can modify and/or audit the source code.
 
-See the man page for 'imagex' for more information.
+See the man page for 'wimlib-imagex' for more information.
 
                                 BUILDING ON WINDOWS