starting Terminal with wt no longer returns the main window handle of the resulting window

[torchgm]

Environment

Windows build number: 10.0.20175.0
Windows Terminal version (if applicable): 1.2.2022

Any other software?
N/A

Steps to reproduce

Open Windows Terminal 1.2.2022 from code that supports returning the main window handle; for example in C# .NET

using System;
using System.Diagnostics;
using System.Threading;

namespace Test
{
    class Program
    {
        static void Main(string[] args)
        {
            Process p = Process.Start("wt"); // Start Windows Terminal
            Thread.Sleep(1000); // Wait a second to make sure it's open
            Console.WriteLine(p.MainWindowHandle.ToString()); // Print handle to console
            Console.ReadLine(); // Wait for user input before finishing
        }
    }
}

Expected behavior

The handle for the subsequently opened window is returned. In the example above, a numerical value representing the window handle is printed to the console (such as 856282)

Actual behavior

A handle of 0 is returned.

[torchgm]

Alrighty, just discovered the reason for this being #6860, and fair enough it's not an API, although would it be possible to also reinstate a direct app execution alias as WindowsTerminal (or wtalias, or something like that)? It would be very-much appreciated.

[DHowett]

What is your use case?

[torchgm]

Probably rather petty, but it was the only reliable way to alter its parent without user interaction and as such be able to do stuff such as use it as a desktop wallpaper:

It's probably possible to just start the process and then iterate through every window until I find something with the correct title but that feels super-messy and isn't very reliable.

[KalleOlaviNiemitalo]

Could reparenting instead be implemented as a command-line option similar to xterm -into windowId? Related to #4572.

[zadjii-msft]

I'm just gonna put this out there, with the process model changes coming in #5000, I'm fully expecting this (officially unsupported) scenario to break further.

[torchgm]

I'm well-aware this isn't supported officially in any capacity, although this same ability to set an app as a wallpaper works pretty consistently across even more complex apps; I'm not expecting it to be perfect nor would I ever ask for any changes that would solely benefit such a scenario, although it would be really nice to have a traditional alias available as well as the shim. I do however entirely understand if this isn't feasible and'll happily respect that.

[DHowett]

So, okay, this is really cool and I'm sorry we broke it. We've got some changes in store that are probably going to make this worse before it makes it better. Once #5000 lands, even WindowsTerminal.exe isn't really going to have an HWND to hand out...

@zadjii-msft: gvim supports a --windowid parameter that allows for hosting. 1-10 how mad would it be if we ... did something that .. was horrible like that?

[torchgm]

I mean something like that would be perfect! I just tried it out in vim and now I have it stuck as my wallpaper so that's fun. And no worries about breaking anything, it's to be expected! Terminal is still super-awesome anyway and I'd hate to have silly little things like this hold it back; I can't wait to see the changes you have planned come to fruition.

[DHowett]

If I can suggest a somewhat obnoxious workaround for now: launching WT with --title [something you will recognize] and enumerating looking for that title might work acceptably. It's not excellent, but it is passable.

[torchgm]

I'll probably end up doing that for now, thank you!