StormLib reads and writes Blizzard MPQ archives
Official GitHub repository of the StormLib library created by Ladislav Zezula (author)
At a glance
- What is it?
- StormLib is Ladislav Zezula's C library for working with Blizzard's MPQ archive format, the container used by the Warcraft, StarCraft and Diablo data files. It builds with CMake or with a Visual Studio solution, links against zlib, bzip2, libtommath and libtomcrypt, and can be pulled in through Conan on any platform.
- Who is it for?
- StormLib suits a developer who needs to read or write MPQ archives directly, because it implements the format rather than wrapping a command line tool, and it gives you the compression and encryption choices the format supports. It is the wrong tool for a game that only consumes its own data files, since the game already has a reader, and it is the wrong tool if you need to work with a newer archive format the library does not implement.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 11 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What an MPQ archive is, and why the format still matters
StormLib is the official repository for the StormLib library, an open source project that can work with Blizzard MPQ archives, and the homepage is the author's own MPQ documentation page at zezula.net/mpq.html.
MPQ is the archive format Blizzard's games use to package their data. A large game is not a directory of loose files; it is a handful of archives, each holding many files, indexed by a hash table, and each entry optionally compressed and encrypted. The format predates most of the modern game data pipelines and is still the shipping format for the older titles in that catalogue.
The interesting engineering in a library like this is not reading bytes, it is the range of compression and encryption variants the format allows. An MPQ entry can be stored raw, or compressed with one of several schemes, and it can be encrypted with a per-file key, a per-table key, or the file's own hash used as a key. A reader that handles only the common case will fail on a specific archive, and a writer that cannot reproduce the original encryption will produce files the game refuses to load.
That is why the dependency list matters. StormLib builds against the system versions of zlib, bzip2, libtommath and libtomcrypt. The compression libraries are the backends for the archive's compression schemes, and libtommath and libtomcrypt provide the large number arithmetic and the cipher implementations that the encryption schemes need. This is not a trivial dependency list; it is the format's own complexity showing through in the build system.
The library is written in C, is MIT licensed, and the primary language of the repository is recorded as C.
Building it on Linux with CMake
The Linux path is the cleanest, and the README is explicit about the dependencies.
Install the build tools and dependencies on Debian or Ubuntu:
sudo apt-get install build-essential cmake pkg-config zlib1g-dev libbz2-dev libtommath-dev libtomcrypt-devThen clone, check out the release tag you want, configure, build and install:
git clone https://github.com/ladislav-zezula/StormLib.git
cd StormLib && git checkout <latest-release-tag>
cmake -B build -D CMAKE_BUILD_TYPE=Release -D BUILD_SHARED_LIBS=ON
cmake --build build
sudo cmake --install buildThe git checkout of the release tag is the part to notice. The default branch is the development line, so building from a clone of master gives you whatever is on master rather than a released version, and the README puts the tag step in the sequence for that reason.
The two CMake options in that line are the two you will change most often. CMAKE_BUILD_TYPE selects a release build, and BUILD_SHARED_LIBS controls whether you get a shared library rather than the static default.
To link the library into your own project, the README says to include the main header with #include <StormLib.h> and compile with -lstorm -lz -lbz2. Those two compression libraries are needed by name at link time even though the archive format is MPQ.
Packaging is handled with CPack, and the two commands produce both a deb and an rpm:
cd build
cpack -G "DEB"
cpack -G "RPM"The bundled library option, and why it exists
There is a second way to resolve the dependencies, and it is the option that makes the library easier to ship.
By default, StormLib is built against the system versions of zlib, bzip2, libtommath and libtomcrypt. To use the copies of the dependencies bundled with StormLib instead of the system ones, add -D STORM_USE_BUNDLED_LIBRARIES=ON to the first cmake command. In that case only build-essential and cmake need to be installed.
That is a meaningful difference for a library with four native dependencies. A distribution package can then be built without depending on four specific versions of system libraries, and a vendor can ship a single self-contained artefact. The cost is that you no longer get the distribution's security updates for zlib or bzip2 through the package manager, which for a library that parses untrusted archives is a decision worth making consciously rather than by default.
The CMake options table also shows the granularity. STORM_UNICODE toggles Unicode or ANSI support. STORM_SKIP_INSTALL skips installing files. WITH_BUNDLED_LIBTOMMATH and WITH_BUNDLED_LIBTOMCRYPT each bundle one library even when STORM_USE_BUNDLED_LIBRARIES is off, and STORM_BUILD_TESTS compiles the StormLib test application.
That last option connects to a detail in the test application behaviour. STORMTEST_USE_OLD_PATHS uses hardcoded paths for test files, while OFF uses build_folder/work, and the default is ON. In other words the test application, out of the box, expects files in a fixed location, which is a leftover from the Visual Studio layout, and turning it off makes it look in the build tree instead.
Windows builds, and the two Visual Studio solutions
The Windows instructions cover three routes, and the oldest one is still there.
The current route is Visual Studio 2022. Make sure you have the toolset for Visual Studio 2017 - Windows XP installed, download the latest release, open StormLib.sln in Visual Studio 2017, 2019 or 2022, choose Build then Batch Build and select every build of StormLib, choose Rebuild, and the resulting libraries are in the .\bin\Win32 and .\bin\x64 directories.
The instruction about the Visual Studio 2017 toolset is not incidental. StormLib targets the Windows XP toolset, which is what allows the library to be used on older systems, and the README also says you can build with a newer toolset such as v143 if you retarget the projects: right-click the solution, choose Retarget solution and pick the toolset version.
The older route is Visual Studio 2008, with the separate StormLib_vs08.sln solution and the same batch build and rebuild steps, producing the same bin directories. That solution file has been in the repository for a long time and is the reason a very old compiler still works with the library.
The third route is CMake, which is the one to prefer for a scripted or non-Windows-native build. Open the appropriate Visual Studio command prompt or launch a regular cmd and load the environment, then configure for amd64 or x86:
"C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Auxiliary/Build/vcvarsall.bat" x64
cmake -G "Visual Studio 17 2022" -B build_amd64 -D BUILD_SHARED_LIBS=ON
cmake --build build --config ReleaseThe x86 variant is the same with x86 and build_x86. One detail in the README's amd64 sequence is worth noting: the configure step names build_amd64 but the build step says cmake --build build, so the build directory names in the two lines do not match in the text as printed. If you follow it literally, the build step will not find the directory it configured.
Conan, and getting the library onto a non-Windows platform
The Conan route is the one that covers any platform, and it exists because the dependency set is awkward to satisfy by hand.
conan install . -of build -s build_type=Release --build=missing
cmake -B build -DCMAKE_BUILD_TYPE=Release -DSTORM_USE_BUNDLED_LIBRARIES=OFF -DWITH_BUNDLED_LIBTOMCRYPT=ON -DCMAKE_TOOLCHAIN_FILE=build/conan_toolchain.cmake
cmake --build build --config ReleaseConan resolves and builds all the dependencies, zlib, bzip2 and libtommath, on any platform, and the CMake configure step then consumes the generated toolchain file.
The two non-default options in that command are there for a reason and the README explains it. STORM_USE_BUNDLED_LIBRARIES=OFF tells StormLib to use the Conan-resolved libraries rather than its own copies, and WITH_BUNDLED_LIBTOMCRYPT=ON is required because libtomcrypt is not yet packaged in the Conan Index. That single missing package is the whole reason the option exists, and it is a good illustration of what a cross platform C library inherits from its dependency set.
For a 32-bit build on Windows, add -s:h arch=x86 to the conan install command.
The repository layout shows the breadth of the platform support in practice. There is StormLib.sln for modern Visual Studio, StormLib_vs08.sln for the 2008 toolchain, the vcxproj files, a StormLib.xcodeproj directory for macOS, a Premake5.lua script, make.bat and make-msvc.bat for command line builds on Windows, a conanfile.py, an Info.plist, and the src/, sources/, storm.dll/, test/ and doc/ directories.
Where StormLib fits, and where it stops
The comparison worth making is with the other ways of handling MPQ data, and the differences come down to whether you need the format or just the files.
Against a command line extractor, the difference is control. A tool that unpacks an archive gives you the files; a library gives you the entries, with their flags, their keys and their sizes, and lets you decide what to do with each one. For a project that has to rewrite an archive, or verify one entry without extracting thousands, that distinction decides the tool.
Against a game engine's own resource system, the difference is scope. The engine already reads the archives it ships with. StormLib is for the cases where the archive is the input to something else, a modding tool, an extractor, a converter, a verifier.
The limits are visible in the shape of the project. It is a C library with a native dependency set, so integrating it into a managed or a modern build means a native build step, and the Conan recipe is needed precisely because of that. The Windows instructions still centre on a Visual Studio 2017 Windows XP toolset, which tells you the compatibility target is deliberately old.
The maintenance picture is healthy. The releases are v9.40 from 2026-07-04, v9.31 from 2025-11-22 and v9.30 from 2024-11-02, the last push was on 2026-10-12, and the repository is not archived.
The last thing an adopter should check is the format coverage for the specific version of the game or tool they are dealing with, and that means the author's own documentation site rather than the repository README, because the README here is installation instructions and the format reference lives at zezula.net/mpq.html. The MIT licence means there is no obstacle to shipping it in a commercial product, which is the practical reason it has stayed in use for so long.
Editorial conclusion
StormLib suits a developer who needs to read or write MPQ archives directly, because it implements the format rather than wrapping a command line tool, and it gives you the compression and encryption choices the format supports. It is the wrong tool for a game that only consumes its own data files, since the game already has a reader, and it is the wrong tool if you need to work with a newer archive format the library does not implement. Before adopting it, check the v9.x release notes for the format coverage you need, and decide between the system dependency set and the bundled libraries with STORM_USE_BUNDLED_LIBRARIES.
Frequently asked questions
How do I build StormLib on Linux?
Install build-essential, cmake, pkg-config, zlib1g-dev, libbz2-dev, libtommath-dev and libtomcrypt-dev, then clone the repository, check out the release tag, and run cmake -B build with CMAKE_BUILD_TYPE=Release and BUILD_SHARED_LIBS=ON before building and installing. Add -D STORM_USE_BUNDLED_LIBRARIES=ON to use the bundled copies of the dependencies instead of the system ones.
What are StormLib's build dependencies?
By default it is built against the system versions of zlib, bzip2, libtommath and libtomcrypt. The compression libraries back the archive's compression schemes and the two libtom libraries provide the arithmetic and cipher support the encryption schemes need.
How do I use StormLib in my own project?
Include the main header with #include <StormLib.h> and compile with -lstorm -lz -lbz2. On Windows the README explains the library naming convention, where X is Debug or Release, Y is ANSI or Unicode, and Z is static or dynamic CRT.
How do I build StormLib with Conan on any platform?
Run conan install with -of build and --build=missing, then configure CMake with STORM_USE_BUNDLED_LIBRARIES=OFF, WITH_BUNDLED_LIBTOMCRYPT=ON and the generated toolchain file. The libtomcrypt option is required because libtomcrypt is not yet packaged in the Conan Index.
How do I produce deb and rpm packages from StormLib?
From the build directory, run cpack with the DEB generator and then with the RPM generator. The README also documents the CMake option STORM_BUILD_TESTS, which compiles the StormLib test application.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/ladislav-zezula-stormlib)Was this useful?