Terminal: 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.

[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.

[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. :smile:

[vefatica]

We have been spoiled.