24,515 Functions Later: The 3.3.5a Client Is 90 Percent Decompiled

By Indie Kings | October 15, 2026

Updated October 15, 2026: The wowdecomp project has reconstructed 24,515 of 27,157 functions from the 3.3.5a client build 12340, which is 90.3 percent of functions and 93.2 percent of code bytes per the official repository README. This article describes that decompilation research and what the numbers cover.

Scope note: This is decompilation research coverage, not a play guide. The repository ships no game data and no binaries, and you need your own legal 3.3.5a client to use it. This article contains no binary or download links beyond the Sources link to the repository, and it describes the build rather than directing you through each command.

Image: wowdecomp repository card. Credit: GitHub, SatyPardus.

What wowdecomp is

Per the official repository README, wowdecomp is a C++ decompilation of the World of Warcraft 3.3.5a client, specifically the file named Wow.exe at build 12340 from June 2010. The project rebuilds the client as readable C++ source code instead of leaving it as machine code inside a binary. That distinction matters because machine code executes but explains little, while reconstructed source code can be read, searched, and studied function by function.

The README attributes the work to community reverse engineering effort, and it names Blizzard as the maker of the original client without hosting any of the original game data. The repository contains reconstructed code and build instructions, and it pointedly excludes the Data folder contents that a real client install provides. That separation is the load bearing fact for anyone evaluating the project, since the code is research output and the game data stays with the reader and their own legal copy.

The chosen target is deliberate. Build 12340 of the 3.3.5a client sits at the end of the second expansion era of the game, which makes it a stable and widely studied reference point for client behavior. The README states the decompilation target as that exact binary, so every progress figure in this article traces back to that single measured executable. Readers should treat any claim about a different build as out of scope unless the repository itself adds one later.

The project also keeps the original structure visible. Per the README, the source tree follows the layout of the original client, with engine code under one path and game code under another, keeping original module groupings and file names where they are known. That choice turns the repository into a map of the original program as well as a rebuild of it, because a reader can compare a reconstructed file against the corresponding region of the original binary.

Two build flavors exist. Per the README, x64 is the main target, while Win32 still builds and serves as a check on struct layouts against the 32 bit original. That dual target setup is common in decompilation work, where the older 32 bit layout acts as a reference for memory shapes even after the primary effort moves to 64 bit. The practical result is that contributors can validate data structure sizes on Win32 while doing most feature work on x64.

The output of the build is a client executable produced from the reconstructed source. Per the README, the build writes its results into a binary output folder, with separate names for the 64 bit and 32 bit products. One named target adds a crash logger that opens a console window and writes a crash log file, while the plain target is the same client without that helper. That logger exists for development and debugging, not for gameplay advantage, and the README documents a build option to turn it off.

Configuration options stay small and legible. Per the README, there are three documented CMake options covering signature check behavior, the crash logger, and an output name override. The signature check option lets modified game data and interface files load, which is the kind of switch that matters to researchers testing altered assets against their own installs. Each option has a stated default, so a reader can predict build behavior before changing anything.

Attribution in this article stays with the primary source throughout. Every figure, path, requirement, and build behavior below comes from the official repository README as fetched for this article, and the standing line Per README marks the tables that restate its numbers. Where the README is silent, this article says so instead of filling the gap with outside claims.

Progress measured October 15 2026

Per the official repository README, progress was measured against the 12340 binary on October 15, 2026, which is the same date as this article. A function counts as ported when its address is tagged in the source, which gives the headline numbers a concrete and checkable meaning. A claim of completion here does not mean polished or refactored code, since it means the function exists in reconstructed form at its original address.

The headline figures are strong. Per the README, 24,515 of 27,157 functions are ported, which the project reports as 90.3 percent. Code bytes run slightly higher, at 5,270,186 of 5,656,573 bytes, reported as 93.2 percent. The gap between the two percentages is itself informative, since it suggests the ported functions cover a larger than average share of code volume.

The totals already exclude two categories. Per the README, the total leaves out 658 functions that IDA identifies as compiler library code plus 132 import thunks. That exclusion keeps the progress figures focused on code the project actually intends to reconstruct, rather than padding or penalizing the count with linker level artifacts. Readers comparing this project to others should check whether competing counts apply the same exclusion before treating percentages as comparable.

The byte count deserves a short explanation for non programmer readers. Functions are the named units of work inside a program, while code bytes measure how much machine code those functions contain. A project can port most bytes while leaving many small functions unported, or port most functions while leaving a few large ones behind. Here both measures sit above 90 percent, so the project is past the point where either measure alone could mislead.

