Comment by quotemstr | Hacker News Reader

Comment by quotemstr | Hacker News Reader

Parent Full thread

Windows really needs a public psuedoconsole API.

For the uninitiated: cmd.exe is the shell, like bash. conhost.exe is the terminal emulator, like xterm. bash or cmd (the shell) talks to the terminal via its standard input, output, and error file handles. Terminal handles are like full-duplex pipes, but richer: they transmit all the information needed for interaction with the user. Each terminal handle has two ends: master* and slave. The slave is the terminal to which cmd or bash talks; it basically emulates a teletype. The master handle allows for reading both in-band and out-of-band information from the slave terminal handle and supports special APIs that allow anyone with access to the master handle to fully emulate a terminal.

POSIX systems allow anyone to create master and slave terminal handles. When you start xterm, xterm calls openpty, gets master and slave handles, starts your shell with the slave handle, and uses the master terminal to get the information needed to draw characters.

There's no equivalent for Windows. The only Windows program that can call the Windows equivalent of openpty is conhost, which ships with the operating system. It's not possible for a different program to make a master-side terminal handle. There are two workarounds, which both suck: 1) use pipes, not console handles, and 2) make a hidden conhost.exe and scrape it. The former causes programs to think they're being run non-interactively, with all sorts of negative side effects (like excessive buffering). The latter loses screen updates, is inefficient, and is generally awful.

Microsoft could easily make this situation much better by opening the protocol that conhost uses to communicate with the kernel. If any program can create a console handle, it's much easier to implement things like ssh daemons, Cygwin, and terminal emulators that suck less than conhost.

...

* As an aside: when bash talks to xterm, it uses in-band signaling (mostly: see termios): it sends control code sequences, which xterm understands as "move cursor to 3,3" and "set color to green". By contrast, when cmd communicates to conhost, it uses out-of-band signaling: it uses special API functions to move the cursor and set the text color.

Forking a process on Windows is really slow, making most opensource toolchains sluggish on Windows.

The UNIX philosophy is that everything is a file, so you can read and write from files and pass data around with convenient tools... that mindset is also missing in Windows.

Command lines were not foreseen as a preferred way of interacting with the system in Windows until recently. PowerShell tried to fill some gaps, and many tools integrate with it... but it's not the same. It has a long way to go.

Also, on Unix everything is a fd until it isn't, like timers, signals, semaphores , pids...(and sockets have their own peculiar API). Pids not being fds leads to a really annoying issue of basically not being able to easily implement a robust way of handling child exits

NT is more Unix than Unix in a lot of ways, where everything is an object (more or less)

Plan 9 though really ran with the whole file thing

> NT is more Unix than Unix in a lot of ways, where everything is an object

Yep. NT's design in this respect is great. Each NT object also has a name in a global system namespace; each object has its own access control list; and most objects are dispatcher objects that you can use with functions like WaitForMultipleObjects. In Windows, it's trivial to wait for, say, a socket* and a process at the same time.

I've always wanted to add NT-style process handles to Linux. A few other people have tried, but Linus has rejected their patches on the grounds that if you can open a handle to a process (preserving its PID), a program can fill up the process table.

I've never bought this argument. You can fill up the process table in other ways today without a ulimit, and we can make the process ulimit apply to process handles too.

...

* Screw you, in-process winsock providers. My programs treat sockets as regular HANDLEs, and if you install some shim that breaks this model, shame on you.

One day the capsicum port to Linux might happen, but in the meantime FreeBSD does have it, so has file descriptors for processes.

And signals, timers and events (inc semaphores) have non-standard fd versions too, but they've been bolted on and you need all kinds of new syscalls to make them work right.

Plan 9 did it right if you want to go "everything is a file"

Fork doesnt make a lot of sense on win32 processes (how do you handle a forked message loop?) so the functionality isn't exposed, though nt native processes can do it. The best you can do is a spawn equivalent with manual copying of structures so you lose the CoW fork semantics that allow for speed on Unix.

For Linux subsystem processes fork works pretty well, but they are different animals

> Fork doesnt make a lot of sense on win32 processes (how do you handle a forked message loop?

Message loops are per-thread and per-HWND (which are thread-affine) anyway. One way of making fork "make sense" in win32 processes is to say "Okay, you can fork, but your new process begins execution in a new thread, and none of the old threads survive."

New thread means new message loop. You could even do things like automatically tear down single-threaded COM apartments in the child process.

Fork was implemented in the NT kernel for WSL - https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process...

Fork worked already, as the article notes. What I really want is fork to work for the win32 subsystem! I want Cygwin, not WSL! I want tight integration between the POSIX and Win32 worlds, not the pseudo-container that WSL gives you.

There is a third way: you can create PowerShell Host application with the same .Net API that PowerShell ISE uses.

I tried that --- specifically, I made a readline-powered psh host for my own use. There are a few problems in practice:

1) readline hardcodes the backslash in a bunch of places, especially in history expansion. Psh needs '^', not '\'.

