Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing the Windows Pseudo Console (ConPty)

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

81–90 of 196 posts

Re: Introducing the Windows Pseudo Console (ConPty)

#81

Post by rossy »

zadjii wrote: post #32
rogerbinns wrote: post #12

Earlier quoted context omitted.

Have you given thought on how to solve the "unwanted console" problem? For example if you run a .py file (Python) under Windows then you get a console. That is fine for command line stuff, but beyond annoying if the file displays as a gui. So there are now two Python binaries - python.exe and pythonw.exe. The only difference is the latter ensures no console appears. Also good luck if the script printed a help message…

Technically, any executable that's compiled as a commandline application is going to get a console allocated for it, no matter what on Windows. I don't believe that's something we can fix retroactively unfortunately, that's just a part of how things have to be. Now, I believe that python could have python.exe compiled as a win32 application, then call AllocateConsole as soon as the script called print() or something.…

I think the behaviour of cmd.exe is part of the problem here. When an interactive cmd.exe launches a console-subsystem app, it waits for the process to finish before showing the prompt again, but when it launches a GUI-subsystem app, cmd.exe writes the prompt again immediately, so even if the new process calls AttachConsole(ATTACH_PARENT_PROCESS) before it tries to write to the console, it will write over cmd.exe's prompt, which makes a poor user experience.

So, if someone wants to make a "dual-mode" app that works as a win32-subsystem app when launched from Explorer and a console-subsystem app when launched from a console, they have to choose between two bad options. They can make their app a console-subsystem app, which means a console will always briefly appear on screen when the app is started (no matter how quickly the app calls FreeConsole(),) or they can make their app a GUI-subsystem app (that opportunistically calls AttachConsole(),) which behaves sub-optimally in cmd.exe.

Maybe the solution is to add a flag (in the .manifest file?) that makes the console initially hidden for a console-subsystem app. That would prevent the brief appearance of a console window when launching a console-subsystem app from Explorer. Then there would be no need for pythonw.exe and python.exe could show the console window only after a message is printed.

Re: Introducing the Windows Pseudo Console (ConPty)

#82

Post by [deleted] »

cryptonector wrote: post #58
zadjii wrote: post #46

Earlier quoted context omitted.

It is! But this is a very un-windows like feature, isn't it? We want this to work on other platforms with as little modification as necessary, and frankly, jumping through the wchar_t char hoops is a _pain_. So we'll do it for you!

Hear hear! wchar_t is a disaster. UTF-16 is terrible. I'm not at all convinced that 2^21 codepoints will be enough, so someday it'd be nice to be able to get past UTF-16 and move to UTF-8, and Windows and ECMAScript are the biggest impediments to that. Your choice of UTF-8 will tend to place UTF-8 on a level playing field in Win32. I guess, too, that this is the end of codepages -- I doubt they'd go away, but there s…

[deleted]

Re: Introducing the Windows Pseudo Console (ConPty)

#83

Post by mehrdadn »

cryptonector wrote: post #58
zadjii wrote: post #46

Earlier quoted context omitted.

It is! But this is a very un-windows like feature, isn't it? We want this to work on other platforms with as little modification as necessary, and frankly, jumping through the wchar_t char hoops is a _pain_. So we'll do it for you!

Hear hear! wchar_t is a disaster. UTF-16 is terrible. I'm not at all convinced that 2^21 codepoints will be enough, so someday it'd be nice to be able to get past UTF-16 and move to UTF-8, and Windows and ECMAScript are the biggest impediments to that. Your choice of UTF-8 will tend to place UTF-8 on a level playing field in Win32. I guess, too, that this is the end of codepages -- I doubt they'd go away, but there s…

Confused, where does 2^21 code points come from and how is that related to the UTF-16 vs. UTF-8 distinction? Can't both of them encode all Unicode code points? Or are you thinking of code units perhaps, and UCS-2? Although even there I'm confused where the 2^21 came from.

Re: Introducing the Windows Pseudo Console (ConPty)

#84

Post by swozey »

JonathonW wrote: post #78
swozey wrote: post #60

Earlier quoted context omitted.

Could you elaborate? I've been under the guise for most of my career that doubling a digit leads to huge benefits that I'm too comp-sci ignorant to understand.

UTF-16 has a bit of a funky design (using four byte/two code unit surrogate pairs to encode code points outside the basic multilingual plane) that ultimately restricts Unicode (if compatibility is to be maintained with UTF-16, at least) to 17 planes, or 2^20 code points (about 1 million). UTF-8 uses a variable length encoding that allows for more characters-- if restricted to four bytes, it allows for 2^21 total code…

Thank you, this was an incredibly understandable explanation.

Re: Introducing the Windows Pseudo Console (ConPty)

#85

Post by asveikau »

While we're talking Unixisms, Windows needs a dup2(2). That is, given a HANDLE, you should be able to swap out its backing kernel data structure with that of another HANDLE.

