OpenConsole.exe vs conhost.exe, questions

[vefatica]

I stumbled on a thread here where it was pointed out that OpenConsole.exe could replace conhost.exe. While I did not replace conhost.exe, I found that is was easy enough to start a console app in OpenConsole instead of conhost. I've simply used my favorite shell ... "openconsole.exe d:\tc26\tcc.exe". And that gives me many questions.

Is there a place where I can read about command line arguments for OpenConsole and/or the differences/similarities between OpenConsole and conhost? I noticed that OpenConsole reads HKCU\Console. Can I get it to read a subkey of HKCU\Console?

One noticeable difference is that after setting custom tabstops (usingTBC and HTS), those settings are lost if I "CMD /C" while using conhost.exe (first pic below), and they're not lost if I do the same thing while using OpenConsole (second pic below). What's the difference there. ["CMD /C" is nothing special. There are many ways I can clobber the tab settings in conhost and not in OpenConsole.] Thanks in advance. - Vince

Conhost:

OpenConsole:

[zadjii-msft]

Fundamentally, they're the same thing. When the code in this repo for openconsole.exe is built by the Windows build system, it turns into conhost.exe. Really, the only difference you're gonna see between the two is that the OpenConsole in this repo (and that ships with the Terminal) has a few more months of bug fixes and features added to it relative to the conhost.exe in your system32. If someone's interested, I could give a history lesson on why the two are named differently, but that's more of an aside.

We're explicitly not documenting the arguments to conhost, because then 3rd party developers could take a dependency on those arguments, and we would have a lot less flexibility in changing them in the future. Generally, the arguments only exist to help support conpty scenarios. If we really needed to change them in the future, we like keeping the door open for that. The astute reader could go looking through this repo to find the args to conhost if they really wanted, but again, there's no contract here - those are subject to change at any time.

As far as the tab stops thing - what version of Windows are you on? We had a change a while ago where turning VT support off and on would reset the tabstops set by VT. And for reasons that I don't want to get into the weeds on, cmd.exe will disable VT support when launching a child process, then re-enable it when it starts. So doing cmd.exe will probably cause VT to get toggled, resetting the tab stops. I'm sure I could go look up the actual issue # for where we changed the tabstop behavior - I'm pretty confident it was after we started using this repo to track issues.

[george-tsiros]

We're explicitly not documenting the arguments to conhost, because then 3rd party developers could take a dependency on those arguments, and we would have a lot less flexibility in changing them in the future.

Looking back in history, this approach will not have the result you describe. Documented behavior or not, intended behavior or not, developers will use them.

Only way I can think of that could maybe let you remain in some control(but not really) is if you promise, in writing, explicitly, that you will refuse even to discuss the possibility of keeping undocumented/unintended behavior ... and keeping that promise

("but not really" because it is simply impossible to control how others will use your software)

Tangentially related oblig. xkcd ref. 1172

[vefatica]

Thanks for your response, Mike.

As for the tab thing, as I said, cmd.exe is not special. I'm pretty sure it's my shell doing what cmd.exe does ... turn VT processing off/on in various scenarios. I see evidence of it when starting just about anything, including pipe instances. Making the tab settings "static" is a nice touch (and suits me just fine).

I found the command line args in the source (nothing very interesting to me). When I "openconsole.exe myshell.exe", it's not same as Windows using conhost.exe. Openconsole.exe becomes the parent of myshell.exe, an apppropriate subkey of HKCU\Console is not read (if it exists), the console does not automatically display myshell's icon, and probably more differences I'm yet to discover. From your remarks I suppose that would change if Windows actually used openconsole.exe. Short of actually replacing conhost.exe with openconsole.exe (I've read several "no guarantees" from you (Mike) and Dustin) is there a way to mimmick running an app in openconsole.exe the same way that Windows runs an app in conhost.exe?

[vefatica]

You asked and I neglected to reply. I'm on

Microsoft Windows 10 Pro for Workstations
10.0.18363.1139 (1909)

Should I expect conhost.exe to reset the tabstops when VT is toggled?

[zadjii-msft]

So technically, yes, there's a way to do it, but I'm not positive that this counts as supported. So HERE BE DRAGONS.

Technically, what happens when the OS determines that you're launching a console application that doesn't currently have a console server, it creates a new conhost for that process, and aclls some private APIs to re-parent the commandline application as a child of conhost.exe. In order to connect the client to the conhost.exe it's about to spawn, it creates a bunch of console handles in ConDrv, and passes the server handle to conhost on the commandline. That's why you'll see the commandline for conhost typically be conhost.exe 0x4 - 0x4 is the value of the console server handle that the OS has created for this console instance.

You know what, now that I've typed this all up, I'm pretty sure there isn't a way to do this publicly. That private API, the one that re-parents a process, that's probably the one you really want to be able to call. I'm pretty confident that we won't be able to make that one publicly available.

