GWToolbox++: a DLL injected into the Guild Wars client, buildable on Linux

A DLL and a launcher that puts it inside the game

GWToolbox++ is a set of tools for Guild Wars players, and the interesting thing about how it delivers them is the mechanism.

The project compiles as two artefacts, a DLL named `GWToolboxdll.dll` and an executable named `GWToolbox.exe`. The executable lets you select a Guild Wars Client and injects the DLL into it, and the documentation is explicit that you can use other DLL injectors of your choice instead. By default the launcher runs the `GWToolboxdll.dll` sitting in the same folder, and if there is none there it will inject the one in the installation folder instead.

That is the whole architecture in one paragraph. The toolbox is not a separate application that runs alongside the game, and it is not a mod installed into the game directory. It is code loaded into the running client process, which is why it can draw panels over the game and read the game's state.

The consequences follow from that. The tools work on a live game client, so a game patch can break them, and the debugging story is a process attachment story. The documentation explains how to use the Visual Studio debugger directly to break and step through toolbox code: launch toolbox in debug mode as normal, then Debug, Attach to process, select the Gw.exe process and click Attach. You can also attach before running toolbox to debug issues during launch, in which case you have to launch toolbox manually from outside Visual Studio, either with `GWToolbox.exe` or with the `AutoItLauncher/inject.au3` script.

The repository is hosted under the `gwdevhub` organisation, is written in C++, and is MIT licensed.

Modules, widgets and windows, and one destruction rule

The code overview in the readme is short and it is the best guide to the codebase. There are three main kinds of Toolbox components: modules, widgets and windows, and any new code is most likely an additional one of those or a change to one.

Modules are components without an interface, but they do have a panel in Settings. Widgets are visual elements without an explicit window, no border or header of their own. Windows are visual elements with an explicit window. Both widgets and windows can also have a panel in Settings, and they share common code in `ToolboxUIElement`, which handles saving of position and visibility. The readme asks contributors creating a new window or widget to look at how similar ones were implemented, which is a fair description of the project's architecture style: a set of comparable implementations rather than a framework with a plugin API for the interface layer.

The one rule that is called out as important is the destruction chain, `SignalTerminate` to `Terminate` to `Destructor`. The instruction is to handle all destruction logic that uses other modules or interfaces with GWCA in `SignalTerminate` and `Terminate`, in order to revert any changes to the game, and to use the destructor only for class scope clean up.

That constraint comes from the host environment. Because this code runs inside another process, the order in which it undoes its changes to the game matters, and the three-phase chain exists so that a module can still talk to its peers while it is unwinding.

The Visual Studio build, in five commands

The requirements list for the Windows build is specific and modern: Visual Studio 2026 version 18.0 or newer with the Desktop development with C++ package, a C++23 compatible v144 MSVC Platform Toolset, the Windows 11 SDK, CMake 3.29 or higher, vcpkg, and Git. The documentation notes that CMake and vcpkg are both integrated into the Visual Studio Developer PowerShell, with download links given for each if you would rather install them separately.

The build sequence runs in the Visual Studio Developer PowerShell:

git clone https://github.com/gwdevhub/GWToolboxpp.git
cd GWToolboxpp
cmake --preset=vcpkg
cmake --open build
cmake --build build --config RelWithDebInfo

The `cmake --preset=vcpkg` step is what pulls in the dependency configuration, and the repository carries `vcpkg.json`, `vcpkg-configuration.json` and a `vcpkg-overlays/` directory, which is how a project pins dependency versions and applies local overlay packages. The `Dependencies/` directory at the root holds the vendored pieces the project builds itself.

The `RelWithDebInfo` configuration is the one named in the instructions, which makes sense for a tool that people are expected to attach a debugger to. There is also `CMakePresets.json` and `CMakeSettings.json` for Visual Studio integration, and a `build-clang.bat` script for a clang-based Windows build.

Cross-compiling for Windows from Linux with xwin and vkd3d-shader

The Linux build path is the most unusual thing in the repository, and it exists for a specific reason.

The mechanism is that `clang` targets `i686-pc-windows-msvc` directly, linking with `lld-link`, against the MSVC CRT and the Windows SDK headers and libraries fetched by xwin from Microsoft's official installer manifests. The documentation is explicit that nothing Microsoft-built ever executes, so no Wine is involved, and builds run at full parallelism. That last point is the payoff: a CI machine or a container can produce a Windows binary without a Windows licence and without a virtual machine.

The second half of the problem is shaders. The twelve SM3 shaders are compiled by vkd3d-shader in place of `fxc.exe`, and the reason given is that `fxc` is the only Microsoft compiler still emitting shader model 1 to 3, while `dxc` dropped everything below SM6.

The container path needs only Docker:

./scripts/build-xwin.sh

The first run builds the image, downloading the SDK headers and libraries and building vkd3d, and the documentation warns to expect it to take a while. Later runs reuse the cached image and rebuild only changed files. The output is `bin/GWToolboxdll.dll`, and the build directory `build-xwin/` is gitignored, so deleting it gives a clean reconfigure, which is what you want after switching configuration or branches.

