diff --git a/docs/vb-gow.txt b/docs/vb-gow.txt
new file mode 100644
index 0000000..e2ba64b
--- /dev/null
+++ b/docs/vb-gow.txt
@@ -0,0 +1,71 @@
+Virtual Bridges GOW Disk Image formats
+======================================
+GOW has 3 versions that covers the following products:
+ v1: (circa 2006) Win4Lin Pro, Win4BSD, Win4Solaris
+ v2: (circa 2008) Virtual Bridges VERDE,
+ IBM Virtual Desktop for Smart Business
+ v3: (circa 2009) Virtual Bridges VERDE,
+ IBM Virtual Desktop for Smart Business
+
+Current versions of VERDE and IBM Virtual Desktop for Smart Business use
both
+versions 2 and 3 in virtual machines to store user images and gold images,
+respectively.  Older versions of VERDE (prior to 2009) used only version 2.
+
+What is GOW?
+============
+GOW stands for "Grow on Write", which is a very simple disk image format
that
+grows by 64KB blocks when data is added to disk images.  Data added to
existing
+allocated areas do not result in growth of course.  There is no compression
+other than that explicitly available by not having to allocate unused
blocks
+in order to handle data beyond them.  A simple header at the beginning of
the
+image file maps logical blocks (from the guest's perspective) to file
offsets
+(from the host's perspective).
+This image format is optimized for product virtual desktop use cases only,
and
+has been in mainstream use since 2006.  Both Virtual Bridges and IBM sell
+new versions of this technology worldwide at the time of this writing.
+GOW implementation memory maps the allocation map in order to reduce
additional
+file-level system calls during normal operation.  It supports both
read-only
+and read-write images.
+
+Differences Between Versions
+============================
+Version 1 supports disk images of up to 64GB logical size, with an
approximate
+4MB header overhead.
+Version 2 supports disk images of up to 256GB logical size, with an
approximate
+16MB header overhead.  It also aligned file offsets of logical sectors to
512-
+byte boundaries (starting at the first such boundary following the header).
+Version 3 supports disk images of up to 256GB logical size, with an
approximate
+32MB header overhead.  It is identical to GOW2 except that it also tracks
+block-level version numbers, incrementing (once-per-session) them on
changes
+or new allocation.  This allows for very easy delta size calculations when
+synchronizing images with external tools (see below).
+File offsets in headers are expressed in 64KB blocks.  Block 0 starts
+immediately after the header for each version.  In GOW2 and GOW3, block 0
+is actually aligned to a 512 byte boundary beyond the header.  Using 64KB
+blocks allows the use of 32-bit unsigned integers in the header itself,
rather
+than 64-bit integers, to store offsets even for large files.  This cuts the
+header size requirement in half while adding only a minimal shift overhead
to
+offset calculations.
+
+Advanced Use Case: Synchronizing Remote Images from Master
+==========================================================
+One of the technologies VERDE provides is "decentralized" virtual desktops.
+This means a gold master image living in the data center can be cached on
+either local desktop(s) or local server(s) to use offline or in a
decentralized