Progress at this level changes the character of the remaining work. Early in a decompilation, each newly ported function can unlock large regions of behavior, while late stage work tends to grind through repetitive or generated code with lower research value per function. The README anticipates exactly that reading by describing the remainder as mostly generated code, runtime helpers, and third party libraries linked from upstream sources.

The date on the measurement matters for citation. Because the README dates the measurement to October 15, 2026, any later change in the repository may move the numbers without warning. This article freezes the figures at that date, and readers who need current totals should consult the repository directly through the Sources link. That is also why the tables carry the standing line Per README instead of presenting the numbers as independently verified by this site.

How each function stays verifiable

The central verification mechanism is simple and public. Per the README, every function is reconstructed from the original binary and keeps the address it came from in an address tag, so each one can be compared against the original. In practice that means a reader with a legal copy of the original binary can take a reconstructed function, note its tagged address, and check the corresponding bytes in the original.

That design answers the hardest question about any decompilation, which is how a reader knows the reconstructed code matches the original program. A project without address tags asks for trust, while a project with per function address tags invites checking. The tag does not prove correctness by itself, but it makes every correctness claim testable, which is the practical definition of research transparency here.

The tree layout reinforces the same checkability. Per the README, the source tree follows the layout of the original client with engine and game groupings and original file names. A reader who knows which module handles rendering, sound, scripting, or networking can navigate straight to the matching directory instead of searching the whole repository. That grouping also preserves context, since neighboring files in the original tend to cooperate at runtime.

The dual target strategy adds a second layer of checking. Per the README, x64 is the main target while Win32 still builds and is used to check struct layouts against the 32 bit original. Struct layouts are the exact memory shapes the program uses for its data, and even a small size error can shift every field that follows. Keeping a 32 bit build alive gives contributors a reference that matches the original program and word size, which catches layout drift before it spreads.

The README also describes the role of IDA in scoping the totals, since 658 functions are excluded because IDA identifies them as compiler library code. Naming IDA in prose matters because it tells readers which industry standard disassembler informed the classification, without implying that any single tool did the reconstruction alone. The import thunk exclusion follows the same logic, since thunks are linker generated stubs rather than hand written program logic.

None of this means the reconstruction is finished or flawless. A tagged function can still contain a subtle behavioral difference from the original, and late stage functions may need revision as neighboring code gets understood better. What the system does guarantee is traceability, because each function carries its provenance in the source itself. Future fixes can cite the same addresses, so corrections accumulate instead of restarting the work.

What the remainder consists of

Per the README, most of what remains is compiler generated code such as static initializers and template instances, plus C runtime helpers and third party libraries that are linked from their upstream sources instead of being decompiled. Each of those categories has a different reason for sitting outside the reconstructed core. Generated code is voluminous but low in research value, runtime helpers belong to the toolchain rather than the game, and third party libraries already have canonical sources elsewhere.

Static initializers deserve a brief gloss. These are small routines the compiler emits to set up program state before the main logic runs, and they tend to look alike across large codebases. Porting them by hand adds little understanding while consuming real effort, which is why decompilation projects commonly leave them for last. Their presence in the remainder is therefore a sign of project maturity rather than a gap in coverage of game behavior.

Template instances follow a similar pattern. Modern C++ generates specialized copies of generic code for each type combination it uses, so one template can produce many near identical functions in the final binary. Reconstructing each instance individually would multiply work without multiplying insight, and the README groups them with the rest of the generated remainder. A researcher studying game logic will rarely need to read these copies one by one.

The third party library list is explicit. Per the README, the linked upstream libraries include FreeType, zlib, PCRE, and parts of FMOD Ex, and these are linked from their upstream sources instead of being decompiled. That is the correct engineering call, since reimplementing a standard compression or text shaping library from disassembly would risk subtle incompatibility for zero research gain. Linking the canonical library preserves behavior while keeping the reconstructed tree focused on game and engine code.

The FMOD Ex wording carries a useful nuance. Per the README, only parts of FMOD Ex fall in this category, which implies the audio integration code that belongs to the game itself is still in scope for reconstruction. Readers should not read the third party paragraph as saying that all sound code is outsourced, since engine sound modules remain part of the reconstructed tree. The distinction is between the external sound library and the game code that calls it.

Taken together, the remainder profile reads like a project approaching its natural boundary. The reconstructed core covers the game and engine logic that researchers actually want to read, while the unported remainder clusters in generated code, toolchain helpers, and canonical libraries. That is why the byte percentage can sit at 93.2 percent while the most interesting behavioral questions are already addressable in source form.

Requirements

Per the README, the requirements assume a Windows development machine with modern Microsoft tooling. The operating system floor is Windows 10 or 11, and the compiler toolchain is Visual Studio 2022 with the desktop C++ workload, which supplies the MSVC compiler version named v143 plus a Windows SDK. Those two lines alone tell most readers whether their machine qualifies before they read further.

