+/*
+ * Perform the intermediate stages of creating a "pipable" WIM (i.e. a WIM
+ * capable of being applied from a pipe). Such a WIM looks like:
+ *
+ * Pipable WIMs are a wimlib-specific modification of the WIM format such that
+ * images can be applied from them sequentially when the file data is sent over
+ * a pipe. In addition, a pipable WIM can be written sequentially to a pipe.
+ * The modifications made to the WIM format for pipable WIMs are:
+ *
+ * - Magic characters in header are "WLPWM\0\0\0" (wimlib pipable WIM) instead
+ * of "MSWIM\0\0\0". This lets wimlib know that the WIM is pipable and also
+ * should stop other software from trying to read the file as a normal WIM.
+ *
+ * - The header at the beginning of the file does not contain all the normal
+ * information; in particular it will have all 0's for the lookup table and
+ * XML data resource entries. This is because this information cannot be
+ * determined until the lookup table and XML data have been written.
+ * Consequently, wimlib will write the full header at the very end of the
+ * file. The header at the end, however, is only used when reading the WIM
+ * from a seekable file (not a pipe).
+ *
+ * - An extra copy of the XML data is placed directly after the header. This
+ * allows image names and sizes to be determined at an appropriate time when
+ * reading the WIM from a pipe. This copy of the XML data is ignored if the
+ * WIM is read from a seekable file (not a pipe).
+ *
+ * - The format of resources, or streams, has been modified to allow them to be
+ * used before the "lookup table" has been read. Each stream is prefixed with
+ * a `struct pwm_stream_hdr' that is basically an abbreviated form of `struct
+ * wim_lookup_table_entry_disk' that only contains the SHA1 message digest,
+ * uncompressed stream size, and flags that indicate whether the stream is
+ * compressed. The data of uncompressed streams then follows literally, while
+ * the data of compressed streams follows in a modified format. Compressed
+ * streams have no chunk table, since the chunk table cannot be written until
+ * all chunks have been compressed; instead, each compressed chunk is prefixed
+ * by a `struct pwm_chunk_hdr' that gives its size. However, the offsets are
+ * given in the chunk table as if these chunk headers were not present.
+ *
+ * - Metadata resources always come before other file resources (streams).
+ * (This does not by itself constitute an incompatibility with normal WIMs,
+ * since this is valid in normal WIMs.)
+ *
+ * - At least up to the end of the file resources, all components must be packed
+ * as tightly as possible; there cannot be any "holes" in the WIM. (This does
+ * not by itself consititute an incompatibility with normal WIMs, since this
+ * is valid in normal WIMs.)
+ *
+ * Note: the lookup table, XML data, and header at the end are not used when
+ * applying from a pipe. They exist to support functionality such as image
+ * application and export when the WIM is *not* read from a pipe.
+ *
+ * Layout of pipable WIM:
+ *
+ * ----------+----------+--------------------+----------------+--------------+------------+--------+
+ * | Header | XML data | Metadata resources | File resources | Lookup table | XML data | Header |
+ * ----------+----------+--------------------+----------------+--------------+------------+--------+
+ *
+ * Layout of normal WIM:
+ *
+ * +---------+--------------------+----------------+--------------+----------+
+ * | Header | Metadata resources | File resources | Lookup table | XML data |
+ * +---------+--------------------+----------------+--------------+----------+
+ *
+ * Do note that since pipable WIMs are not supported by Microsoft's software,
+ * wimlib does not create them unless explicitly requested (with
+ * WIMLIB_WRITE_FLAG_PIPABLE) and as stated above they use different magic
+ * characters to identify the file.
+ */
+static int
+write_pipable_wim(WIMStruct *wim, int image, int write_flags,
+ unsigned num_threads, wimlib_progress_func_t progress_func,
+ struct list_head *stream_list_override)