Type “how do I play Windows games on my Android phone” into Google in September 2026 and three names keep surfacing: Winlator, Box64, and Wine. They get lumped together constantly, but they are not competing products in the way “iPhone vs Android” is. They are three different layers of the same stack, and mixing them up is why so many people install the wrong thing and get 12 FPS in a game that should run at 40. Winlator is the Android app that most people actually launch. Box64 is the x86-64-to-ARM CPU translator doing the heavy lifting underneath it. Wine is the compatibility layer that reimplements the Windows API so a .exe built for Windows can run on Linux, and through Winlator on Android, without a Windows license or a virtual machine.
This matters more in 2026 than it did two years ago because the hardware caught up. Android gaming handhelds built on Snapdragon 8 Gen 3 and Snapdragon 8 Elite silicon are now fast enough that a Steam library built for a 2015 gaming PC is playable, not just bootable, on a device that fits in a jacket pocket. The “winlator” keyword alone pulls over 22,000 monthly US searches, more than most individual Android emulator terms, because it has become shorthand for an entire category of software rather than one app. This guide breaks down what Winlator, Box64, and Wine actually do, how they relate to each other, what changed in their most recent 2026 releases, and which one you should actually be looking at depending on whether you are holding a phone, a Linux handheld, or a Raspberry Pi.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Winlator, Box64, and Wine actually are
The confusion starts because all three get called “emulators” in casual conversation, and technically only one of them is doing anything close to emulation. Wine is not an emulator at all — its name is a recursive backronym for “Wine Is Not an Emulator.” Wine reimplements the Windows API (DLLs like kernel32, user32, d3d11) as a translation layer running directly on the host operating system’s own CPU instructions. On an x86-64 Linux desktop, Wine lets a Windows game run at close to native speed because the CPU instructions in the game’s .exe already match the host CPU architecture; only the API calls need translating.
Box64 is a genuine emulator in the strict sense: it is a userspace binary translator that converts x86-64 machine instructions into ARM64 instructions on the fly, because Android phones and most modern handhelds run on ARM chips, not x86. This is the expensive part of the whole chain, because instruction-set translation carries real CPU overhead that pure API translation does not. Box86 is Box64’s older 32-bit sibling, still relevant because plenty of older Windows games and DirectX 9 titles were compiled as 32-bit binaries.
Winlator is the Android application, originally built by developer Bruno Silva (brunodev85), that packages Wine and Box64/Box86 together with a graphics-translation layer (DXVK for Direct3D 9/10/11 games, VKD3D-Proton for Direct3D 12 titles) into something a non-technical user can install from an APK, tap, and use to launch a Windows .exe on a touchscreen. Without Winlator’s wrapper, running Wine and Box64 together on Android would mean compiling from source and configuring everything by hand in Termux. Winlator’s contribution is the packaging, the container/profile system, and the Android-specific input and driver handling — not the underlying translation engines themselves, which it inherits from the Wine and Box64/Box86 projects and updates as those upstream projects ship new builds.
Latest versions and release dates as of September 2026
All three projects are under active, if uneven, development. Here is where each one stood as of late September 2026, based on their own GitHub release pages.
| Project | Latest version | Release date | Maintainer / repo |
|---|---|---|---|
| Winlator (upstream) | 11.2.0 | August 19, 2026 | brunodev85/winlator on GitHub |
| Winlator prior stable | 11.1 (“Final”) | June 12, 2026 | brunodev85/winlator |
| Winlator Ludashi (fork) | 4.1 | September 13, 2026 | StevenMXZ/Winlator-Ludashi |
| Winlator Ludashi Plus (fork) | 4.0 Update 1 | September 9, 2026 | squalle0nhart/winlator_ludashi_plus |
| Box64 | v0.4.4 | August 7, 2026 | ptitSeb/box64 (box86.org) |
| Wine (upstream) | 11.2.0 (beta) | August 19, 2026 | WineHQ / GitLab |
| Wine prior stable | 11.1 (“Final”) | June 12, 2026 | WineHQ / GitLab |
Two things stand out here. First, the brunodev85/winlator repository is still active — it received a README update on September 22, 2026, and the project is not archived, contrary to some forum chatter that the original developer walked away. Second, the fork situation is genuinely messy. Because Winlator is open source under a permissive license, multiple community teams — Ludashi, Ludashi Plus, WinlatorMali (a fork tuned for Mali-GPU Android devices rather than Adreno), and others — have branched off and now ship their own version numbers on their own schedules. Ludashi Plus, for example, sat 43 commits ahead of and 278 commits behind its longjunyu2/winlator upstream as of its September 19, 2026 commit, which tells you these forks are not simply repackaging the same code with a new coat of paint; they are diverging in real, sometimes incompatible ways. If you search “Winlator” and land on a version number that does not match 11.2.0, you have likely found a fork, not upstream — check the repository name before assuming feature parity.
System requirements for each layer
Because Winlator, Box64, and Wine sit at different layers, their hardware and software requirements do not line up neatly, and skipping this step is the most common reason people give up on the whole stack after one bad first impression.
For Winlator on Android, the practical floor is a device running Android 8 or newer with at least 4GB of RAM, though 8GB or more is what current testing actually recommends for anything beyond light 2D or early-2000s 3D titles. A 64-bit ARM chip is mandatory — Winlator will not run on 32-bit-only hardware at all, since Box64’s entire job depends on 64-bit ARM instructions being available to translate into. Storage matters more than people expect too: a single mid-size Windows game plus its Wine prefix and DXVK cache can easily consume 10-20GB, on top of whatever space the Winlator app itself and its bundled components need.
For Box64 running standalone on a Raspberry Pi 5 or similar ARM single-board computer, the requirements are lighter in absolute terms but the constraint shifts to CPU clock speed and available cores, since there is no mobile GPU driver layer masking a slow CPU the way it sometimes can on a phone. Most Raspberry Pi 5 Box64 use cases target command-line or lightly graphical x86-64 Linux software rather than demanding 3D games, and users report that anything CPU-bound scales close to linearly with the Pi’s clock speed rather than hitting a translation-specific wall.
For Wine on a native x86-64 Linux desktop or Steam Deck, requirements essentially match whatever the Windows game itself demands, since Wine is not adding a CPU-translation tax on top. The practical requirement is disk space for the Wine prefix (typically a few hundred MB to a few GB per game, separate from the game’s own install size) and, for Proton specifically, whatever Vulkan driver support your GPU already needs for native Linux gaming.
How the three pieces fit together
Think of it as a pipeline rather than a menu of three alternatives. A Windows game’s x86-64 instructions hit Box64 first, which translates them to ARM64 instructions the phone’s Snapdragon or MediaTek chip can actually execute. Any call the game makes to a Windows system function — opening a file, allocating memory, rendering a Direct3D frame — gets intercepted by Wine, which reimplements that function using Android’s own underlying Linux kernel and graphics stack. Direct3D calls specifically get routed through DXVK or VKD3D-Proton, which translate Direct3D 9/10/11/12 instructions into Vulkan, the graphics API Android GPUs actually understand. Winlator is the container that holds all of this, presents it as a single tappable app icon, and gives you sliders for resolution, Box64 preset (compatibility vs performance), and which Wine/DXVK build to use per game profile.
Worth flagging explicitly: this is the opposite direction from tools like BlueStacks, NoxPlayer, or GameLoop, which run Android apps on a Windows PC, or the broader category of Android emulators for PC. Winlator, Box64, and Wine solve the reverse problem — running Windows software on Android — and the two categories share almost no code despite both getting called “emulators” in casual search terms.
This is why the “vs” framing is misleading if taken too literally. You cannot meaningfully run “just Box64” and play a modern Windows game, because Box64 alone has no idea what a Windows API call is — it only translates CPU instructions. You cannot run “just Wine” on an ARM Android phone and get anywhere, because Wine expects to be running on the same CPU architecture as the software it is translating. The three-way comparison in this article is really about understanding what each layer contributes, where the performance cost lives, and where each project shows up on non-Android platforms too — because Box64 and Wine both have lives well outside of Winlator.
Winlator vs Box64 vs Wine: full specs comparison
| Category | Winlator | Box64 | Wine |
|---|---|---|---|
| What it actually is | Android app / container wrapping Wine + Box64/86 | x86-64 to ARM64 userspace CPU instruction translator | Windows API compatibility layer (not an emulator) |
| Primary platform | Android (APK) | Linux on ARM (Android, SBCs, ARM laptops) | Linux, macOS, BSD (x86-64 native host) |
| Latest version (Sept 2026) | 11.2.0 (Aug 19, 2026) | v0.4.4 (Aug 7, 2026) | 11.2.0 beta / 11.1 stable |
| License | Open source (community forks add own terms) | MIT | LGPL |
| CPU translation needed? | Yes, bundles Box64/Box86 | N/A — it is the CPU translator | No, assumes matching host CPU architecture |
| Graphics translation | Bundled DXVK / VKD3D-Proton per profile | None (CPU layer only) | Relies on external DXVK/VKD3D or native OpenGL/Vulkan |
| Typical performance overhead | Highest (CPU translation + API translation + mobile GPU driver) | Significant on its own (instruction-set translation) | Low to none on matching-architecture x86-64 Linux |
| Best-case use scenario | Playing a Windows PC game on an Android phone/handheld | Running x86-64 Linux software on an ARM SBC or ARM laptop | Running a Windows game on a Linux or Steam Deck-class x86-64 PC |
| Setup difficulty | Low — install APK, add container, launch | Moderate — usually bundled inside another tool (Winlator, Box64 Droid, distro packages) | Low on Linux desktop (Bottles, Lutris, Proton all wrap it); moderate raw |
| Community fork activity | High (Ludashi, Ludashi Plus, WinlatorMali, others) | Low — single upstream project | Low upstream; heavily forked downstream as Proton/Proton-GE/CrossOver |
| Cost | Free | Free | Free (CrossOver is a paid commercial wrapper) |
The single most important row in that table is “performance overhead.” Every translation layer you stack costs frame rate, and Winlator on Android stacks three of them: CPU instruction translation (Box64), Windows API translation (Wine), and graphics API translation (DXVK/VKD3D-Proton) — all running on top of a mobile SoC that is already thermally constrained compared to a desktop GPU. That is the fundamental reason a game that runs at 90 FPS on a mid-range gaming PC might land at 30-40 FPS through Winlator on even a flagship Snapdragon 8 Elite handheld. Wine alone, running x86-64 code on an x86-64 Linux desktop, skips the CPU-translation cost entirely, which is why Steam Deck-class devices running Proton (itself a Valve-maintained Wine fork) get so much closer to native Windows performance than any Android Winlator setup can.
Performance benchmarks: what real testing shows
Reliable, apples-to-apples benchmark data across all three layers is hard to find because most public testing bundles Box64 and Wine together inside Winlator or a Winlator-based app, rather than isolating each layer. With that caveat, here is what independent 2026 testing has shown for real games running through the Winlator stack on current Android hardware, alongside what Wine achieves on matching-architecture Linux hardware for context.
| Game | Platform / chip | Stack | Settings | Reported FPS |
|---|---|---|---|---|
| The Witcher 3 | AYANEO Pocket S2 Pro (Snapdragon 8 Gen 3) | Winlator, no driver tuning | 720p Medium | 30-40 FPS |
| The Witcher 3 | Same-class Snapdragon 8 Gen 3 handheld | Winlator CMOD, spoofed device settings | 720p Medium | 55-60 FPS |
| Dark Souls 3 | AYN Odin 2 Portal (Snapdragon 8 Gen 2) | GameNative (Winlator-based app) | 720p | 20-25 FPS |
| Firewatch | AYN Thor | Winlator | Default | Listed as “stable” — no FPS figure published |
| Grand Theft Auto V | Snapdragon 8 Elite handheld | Winlator | 720p Normal | 40+ FPS |
| Cyberpunk 2077 | Snapdragon 8 Elite handheld | Winlator | Reduced settings | Generally under 30 FPS — described as demanding, not smooth |
| Windows x86-64 apps (general) | x86-64 Linux desktop / Steam Deck | Wine / Proton, no ARM translation needed | Native-architecture | Typically 85-98% of native Windows performance per Valve/ProtonDB community data |
Two conclusions come out of this data cleanly. First, spoofing device information and tuning graphics settings inside the Winlator container profile — what testers call “driver mastery” — can nearly double frame rates in the same game on the same hardware, which means two people reporting wildly different Winlator experiences for the same title are often just running different configurations, not different silicon. Second, the performance gap between Wine on matching-architecture x86-64 Linux and Winlator on ARM Android is not small. Wine/Proton on Steam Deck-class hardware routinely reaches 85-98% of native Windows frame rates because it only pays the Windows-API-translation tax. Winlator on Android pays that same tax plus a CPU-architecture-translation tax via Box64, plus a graphics-translation tax, which is why even a flagship phone chip struggles to hit 40 FPS in a nine-year-old open-world game that a five-year-old gaming laptop runs at 100+.
Fork drama and where the ecosystem stands in September 2026
The Winlator community has spent much of 2026 fragmenting rather than consolidating, and it is worth understanding why before you pick a download link from a random forum post. The original brunodev85/winlator project remains active — commits landed as recently as September 22, 2026 — but it is no longer the only game in town, and it may not even be the most feature-rich option depending on your specific device’s GPU vendor.
WinlatorMali exists specifically because Adreno GPUs (found in most Snapdragon chips) and Mali GPUs (common in MediaTek and some Exynos chips) behave differently enough under Vulkan translation that a one-size-fits-all build leaves real performance on the table for Mali-GPU owners. Ludashi and Ludashi Plus, meanwhile, are less about GPU-specific tuning and more about bundling extra quality-of-life features, UI changes, and in some cases newer component versions ahead of when upstream ships them — Ludashi’s 4.1 release on September 13, 2026 and Ludashi Plus’s 4.0 Update 1 on September 9, 2026 both landed within upstream Winlator’s own 11.1-to-11.2 release window, illustrating how closely these forks now track (and sometimes outpace) the original project on specific fixes.
This is not necessarily a bad thing for users — competition between forks has generally meant faster iteration on driver quirks and per-game fixes than a single small team could manage alone. But it does mean “just download Winlator” is no longer straightforward advice. The practical guidance: start with upstream brunodev85/winlator unless you have a specific, documented reason (a Mali GPU, a particular game that only runs well on a named fork) to look elsewhere, and always check which repository a download actually comes from before trusting version-number claims, since forks do not always follow the same numbering scheme as the project they branched from.
Common problems and how to fix them
Game launches but crashes within seconds. This is most often a missing Wine dependency (commonly .NET or Visual C++ redistributables the game expects) rather than a Box64 or hardware problem. Installing the relevant dependency inside the Winlator container’s Wine prefix, the same way you would on a fresh Windows install, resolves the majority of these crashes.
Frame rate is far lower than benchmarks you have seen online. Check three things in order: whether you are on the Compatibility or Performance Box64 preset (Performance trades some accuracy for speed and is usually the right default for actual gameplay rather than testing), which DXVK or VKD3D-Proton version your container is using versus what a benchmark you are comparing against used, and whether your device is thermal-throttling after a few minutes of sustained load, which is extremely common on phone-form-factor hardware without active cooling.
Game will not install or the installer hangs. Some Windows installers check for a specific Windows version string, and Winlator containers let you spoof this per-profile. Games that check for DirectX 12 support specifically sometimes need VKD3D-Proton explicitly selected rather than left on a DXVK default meant for older Direct3D versions.
Audio is stuttering or missing entirely even though video runs fine. This is a known weak point across the entire Winlator/Box64/Wine stack on Android specifically, since audio drivers add another translation hop. Reducing the audio buffer size in container settings, or in some cases disabling and re-enabling the audio driver mid-session, is the most commonly reported workaround in community troubleshooting threads.
Pricing and licensing
| Project | Cost | License | Paid alternative |
|---|---|---|---|
| Winlator | Free | Open source (forks vary) | None official; some forks bundle ads or “plus” tiers |
| Box64 / Box86 | Free | MIT | None |
| Wine | Free | LGPL | CodeWeavers CrossOver (~$74/year, adds support and Mac/Chromebook polish) |
| GameNative (Winlator-based app) | Free | Open source | — |
| GameHub (Winlator-based app) | Free | Open source | — |
None of the core technology in this comparison costs money. The only paid option in this entire ecosystem is CodeWeavers’ CrossOver, a commercial Wine wrapper aimed at Mac and Chromebook users who want a supported, GUI-driven install experience rather than compiling or configuring anything themselves. Everything else — Winlator, its forks, Box64, upstream Wine, and the Android apps built on top of them like GameNative and GameHub — is free and open source, funded by donations and, in a few fork cases, in-app ads.
Where each project shows up outside gaming handhelds
This is the part of the comparison that gets lost when Winlator dominates the conversation. Box64 and Wine both have substantial lives on hardware that has nothing to do with phones.
Box64 is the reason x86-64 Linux software runs at all on ARM single-board computers like the Raspberry Pi 5, ARM-based mini PCs, and ARM Windows-on-Snapdragon laptops running Linux instead of Windows. Distributions like Armbian and various Raspberry Pi-focused Linux builds ship Box64 as a package precisely so users can run x86-64 binaries — not just games, but general Linux software with no ARM build available — without needing Winlator or Android at all. Box86, its 32-bit predecessor, still matters for older 32-bit Linux software and DirectX 9-era games running through Wine on the same ARM boards.
Wine’s biggest audience by far is not Android at all — it is Valve’s Steam Deck and the broader Linux gaming desktop, where Wine forms the base layer of Proton, Valve’s own compatibility tool that ships with every Steam Deck and every SteamOS-alternative Linux distro and is available to any Linux Steam user. Proton-GE, a community fork of Proton maintained separately from Valve, adds extra patches, codecs, and compatibility fixes that Valve has not merged upstream yet, and is popular precisely because it often supports a new game before official Proton does. None of this requires Box64, because Steam Deck’s CPU is x86-64, the same architecture the Windows games were compiled for — the entire CPU-translation problem that defines the Android Winlator experience simply does not exist on Steam Deck.
What kinds of games actually run well
Compatibility through this stack is not evenly distributed across game types, and understanding the pattern saves a lot of trial and error. Older titles built on DirectX 9 or early DirectX 11, with modest CPU demands and no aggressive anti-cheat, tend to be the strongest performers: turn-based and strategy games, older JRPGs and visual novels, 2D platformers and metroidvanias, and PC ports of last-generation console games generally run at or close to full frame rate on current flagship Android hardware.
Mid-tier compatibility covers open-world and action-RPG titles from roughly the 2014-2019 window — The Witcher 3 and Dark Souls 3, both referenced in the benchmark table above, sit in this bracket. These generally run, but require settings reductions, resolution drops to 720p or below, and sometimes the device-spoofing tricks the “driver mastery” testing referenced earlier relies on to hit acceptable frame rates.
The weakest category by a wide margin is anything with kernel-level anti-cheat. Games using Easy Anti-Cheat in kernel mode, BattlEye, or similar systems generally will not run through Wine at all, on any platform, because these anti-cheat drivers are specifically designed to detect and block non-native Windows kernel environments — this is a Wine-wide limitation that predates Winlator and Box64 entirely and has nothing to do with ARM translation specifically. Most competitive online shooters and battle royale titles fall into this category and should not be expected to work regardless of how much a container profile gets tuned. DirectX 12 titles with heavy ray-tracing or upscaling dependencies (DLSS specifically, since it is Nvidia-proprietary) also tend to underperform relative to their DirectX 11 counterparts, because VKD3D-Proton’s DirectX 12-to-Vulkan translation is a younger, less mature project than DXVK’s DirectX 9-11 translation.
Real-world use cases and recommendations
1. You own a Retroid Pocket, AYN Odin 2, AYANEO Pocket, or similar Android gaming handheld and want to try PC games. Install Winlator directly, or one of the packaged apps built on it, GameNative or GameHub, if you want less manual configuration. Expect older or less graphically demanding titles — 2D indies, older 3D games, emulator-adjacent software — to run comfortably, and expect recent AAA titles to need reduced settings and lowered expectations, per the FPS data above.
2. You have a Raspberry Pi 5 or another ARM single-board computer and want to run x86-64 Linux software. Look at Box64 directly, installed through your distro’s package manager or compiled from the ptitSeb/box64 repository, rather than reaching for Winlator, which is Android-specific and irrelevant on a headless or desktop Linux ARM board.
3. You have a Windows-on-ARM device or Apple Silicon Mac and want to run a Windows game. Wine alone will not help here without an ARM-aware Wine build or an x86 translation layer like Apple’s own Rosetta (on Mac) or Microsoft’s built-in x86 emulation (on Windows on ARM) doing the CPU-translation job that Box64 does on Android/Linux. CrossOver on Mac packages this into a supported product.
4. You have a Steam Deck, ROG Ally, Legion Go, or any x86-64 handheld gaming PC. None of this article’s core dilemma applies to your CPU-translation problem, because you do not have one — your chip is the same architecture the Windows games were built for. Proton, Valve’s Wine fork, is already handling the Windows-API-translation job at 85-98% of native performance according to community ProtonDB data, and Proton-GE is worth installing if a specific game is not yet supported upstream.
5. You are a developer or power user who wants to fine-tune performance rather than accept app defaults. Learning the difference between Box64’s compatibility and performance presets, and choosing DXVK versus VKD3D-Proton per game inside a Winlator container profile, is where the 20-30 FPS swings documented in the benchmark table above actually come from. This is manual, not automatic, and it is the main reason two people on identical hardware report very different results.
6. You run a home lab or self-hosted game streaming setup and want to serve Windows games to thin clients. Wine on an x86-64 Linux server, rather than Winlator, is the right tool here, since you can pair it with a streaming layer like Sunshine/Moonlight and avoid the ARM-translation overhead entirely by running the actual game on x86-64 hardware and only streaming the video output to lightweight ARM clients, phones, or tablets.
7. You are evaluating whether to buy a new Android gaming handheld specifically for PC game emulation, versus a Windows-native handheld like the ROG Ally or a Steam Deck. The benchmark gap documented above (30-60 FPS on flagship ARM silicon through Winlator versus 85-98% of native performance through Proton on matching-architecture hardware) is the single number that should drive this decision. If your priority is playing recent, demanding PC games reliably, an x86-64 handheld running Windows or SteamOS natively remains the more predictable purchase in September 2026; Android-plus-Winlator is a better fit for older or lighter titles, or as a secondary device you already own rather than a primary gaming purchase.
Migration guide: moving between Winlator, GameNative, and GameHub
Because Winlator, GameNative, and GameHub all share the same underlying Wine/Box64/DXVK stack, switching between them does not mean starting your game library from zero, but it does mean redoing container setup. Follow this sequence if you are moving off stock Winlator to a packaged alternative, or between Winlator forks:
- Back up your existing Winlator container folder (the app’s designated storage directory) before uninstalling anything — this holds your installed Windows game files and Wine prefix configuration.
- Note which Box64 preset (Compatibility, Performance, or a custom profile) and which DXVK/VKD3D version you were using per game, since these settings do not always carry over automatically between forks.
- Install the new app (GameNative, GameHub, or a specific Winlator fork like Ludashi) fresh rather than trying to update in place across forks, since their codebases have diverged enough that in-place updates can corrupt a container.
- Recreate a container/profile matching your old Box64 and graphics settings as closely as possible, then reinstall or point the new container at your backed-up game files rather than re-downloading everything.
- Test with a lightweight, well-documented title first (something already confirmed to run well in community compatibility lists) before moving your full library over, so you can isolate whether a problem is your new setup or the game itself.
- If performance regresses after migrating, check whether the new app defaults to a different DXVK or VKD3D-Proton version than you were using — this single setting explains a large share of “it got slower after I switched apps” reports in community forums.
Pros and cons
Winlator
Pros: Free, actively maintained upstream, the most accessible on-ramp for non-technical Android users, per-game container profiles, large community knowledge base built up over several years.
Cons: Fork fragmentation makes “which Winlator” a real question, highest cumulative performance overhead of the three because it stacks CPU, API, and graphics translation, results vary heavily by device and configuration, no official OEM support from any handheld manufacturer as of September 2026.
Box64
Pros: Single, stable upstream project rather than a fork jungle, useful well beyond gaming on ARM Linux SBCs and mini PCs, MIT-licensed and permissively usable in other projects, continuously updated (v0.4.4 as of August 7, 2026).
Cons: Not usable on its own by an end user — it is a component, not an application, and it carries inherent CPU-translation overhead no amount of tuning fully eliminates.
Wine
Pros: Decades of development maturity, by far the best performance of the three when running on matching x86-64 hardware, forms the base of Valve’s Proton, wrapped by user-friendly tools like Bottles and Lutris on Linux desktop.
Cons: Provides no CPU-architecture translation on its own, so it is close to useless for ARM Android use without Box64 underneath it, raw Wine configuration without a wrapper tool is not beginner-friendly.
The verdict
There is no single winner here because these three projects are not solving the same problem for the same person. If the question is “what should I install on my Android gaming handheld,” the answer is Winlator or one of its packaged descendants (GameNative, GameHub), because that is the only one of the three built for that job. If the question is “why is my Android Windows-gaming performance worse than my old gaming laptop,” the answer is Box64, because CPU-instruction translation is the single most expensive layer in the whole stack — the benchmark data above shows a roughly 2x FPS gap between well-tuned and default Winlator configurations on identical Snapdragon 8 Gen 3 hardware, and an even larger gap versus native x86-64 Wine/Proton performance on Steam Deck-class devices. If the question is “how do I run Windows software on my Linux PC or Steam Deck,” the answer is Wine, most likely through Proton, and you can skip Box64 and Winlator entirely, because your CPU already speaks the same instruction set the software was compiled for.
The practical takeaway for September 2026: match the tool to the architecture problem you actually have. Same-CPU-architecture users (Steam Deck, x86-64 Linux desktops) should look at Wine/Proton and expect near-native results. Different-CPU-architecture users (Android phones, ARM handhelds, ARM SBCs) need Box64 in the mix regardless of which app wraps it, and should expect a real performance tax that no amount of settings-tuning fully erases — 30-60 FPS in demanding titles is the realistic 2026 ceiling on current flagship mobile silicon, not the 90+ FPS a modern gaming PC delivers natively.
Frequently asked questions
Is Winlator legal to use?
Yes. Winlator, Box64, and Wine are all open-source software, and running them is not illegal. Legality only becomes a question around how you obtain the Windows games you run through them — installing games you legitimately own or purchase is not a legal gray area, in the same way running Steam or GOG software is not.
Do I need Box64 if I already have Winlator installed?
No separate installation is needed. Winlator bundles Box64 (and Box86 for 32-bit titles) internally, so installing Winlator already gives you Box64’s CPU translation. You do not download or configure Box64 as a standalone step on Android.
Why is my game running so much slower in Winlator than on my PC?
Because Winlator on Android stacks CPU-instruction translation (Box64), Windows-API translation (Wine), and graphics-API translation (DXVK/VKD3D-Proton) on top of a mobile chip that is already less powerful than a desktop GPU. Each layer costs performance, which is why even flagship Snapdragon 8 Elite hardware lands in the 30-60 FPS range for demanding titles rather than matching desktop frame rates.
What is the difference between Winlator and GameNative or GameHub?
GameNative and GameHub are separate Android apps built on the same underlying Wine/Box64/DXVK technology as Winlator, but with different default configurations, UI choices, and in some cases different bundled driver or graphics-translation versions. Reported benchmarks show meaningful FPS differences between them on identical hardware, largely driven by which DXVK/VKD3D and Box64 preset each app ships by default.
Can I use Box64 without Winlator?
Yes. Box64 is a standalone, general-purpose x86-64-to-ARM64 translator that many ARM Linux distributions package independently, including builds used on Raspberry Pi 5 and other single-board computers, entirely separate from Android or gaming.
Is Wine the same thing as Proton?
No, but they are closely related. Proton is Valve’s own fork of Wine, customized and maintained specifically for Steam and Steam Deck, with additional patches for game compatibility that are not always present in upstream Wine. Proton-GE is a further community fork of Proton with extra fixes not yet merged by Valve.
Which Winlator version should I actually download?
Start with the upstream brunodev85/winlator repository, currently on version 11.2.0 as of August 19, 2026, unless a specific fork (like WinlatorMali for Mali-GPU devices) is documented as better suited to your exact hardware. Community forks like Ludashi and Ludashi Plus update on their own schedules and can diverge significantly from upstream, so treat their version numbers as separate from, not newer than, mainline Winlator.
Do I need a powerful phone to use Winlator?
Reasonable results require a recent flagship-tier chipset. Benchmarks in this article, gathered on Snapdragon 8 Gen 2, 8 Gen 3, and 8 Elite devices, show meaningfully better frame rates as chip generation increases, and mid-range or older chipsets generally struggle to run anything beyond light or older 3D titles.
External resources
For readers who want to go deeper on any single layer covered here: the upstream Winlator repository on GitHub documents current releases and container setup, Box64’s own GitHub project covers its ARM Linux use cases beyond gaming, Wine’s official release history on GitLab tracks the stable/development branch split referenced above, the WineHQ AppDB lists community-reported compatibility ratings for individual Windows applications, and VKD3D-Proton’s repository documents the Direct3D 12 translation layer referenced in the benchmark and specs sections.