2) the psh hosting APIs aren't ready: powershell.exe uses a few internal APIs to which other hosts don't have access, and without these APIs, psh does helpful things like wrap lines at 80 characters and paginates output.

I also recall there being some problem with psh's completion.

Still, it's amazing that embedding the CLR and posh inside a Cygwin process works at all.

Is there any historical reason that conhost is the only executable able to open a master handle?

Well, originally, console handles weren't real handles. They were userspace hacks, which is why DuplicateHandle[1] has special cases for console handles. (Imagine using negative file descriptor values that libc understood.) Originally, the terminal emulator ran as SYSTEM and was spawned from (IIRC) csrss (which is special, because reasons). In Vista, with integrity levels introduced, the terminal emulator had to run in a different security context, and so wasn't themed. (To prevent shatter attacks.) In Windows 7 and 8, Microsoft developed a real, honest-to-god pseudoconsole API, with a real protocol. In this implementation, console handles are real handles and conhost is just a normal program that speaks a protocol.

IIRC, the only thing at this point stopping Microsoft creating a pseudoconsole API based on real, honest-to-god kernel HANDLEs is a willingness to externalize, document, and support what has been until now a Windows-internal API.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...

Regarding a public API, this GitHub comment suggests that people at Microsoft are working on it.[1] Of course, Microsoft can't commit to anything. As the winpty maintainer, I hope some kind of public API emerges to reduce my maintenance burden and make winpty more robust and efficient.

Aside: About a year ago, I studied how the console handles worked (especially in relation to console attach/detach/alloc and CreateProcess), and I discovered a bunch of interesting things. For example, the "fake" handles were inherited regardless of the bInheritHandles parameter to CreateProcess, and an entire "ConsoleHandleSet" was inherited if a process attached to another process' console. Real handles in Win8 seemed to be either "bound" to a particular input/screen buffer or "unbound" so they worked with any attached console. It was possible to have a console open with no attached processes.

I tried to formalize the behavior I observed here: https://github.com/rprichard/win32-console-docs

In the course of testing, I found some neat bugs like:

- A small program that blue-screens Vista

- The inheritable flag on a console handle can be changed on any Windows version, except for Windows 7.

- CreateProcess has an undocumented(?) behavior where it duplicates stdio handles into the new process rather than inherit them. (The handle values will generally change.) Up until Windows 8.1, a stdio handle of INVALID_HANDLE_VALUE was duplicated into a true handle to the parent process. (Because INVALID_HANDLE_VALUE is actually the GetCurrentProcess() pseudo-handle, you see.)

- Assorted inconsistencies in Windows XP and WOW64 (probably fixed in newer OSs).

I'm not sure how much confidence I have in the spec. It is backed by a big test suite, but there are so many cases to consider.

[1] https://github.com/Microsoft/BashOnWindows/issues/111#issuec...

> winpty

Cool. There's a third option that you might want to consider for winpty. (I was experimenting with it before I left Microsoft.)

The basic idea is to use a DLL shim to provide your own console API implementation for a process and its children --- you can replace the system console API with your own by shimming DLL import and export tables. You'd use your own type of pseudohandle for your fake console handles; programs written to work with the old console pseudohandles should work correctly with your pseudohandles, provided you've hooked the relevant HANDLE-using APIs.

Yeah, I considered that route, but I was concerned that it'd be unreliable -- maybe with other programs doing clever tricks with import/export tables, or maybe with antivirus. I can't think of a specific reason it wouldn't work, though. I think it'd have to override CreateProcess to propagate the API hook. IIRC, ConEmu's CreateProcess starts a child in a suspended state so it can install its hook before resuming the child. Maybe it'd have to hook GetProcAddress, too.

I was assuming I'd use genuine console handles, but recognize that they're associated with the special console, so divert their API calls.

Maybe the technique would make programs slower. I know that's a complaint people have about ConEmu.

There's a similar (4th?) technique I've considered -- instead of hooking every process attached to the console, hook APIs in the conhost process and reimplement the internal protocol. It should avoid the performance problems and confine the hackiness to one address space. The trouble is that the protocol is undocumented. A small change could break everything without warning, but MS could also redesign the whole thing, making a fix impossible.

I also tried using the console accessibility APIs [1] to at least synchronize scraping and forwarding to the pty. The problem with this approach is that the console code issues EVENT_CONSOLE_UPDATE_REGION and such with its internal locks held, so attempting to read from the console from inside the accessibility handler deadlocks.

[1] https://msdn.microsoft.com/en-us/library/ms971319.aspx

To do that, you have to attach the conhost.exe process to its own console with AttachConsole, right? I tried that and also noticed the deadlock. An out-of-context handler avoids the deadlock, but then it's not synchronized.