The build orchestration relies on CMake at version 3.10 or newer, and the README notes that the copy shipping with Visual Studio works. That detail removes a common setup trap, since readers do not need to hunt for a separate CMake install when their compiler already bundles a new enough copy. Version floors like this one matter because older build planners may not understand the project files.

One requirement applies only to 32 bit builds. Per the README, Win32 builds need the NASM assembler available on the search path or passed in as a configured path, plus a specific decoder library file copied from the reader and their own 3.3.5a client into a third party folder. The 64 bit build instead uses its own decoder, so most readers following the main x64 target never touch that step. That split is worth stating plainly because it keeps x64 readers from installing tools they do not need.

The final requirement is the legal and practical key to the whole project. Per the README, the reader supplies their own World of Warcraft 3.3.5a build 12340 client, and no game data is included in the repository. That single sentence carries the scope of this article, since everything the repository teaches still needs the reader and their own data to run. Nobody should expect a working game from the repository alone.

The table above restates the README without adding setup advice beyond it. Readers who meet every row can treat the repository as buildable in principle, while readers missing any row should resolve that gap first. The game data row deserves a second reading, since it is both a requirement and a scope boundary for the project.

Building and running in plain terms

Per the README, the build starts from a shell where the CMake tool is available, such as a developer shell shipped with Visual Studio. The reader clones the repository, then configures a separate build directory rather than building inside the source tree, because in source builds are refused. That refusal is a small quality guard, since it keeps generated files from polluting the reconstructed source.

The README documents one configured target for 64 bit and one for 32 bit, each using the Visual Studio 2022 project generator with the matching architecture. The named client target builds the crash logger variant, while a second shorter target name builds the same client without the logger. Build parallelism is supported, so multi core machines can compile faster, though the README does not promise any specific build time.

The outputs land in a binary folder with distinct names per architecture. Per the README, the logger variant produces one executable name on x64 and a parallel name on Win32, while the plain variant uses the shorter classic names on each architecture. That naming keeps the two architectures from overwriting each other and keeps the logger variant visibly separate from the plain one.

The crash logger itself is modest and legible. Per the README, the logger variant opens a console window and writes a named crash log file when the client crashes, and a documented build option turns that logger off. That behavior targets debugging rather than normal play, since a visible console and a log file are exactly what a contributor wants when a reconstructed function misbehaves. Readers who only want to study code can safely ignore this target distinction.

Running the built client needs the reader and their own data once more. Per the README, the reader copies the Data folder from their own 3.3.5a client into the binary output folder so the expected Data path exists, then points a realmlist file at the chosen server and starts the matching executable. This article describes that sequence without reproducing server addresses or setup commands, since connection choices belong to the reader and their own legal environment.

The three documented build options adjust narrow behaviors. Per the README, one option skips signature checks on data and interface files so modified assets load, one toggles the crash logger, and one renames the logger executable. The defaults keep signature checks on and the logger on, with no rename applied. Readers should treat the signature check option as a research switch with consequences for asset integrity rather than as a general recommendation.

Source tree layout

Per the README, engine modules live under an Engine Source path and cover systems such as Storm, Gx with Direct3D 9 and OpenGL support, Model2, Frame and FrameXML user interface code, SoundEngine, Lua, and more. Game modules live under a game Source path and cover objects, world rendering, user interface, networking, database code, and glue screens, with shared game code in a Common folder. That split mirrors how the original client separates reusable engine systems from game specific logic.

The engine list rewards a slow reading. Storm is the low level utility layer that classic Blizzard client architecture is known for, Gx abstracts graphics device work across Direct3D 9 and OpenGL paths, Model2 handles game models, Frame and FrameXML implement the scriptable interface system, SoundEngine carries audio, and Lua embeds the scripting language that interface code uses. Per the README these all sit under the engine grouping, so a reader studying one subsystem can find its neighbors without guessing.

The game grouping covers the parts players actually see. Objects, world rendering, interface behavior, networking, database access, and glue screens are the systems that turn engine services into a living client, from the login flow through the game world. Per the README these sit under the game source path with shared code factored into a Common folder, which keeps cross module helpers in one discoverable place.

Third party code is fenced off rather than scattered. Per the README, libraries linked from upstream sources live under a ThirdParty path, which keeps canonical external code visibly separate from reconstructed game code. That fencing helps reviewers trust the reconstruction boundary, since anything under the third party path is declared as external rather than claimed as decompiled output.