On a Windows host, `scripts\build-xwin.ps1` drives the same container through Docker Desktop, and the documentation positions it as the way to reproduce a CI result or to check that a change builds clean under clang, rather than as the ordinary Windows development path.

The container build has switches, and the host build has a floor

The build script exposes its options directly, which is worth reading before you start, because a full SDK download is not something to trigger by accident.

The options for `./scripts/build-xwin.sh` are a target, which defaults to `GWToolboxdll` and accepts `all` for everything; a config of `Debug`, `RelWithDebInfo` or `Release`, defaulting to `RelWithDebInfo`; a jobs count, defaulting to all cores; a `--shell` option that drops into a shell in the build container instead of building; and `--rebuild-image` to force a clean rebuild of the image. The container runs as root and the script hands ownership of anything it writes back to the user when it finishes.

Building directly on the host rather than in the container has a harder floor. The documentation lists `clang` 19 or newer, with the reason spelled out: the MSVC STL rejects older ones outright with `error STL1000`, and Ubuntu 24.04 still ships 18. You also need `lld`, `llvm` for `llvm-rc`, `llvm-lib` and `llvm-mt`, `cmake` 3.29 or newer, `ninja`, `python3`, and a bootstrapped `vcpkg` in `$VCPKG_ROOT`. Some distributions do not ship a `clang-cl`, and the workaround given is that it is the same binary as `clang` selected by name, so a symbolic link is enough.

The host sequence is:

./scripts/xwin/setup-toolchain.sh          # one-off: SDK (~800MB) + vkd3d-compiler
export XWIN_SDK="$PWD/.xwin-toolchain/xwin-sdk"
export VKD3D_COMPILER="$PWD/.xwin-toolchain/vkd3d-1.19/vkd3d-compiler"
cmake --preset xwin -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build build-xwin -j"$(nproc)"

The toolchain setup is a one-off that pulls roughly 800MB of SDK, and the vkd3d version is pinned in the path, which tells you this is a known-good combination rather than a moving target.

A clang-built DLL is not what ships

The caveats section in the readme is short and it changes how you should use the Linux build path.

The first is that vkd3d-shader has no SM1-3 optimiser, so the shader bytecode is longer than `fxc`'s, with register allocation unaffected. The second is the one that matters for a release: releases are still cut on Windows with MSVC, and rendering changes should be validated in game before shipping a clang-built DLL.

That is a reasonable position and it tells you exactly what the cross-build is for. The clang and xwin path is there to make CI cheap, to let contributors check that a change builds without a Windows licence, and to reproduce a CI result. It is not the release path, and a change that touches rendering has to be checked on the real compiler before it goes out.

The two facts together mean a bug in the shader compiler path can pass CI and fail on the user's machine, and the mitigation is in the workflow rather than the code: build with MSVC, test in game, then cut the release.

The repository also carries an `AutoitLauncher/` directory, an `UPDATE.md`, a `deploy.bat` and a `deploy.py` for the release packaging, a `RestClient/` directory, `bake_pathing/` for the pathing textures, a `site/` directory for the website, and `plugins/` for the plugin system, plus `AGENTS.md` and `CLAUDE.md` for tooling support.

The plugin system is a beta, and the whole thing hooks a game process

The plugin system is the extension point, and the documentation labels it plainly. Toolbox supports plugins, meaning you can extend Toolbox functionality, and it asks you to note that plugins are currently a beta feature: plugins compiled for one version of toolbox should continue working, but may need to be recompiled.

That caveat is the whole story of the extension model. There is no compatibility guarantee, so a plugin is a source-level dependency on a specific toolbox version, and a toolbox update can require rebuilding every plugin in the ecosystem.

The second limitation is the nature of the host. A toolbox that injects a DLL into a running game client is, by construction, sensitive to the client changing. A game patch that alters the client binary can break the injection or the memory offsets the tools rely on, and the release line here is a series of numbered builds, 8.34_Release with 8.34_Beta3 and 8.34_Beta4 before it, dated through late September and October 2026, with the last push to the repository on 2026-10-15. The version names are tied to the toolbox release cycle, and the betas preceding the release suggest the project tracks changes to the game closely.

For an evaluation, that means the tool is a community-maintained overlay for a specific game, not a general product, and the cost of ownership falls on whoever maintains it when the game updates. The licence is MIT, and the contribution guidance is conventional: a branch per change, clang-format and clang-tidy on the code you write, with both configuration files in the repository root, and a pull request for review.

Editorial conclusion

GWToolbox++ fits a Guild Wars player who wants extra panels, keybinds and window management inside the game client, and it fits a contributor who wants to build and debug the DLL on either operating system. It does not fit a team that needs a supported, stable extension API, because the plugin system is documented as a beta feature, and it is the wrong choice if you cannot accept a build that hooks a running game process. Before you ship a clang-built DLL, note the project's own instruction that releases are still cut on Windows with MSVC and that rendering changes should be validated in game, since the vkd3d-shader path produces longer shader bytecode than `fxc`.

Frequently asked questions

Official sources

1. gwdevhub/GWToolboxpp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases