Skip to content

Add Open in Admin Terminal mod#4247

Merged
m417z merged 2 commits into
ramensoftware:mainfrom
aimagist:add-open-in-admin-terminal
Jun 4, 2026
Merged

Add Open in Admin Terminal mod#4247
m417z merged 2 commits into
ramensoftware:mainfrom
aimagist:add-open-in-admin-terminal

Conversation

@aimagist
Copy link
Copy Markdown
Contributor

Changelog

  • New mod submission.
  • Adds a classic Explorer context menu entry to open an elevated terminal in the current or selected folder.
  • Supports folder background, folder item, drive root, Desktop, and optional navigation pane / Quick access targets.
  • Supports Auto, Windows Terminal, PowerShell 7, Windows PowerShell, Command Prompt, WSL, Git Bash, WezTerm, Alacritty, ConEmu, and a custom command.

Mod authorship

This mod was created by:

    • The submitter, without AI assistance
    • The submitter, with AI assistance
    • Claude
    • ChatGPT
    • Gemini
    • Another AI (please specify):
    • Other (please specify):

@m417z
Copy link
Copy Markdown
Member

m417z commented Jun 1, 2026

Submission review

Note: This review was done by Claude, and then refined manually. Due to the amount of submissions, doing a fully manual review for each pull request is no longer feasible. Thank you for understanding.

Please address the following issues. The items in the collapsed sections are optional, so it's your call whether to address them.

Also, update or remove the "Files" and "How to use" sections in the readme. Normally, users just have to install the mod, not to compile it manually.


The items below are mostly about the launch mechanism and the custom-command option.

1. Elevation is routed through a mandatory powershell.exe launcher. Every launch — even cmd, wt, wsl, etc. — is wrapped in powershell.exe -NoProfile -WindowStyle Hidden -EncodedCommand <base64 of "Start-Process … -Verb RunAs"> (BuildStartProcess, line 653). This has a few downsides for users:

  • Single point of failure: if Windows PowerShell (powershell.exe) isn't available on PATH, nothing launches regardless of the selected terminal. Microsoft is steering Windows PowerShell 5.1 toward being an optional/removable component, so this is a real robustness concern.
  • Wrong UAC label: the consent prompt names "Windows PowerShell" rather than the terminal the user actually chose, which is confusing.
  • It also pulls in ~150 lines of escaping/encoding machinery (EscapePS, BuildPSStringLiteral, QuoteProcessArgument, BuildPSArgumentArray, Base64Encode, EncodePowerShellCommand) that depend on Windows PowerShell 5.1's specific -ArgumentList concatenation behavior.

Recommend elevating directly with ShellExecuteEx + the runas verb instead — lpFile = the resolved exe, lpParameters = the per-terminal argument string, lpDirectory = the target folder. That elevates without an intermediary process, shows the real terminal in the UAC prompt, removes the powershell.exe dependency, and lets you delete almost all of the PS-quoting code. See keyboard-shortcut-actions.wh.cpp for the runas pattern.

2. The "Custom command" option never receives the folder path. When terminalChoice == "custom", BuildCommand (line 669) matches none of the if (choice == …) branches and falls through to BuildStartProcess(exe, {}, {}) — no arguments and no working directory. So a custom terminal opens elevated but at the default location, not at the right-clicked folder, which defeats the mod's purpose for that choice. Additionally, a custom string that includes arguments (e.g. wt.exe -d) is passed wholesale as -FilePath and won't resolve. At minimum, set the working directory to the target. Ideally, support a placeholder so the user can position the path explicitly — Windows itself uses %V for the folder in its built-in "open terminal here" command templates; substituting %V (and/or %1) with the target path would be the idiomatic, predictable option. (If you switch to ShellExecuteEx with lpDirectory per item 1, the working-directory half of this is solved for free.)

3. debugLogging setting + DEBUG_LOG macro reimplement something Windhawk already provides. Windhawk lets the user enable/disable a mod's logging from the UI and already prefixes log lines with the mod name, and Wh_Log compiles to a cheap guarded check that's disabled by default — so it's safe to call directly even in the menu path. You can drop the debugLogging setting and the DEBUG_LOG wrapper and just call Wh_Log where needed.

Optional improvements

Minor polish — none of this affects users, so it's your call.

  • GetSettingString (line 197) does a raw Wh_GetStringSetting + Wh_FreeStringSetting; WindhawkUtils::StringSetting is the RAII idiom for this. Also note Wh_GetStringSetting never returns NULL (it returns L"" when unset/on error), so the if (PCWSTR s = …) guard's fallback branch is effectively dead.
  • Hooks use raw Wh_SetFunctionHook with reinterpret_cast<void*> (lines 1555, 1562). WindhawkUtils::SetFunctionHook is the type-safe equivalent. (Low priority — files-2-folders uses the raw form too.)
  • -loleaut32 in @compilerOptions doesn't appear to be used (the code uses plain VARIANT structs but no oleaut32 API such as SysAllocString/VariantClear). Worth double-checking and removing if unused.
  • The simpler variant of Wh_ModSettingsChanged can be used: void Wh_ModSettingsChanged() {...}.

Functionality notes

Non-critical observations about the feature behavior itself.

  • position: Default placement is English-only. InsertAdminTerminalMenuItem (line 1406) finds its insertion point by matching the substrings "Open"/"Terminal" in existing menu item text. On a non-English Windows UI nothing matches and it silently falls back to the top. It degrades gracefully, but the "Default" placement won't behave as intended in other languages.
  • Per-menu resolution cost. Each right-click in a shell view resolves the target via CoCreateInstance(CLSID_ShellWindows) + an enumeration of shell windows. It's gated to shell-view / navigation-pane menus and mirrors how files-2-folders works, so there's no obviously cheaper route — just noting the small added latency on context-menu open.
  • Menu icon DPI. CreateMenuBitmapFromIcon sizes the bitmap from GetSystemMetrics(SM_CXMENUCHECK) (system DPI). On mixed per-monitor-DPI setups the injected icon may be slightly mis-sized on a secondary monitor. Purely cosmetic.

@aimagist
Copy link
Copy Markdown
Contributor Author

aimagist commented Jun 3, 2026

Thanks for the review — addressed the requested launch/custom-command/logging/docs items in e7665db:

  • Switched elevation to direct ShellExecuteExW with runas, so the UAC prompt is for the selected terminal executable.
  • Removed the mandatory PowerShell launcher dependency and the related encoding/trampoline machinery.
  • Fixed custom commands to parse quoted executable paths with trailing args, use the selected folder as the working directory, and expand %V / %1 placeholders in parameters.
  • Removed the custom debugLogging setting and DEBUG_LOG macro in favor of direct Wh_Log calls.
  • Removed the README Files and manual How to use sections.

Validation run locally:

  • Windhawk compliance script: compile check passed, no mechanical blockers.
  • Catalog scripts/compile_mod.py: passed for x86, x64, and ARM64.

@m417z m417z merged commit e2b57e7 into ramensoftware:main Jun 4, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants