GWToolbox++

A set of tools for Guild Wars Players

If you are here to check toolbox features or for a download link, go to https://gwtoolbox.com. Stay here and keep reading for information on how to download and build from source.

How to download, build, and run

Requirements

• Visual Studio 2026 version 18.0+. You can download Visual Studio Community for free. You will also need the "Desktop development with C++" package.
• C++23 compatible v144 MSVC Platform Toolset
• Windows 11 SDK
• CMake 3.29 or higher. This is integrated in the Visual Studio Developer PowerShell. Alternatively download the latest version from https://cmake.org/download/.
• vcpkg. This is integrated in the Visual Studio Developer PowerShell. Alternatively download the latest version from https://github.com/microsoft/vcpkg/releases/.
• Git

1. Open Visual Studio Developer PowerShell. Use all the following commands:

2. Clone the repository: git clone https://github.com/gwdevhub/GWToolboxpp.git

3. Navigate to the GWToolboxpp folder: cd GWToolboxpp

4. Build: cmake --preset=vcpkg

5. Open: cmake --open build

6. Build the solution. cmake --build build --config RelWithDebInfo

7. Run.

Building on Linux

clang targets i686-pc-windows-msvc directly, linking with lld-link, against MSVC CRT and Windows SDK headers/libs fetched by xwin from Microsoft's official installer manifests. Nothing Microsoft-built ever executes, so no Wine is involved and builds run at full -j. The twelve SM3 shaders are compiled by vkd3d-shader in place of fxc.exe, since fxc is the only Microsoft compiler still emitting shader model 1-3 and dxc dropped everything below SM6.

With Docker - the only requirement is Docker:

./scripts/build-xwin.sh

The first run builds the image (downloads the SDK headers/libs and builds vkd3d, expect it to take a while), then configures and builds GWToolboxdll into bin/GWToolboxdll.dll. Later runs reuse the cached image and only rebuild changed files.

Options (see ./scripts/build-xwin.sh --help):

• --target <name> - build a different CMake target (default: GWToolboxdll; use all for everything)
• --config <Debug|RelWithDebInfo|Release> - CMake config to build (default: RelWithDebInfo)
• --jobs <n> - parallel build jobs (default: all cores)
• --shell - drop into a shell in the build container instead of building
• --rebuild-image - force a clean rebuild of the Docker image

The container runs as root; the script hands ownership of anything it writes back to your user once done. Build output lives in build-xwin/ (gitignored) - delete it for a fully clean reconfigure, e.g. after switching --config or branches.

On a Windows host, scripts\build-xwin.ps1 drives the same container through Docker Desktop (-Config, -Target, -Jobs, -Shell, -RebuildImage). Use it to reproduce a CI result or to check a change builds clean under clang - for ordinary Windows development build with Visual Studio or build-clang.bat instead.

Directly on the host - needs clang 19 or newer (the MSVC STL rejects older ones outright with error STL1000; note Ubuntu 24.04 still ships 18), lld, llvm (for llvm-rc/llvm-lib/llvm-mt), cmake >= 3.29, ninja, python3, and a bootstrapped vcpkg in $VCPKG_ROOT. Some distros do not ship a clang-cl; it is the same binary as clang selected by name, so ln -s $(command -v clang) /usr/local/bin/clang-cl is enough.

./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)"

Caveats: vkd3d-shader has no SM1-3 optimiser, so the shader bytecode is longer than fxc's (register allocation is unaffected). Releases are still cut on Windows with MSVC - validate rendering changes in-game before shipping a clang-built DLL.

Notes

• GWToolbox compiles as a DLL (GWToolboxdll.dll) and EXE (GWToolbox.exe). The exe lets you select a Guild Wars Client and injects the dll, but you can also use other dll injectors of your choice.
• By default, the launcher (GWToolbox.exe) will run the GWToolboxdll.dll in the same folder, if there is none, it will inject the one in your installation folder.
• You can use the Visual Studio debugger directly to be able to break and step through toolbox code. First launch toolbox in debug mode as normal, then go to Debug -> Attach to process, then select the Gw.exe process and click Attach. You can also attach the debugger before running toolbox, to debug issues during launch, but then you will have to manually launch toolbox from outside visual studio, either with GWToolbox.exe or AutoItLauncher/inject.au3.

How to contribute

• Create a new branch and commit the changes relevant to your contribution. Please make sure you don't commit unrelated lines.
• Run clang-format and clang-tidy on the code you wrote. .clang-tidy and .clang-format files are in the root of the repository.
• Finally, submit a pull request and let us review your code. Stay updated in the pull request page for feedback and comments.

Quick code overview: There are three main kinds of Toolbox components: Modules, Widgets and Windows. Any new code is most likely an additional one of those, or some change in one.

• Modules are components without an interface, but they do have a panel in Settings.
• Widgets are visual elements without an explicit window (border, header, etc).
• Windows are visual elements with an explicit window.

Both Widgets and Windows can also have a panel in Settings, and share common code in ToolboxUIElement, which handles saving of position, visibility, etc. If you wish to create a new window/widget, please take a look at how similar ones have already been implemented.

Important: The destruction chain is as follows: SignalTerminate -> Terminate -> Destructor. Make sure to handle all destruction logic that uses other modules or interfaces with GWCA in SignalTerminate, Terminate to revert any changes to the game and only use the destructor for class scope clean up.

Plugins

Toolbox supports plugins, meaning you can extend Toolbox functionality. Please take note that plugins are currently a beta feature - plugins compiled for one version of toolbox should continue working, but may have to be recompiled

For users: put the plugin into GWToolboxpp/<Computername>/plugins If you use plugins that aren't compatible with your Toolbox version, you might experience crashes.

For developers: there are a few things you should take note of:

• Two examples (Clock and InstanceTimer) will automatically be added to the solution (see CMakeLists.txt)
• Your Plugin::Initialize must call ToolboxPlugin::Initialize(ctx, fns, tbdll), otherwise you must take care of creating and destroying your own ImGui context.
• We do not guarantee API stability between versions
• If you wish to draw in your plugin, inherit from ToolboxUIPlugin. It will automatically initialise GWCA access for you (GW::Initialize()). If you create a plugin that inherits from ToolboxPlugin, you must manage that yourself. If you use GWCA, make sure the GW::Scanner points to GW.exe at the end of Plugin::Initialize().

Credits

HasKha

• Original creator of GWToolbox++.

KAOS

• Original creator of the GW API used, reverse engineering work.
• Several minor additions.

Ziox

• Implementation of the vast majority of the chat-based features, such as custom chats and the chat timestamps.
• Major contributor to the GW API used, reverse engineering work.

Jon

• Implemented many new features and improvements.
• Major contributor to the GW API used, reverse engineering work.
• Current maintainer of the project.

Marc

• Implemented many new features and improvements.
• Code quality improvements.

Itecka

• Original creator of a damage monitor, which inspired the toolbox damage monitor.
• Created the original implementation of the Cursor Fix.

Misty/DarkManic

• Extensive work on the site and documentation.

Everyone who proposed a PR

and everyone suggesting ideas!

All images in resources/icons are from www.flaticon.com

Sponsors

• The community of users who donate. All proceeds are invested only into server-costs, visible on OpenCollective, we do not pay ourselves.