Complete end-to-end guide: from creating a Windows 11 KVM VM to running Minecraft Bedrock on Ubuntu using WineGDK, a Wine fork with native GDK (Game Development Kit) support.
Status: PLAYABLE (2026-06-28) — Bedrock 26.32 runs on WineGDK + DXVK: the menu renders, gamepad works (Xbox / Stadia / PS3), keyboard works, and it connects to remote BDS servers (advertised as LAN games by the included proxy). Menu mouse-clicks may need the ~5s gate wait on 26.3x (keyboard/gamepad always work — see Known Limitations). Confirmed in real use. See
PLAYING.mdfor how to play andATTEMPTS.mdfor the full investigation.Quick start: launch "Minecraft Bedrock" from the GNOME dash (or run
scripts/play-bedrock.sh [--windowed]), connect a controller before launching, and join your server from LAN Games. Configure servers in the gitignoredscripts/servers.conf(copyscripts/servers.conf.example).
Known Limitations & Caveats
- Menu mouse-clicks on 26.3x — the custom dwmapi click-hook proxy that drove menu clicks on 1.26.21 page-faults under 26.3x's reworked pointer-input API, so the launcher uses Wine's builtin dwmapi (
dwmapi=b). The game renders and plays fine; in the menu, give it the ~5s gate wait before clicking, or use keyboard/gamepad. In-world mouse-look is unaffected.- Intermittent "missing required component" error screen on launch — a ~50/50 GDK component-check race. Just relaunch.
- Silent "no window" on launch — leftover
lan-proxy.py/ wineserver / game processes from a previous run make the game hang before rendering.scripts/play-bedrock.shcleans these up automatically before launching.- Connect a controller before launching — GameInput enumerates devices at startup. Xbox/Stadia go through XInput; PS3/generic pads through DirectInput.
- Keep private server IPs out of git — real addresses live in the gitignored
scripts/servers.conf; never commit Tailscale IPs or personal server names.- No Microsoft account login — Xbox Live sign-in isn't working here, so no Realms, no featured servers, no signed-in online multiplayer. Self-hosted / LAN BDS servers work fine (same version as Windows).
- File picker crashes the game — import worlds manually by extracting
.mcworldfiles intocom.mojang/minecraftWorlds/.- Wine prefix can corrupt on crashes — back up your saves regularly.
If you only need Java Edition, it runs natively on Linux — just use Prism Launcher. mcpelauncher (Android-based) is not a viable alternative — it cannot run the latest Bedrock versions, so cross-play with Android/console/Windows players fails due to version mismatch.
| Component | Details |
|---|---|
| Host OS | Ubuntu 24.04 LTS |
| VM | Windows 11 on KVM/QEMU with virt-manager |
| Runner | WineGDK (built from source), Wine 11.8 |
| Game Version | Bedrock 26.32 |
| GPU Tested | NVIDIA GeForce GTX 1650 (TU117), Driver 595.58.03 |
| Forks | jphein/WineGDK, jphein/GDK-Proton |
PLAYABLE. Minecraft Bedrock 26.32 runs on Ubuntu Linux via WineGDK + DXVK — menu renders, gamepad + keyboard work (menu mouse-clicks may need the ~5s gate wait on 26.3x — see Known Limitations), connects to self-hosted BDS servers. Played end-to-end. Current build:
| Build | Install Path | Notes |
|---|---|---|
| clang-23 | ~/Projects/WineGDK/install-clang23/ |
wine-11.1; the playable build (gameinput.dll = drop-mouse + gamepad XInput/DInput) |
| clang-20 | ~/Projects/WineGDK/install/ |
wine-11.8 (alt) |
Build base: WineGDK source on branch
wip/input-xbl(tracksLukasPAH/WineGDK minimal-xbl) plus our input fixes: gamepadGetCurrentReading(XInput + DInput8) and the mouse-device handling. GDK-Proton is current with upstream but dead for 1.26.x (no D3D device) — bare WineGDK is the path.
- Menu renders (cohtml Ore UI) and is fully navigable by mouse, keyboard, and gamepad.
- Mouse — in-world mouse-look works; menu clicks may need the ~5s gate wait on 26.3x (the launcher uses builtin dwmapi there — see Known Limitations). Keyboard/gamepad always navigate the menu.
- Gamepad — Xbox / Stadia / PS3 controllers (XInput + DirectInput paths). Connect before launching.
- 3D world renders (DXVK d3d11 + vkd3d-proton d3d12), audio, in-world mouse-look.
- Multiplayer to self-hosted BDS servers — advertised as LAN games via
scripts/lan-proxy.py; one-shot launch viascripts/play-bedrock.sh+ GNOME dash entry.
- Microsoft / Xbox Live login — no sign-in, so no Realms or featured servers.
- Note: an intermittent GDK component-check race shows the "missing required component" screen on ~half of launches — just relaunch.
Before the 3D world rendered, the game showed a black screen across 13 configurations (DXVK, lavapipe, wined3d OpenGL/Vulkan, etc.). That root cause was the wrong game binary: VM extraction had silently left version 1.26.3 in place when 1.26.21 was expected. With the correct 1.26.21 binary built under clang-23, the 3D world renders. That black screen was never bgfx, Wine, or the GPU driver — it was a version mismatch. (This is distinct from the current cohtml UI blocker above.)
The file xgameruntime.dll.threading is a native Microsoft DLL that must be present in the game directory. It is not built by WineGDK -- it comes from the Windows VM game extraction. If this file is missing, the game will fail to launch. Verify it exists after running host-copy-from-vm.sh.
- Issue #4 — Black screen (resolved: wrong binary version)
- Issue #5 — bgfx analysis (resolved: not a bgfx issue)
- Weather-OS/WineGDK#54 — Upstream discussion
| Script | Where | Purpose |
|---|---|---|
scripts/host-install-kvm.sh |
Host | Install KVM/QEMU/virt-manager on Ubuntu |
scripts/host-create-vm.sh |
Host | Create the Windows 11 VM via CLI |
scripts/vm-setup-ssh.ps1 |
VM | Enable OpenSSH, fix admin key auth, configure firewall |
scripts/vm-extract-minecraft.ps1 |
VM | Decrypt and copy Minecraft files (robocopy + package context) |
scripts/host-copy-from-vm.sh |
Host | SSH into VM, extract game files, SCP to host |
scripts/setup.sh |
Host | Set up XCurl, SSL certs, stub DLLs, and Wine prefix |
scripts/launch.sh |
Host | Launch Minecraft via WineGDK (wine) |
scripts/debug-launch.sh |
Host | Launch with Wine debug output captured to log file |
scripts/update-xcurl.sh |
Host | Re-download XCurl.dll after game updates |
scripts/update-bedrock.sh |
katana | One-command update orchestrator — VM update → extract → setup → smoke → push to katana → update BDS servers |
scripts/game-update.sh |
game host | Game-side sequencer the orchestrator calls: VM update + extract + setup + headless smoke |
scripts/update-bds-servers.sh |
terra | Update self-hosted BDS servers to a matching version (worlds/configs preserved) |
scripts/vm-update-minecraft.ps1 |
VM | Headless Microsoft Store update inside the Windows 11 VM |
scripts/update-targets.conf.example |
katana | Topology config template for update-bedrock.sh (copy to gitignored update-targets.conf) |
scripts/update.sh |
Host | Deprecated (old GDK-Proton flow) — prints a notice and exits; use update-bedrock.sh |
scripts/collect-logs.sh |
Host | Collect full diagnostic info (system, DLLs, prefix health) |
scripts/lan-proxy.py |
Host | UDP broadcast proxy for LAN multiplayer across subnets |
scripts/install-addon.sh |
Host | Install .mcaddon/.mcpack into the game's com.mojang directory |
scripts/deploy-gameinput.sh |
Host | Copy builtin GameInput DLLs from WineGDK build to prefix |
scripts/uninstall.sh |
Host | Remove all Minecraft Bedrock files |
stubs/gameconfighelper/ |
Host | MinGW stub DLL: GameConfigHelper.dll (OpenGameConfigForPackage) |
stubs/midlproxystub/ |
Host | MinGW stub DLL: ObjectStublessClient3-32 forwarding to rpcrt4 |
./scripts/host-install-kvm.shOr manually:
# Verify CPU supports hardware virtualization
egrep -c '(vmx|svm)' /proc/cpuinfo # Must be > 0
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients \
bridge-utils virt-manager virtinst ovmf swtpm swtpm-tools
sudo usermod -aG libvirt $USER
sudo usermod -aG kvm $USER
newgrp libvirt-
Windows 11 ISO: Download from microsoft.com/software-download/windows11 — select "Download Windows 11 Disk Image (ISO) for x64 devices"
-
VirtIO drivers ISO:
wget -P ~/Downloads/ https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.isoUse virt-manager (GUI) or the CLI script:
./scripts/host-create-vm.sh ~/Downloads/Win11.iso ~/Downloads/virtio-win.isovirt-manager GUI settings (if doing it manually):
| Setting | Value |
|---|---|
| Chipset | Q35 |
| Firmware | UEFI: /usr/share/OVMF/OVMF_CODE_4M.ms.fd (Secure Boot) |
| CPU | Copy host configuration (host-passthrough), 4+ cores |
| RAM | 4096 MiB minimum (8192 recommended) |
| Disk | 40+ GiB, SATA or VirtIO bus |
| NIC | e1000e or virtio |
| TPM | Emulated, TIS model, version 2.0 |
Note: VirtIO disk/NIC are faster but require loading drivers during Windows install (browse VirtIO CDROM ->
vioscsi\w11\amd64when no disk is found). SATA + e1000e work out of the box with no extra drivers.
After install, install the virtio-win guest tools inside the VM for best performance (open the ISO in Explorer, run virtio-win-gt-x64.msi).
We use SSH + SCP to copy game files from the VM (see Parts 2 and 3). This is the most reliable method because Xbox App games are encrypted at rest and need special handling.
Alternative: virtiofs shared folder (optional, more setup):
- Install
virtiofsdon the host:sudo apt install virtiofsd - Shut down the VM, then in virt-manager:
- Memory -> check "Enable shared memory"
- Add Hardware -> Filesystem: Driver=virtiofs, Source=
/home/<user>/vmshare, Target=vmshare
- Inside Windows: install WinFSP, reboot, start "VirtIO-FS Service" in
services.msc - The shared folder appears as a new drive letter
Note: Even with virtiofs, you still need
Invoke-CommandInDesktopPackageto decrypt the game files — direct copies from the game directory will be encrypted/access-denied.
SSH is how we extract and copy game files from the VM. Run scripts/vm-setup-ssh.ps1 in an elevated PowerShell inside the VM, or follow these manual steps:
# Install OpenSSH Server (takes a few minutes to download)
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
# Start and auto-start
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'
# Firewall rule
New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server' `
-Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22By default, Windows OpenSSH uses a separate administrators_authorized_keys file for admin accounts, which breaks normal ~/.ssh/authorized_keys. This must be fixed:
Open C:\ProgramData\ssh\sshd_config in Notepad and comment out these two lines at the bottom:
#Match Group administrators
# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
Then restart sshd:
Restart-Service sshdOn the Ubuntu host:
# Generate a key (if you don't have one)
ssh-keygen -t ed25519
# Find the VM's IP
virsh domifaddr <vm-name>
# Or: virsh net-dhcp-leases defaultThe IP is typically 192.168.122.x with the default NAT network.
In the Windows VM (PowerShell):
mkdir C:\Users\<user>\.ssh -Force
# Paste your public key (~/.ssh/id_ed25519.pub contents) into:
notepad C:\Users\<user>\.ssh\authorized_keysssh <windows-user>@192.168.122.xxx "echo connected"- Minecraft Bedrock installed via Xbox App in the Windows 11 VM
- Game launched at least once
- SSH working (Part 2)
Xbox App games are encrypted at rest. You cannot simply copy files from C:\XboxGames\ or C:\Program Files\WindowsApps\ — the exe will be unreadable and other files may be access-denied.
The workaround is Invoke-CommandInDesktopPackage, which runs a command inside the app's sandbox where files are transparently decrypted:
- robocopy all game files to a user-accessible staging directory
- copy the exe separately (robocopy gets the encrypted version; the exe must be copied inside the package context to get the decrypted version)
From the Ubuntu host (does everything via SSH):
./scripts/host-copy-from-vm.sh <windows-user> <vm-ip>Or run vm-extract-minecraft.ps1 inside the VM (elevated PowerShell), then SCP the files:
# In the VM:
.\vm-extract-minecraft.ps1# Then from Ubuntu:
scp -r <user>@<vm-ip>:C:/Users/<user>/minecraft/* ~/vmshare/minecraft-bedrock/file ~/vmshare/minecraft-bedrock/Minecraft.Windows.exe
# Should say: PE32+ executable (GUI) x86-64, for MS Windows
# Or check the MZ header:
xxd -l 2 ~/vmshare/minecraft-bedrock/Minecraft.Windows.exe
# Should output: 00000000: 4d5a MZIf it says data instead of PE32+, the exe is still encrypted — re-run the decryption step.
sudo apt install -y build-essential gcc-mingw-w64-x86-64 flex bison \
libx11-dev libxrandr-dev libxinerama-dev libxcursor-dev libxi-dev \
libxcomposite-dev libglu1-mesa-dev libfreetype-dev libosmesa6-dev \
libgnutls28-dev libpulse-dev libudev-dev libdbus-1-dev libfontconfig-dev \
libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libvulkan-dev \
libusb-1.0-0-dev libsdl2-dev libcups2-dev libkrb5-dev libsane-dev \
libpcap-dev libunwind-dev gettextgit clone https://github.com/Weather-OS/WineGDK.git ~/Projects/WineGDK
cd ~/Projects/WineGDK
# Configure with an install prefix (64-bit only is sufficient for Bedrock)
./configure --prefix=$HOME/Projects/WineGDK/install --enable-win64
# Build (uses all cores)
make -j$(nproc)
# Install to the prefix directory
make installThe build takes 10-30 minutes depending on hardware. The resulting wine binary will be at ~/Projects/WineGDK/install/bin/wine.
Alternative: clang-23 build (matches ChristopherHX's configuration):
cd ~/Projects/WineGDK
CC=clang-23 ./configure --prefix=$HOME/Projects/WineGDK/install-clang23 --enable-win64
make -j$(nproc)
make installBoth clang-20 and clang-23 builds produce a working game. To use the clang-23 build, set WINEGDK_DIR=~/Projects/WineGDK/install-clang23 when running the launch scripts.
./scripts/setup.shThis will:
- Replace
XCurl.dllwith the mingw curl build (for network functionality) - Copy XCurl dependency DLLs to the game directory
- Download SSL certificates (for HTTPS)
- Copy xgameruntime DLLs to the game directory
- Create the Wine prefix and install GameInputRedist
- Build and install the midlproxystub DLL (ObjectStublessClient fix)
- Patch graphics options to avoid deferred renderer crash
Known issue: msiexec hangs on GameInputRedist.msi
Step 5 uses
wine msiexecto install GameInputRedist, but msiexec hangs indefinitely under WineGDK. The workaround is to usemsiextract(from themsitoolspackage) instead:sudo apt install msitools msiextract -C "$PREFIX_DIR/drive_c" "$GAME_DIR/Installers/GameInputRedist.msi"The
setup.shscript does not yet handle this automatically -- if it hangs at the GameInputRedist step, kill it (Ctrl+C), run themsiextractcommand above, and re-runsetup.sh(it will skip already-completed steps or re-do them harmlessly).
./scripts/launch.shThis runs wine from your WineGDK build directly — no Proton, no Steam Runtime, no Lutris.
Environment variables (all have sensible defaults in the script):
| Variable | Default | Purpose |
|---|---|---|
WINEGDK_DIR |
~/Projects/WineGDK/install |
Path to WineGDK install prefix |
GAME_DIR |
~/Games/minecraft-bedrock/game |
Path to extracted game files |
WINEPREFIX |
~/Games/minecraft-bedrock/prefix |
Wine prefix for the game |
Example with custom paths:
WINEGDK_DIR=~/Projects/WineGDK/install GAME_DIR=~/vmshare/minecraft-bedrock ./scripts/launch.shTo capture Wine debug output for troubleshooting:
./scripts/debug-launch.sh # Standard debug channels
./scripts/debug-launch.sh --verbose # All warnings + SEH + module loadingLogs are saved to ~/minecraft-debug-<timestamp>.log.
./scripts/uninstall.shThis removes the game directory, Wine prefix, and related configs. Source game files in ~/vmshare/ are kept as a backup — delete them manually if no longer needed. Your WineGDK build at ~/Projects/WineGDK/ is not touched.
When a new Bedrock version ships, run the orchestrator from katana (your workstation):
./scripts/update-bedrock.shIt drives the whole update end-to-end and never declares success on a failed smoke check:
- VM Store update — triggers and waits for the Microsoft Store to pull the new build inside the Windows 11 VM (headless), then reads the new version.
- Extract — decrypts and copies the updated game files out of the VM.
- Host setup — re-runs
setup.sh(XCurl, certs, stub DLLs, prefix) against the new build. - Headless smoke check — launches the game on the game host for ~60s to confirm it actually starts. A failed smoke halts the run — nothing is pushed and the previous build's
game.bakrollback stays intact. - Delta-push to katana — backs up katana's current build, then delta-rsyncs the verified build over (resume-retry on flaky links), and re-verifies the binary (PE32+, size match, manifest version).
- Update the BDS servers — updates your self-hosted terra BDS servers to the matching protocol release (Bedrock requires client↔server version match), preserving worlds and configs, and verifies each comes back up.
Then launch and join a server to confirm the protocol match:
./scripts/play-bedrock.shConfigure topology in scripts/update-targets.conf — copy the template and fill in your real values:
cp scripts/update-targets.conf.example scripts/update-targets.confThat file is gitignored (it holds private Tailscale IPs, the VM domain name, and your BDS server list), so real addresses are never committed.
Flags:
| Flag | Effect |
|---|---|
--client-only (or --skip-servers) |
Update only the client (game + katana); skip the terra BDS servers |
--skip-vm |
Re-extract the current VM build; skip the Store update |
--dry-run |
Print the plan and run read-only probes only; touch nothing |
--yes |
Don't pause for interactive confirmation |
Under the hood the orchestrator calls the building blocks directly — scripts/game-update.sh (the game-side VM-update → extract → setup → smoke sequencer, which in turn uses host-copy-from-vm.sh and setup.sh), scripts/vm-update-minecraft.ps1 (the in-VM headless Store update), and scripts/update-bds-servers.sh (the worlds-preserving terra BDS updater). You can run any of them standalone.
Deprecated: the old GDK-Proton
scripts/update.shis retired — it targeted dead paths and now just prints a notice pointing here and exits.
To update WineGDK itself, rebuild from source:
cd ~/Projects/WineGDK && git pull && make -j$(nproc) && make installWineGDK is a Wine fork that includes native support for several Windows APIs that Minecraft Bedrock depends on. The following are handled natively by WineGDK (no patches needed):
- GameInput — builtin
gameinput.dllandgameinputredist.dllstub the GameInput API safely (Microsoft's native redistributable crashes under Wine due to missing HID/winebus.sys support) - xgameruntime —
xgameruntime.dlland related GDK runtime DLLs are built into WineGDK - DataTransferManager —
DataTransferManager.GetForWindow()returns a stub instead ofE_NOTIMPL - CoreApplication WinRT activation —
RoGetActivationFactory("Windows.ApplicationModel.Core.CoreApplication")is supported - WNF stubs in ntdll.dll —
NtQueryWnfStateData,RtlSubscribeWnfStateChangeNotification, and related Windows Notification Facility functions are stubbed - NtQueryLicenseValue — returns
STATUS_OBJECT_NAME_NOT_FOUNDcorrectly - RtlGetDeviceFamilyInfoEnum — form factor value is correct
- kernelbase.dll package APIs —
GetCurrentPackagePath2,PackageFamilyNameFromFullName,PackageNameAndPublisherIdFromFamilyNameare stubbed
-
XCurl.dll — Minecraft ships a proprietary XCurl that depends on Xbox Live services. We replace it with a mingw-built
libcurlso networking (skin downloads, marketplace, etc.) works. The replacement depends on ~13 DLLs (libbrotlidec, libssl, libcrypto, etc.) that must be in the game directory —setup.shhandles this. -
SSL certificates — The mingw curl needs a CA bundle. Downloaded from curl.se/ca by
setup.sh. -
GameConfigHelper.dll — Minecraft's
GameLaunchHelper.exeimportsOpenGameConfigForPackagefrom this DLL, which does not exist in Wine. The MinGW stub instubs/gameconfighelper/returnsS_OK. Deployed bysetup.sh. -
midlproxystub DLL — Wine's PE-only mode has a bug resolving
combase.dllforwarders torpcrt4.dllforObjectStublessClient3throughObjectStublessClient32. The stub DLL instubs/midlproxystub/provides direct implementations. Built and deployed bysetup.sh.
| Variable | Value | Purpose |
|---|---|---|
WINEPREFIX |
~/Games/minecraft-bedrock/prefix |
Wine prefix for the game |
WINEDLLOVERRIDES |
GameInputRedist=b |
Force Wine's builtin GameInput instead of the native MSI redistributable, which crashes |
- No Microsoft account login — XUser is not implemented in WineGDK
- No Realms or featured servers — requires Microsoft auth
- Menu mouse-clicks on 26.3x — the custom dwmapi click-hook proxy page-faults under 26.3x's reworked pointer-input API, so the launcher uses Wine's builtin dwmapi (
dwmapi=b). The game renders and plays normally; menu clicks may need the ~5s gate wait (or use keyboard/gamepad). In-world mouse-look is unaffected - Multiplayer — LAN play works natively; for external servers, use ProxyPass to proxy them as LAN
- File picker crashes — import worlds manually by extracting
.mcworldfiles intocom.mojang/minecraftWorlds/ - Wine prefix corruption — crashes can corrupt the prefix; back up saves regularly
- Deferred rendering crash — the game's PBR/RTX renderer (graphics_mode:2) has a race condition under Wine; launch scripts force Classic mode (graphics_mode:0) automatically
- msiexec hangs —
wine msiexechangs when installing GameInputRedist.msi; usemsiextractinstead (see setup instructions above) - xgameruntime.dll.threading — this native Microsoft DLL must come from the Windows VM extraction; it is not built by WineGDK
- Work in progress — WineGDK is under active development; some APIs may still be incomplete
Ensure WineGDK is built and installed:
ls ~/Projects/WineGDK/install/bin/wineIf missing, rebuild: cd ~/Projects/WineGDK && make -j$(nproc) && make install
Common issues:
- Missing headers: install the build dependencies from 4.1
- Vulkan not found:
sudo apt install libvulkan-dev - MinGW not found:
sudo apt install gcc-mingw-w64-x86-64(needed for PE DLL builds and stub DLLs)
- Run
scripts/debug-launch.shand check the log forerr:module:import_dlllines — these indicate missing DLLs - Ensure
XCurl.dlland its dependencies are in the game directory - Check that
GameConfigHelper.dlland the midlproxystub DLL are installed
- Verify
xgameruntime.dllis in the game directory (copied from the WineGDK build bysetup.sh) - Verify
xgameruntime.dll.threadingis in the game directory -- this is a native Microsoft DLL that must come from the Windows VM game extraction, not from WineGDK. If missing, re-runhost-copy-from-vm.sh - Check that
WINEPREFIXpoints to a valid prefix
If the game launches but shows only a black screen, the most likely cause is the wrong game binary version. Verify you have the correct version:
strings ~/Games/minecraft-bedrock/game/Minecraft.Windows.exe | grep -i "1\.26\."Re-extract from the VM with host-copy-from-vm.sh if the version does not match what is installed in the Xbox App. The VM file copy can fail silently, leaving an older binary in place.
wine msiexec hangs under WineGDK. Kill the script (Ctrl+C) and install manually:
sudo apt install msitools
msiextract -C ~/Games/minecraft-bedrock/prefix/drive_c ~/Games/minecraft-bedrock/game/Installers/GameInputRedist.msiThen re-run setup.sh to complete the remaining steps.
Re-run Invoke-CommandInDesktopPackage on the Windows VM — see Part 3
virsh domifaddr <vm-name>
# Or check DHCP leases:
virsh net-dhcp-leases default- Run
scripts/debug-launch.shto capture Wine debug output - Run
scripts/collect-logs.shfor a full diagnostic report
- WineGDK (GitHub) — Wine fork with GDK support
- Minecraft Wiki - Playing on Linux
- MCGDKLauncher (GitHub)
- Bedrock Native Modding Wiki - GDK
- Microsoft - Download Windows 11
- VirtIO Windows Drivers
This project is licensed under the GNU General Public License v3.0.
Minecraft is a registered trademark of Mojang Studios / Microsoft Corporation. This project is not affiliated with, endorsed by, or associated with Mojang or Microsoft. You must own a legitimate copy of Minecraft Bedrock Edition to use this guide.
Third-party components downloaded at runtime by the setup scripts:
- mingw-w64 curl (curl license) — replaces XCurl.dll for network functionality
- CA certificate bundle (Mozilla Public License 2.0) — from curl.se/ca
- WineGDK (LGPL, same as Wine) — Wine fork with GDK support, built from source