Without this, I/O redirection is slightly broken. Last I checked you can't change where stderr goes after the process starts, for example. [SetStdHandle doesn't do it at the right layer.]

Re: Introducing the Windows Pseudo Console (ConPty)

#86

Post by exikyut »

zadjii wrote: post #32
rogerbinns wrote: post #12

Earlier quoted context omitted.

Have you given thought on how to solve the "unwanted console" problem? For example if you run a .py file (Python) under Windows then you get a console. That is fine for command line stuff, but beyond annoying if the file displays as a gui. So there are now two Python binaries - python.exe and pythonw.exe. The only difference is the latter ensures no console appears. Also good luck if the script printed a help message…

Technically, any executable that's compiled as a commandline application is going to get a console allocated for it, no matter what on Windows. I don't believe that's something we can fix retroactively unfortunately, that's just a part of how things have to be. Now, I believe that python could have python.exe compiled as a win32 application, then call AllocateConsole as soon as the script called print() or something.…

Hmmm.

MSDN doesn't really say much about AllocConsole(), if that's the right function: https://docs.microsoft.com/en-us/windows/console/allocconsol...

If AllocConsole does behave in the way you say (which I understand it may{, not}), then the documentation sorely needs updating, because right now that bit of functionality (if it is there) is rather implicit.

It would be really cool to effectively deprecate the current console functionality and make it relatively straightforward to use the PTY API going forward, adding the bits people need to support use cases like this (allocating a console when/as it's needed).

Perhaps Visual Studio could introduce a new template for commandline applications that targets the PTY, and put "(Recommended)" next to that one? :D

Re: Introducing the Windows Pseudo Console (ConPty)

#88

Post by wtallis »

AnIdiotOnTheNet wrote: post #80
wtallis wrote: post #76

Earlier quoted context omitted.

It's also the most absurdly verbose shell that exists, which means it sucks as a shell even if it's a half-decent scripting language.

What is with all you people who used PowerShell for a grand total of 10 seconds, gave up because it wasn't bash, then go on to complain about completely false things? PowerShell has aliases. It has shortened aliases for all the common commandlets. You can create your own aliases if you want. PowerShell has tab completion on commandlets, arguments, flags, and variable names. FFS... Every time I run into another one of…

Powershell doesn't get any credit for the tab completion when the default behavior for it just makes the verbosity even more of a nuisance. Having tab completion scroll through all the possible completions one at a time doesn't save keystrokes in most cases, especially when there are dozens or hundreds of options that are really long so when you give up on tab completion and decide to type it out manually in full, you have to erase 10-20 characters. The bash-style completion behavior of completing any unambiguous characters then giving you a list of the possibilities would be even more useful for powershell than it is for bash. But Microsoft once again had to throw in gratuitous differences at the cost of usability.

Re: Introducing the Windows Pseudo Console (ConPty)

#89

Post by Jasper_ »

badminton1 wrote: post #71

HRESULT WINAPI ResizePseudoConsole(_In_ HPCON hPC, _In_ COORD size); If Microsoft is in the mood to fix old problems, right ^there you've got another old problem: its bizarre API that is different to everything else. Designed that way to lock everyone into their OS. In 2018 nobody has the time to learn this. Just use a cross-platform API and if it doesn't run on Windows then just don't run Windows. As a developer, us…

What cross-platform API would that be? ioctl(tty_fd, TIOCSWINSZ, &size); ? How does the user get the TTY FD? open("/dev/tty0")? Or should they implement SYSV compatibility and use "/dev/vt0"? Or perhaps follow FreeBSD, which has "/dev/ttyv0"?

Re: Introducing the Windows Pseudo Console (ConPty)

#90

Post by AnIdiotOnTheNet »

wtallis wrote: post #88
AnIdiotOnTheNet wrote: post #80

Earlier quoted context omitted.

What is with all you people who used PowerShell for a grand total of 10 seconds, gave up because it wasn't bash, then go on to complain about completely false things? PowerShell has aliases. It has shortened aliases for all the common commandlets. You can create your own aliases if you want. PowerShell has tab completion on commandlets, arguments, flags, and variable names. FFS... Every time I run into another one of…

Powershell doesn't get any credit for the tab completion when the default behavior for it just makes the verbosity even more of a nuisance. Having tab completion scroll through all the possible completions one at a time doesn't save keystrokes in most cases, especially when there are dozens or hundreds of options that are really long so when you give up on tab completion and decide to type it out manually in full, yo…

That's subjective opinion. I much prefer the Windows way because I can either specify additional characters or keep hitting tab to until what I want comes up. "Display all 1026 possibilities? (y or n)" certainly isn't an improvement.

Not to mention of course that it tab completes things bash can't and doesn't, and all the other reasons your initial comment was wrong.

Post reply on HN