Live data from Hacker News

Inside the Windows Console

blogs.msdn.microsoft.com

111–120 of 259 posts

Re: Inside the Windows Console

#111
post #62

So, MS has finally realized they're 40 years behind the civilized world. I'm curious to see how long it will take them to catch up.

So, MS has finally realized they're 40 years behind the civilized world Yes they should be emulating a teletype like enlightened folk!

More specifically, a TeleType Model 37 from 1967. None of this modern ECMA-48 stuff from 1976. (-:

* https://news.ycombinator.com/item?id=17557575

* https://news.ycombinator.com/item?id=15779194

Re: Inside the Windows Console

#112
post #45

Earlier quoted context omitted.

This is bizarre to me. You simply can not attract developers to your platform without a first rate console experience. Why even bother with Powershell, Linux Subsystem etc without getting this crucial component working perfectly ?

Windows is the biggest, most popular development platform in the world. Are you not even slightly aware of the bias and bubble you live in?!

Even if you live in a strict Windows world, the console is important. Plenty of sysadmin-type tasks can only be done from the command line, or is at least faster/easier than the alternative (Exchange, VMware, SharePoint, ...). At work, ConEmu is among the first programs I start after logging in.

Re: Inside the Windows Console

#114
post #21
post #14

Earlier quoted context omitted.

Well, the team is small, we're up to three whole devs now. Since 2014 we've been doing a lot of work o help bring our VT implementation up to par (to help enable WSL), as well as implementing new features such as 256/RGB color support, improved accessibility features, and we're even releasing a pty-like API for Windows. Not only that, but since the team was founded we discovered that conhost was not the only console…

Thank you for explaining! Please don't take my initial post as criticism of your work. There is just this visible disconnect between approximately 4 years of work and comparatively simple features that have been shown off so far. So there must be a story there. I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass? Also,I am cur…

Linux terminal emulators are by no means uniform about this. Scrolling speed, and whether to not re-render for every character, are points of contention amongst the XTerm, Alacritty, and VTE people.

Re: Inside the Windows Console

#115

I like the post, it seems like they are good guys doing a good work on an unrewarding application. It is interesting the insight thet are giving with this article: - MS is improving on Windows Console only because of WSL - the design of the Windows Console was flawed since the beginning and remained unchanged to something like 30 years. Flaws includes: - using Console API instead of sending characters / cannot work r…

I don't think anyone who has suffered fixing their termcap, terminfo and stty settings would think Unix has much to boast about in the terminal space. Even today, whole swathes of key combinations have no distinct escape sequences, forcing a different experience for apps like Emacs that can run both native and in terminal.

FWIW, I worked at Borland back in the day, and it simply isn't the case that MS only cared about VS users.

Re: Inside the Windows Console

#116
post #109

I like the post, it seems like they are good guys doing a good work on an unrewarding application. It is interesting the insight thet are giving with this article: - MS is improving on Windows Console only because of WSL - the design of the Windows Console was flawed since the beginning and remained unchanged to something like 30 years. Flaws includes: - using Console API instead of sending characters / cannot work r…

X Window has a good design? Only because it allowed competing tool kits on top of it ("Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.") Besides the fact that the X libs are almost universally reviled and nobody used them as soon as they could (Motif, Qt, Gtk, etc.). The core concept, that of network part is actively being abandoned right now, see the Wayland ef…

I don't think Win32 UI API is terrible. It's basically message passing object orientation before its time.

The API idioms are clumsy to code against, but OTOH it's much more viable to avoid linking libc into your app, whereas in Unix land, the only portable API is defined largely in terms of a C worldview. And some things are just leagues better, like signals vs structured exception handling.

Re: Inside the Windows Console

#117
post #88

Earlier quoted context omitted.

I'm not sure how often you start and stop your shells, but start time is seldom a concern. I enjoy you chose Hyper.js, which uses electron. I'm not sure what speed you were expecting there. You might try ConEmu https://conemu.github.io/ .

I love ConEmu, but it's still pretty slow starting up

You can choose to have it run on startup and keep it in the system tray, that'll help with the startup time.

Re: Inside the Windows Console

#118
post #109

I like the post, it seems like they are good guys doing a good work on an unrewarding application. It is interesting the insight thet are giving with this article: - MS is improving on Windows Console only because of WSL - the design of the Windows Console was flawed since the beginning and remained unchanged to something like 30 years. Flaws includes: - using Console API instead of sending characters / cannot work r…

X Window has a good design? Only because it allowed competing tool kits on top of it ("Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.") Besides the fact that the X libs are almost universally reviled and nobody used them as soon as they could (Motif, Qt, Gtk, etc.). The core concept, that of network part is actively being abandoned right now, see the Wayland ef…

> X Window has a good design? Only because it allowed competing tool kits on top of it ("Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.")

Yes only this simple thing made a much better design. It can be used to provide a modern and beautiful desktop environment even 35 years after its creation.

> Besides the fact that the X libs are almost universally reviled and nobody used them as soon as they could (Motif, Qt, Gtk, etc.).

You are not supposed to use Xlibs directly to program user interface. They just provide the primitive APIs to create windows, process events and draw on the screen. It is normal to use a toolkit like Qt that use Xlib as a backend.

I agree that programming Xlib directly is not very sexy but it sort of make sense and is yet better than Win32 programming.

> The core concept, that of network part is actively being abandoned right now, see the Wayland efforts.

The fact that this is a good choice is still to be demonstrated.

> Win32 is also horrible, but you can kind of get why it was that way: the hardware was abysmal when it was conceived and backwards compatibility was super, super important in the early and cutthroat desktop market.

Yes, you can excuse them for creating Win32 at the time but they have no excuse for not providing qnything better after 30 years. Oh yes, you can create beautiful UI if you only use Visual Studio, you get use to all the warts and limitations, if you forget cross-platform, it will works only on windows, if you use visual studio installer and ship all the zillions of DLLs that you may need with the most baroque distribution system.

On windows I am still looking for a decent way of programming UIs without embracing all the MS bullshit.

Re: Inside the Windows Console

#119
post #34
post #14

Earlier quoted context omitted.

Well, the team is small, we're up to three whole devs now. Since 2014 we've been doing a lot of work o help bring our VT implementation up to par (to help enable WSL), as well as implementing new features such as 256/RGB color support, improved accessibility features, and we're even releasing a pty-like API for Windows. Not only that, but since the team was founded we discovered that conhost was not the only console…

Are you able to speak at all to the labor assignment? Microsoft is big, why only put 3 engineers on this project?

Three is probably a good number, if they are decent engineers. Throwing more people at a problem has diminishing results very, very quickly in software, unless the project can be broken down into mostly independent teams. Even then integrating the work into something coherent can easily be more challenging and time consuming than just having a tiny skilled team own the project soup to nuts.
Post reply on HN