Running openconsole myapp.exe was really only ever intended as a quick-and-dirty way to iterate quickly on console features, without needing to wait for an entire windows build. It's a happy coincidence that it has worked so well for us to be able to use it as a side-by-side conpty host for the Terminal. I'd again caution against using it in production 😃

---

As far as the tabstops thing - I asked for your version number, but I honestly have no recollection of when that was actually changed. #140 looks like it's about what we're looking for, but then that would have shipped in 1809, so that's not right. Then there was #4669/#5173, which is a good amount more recent. Judging only based off of bot comments, this one hasn't made it to an Insider's build yet, but that can't be right - @DHowett did the bot miss a bunch of commits when we just bulk merged a bunch of stuff to OS>

[DHowett]

The bot that comments on insider build merges is me :) and this was one of the earlier fixes we made, so I almost certainly didn’t have a process for tracking them back then. I believe James fixed tab stops?

[vefatica]

Thanks again. Sometime fairly recently I read about a re-parenting hack but that's not sufficiently important to make me look for it again. I was more interested in the convenience of getting OpenConsole automatically. Do you want reports of differences between OpenConsole and Conhost ... even when Conhost seems to have the edge? Two are pretty obvious.

1. Conhost sets the icon while OpenConsole doesn't.
2. I use the dark theme in Windows 10. Conhost has dark scrollbars; OpenConsole has light ones.

[yegor-mialyk]

I use the dark theme in Windows 10. Conhost has dark scrollbars; OpenConsole has light ones.

#17831 (just for reference)

[DHowett]

I would go so far as to say: no, we do not want such reports. They are built out of the same code (delta a couple private APIs). OpenConsole is not a shipping production scenario and we will not be changing it to address any perceived differences from conhost.

[DHowett]

(The icon/registry key/shortcut detection is broken because OpenConsole isn’t receiving the LPSTARTUPINFO that the erstwhile parent process started with... because it isn’t being spawned in response to somebody else needing a console handle.)

[DHowett]

If you want to get OpenConsole automatically, replace conhost on your system. No warranty is expressed or implied. Right now, it’s the only way.

Eventually, the spec in #7414 will land and we’ll agree on how to seamlessly replace conhost with some other console host.

[eryksun]

[calls] some private APIs to re-parent the commandline application as a child of conhost.exe

The conhost.exe process is the child of the allocating process. That has been the case since the ConDrv device was introduced in Windows 8. IIRC, in the old Windows 7 implementation that used ALPC pseudo-files instead of a device, each conhost.exe session was created by the desktop session server, csrss.exe.

From what I remember from the last time I walked through this in a debugger, the console init routine in kernelbase does basically the following steps:

• open "\Device\ConDrv\Server"
• open "Reference" relative to the "Server" handle
• make an ioctl to the "Server" file to pass the parameters for the new conhost.exe server process
• wait for ConDrv in the kernel to create the session server process
• open "Connect" relative to the "Reference" handle via NtCreateFile. IIRC, the call passes connection information -- such as the current process STARTUPINFO -- via the EaBuffer argument (extended attributes). The handle for the "Connect" file is the process ConsoleHandle, which is used for miscellaneous console functions such as GetConsoleCP.
• open the generic "Input" and "Output" files relative to the "Connect" file, and duplicate the handle for the "Output" file. The handles for these files are the process StandardInput, StandardOutput, and StandardError handles
• set the PID of the conhost.exe server as data in the current process via NtSetInformationProcess: ProcessConsoleHostProcess
• initialize the console control handler list to the default handler function that calls ExitProcess(STATUS_CONTROL_C_EXIT)

[vefatica]

I replaced conhost (briefly). It worked OK but I didn't like looking at the white scroll bar.

[DHowett]

Ah, console users can be so picky. 😄

[vefatica]

We have been spoiled.

[3N4N]

@DHowett sorry to resurrect an answered thread but I had a small question.

In the old console, we could do something like the following to change the console icon from inside an external TUI program.

hWnd_variable = GetConsoleWindow();
SendMessage(hWnd_variable, WM_SETICON, (WPARAM)ICON_SMALL, (LPARAM)hIconSmall_variable);

(The example ^ is from vim codebase.) It doesn't seem to change the icon in the Windows Terminal tabs. Is there a similar API which handles such cases?

I read the thread. Can't say I followed much. Apologies if it's already been answered. I realize this repo is absolutely brimming with people engaging, asking, wanting. Must be exhausting.

[3N4N]

I suppose the modern way to do this would be with a VT control sequence

That was my first thought, but I couldn't find any control sequence related to icons in the docs. I'm not experienced with terminal sequences. There might be sequences related to icons in xterm or other *nix terms, which may be implemented in conpty but not documented?

[j4james]

I suppose the modern way to do this would be with a VT control sequence

FWIW, this has been discussed before. See issue #1868.

