]> wimlib.net Git - wimlib/blobdiff - README.WINDOWS
Fix UNIX build; rename functions; comments
[wimlib] / README.WINDOWS
index a0521f023e394f4245e3af38a8ab40fec3cf4562..45b7ad568526e9a8453f407084dc7e57a97a3453 100644 (file)
@@ -1,25 +1,18 @@
-wimlib 1.3.0 has added experimental support for Windows builds.  These builds
-include both the "wimlib" library (built as a DLL) and the "imagex" executable.
+                                  INTRODUCTION
 
-The Windows builds use native Win32 calls when appropriate to handle alternate
-data streams, security descriptors, and reparse points.
+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.
 
-Windows support currently has the following limitations:
+The Windows build of wimlib uses native Win32 calls when appropriate to handle
+alternate data streams, security descriptors, and reparse points.
 
--  It relies on the Cygwin UNIX-compatibility layer.  You do not, however, need
-   to have the Cygwin distribution installed to run it, as I have posted a ZIP
-   file on SourceForge that contains the build of wimlib along with the DLLs
-   needed for it to run.  Please note that these DLLs are free and open source
-   software; see http://www.cygwin.com/ for more details.
+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
+"imagex", and wimlib is NOT intended to be API compatible with Microsoft's
+WIMGAPI.  They are similar, though.
 
--  Mounting WIM files is not supported.  On Windows there is no equivalent of
-   FUSE, which I used to get mounting working on Linux and BSD, so I would have
-   to program a "Filesystem Filter" driver with Microsoft's eccentric API.
-
--  wimlib's API is not compatible with Microsoft's WIMGAPI, although they offer
-   some of the same functionality.
-
-So to be clear:
+                                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,
@@ -31,11 +24,32 @@ way on Windows as on UNIX.
 
 "imagex mount", "imagex mountrw", and "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:
 
-- wimlib can be freely distributed; there is no need to download a 1.8 gigabyte
-  "Windows Automated Installation Kit".
 - 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.
+
 - wimlib is free software, so you can modify and/or audit the source code.
+
+See the man page for 'imagex' for more information.
+
+                                BUILDING ON WINDOWS
+
+Actually doing the Windows build is a bit tricky, and I'd recommend you download
+precompiled binaries from http://sourceforge.net/projects/wimlib/files/ instead.
+I did it using MinGW-w64 on a Linux host, with the following configuration
+command:
+
+$ ./configure --host=i686-w64-mingw32 \
+              CPPFLAGS=-I/opt/libxml2-min/i686-w64-mingw32/include/libxml2 \
+              LDFLAGS=-L/opt/libxml2-min/i686-w64-mingw32/lib
+
+Building wimlib using Cygwin is not supported.  I was trying this for a while,
+but I ran into some issues with mixing native Win32 functions and
+Cygwin-provided functions, so I just made it possible to do a native Win32 build
+instead.