Commits on Sep 14, 2026

• build.exe: robust download (curl.exe), validate the zip, self-heal

  …

  On a real user machine the download saved a corrupt/partial archive and
  Expand-Archive failed with "End of Central Directory record could not be found."
  Invoke-WebRequest on Windows PowerShell 5.1 was the weak link.
  
  Download with curl.exe now (bundled since Windows 10 1803; -L follows the GitHub
  redirect, --fail refuses to save an error page), with PowerShell as fallback.
  Validate the archive (PK signature + size) before unpacking, delete a bad or
  half-finished one so a re-run starts clean, and unpack with tar.exe (Expand-
  Archive as fallback). On a hard failure, print the URL for a manual download
  that build.exe will then pick up. Verified end to end on a clean Windows box.
  
  Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

  K Kretrod committed 4 hours ago
  a0a534f
• build.exe: mkdirs must create only parent dirs, not the .o path

  …

  Second issue from the clean-box test: g++ failed with "can't create
  build/src/main.cpp.o: Permission denied" because mkdirs() created the full
  object path — filename included — as a directory, so a directory sat where the
  object file needed to be written. Create only the directories above the final
  path component.
  
  Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

  K Kretrod committed 4 hours ago
  d6c7419
• build.exe: put w64devkit\bin on PATH so g++ can find as/ld

  …

  Tested from a clean Windows box: the download and unpack worked, but the first
  g++ invocation failed with "cannot execute 'as'". w64devkit expects its bin
  directory on PATH; called by a bare relative path it could not find the
  assembler or linker it shells out to. Prepend the toolchain's absolute bin to
  PATH before compiling; system() children inherit it.
  
  Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

  K Kretrod committed 4 hours ago
  943cbd1
• Add build.exe: one-click Windows builder, vendor jni.h

  …

  build.exe downloads a portable mingw toolchain (w64devkit, pinned) into a
  subfolder on first run — nothing installed system-wide, no admin — then
  compiles the DLL and loader directly with g++, mirroring the Makefile's flags
  and source list, and prints the DLL imports to confirm the static link held.
  Source is build_bootstrap.c.
  
  jni.h is now vendored under third_party/jni, so no JDK is needed by either
  build.exe or make. JAVA_INC is optional and only overrides the vendored header;
  the Makefile picks up third_party/jni and adds -I<JAVA_INC> only when set.
  
  BUILD.md leads with build.exe; the make paths (Linux, MSYS2, WinLibs) stay for
  anyone who prefers it. Verified the exact recipe build.exe runs still links to a
  DLL importing only KERNEL32/USER32/GDI32/OPENGL32/msvcrt.
  
  Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

  K Kretrod committed 4 hours ago
  d0bd697
• Makefile: build on Windows too, and add BUILD.md

  …

  A cloner on Windows hit `make` failing with "The syntax of the command is
  incorrect." The recipes used a Unix shell — `mkdir -p`, `rm -rf`, and an
  `objdump | grep | sort` pipeline — which cmd.exe cannot run, so the build died
  before the compiler was ever invoked.
  
  Detect the OS (make sets OS=Windows_NT there) and pick the directory-make,
  tree-remove and dependency-dump commands each shell understands; use `$(@D)`
  so there is no trailing slash to trip cmd's quoting. JAVA_INC include is now
  quoted so a path like "C:/Program Files/Java/..." survives, and BUILD.md spells
  out the toolchain, the MSYS2/WinLibs paths, and the JDK include requirement.
  
  CXX/CC/OBJDUMP stay `:=`, not `?=`: make has a built-in default for CXX/CC
  (the host g++/cc), and `?=` would leave that in place and quietly build for the
  wrong platform. A command-line `make CXX=g++` still overrides `:=`.
  
  No change to the build output — same DLL, still importing only KERNEL32,
  USER32, GDI32, OPENGL32 and msvcrt.
  
  Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

  K Kretrod committed 5 hours ago
  61980ae
• C++ port of the client: MinHook, Dear ImGui, JNI bindings

  …

  A from-scratch C++ remake of the Rust client, cross-compiled with mingw into
  a DLL that depends only on KERNEL32, SHELL32, USER32 and msvcrt. MinHook
  detours glfwSwapBuffers; each frame reads the game over JNI on the render
  thread, runs the modules against a copy of the settings, and draws the Enigma
  menu, HUD and ESP with Dear ImGui (both vendored under third_party with their
  licences).
  
  The mingw toolchain is the win32-threads build, so locking uses
  CRITICAL_SECTION and threads use CreateThread. Settings share the Rust
  client's file and key names, so a config written by either means the same to
  the other. File I/O uses fopen rather than iostreams, which saved 1.7 MB.
  
  Around 51 of the 69 menu modules are wired: flight, speed, sprint, bhop,
  jetpack, no fall, noclip, spider, step, timer, kill aura with criticals and
  sprint reset, aimbot, bow aimbot, trigger bot, reach, hitbox, anti-knockback,
  auto clicker, auto totem (Legit/Instant), shield, crystal and mace, the
  visual options, and ESP with ping, threat and gear. Block placing, block
  scanning, freecam, blink and the packet tap are still to come.
  
  Binding names are ported from the Rust client's working definitions, but
  this build has not yet run against the live game.
  
  Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

  K Kretrod committed 7 hours ago
  c1864ef