[vefatica]

There might be sequences related to icons in xterm or other *nix terms

I looked too (only a little) and I didn't find anything.

[3N4N]

Thanks, j4james. That thread is what I was looking for today (and somehow totally missed). I'll keep following that.

It seems like no such sequence is implemented in conpty yet. No biggie. As vefatica said, it's only a novelty anyway.

[DHowett]

I realize this repo is absolutely brimming with people engaging, asking, wanting. Must be exhausting.

In a way, but also being so close to our community is exhilarating and gives us purpose. 😄

no such sequence

Unfortunately, yeah. This is one of the places where I'd love for us to magically bridge the divide between Windows and VT. We just got our first win32 message handler in ConPTY, and I am imagining this crazy world where we could intercept a WM_SETICON and stuff it down the wire and somehow surface that as a tab icon.

There's a mapping from most console APIs to VT, but once we get outside of the console API world (which we own) into the broader "somebody messed with the window handle we gave them" world of win32 APIs (which we emphatically do not ☹️) it gets harder.

[vefatica]

Somewhat along these lines ...

My preferred shell, TCC, used the position and size of the ConsoleWindowClass window to locate and size various things (options diablog, pop-up command and directory history, MSGBOX command). Things are less than optimal when it's using the position and size of the PseudoConsoleWindow window. I can move/resize the PseudoConsoleWindow class window to match the CASCADIA_HOSTING_WINDOW_CLASS window (is that OK?). And that makes things better. But there's another problem ...

Using some of TCC's GUI features cause the PseudoConsoleWindow class window to be shown (it's not very interesting). Can that window be made to keep itself from being shown?

And, a little to my surprise, the PseudoConsoleWindow class window has WS_VISIBLE by default (so says Spy++). ... ?????

[vefatica]

I was hoping for a response. I found that the PseudoConsoleWindow doesn't seem to suffer if it's made message-only. This keeps it from being shown (and from receiving broadcast messages, which doesn't seem to be a big deal). With a one-process/one-event WinEventHook I can make the PseudoConsoleWindow sync with the CASCADIA_HOSTING_WINDOW_CLASS window in size and location even though it can't be seen. That helps a lot with TCC using the size and position of the window returned by GetConsoleWindow.

And a question: Having done what's mentioned in the paragraph above, I noticed this. When TCC returns from an excursion into GUI-land it tries to set the foreground back to the console. The PseudoConsoleWindow (now message-only) can't be shown, but it does become the foreground window (perhaps briefly) and when this happens, if the mouse pointer is in the WT window (now same size/place as pseudo_con window), it turns into the "busy" pointer (spinning blue ring) and stays that way until the mouse is moved or clicked. I can work around that, but my question is ... is that WT doing that (showing the busy pointer) or is it Windows?

[zadjii-msft]

Sorry, been out on paternity. Just getting back now, and still very far behind.

For what it's worth, the PseudoConsoleWindow got a lot of changes just a few months ago (1.15 IIRC), and we definitely haven't fully kicked the tires on it yet. What you're all describing here is probably more extensive hacking on it since the changes, than anything we've tried with it.

I'll repeat the party line - don't rely on GetConsoleWindow. It will not always work the way you expect, it won't work in remote scenarios, it won't work in other terminal emulators. Anything you get from that should be considered an internal implementation detail who's behavior is subject to change. I don't have a better recommendation for trying to mix GUI experiences with CUI ones, but GetConsoleWindow is not the correct long-term answer.

We do have quite a few issues at the moment with the PseudoConsoleWindow being focus/foregroundable. That's not intentional and something that I'd really like to figure out. I'm under the impression that we need to keep WS_VISIBLE in sync with the hosting terminal, so that ShowWindow works as expected, but there's gotta be another way of hiding it from focus. I've got more work to do with @ekoschik on that matter.

[vefatica]

so that ShowWindow works

Do you really want the PseudoConsoleWindow to be showable? As I said earlier, it's not very interesting. I have been making it HWND_MESSAGE for about a week. That prevents it's being shown. Will I run into problems? What does that window do anyway?

Paternity recent? ... Congrats!

[zadjii-msft]

Do you really want the PseudoConsoleWindow to be showable

No, sorry, I was referencing #12570. The PseudoConsoleWindow has many purposes, but here, its purpose is to sync calls to ShowWindow(GetConsoleWindow()) with the hosting terminal.

Paternity recent? ... Congrats!

Yep, baby 2 came this last September. Thanks!

[vefatica]

No, sorry, I was referencing #12570. The PseudoConsoleWindow has many purposes, but here, its purpose is to sync calls to ShowWindow(GetConsoleWindow()) with the hosting terminal.

I really didn't follow #12570 very well. Is there a plan to make GetConsoleWindow more friendly when it's a PseudoConsoleWindows? If anything is implemented, could you please mention it here?