{
  "id": "doom-2016",
  "name": "DOOM (2016)",
  "publisher": "id Software / Bethesda",
  "steamAppId": 379720,
  "exePatterns": [
    "doomx64vk.exe",
    "doomx64.exe"
  ],
  "bottle": {
    "windowsVersion": "win10",
    "translationLayer": "dxvk",
    "dxvk": false,
    "dxvkAsync": false,
    "enhancedSync": "msync",
    "avxEnabled": true,
    "metalHud": false
  },
  "environment": {
    "WINEDLLOVERRIDES": "vulkan-1=b"
  },
  "winetricks": [],
  "launchArgs": "",
  "executableSubstitutions": [
    {
      "replace": "DOOMx64.exe",
      "with": "DOOMx64vk.exe"
    }
  ],
  "notes": "1.1 RUNTIME, 29 Sep 2026 — READ THIS FIRST. On Wyn 1.1 builds 4 to 6 DOOM never got past 91% of its first load. The cause was the winecx Wine, not anything below. It kept %gs on the macOS pthread TSD while Windows code ran, so MSVC's inline GetCurrentFiber() (a gs:0x20 read) returned the TSD's QoS class, 0x8ff. superscriptx64.dll then called SwitchToFiber(0x8ff) and took an access violation in kernelbase. id Tech's CrashHandler wrote Crash.<host>.*.html, and the main thread spun on the 91% screen. It is not the COM-apartment stall in (2): it happened through Steam too, and a working Wine logs the same apartment errors. Build 7 fixes it with patches/winecx/0001: every process that does not run D3DMetal gets %gs on the TEB, as on Windows. Measured 29 Sep 2026 on an Apple M4, macOS 27.0, on an APFS clone of the Steam bottle with build 7's patched ntdll. DOOM was launched the way wyn play does: the frankea Steam plan (steam.exe -no-cef-sandbox -noverifyfiles -cef-disable-gpu -cef-in-process-gpu, vulkan-1=b, msync), then -applaunch 379720. What was seen: (a) DOOM's process logged '%gs is the TEB in Windows code' (WINEDEBUG=+gsbase) and mapped vulkan-1 and winevulkan. (b) It wrote DOOMConfig.local (r_renderAPI 1) at 01:01 and reached the main menu. (c) It was played in Arcade Mode, with profile.bin written at 01:03 and screenshots at 01:03 and 01:05, for 37 minutes (Steam: App Running 01:00:33 to 01:37:36) at 150-390% CPU and 1.3-2.0 GB RSS. (d) The quit was clean: Steam logged 'Game process removed' and no new Crash.*.html was written. The 12 Sep quit on 1.0 did write one. Updating the app alone does not replace an installed 1.1 runtime; run wyn runtime install --bundled --replace, or install fresh.\n\nVERIFIED 12 Sep 2026, Apple M4, macOS 26.5.1. id Tech 6 Vulkan (winevulkan → fly-mvkshim → MoltenVK 1.4.1 → Metal). No D3D layer is involved; translationLayer dxvk + dxvk false is the MoltenVK Steam launch path. Three conditions, all measured: (1) fly-mvkshim in the launching tree's Wine/lib, or vkCreateDevice fails VK_ERROR_FEATURE_NOT_PRESENT on the 15th and 39th VkPhysicalDeviceFeatures flags (depthBounds, shaderCullDistance). Wyn ships that shim as source: Tools/fly_mvkshim.c, built by scripts/build-mvkshim.sh, installed into the launching tree by WynWineInstaller.ensureVulkanFeatureShim (keyed on ProfileValidator.isVulkanNative, which this profile satisfies via WINEDLLOVERRIDES vulkan-1). The run measured here used a recovered Aug 2026 binary with no source (135,200 bytes, md5 e8e03ea1b3976f1db16580f5dc3e0bcd); the rewrite is verified to the same contract by Tools/fly_mvkshim_probe.c — stock MoltenVK 1.4.1 gives VK_ERROR_FEATURE_NOT_PRESENT, the shim gives VK_SUCCESS on Apple M4 — but the in-game run above predates it. (2) Launch THROUGH STEAM — wyn play doom-2016, no --direct. A hand-launched process has no COM apartment, XAudio2 2.7 is COM-only, and the game renders then sits at 91% forever with no ErrorLog (401 'apartment not initialised' in 45 s vs 1 via steam.exe -applaunch). Steam's GameOverlayRenderer64/steamclient create the MTA. (3) DOOMx64vk.exe must be where DOOMx64.exe is, because -applaunch runs Steam's default option: the OpenGL build, a dead end at Apple's GL 4.1 (ERROR_INVALID_VERSION_ARB). Since 28 Sep 2026 Wyn does this itself on every launch (executableSubstitutions; Steam's file is kept as DOOMx64.exe.wyn-bak), because Steam puts the OpenGL build back whenever it checks the install: a verify, and every fresh Steam client (measured: a 32 MB 'update' at the unchanged BuildID 13954591 that rewrote DOOMx64.exe, then FATAL ERROR: wglCreateContextAttribsARB failed). Launched from Steam's own Play after such a repair, DOOM still crashes; launch it from Wyn. Played: DOOMConfig.local at 00:06 with r_renderAPI 1 (Vulkan), profile.bin at 00:08. No ErrorLog on that run (earlier ErrorLogs were XAudio2 FATAL from --direct). Quit wrote CrashHandler ACCESS_VIOLATION in ntdll with no source address — Wine teardown, not the 91% hang. Two fragment pipelines fail to compile (in_TexCoord1 missing); did not stop play. Do not chase Denuvo BCryptDuplicateHash fixmes or Razer Chroma lines. Do not use Libraries.rgl.\n\nGOES BLACK WHEN YOU COME BACK TO IT, and it is not a Wyn bug — do not spend a day on it. Measured 12 Sep 2026. Alt-tab away and alt-tab straight back is FINE. It goes black when focus returns by a different route than it left: clicking DOOM in the Dock, or clicking into another app (a browser) and then coming back. The process is healthy throughout — 204-206% CPU, state Rs, simulating and rendering normally; it is presenting into a WineMetalView that is no longer on screen. Nothing is logged when it happens: no VK_ERROR_SURFACE_LOST_KHR, no OUT_OF_DATE, no error of any kind. WHAT DOES NOT FIX IT: a Wine virtual desktop. Wyn had a setting for it (#84) and it was reverted (#87) once research showed why — Wine's virtual desktop is an X11 display-driver feature and winemac.drv does not implement it. The checkbox is greyed out in winecfg on macOS (wine-stable 10.0, devel 10.5, staging 10.5, CrossOver FOSS 23.7.1), WineHQ's own answer is that building it would be 'extremely complex, so it likely won't happen', and Gcenx — whose macOS builds this runtime descends from — closed the matching issue as 'not planned'. So explorer /desktop=NAME,WxH is a quiet no-op here. The same sources add that a virtual desktop does not fix focus loss anyway: the problem repeats with the whole desktop window. Testing the setting on and off on this title compared a no-op with a no-op. WHAT ACTUALLY HELPS: run the game borderless/windowed rather than exclusive fullscreen, which skips the fullscreen-to-activation transition entirely. That is per-game config, not something Wyn wraps. Whisky has an open request for a borderless option (#1249), unanswered, repo archived May 2025 — this is a long-standing Wine-on-macOS limitation, not something this project introduced. IF SOMEONE DOES GO AFTER IT, the thread worth pulling: the log shows winevulkan using the deprecated vkCreateMacOSSurfaceMVK rather than vkCreateMetalSurfaceEXT, and MoltenVK's own guide says the CAMetalLayer's delegate should be the NSView containing it 'to ensure correct and optimized Vulkan swapchain and refresh timing behavior'. A layer MoltenVK cannot observe would explain a dead view with no surface-lost error. That is a Wine/MoltenVK fix, not a Wyn one. Also do not read the two 'Created 2 swapchain images ... WineMetalView' lines as evidence of the alt-tab: a later session had both at startup before anything was touched. The [mvk-*] lines carry no timestamps, and timing was inferred from them once and got it wrong.",
  "status": "verified"
}