Two tool folders round out the tree. Per the README, one tool path holds the logger executable target and another holds the 64 bit movie decoder that replaces the original 32 bit decoder library. The decoder replacement is a neat case study in porting pragmatism, since the project substitutes a working 64 bit equivalent where the original binary dependency cannot follow the architecture jump. Readers studying media playback should start in that tool folder and trace its callers.

The layout table in the README is compact, and its value lies in orientation rather than completeness. New readers should treat the listed paths as entry points and then follow includes and calls to map the full dependency graph. Because file names track the original client, even a partial map transfers directly to discussion of the original binary.

Why this kind of project matters

Decompilation projects preserve knowledge that binaries alone cannot teach. A shipped executable records what the machine should do, but it hides names, groupings, and intent behind addresses and raw instructions. Reconstructed source restores enough of that intent to let later programmers study decisions, test hypotheses, and document behavior that was previously observable only through black box testing.

The address tag convention raises the value further. Because each function keeps its original address in the source, later research can cite exact locations instead of describing screens or symptoms. That precision compounds over time, since bug reports, structure notes, and behavioral tests can all point at the same tagged function. The repository thus becomes a shared coordinate system for everyone studying that client build.

The struct checking workflow shows unusual care for correctness. Many hobby reconstructions stop at code that compiles and runs, while this project keeps a 32 bit build specifically to check memory layouts against the original. That discipline protects against a class of bugs where the program assembles cleanly but reads the wrong fields at runtime. Readers evaluating reconstruction quality should weigh that checking workflow heavily.

The third party linking policy shows matching judgment. Reconstructing canonical libraries from disassembly would scatter effort and risk behavior drift, while linking upstream sources keeps standard code standard. The README and its explicit library list make that boundary auditable, so reviewers can confirm that external code paths resolve to maintained projects. That choice also keeps the license story cleaner than absorbing foreign code into the tree.

Progress percentages should be read as research milestones rather than product promises. A 90.3 percent function count does not mean the client is 90.3 percent of a shippable product, since build health, runtime stability, and asset compatibility all sit outside the counting rule. What the numbers do mean is that the map of the original program is now nearly complete at function granularity, which is the right unit for continued study.

The requirements list keeps expectations grounded in the same way. A Windows 10 or 11 machine with Visual Studio 2022 and CMake is a mainstream setup for this kind of native code, and the only unusual inputs are the assembler for 32 bit builds and the reader and their own game data. Nobody needs exotic hardware to read the source, while running the built client still demands a legal data set. That split between reading and running is the healthiest way to approach the project.

Finally, the special thanks section of the README points at a wider community of related projects and contributors, including an initial database credit and the broader modding community. This article does not repeat those links, per the scope rule that keeps the repository as the single outbound reference, but the acknowledgment itself signals that the work builds on shared tooling and prior analysis. Readers who want the full credit list will find it in the primary source.

FAQ

What exactly is wowdecomp?

Per the official repository README, it is a C++ decompilation of the 3.3.5a client file Wow.exe at build 12340, with each reconstructed function tagged by its original address. It is research source code, not a game download.

How complete is the decompilation as of October 15 2026?

Per the README measurement dated that day, 24,515 of 27,157 functions are ported for 90.3 percent, and 5,270,186 of 5,656,573 code bytes are ported for 93.2 percent. The totals exclude 658 compiler library functions and 132 import thunks.

Can a reader verify an individual function?

Yes, per the README each reconstructed function keeps its original address in an address tag so it can be compared against the original binary. A reader with their own legal client copy can check the tagged location directly.

What do you need to build or run it?

Per the README you need Windows 10 or 11, Visual Studio 2022 with the desktop C++ workload, and CMake 3.10 or newer, plus your own legal 3.3.5a client data. Win32 builds additionally need the NASM assembler and a decoder file from your own client.

Does the repository include the game or its data?

No, per the README no game data is included in the repository. You must supply your own legal 3.3.5a build 12340 client files to run anything.

What is left unported?

Per the README the remainder is mostly compiler generated code, C runtime helpers, and third party libraries such as FreeType, zlib, PCRE, and parts of FMOD Ex that are linked from upstream sources. Those categories sit outside the reconstructed core by design.

Bottom Line

Per the official repository README, wowdecomp has reconstructed 90.3 percent of functions and 93.2 percent of code bytes from the 3.3.5a build 12340 client, with per function address tags keeping every claim checkable. The repository ships no game data, needs your own legal client, and builds primarily for x64 with Win32 kept for struct checks. For research readers that combination of near complete coverage and explicit provenance is the story, and the Sources link below is the single place to read further.

Sources

Per the official repository README, all figures, paths, requirements, and behaviors in this article come from the primary source: wowdecomp repository README. No game data, binaries, or downloads are linked in this article beyond that source reference.