592c634577
Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows Terminal as Administrator. This is caused by the app execution alias and the actual targeted executable not having the same name. In addition, PowerShell has an issue detecting app execution aliases as GUI/TUI applications. When you run wt from PowerShell, the shell will wait for WT to exit before returning to the prompt. Having a shim that immediately re-executes WindowsTerminal and then returns handily knocks this issue out (as the process that PS was waiting for exits immediately.) This could cause a regression for anybody who tries to capture the PID of wt.exe. Our process tree is not an API, and we have offered no consistency guarantee on it. VALIDATION ---------- Tested manual launch in a number of different scenarios: * [x] start menu "wtd" * [x] start menu tile * [x] powertoys run * [x] powertoys run ctrl+shift (admin) * [x] powershell inbox, "core" * [x] cmd * [x] run dialog * [x] run dialog ctrl+shift (admin) * [x] run from a lnk with window mode=maximized Fixes #4645 (PowerShell waits for wt) Fixes #6625 (Can't launch as admin using C-S-enter)
17 lines
391 B
C
17 lines
391 B
C
//{{NO_DEPENDENCIES}}
|
|
// Microsoft Visual C++ generated include file.
|
|
// Used by wt.rc
|
|
//
|
|
#define IDI_APPICON 101
|
|
|
|
// Next default values for new objects
|
|
//
|
|
#ifdef APSTUDIO_INVOKED
|
|
#ifndef APSTUDIO_READONLY_SYMBOLS
|
|
#define _APS_NEXT_RESOURCE_VALUE 102
|
|
#define _APS_NEXT_COMMAND_VALUE 40001
|
|
#define _APS_NEXT_CONTROL_VALUE 1001
|
|
#define _APS_NEXT_SYMED_VALUE 101
|
|
#endif
|
|
#endif
|