The other interesting problems I found with that API were: (1) when editing an input line, EVENT_CONSOLE_CARET notifications were delayed, (2) if I hit ESC when editing an input line, the line would clear, but there'd be no update-region notification, and (3) it's impossible to distinguish between a call to ScrollConsoleScreenBuffer and the whole buffer scrolling because we've reached the end. ScrollConsoleScreenBuffer might scroll only part of the buffer.

winpty doesn't use the WinEvents API (yet), but it might be good enough to reduce polling when the console is idle.

> - A small program that blue-screens Vista

You mean like on current up-to-date versions of Vista and Server 2008? With a PoC on the github page? You realise that you have found a security vulnerability and are disclosing it publicly, right? Userspace must never crash the kernel, even if not further exploitable, especially so if it's possible for an unprivileged user. Be responsible, send a mail to secure@microsoft.com

Yes, it's a tiny program that (1) detaches the console, (2) attaches a new console, (3) closes all screen buffer handles, then (4) creates a new screen buffer. The fourth step caused a BSOD on Vista and Server 2008. AFAIK, they were up-to-date.

I did report it to Microsoft before making it public. The reply was:

> Thank you for contacting the Microsoft Security Response Center (MSRC). I would suggest trying on a local VM to confirm BSOD. However, this currently is just a local DOS, which would would not be something we would investigate further. If you have any additional information on how this could be further used to exploit another user or a remote DOS, please let us know and we will look into it.

> For an in-depth discussion of what constitutes a product vulnerability please see the following:

> "Definition of a Security Vulnerability" <https://technet.microsoft.com/library/cc751383.aspx>

>Again, we appreciate your report.

I might be suffering from reverse nostalgia, but it was never hard to bluescreen Vista, and I never considered those issues worth reporting.

Just debugged it and it looks like a NULL pointer read in CSRSS, in winsrv!SrvCreateConsoleScreenBuffer.

In fact, the same bug exists in XP, but the NULL page is mapped in XP which is why it does not BSoD. So far I have not seen writes, only reads.

Update: it looks like the NULL pointer is accessed several times in the code. They mostly are 16-bit accesses, so it is probably not addresses. They seems to be in font-related code.

Yes. Please report these bugs!

On Vista, conhost.also ran in user context and console windows were themed, on XP they was not. I believe that conhost.exe was introduced in Vista together with new desktop separation mechanism and on earlier version all the console window logic was internal to csrss (which in original NT design was essentially display server and window manager and placing console emulation in there makes some kind of sense given the NT's model of that).

Ah, yes, you're right! The windows were created directly.

Win7, not Vista.

How do you know all this? :)

Three years on Windows and Windows Phone. I sometimes miss those days. :-)

Conemu doesnt suck and it uses method 2. It has few quirks but nothing serious and is almost on pair with usability as tmux and in some aspects even better.

I use conemu at work. It's not as awful as some alternatives. I would recommend it, but I can't say that it's a good experience. Maybe I'm doing something wrong here... do you run vim in conemu? For me, it's slow when redrawing lines of text while paging and sometimes renders artifacts in the pane, especially when I vertically split vim.

For a command line interface, I find it to be fairly unstable, too.

I use vim in cmder occasionally. The only way I've been able to use it properly is to disable conemu hooks before I execute it.

Basically, I've defined a function my profile to:

* Save the ConEmuHooks environment variable value * Set it to "Off" * Execute vim * Reset it to the previous value

I alias this command to "vim".

It's not pretty at all, and it caused me to use Sublime or VSCode most of the time, but it worked for me.

More info here: http://conemu.github.io/en/ConEmuEnvironment.html

Why would you do that when gvim is available and is ways better experience then vim ? For the sake of being shell purist ? On remote shell ?

I'll give this a shot, but I'm unclear how the hooks affect vim or other processes-does this address all of my vim+conemu problems? Thank you, in any event.

Have you tried Cygwin vim in mintty?

Also, Emacs has a mode where it'll run as a Cygwin process, but use native win32 widgets. I've found using it to be the most pleasant way of interacting with Windows systems.

When I was at Microsoft, I joked that I wasn't so much running "Windows" as GNU/NT. :-)

Agreed. It's the best terminal emulator I've found on windows. I usually use it for other shells and avoid cmd like the plague but, whatever shell you use, it's a far better app than conhost.exe.

I haven't experienced the instability that others have but I do find its configurability a bit excessive. Somehow I want it to be much simpler but still do everything that it does now. I don't know the way to achieve this but I believe it's possible.

Cmder is basically Conemu plus Clink with nice defaults and useful initial profiles.

I tried it a few times, but it always crashes rather quickly. So it sucks.

Have you tried using vim inside it?

Conemu does a decent job given all the restrictions the Windows platform has, but it's still miles behind a real Linux terminal emulator.

No... there is no need for that on Windows. I use gvim all the time.

Reply on news.ycombinator.com