Where's the CASCADIA_HOSTING_CLASS_WINDOW window?

[vefatica]

I replied to "DISCUSSION: Is my app running in Terminal? #7434" but that reply isn't showing up anywhere (excuse me if I'm impatient).

With specific regard to a shell wanting to know where the Windows Terminal user interface is ...

I revisit this every now and then. I'm using the process ID of GetConsoleWindow() and a Toolhelp32Snapshot to find the parent process of OpenConsole.exe. Then I use EnumWindows() to find a CASCADIA_HOSTING_WINDOW_CLASS window belonging to that parent. It works, at least to my satisfaction, but it's a bit cumbersome.

Could you make the handle of the CASCADIA_HOSTING_WINDOW_CLASS window more readily available? One thought is to put it in the value of the WT_SESSION environment variable (along with the GUID which is (AFAICT) useless to the shell.

WT_SESSION=69f813f0-06ef-49d5-a64a-95359e0305c8, 0x303C0

A shell might be looking for the existence of that variable anyway. If it's value had more useful information in it, that would be great.

Am I wrong about the GUID? Is it of any value to the shell (or to anyone)?

[zadjii-msft]

Alrighty, there's two bits here:

• "I want to get at the Terminal's HWND"
  • I'm EXTREMELY reluctant to make this easier for anyone. Messing with the Console's HWND has only ever created compatibility issues that have been extremely challenging for us to deal with. I'd rather not repeat the mistakes of the past in that regard.
• Is WT_SESSION used for anything?
  • People are using it for.. various things. IIRC some people use it in scripts to change the current Terminal's settings? That feels like a mild fact. It's also not reliable, for a number of reasons.

[vefatica]

I don't want to mess with it; I only want to use it to position GUI thingies nicely with respect to the user interface. IIRC, others wanted to do the same thing.

You can get that HWND anyway. It's just the window of a user interface, hardly the sort of thing Windows keeps a secret. I don't see the big deal in making getting it easy.

[MitchBodmer]

@zadjii-msft one reason we might want to get the window handle is to hand it over to the WAM broker. In my neck of the woods this is the only approved way to authenticate console apps. Their official documentation linked above recommends the "not recommended" solution of using GetConsoleWindow with GetAncestor.

[zadjii-msft]

Where does it ever say that that is not the recommended way to do it? That's literally the way I recommended the WAM team to do that 🤣

[zadjii-msft]

For notes on my quest, see #2988 (comment)

[vefatica]

That was also recommended in this forum, quite possibly by @zadjii-msft. I have used it for several years.

HWND GetCascadiaWindow()
{
	WCHAR szClass[32];
	HWND hWnd = GetAncestor(GetConsoleWindow(), GA_ROOTOWNER);

	if	(
			hWnd == nullptr
			|| GetClassNameW(hWnd, szClass, 32) == 0
			|| lstrcmpW(szClass, L"CASCADIA_HOSTING_WINDOW_CLASS") != 0
		)
		return nullptr;

	return hWnd;
}

[MitchBodmer]

@zadjii-msft by "not recommended" I'm referring to the header on the documentation for GetConsoleWindow.

That's what I was trying to imply with the scare quotes. If this is the only recommended way to get the handle, then maybe we should consider removing that header in the GetConsoleWindow docs.

[vefatica]

Hmmm! I may have spoke too soon. Why does this function return nullptr when I'm in the debug tap?

HWND GetCascadiaWindow()
{
	WCHAR szClass[32];
	HWND hWnd = GetAncestor(GetConsoleWindow(), GA_ROOTOWNER);

	if	(
			hWnd == nullptr
			|| GetClassNameW(hWnd, szClass, 32) == 0
			|| lstrcmpW(szClass, L"CASCADIA_HOSTING_WINDOW_CLASS") != 0
		)
		return nullptr;

	return hWnd;
}

[DHowett]

Do not use the debug tap for production purposes. I'll be forced to remove it.

[vefatica]

What good would it be for production? I'm using it for debugging.

[vefatica]

Can you say why my function returns nullptr when TCC is in the debug tap?

[DHowett]

Not outside of business hours, I can't!

[vefatica]

Never mind; I figured it out.