Skip to content

0capture

Maintainer: Bastian Eicher
License: GNU Lesser General Public License
Source: https://github.com/0install/0capture
Zero Install feed: https://apps.0install.net/0install/0capture.xml

0capture is a command-line tool for generating Zero Install feeds with metadata for desktop integration by observing what an installer does to a system. This currently only works on Windows.

It is the easiest way to package closed-source Windows apps that ship as .exe or .msi installers and that register file associations, Start menu entries or shell verbs; details that are tedious to declare by hand. 0capture watches a "before" and "after" snapshot of the system, infers which files and registry entries belong to the app, and emits a ready-to-use feed.

To setup 0capture on your system you can run:

0install add 0capture https://github.com/0install/0capture

If you prefer a GUI, you can use the "New Feed Wizard" in the Windows version of 0publish-gui, which provides similar functionality.

Tip

Run 0capture inside a clean Windows virtual machine. Any unrelated changes that happen between the two snapshots (Windows Update, antivirus signatures, browser caches) end up in the diff and pollute the generated feed.

Usage

First snapshot

First you need to capture a snapshot of the current state of your system by running:

0capture start myapp.snapshot

This will create a file named myapp.snapshot storing information such as the currently installed binaries, registered file handlers, registry contents under typical install hives, and Start menu entries.

App installation

Now you can install the app you wish to capture using its regular installer (e.g. setup.exe or an .msi). Choose any options you want preserved in the feed (shortcuts, file associations).

Avoid running unrelated software in between. Esverything that changes will end up in the diff.

Second snapshot

Once the app is installed you can run:

0capture finish myapp.snapshot myapp.xml --collect-files=myapp.zip

This creates another snapshot of the system state and compares it with the previously stored one. By comparing the two snapshots, 0capture infers which capabilities the app provides (file types, URL protocols, default-program registrations, ...) and uses this information to generate the feed file myapp.xml. With --collect-files it also bundles the new files into the archive myapp.zip so the captured app can be re-distributed without re-running the installer.

The generated feed will reference myapp.zip via a relative <archive href="myapp.zip"/>. Edit it to point at the public URL where you'll host the archive before publishing.

Reviewing and signing the feed

The generated feed is a starting point, not a final product. Open it in an editor or in 0publish-gui and:

  • Set the <name>, <summary>, <description>, <homepage> and <icon> elements. 0capture cannot infer these reliably.
  • Replace the local archive reference with the public download URL once the archive is uploaded.
  • Remove any captured capabilities that don't actually belong to your app (e.g. file associations created by an unrelated update).
  • Set a sensible version= and released= on the <implementation>.

Then sign and publish like any other feed:

0install run https://apps.0install.net/0install/0publish.xml myapp.xml --xmlsign

FAQ

Do I need to repeat this for each release of the app I captured?
If the app provides non-installer archives, you can modify the feed to use those instead of the archive generated by --collect-files. Then you'll only need to run 0capture once to get the desktop integration capabilities, and subsequent versions can be added with 0template or 0publish using the existing capability metadata.
The generated feed seems to be missing some capabilities. How can I improve the quality of the generated feed?
Try running 0capture and the app's installer in an otherwise pristine VM.
Can I use 0capture for portable apps that don't need an installer?
Yes. Run 0capture start, extract the portable app into a fixed location, and run 0capture finish. Capabilities will only be picked up if the app registers them in the system (e.g. by writing to HKCU\Software\Classes). For purely portable apps that don't, declare capabilities by hand using the Capabilities specification.
The captured archive is much larger than the upstream installer. Why?
Installers typically ship compressed payloads that are expanded on disk; --collect-files archives the expanded layout. You can shrink the result by re-compressing with a stronger algorithm (e.g. 7z) or by hosting the original installer instead and pointing the <archive> at it with type="application/x-msi".