It is about time that Windows got a better console. As someone who regularly jumps between macOS, Linux, and Windows, the current console is a uniquely poor experience
I've heard stdout and stderr are extremely slow on Windows console. If you port Unix-like programs to Windows, lots of fprintf() can even come to be a bottleneck, especially in debugging. Meanwhile macOS and Linux/BSD console can output thousands lines in the blink of an eye. Don't know if the new console is gonna solve that.
It draws to a VGA style character grid, like it was a DOS/VGA machine from the 80's. Oddly enough, Unix is older than that, and got it right (abstracted from hardware).
It's a mix of things. Some of them are legacy CP/M / MS-DOS carry-overs, some are strategic decisions. Windows was supposed to be user-friendly and everything would be done through the GUI. This not only de-emphasized CLIs, it was actively hostile to them. I believe that for a time trying to improve CLIs was frowned upon (I haven't worked at Microsoft, it's just based on a million blogs I read from Microsoft employees).
Now that the cloud is the way to go, they're looking at this in a more holistic way, it seems.
It started a while ago, it just took off slowly. Powershell shipped in 2006, for example, and from there all products gradually started integrating with it for admin tasks. Windows Server 2012 already had a command-line-only mode.
> Oddly enough, Unix is older than that, and got it right.
Perhaps it has something to do with Unix tty. Unix systems are mainframes or servers, the tty subsystem only cares about transmitting the text and control sequences, the actual rendering is done by a CRT terminal at a remote location. Meanwhile, the DOS family was designed for microcomputers and PCs, the text output is tightly-coupled with the system and hardware, including how to draw them. The Windows XP console can even switch to the genuine VGA textmode as used by DOS by pressing Control+Enter.
I guess the Unix tty allowed flexibility. It doesn't matter if someone reimplemented it using VGA textmode, or 2D accelerated framebuffer (modern Linux kernel), fancy 3D OpenGL stack (kmscon, but sadly the project is dead), or a cairo-based graphical interface. Meanwhile, Microsoft haven't continue to develop and modernize the console subsystem in a long time (clarify: at least in 8 years of Windows XP era, until recently).
When you stop work for ~20 years, then get crackin' for a few it understandably takes a while for the news to get out. May not be obvious if you're 25.
No, the legacy console is still quite crippled, unicode and tabs just two examples. This new terminal and conpty are promising but have yet to be introduced unless you compile it yourself.
We used to have ANSI.SYS, though that was removed long before I started at the company.
We do however have a pretty solid VT100+ implementation nowadays. Case in point, it'd be pretty hard to run anything in the Windows Subsystem for Linux without a complete VT implementation.
The new Terminal actually does _crazy_ well. The vintage console on windows, conhost.exe, uses GDI to draw to the window. Unfortunately, GDI is CPU-bound, so drawing the screen actually slows down our processing of the text.
With the Windows Terminal, we've switched to a DX/DWrite based renderer, which no longer uses the CPU to draw text, and moves it to the GPU. Our preliminary testing has a insane perf improvement for applications writing lots of text, something like 10x faster :)
Not quite yet - when the first preview builds are available, they'll be in the Microsoft Store.
Also stay tuned for Rajesh Jha's keynote later today, with our official announcement. It'll have some other relevant information I don't think any of the articles have mentioned quite yet :P
This is the main reason Alacritty can claim they're the fastest terminal around. They're using OpenGL to render text with the GPU. It does use more RAM because of that, but in these times I'm not really concerned by that fact.
Can you try to completely omit some rendering if the buffer gets too large? I think this is a very common optim in the X terminal space.
I'm asking because 10x sounds great, but in my memories the Windows terminal was so slow to ouput text that this might not be enough, compared to the competition.
Wasn't there a post here on HN a month or two ago about how conhost is the only windows program with crazy low latency (tens of milliseconds from a key press to that ending up on the screen), and it was all done by not using winforms/.net/html5 like all other apps.
Presumably, the new terminal will have the same lag now other windows apps have?
My take is that Windows is the best experience because the unsuitability of the built-in option for every day use drove me to a real solution. (In my case, SecureCRT.)
One of the things I hate is when the default option is "good enough" so you have the danger of living with mediocrity. Or, worse, the platform doesn't spawn a rich ecosystem of competition.
For example, when I was on OSX I couldn't find a music player I liked. iTunes was bad, but the fact that everyone uses it means there aren't as many alternatives as on Windows.
Clementine is ridiculously laggy for me and uses a lot of CPU, even when idle. Maybe I have too big of a music collection for it? I'm baffled. I've never had performance issues from a music player before.
SMPlayer's homepage says it's only on Windows and Linux. I only ever used VLC for playing one-off files. I never knew about VLC having media collection features, might have to look into that.
Rhythmbox on Ubuntu has been great for me. I just want Rhythmbox on other platforms. I've been using Google Play Music instead. (It lets you upload your music collection into the cloud, which is super useful as I can now use it from devices it's not synced to, though it's not open source or an application I can run offline, and it's pretty limited in how it can sort and display songs. I can't sort songs by date added, etc.)
CLementine can be faster if you disable everything that you dont use since it comes with bunch of plugins that are all loaded by default.
If you want non-laggy, VLC is the best (both video and audio) but its interface sucks a lot although it is probably tolerable on the long run.
SMplayer could probably be ported in a week or so on OS X given it uses mplayer or mpv which are both available on OSX (its just a fronted to those tools + open sub).
I also used MPD with Cantata in x-platform manner its quite nice and fast.
This is a hard problem for commandline applications unfortunately. Think about pasting text with Ctrl+V. Lots of existing commandline applications bind particular actions to Ctrl+V - should the terminal application always eat the Ctrl+V keypress to handle pasting?
This is why we added support to optionally set Ctrl+Shift+V as the paste keybinding in conhost.
Fortunately, the Windows Terminal doesn't have a lot of the legacy to maintain like conhost does, so it'll support setting paste to whatever keybinging you like :)
I don't even care about Ctrl+V. I just want the ability to right-click on selected text and bring up a menu with 'Copy', 'Paste', and maybe a few other operations on it.
No Windows terminal I've ever seen has the ability to do this.
Edit: Note that I haven't used the new terminal yet, so if it supports an actual right-click menu, than bravo!
Thanks for responding here! Really appreciate the interaction.
Pretty sure that this is one of the biggest requests / frustrations you will hear from users. The issue is that MS has normalized the right-click menu as the go-to method of choosing exactly what one wants to do with a selection of text (, or even anywhere, for that matter), and it's useful, and uniformly available in Office and other Windows apps, and missing ONLY in cmd.
For example, when pasting in Excel, Paste vs. Paste Special vs. Keep Formatting vs. Keep Formulas, etc; via the right-click menu is just great. Going from that to a "We insist on a 1982 MS-DOS experience" in the cmd window is just annoying.
I'm assuming that the main reason why the old terminal can't do this is because console apps can, in fact, handle right clicks. Far Manager is one example that does so for file selection, or alternatively to display its own (TUI) context menus.
The terminal still has the menu commands, by the way. They're tucked away in the window system menu (the one with Minimize, Close etc, that you can open by clicking on the app icon in the title bar - it's all under Edit there).
Oh, you want an actual right-click menu? I honestly don't think I've ever heard that _specific_ request before.
You have never heard that people might want to use functionality that has worked on all editable text in the entire rest of the operating system since Windows 95?
No, people have not specifically made that request to our team in the last 4 years we've owned the console. We get feature requests all the time, but I certainly haven't heard this version before.
This fundamentally sums up why I prefer macOS over windows. Things work consistently throughout not only the desktop experience, but the phone and watch experience too.
Hey me too! The number of times I've closed a terminal because "Close" and "Edit" are right next to each other. :(
I do prefer X because of the PRIMARY selection style automatic copy/pasting, but this would go a long way to making my Windows experience more enjoyable. The Windows development experience is hugely improved and my rediscoveries of it in the last few months have been generally very enjoyable.
I would prefer the X11 method of being able just to highlight the text and using middle mouse to to paste. Nice having two easily accessible copy & paste containers.
I've always hated middle-click paste. It's a nightmare waiting to happen.
I'm terrified that, when I'm scrolling, I'll accidentally push down just a little bit too hard on the scroll wheel, and it'll do something awful like paste PII into a chat or paste a passage of text into my terminal and one line of it gets parsed as a valid command.
I'd rather just use my middle button for autoscroll. It's safe, and it's my preferred way to scroll in the few applications that supported it.
I accidentally middle-click paste into terminals all the time while scrolling. I would love to just disable middle-click paste in Linux. Juggling two different clipboards with different behavior is terrible. If it were a good idea, some other product not encumbered by history would have adopted it by now.
Well, Wayland adopted it. I understand they didn't want to, but the users want it. It's basically drag-and-drop where you don't need both things to be visible at the same time and continuity of movement becomes optional. Drag and drop isn't widely used because it's awkward. But PRIMARY is probably used by a much higher proportions of the users who have it available since it fixes all the problems with it.
Btw. If you want to disable it, you can. But I think you need to be more specific than "Linux" to find instructions, since Linux doesn't have anything to do with your gui. There's presently two major tools responsible for taking applications and putting them on screen, and several other environments responsible for providing you with a useful working environment in terms of the graphical display. But you're probably a troll, because a real Linux user would actually make a useful complaint.
>But you're probably a troll, because a real Linux user would actually make a useful complaint.
I thought it was clear enough that my complaint is that there's no button in any of the settings screens to disable middle-click paste. I've searched through the settings menus of both Ubuntu and Fedora. I've searched before for solutions, and I remember the solutions mostly looked like "here's a patch for GTK v2, you'll have to compile it yourself, replace your distro's packages for GTK, cut yourself off from updates, it won't work for programs that don't use GTK v2 specifically or your distro's packaged version of it, and you're never going to know if the random issues that happen later are because you compiled the wrong version of GTK or missed some distro-specific patches". I've done that sort of thing before, and it's pain. I don't have the mental bandwidth for that any more. I think it's more than fair for me to criticize a piece of software for not having a toggle exposed for a strange UI feature that's so easy to accidentally misuse.
It's been a while since I've looked harder than checking the settings menu for a solution to this, so I decided to search again, and found https://askubuntu.com/questions/4507/how-do-i-disable-middle.... All but one of the solutions are terrible. There's people suggesting compiling and replacing distro packages, there's people suggesting globally rebinding middle-click (some in ways that don't even persist), and there's even a suggestion for having a script run 24/7 which clears the clipboard out twice a second. There is a decent solution involving a gsettings command. The setting persists, which is great, though it only works with programs using GTK.
I haven't used a mouse with overloaded middleclick/scroll for a long time. They feel like a bug.
To me it helps me not have to use the keyboard. Windows is a very hybrid keyboard/mouse driven environment (e.g. Alt-Tab is almost indispensible - but simply not how I think). Using the keyboard for things that are not typing is actually genuinely difficult.
Something like Gnome with the compromises their X-based history forces onto them basically means you can use the system without touching a keyboard except for typing, which is very nice. Alt-Tab and Ctrl-C/X/V are there, I think, but I've never used them.
> I don't even care about Ctrl+V. I just want the ability to right-click on selected text and bring up a menu with 'Copy', 'Paste', and maybe a few other operations on it.
The existing windows terminal has supported that for ages.
Click the upper left icon of a terminal window
Properties->Options->Quick Edit Mode.
Uncheck.
It isn't 100% the same, after selecting text right clicking will auto copy it, but other than that, mostly the same.
It seems to be almost a secret (despite being right up there in the menubar), but VS Code has a great terminal tool built into it, which, until we get this new Windows Terminal in a few months, is by far the best terminal experience I've ever had on Windows. Another way MS really is trying to reduce developer friction...
It's not a hard problem. The problem is that the less common use case is being given the nicer UX. I use copy and paste 100x more often than the interrupt codes produced by CTRL+V/C. Put those interrupts in the context menu instead of copy/paste. If the use case needs to be inverted, make it a user preference.
Sometimes when I need ctrl+C, I really need ctrl+C right now. Being able to immediately cancel whatever stupidity I just typed is a very valuable thing.
Ctrl+C to interrupt was inherited from TOPS (via DOS and CP/M).
Ctrl+C to copy selected text was introduced on Xerox PARC, the granddaddy of all modern UIs. In DOS, some text-mode UI apps were already using it, although IBM CUA was more common.
Just do like vim and let users decide. Bind it to paste cuz you're windows and power users can modify a file in 2 sec. This isn't hard. This shouldn't be the issue it is.
I find the current Windows 10 terminal vastly superior to anything default on Mac or Linux... Take resizing the window for instance, Windows adjusts the content text, whereas Mac does not seem to handle this well.
EDIT: It is possible you are on an outdated version of Windows, or have upgraded and still retain your old settings.
Be sure QuickEdit Mode is enabled, as well as Ctrl key shortcuts.
Do you have a specific example on Mac? Reflowing of text always seems to be way better on Mac than Linux. I use Windows least often, but always felt the experience was significantly worse than the other two.
But article points out it will support emojis as main point... I need proper built in history, proper copy-paste as in linux and macOS, proper resizing so I can have longer lines without changing font as in windows.
I just hope it will be there.
It's a techcruch article, not exactly quality reporting. I'm not really sure why so many people link to them when there's usually a better source for most stories (unless the story is merely rumor).
Proper resizing has existed in the console as long as Windows 10 has been out, and we've been aggressivly improving our copy-paste story. Ctrl+C/V to copy in cmd has been around since Windows 10, and Ctrl+Shift+V to paste in WSL was added just last year.
There have been some good quality of life enhancements over the last few years[1] but this looks like it’ll be a big step in the huge shift required in the ancient “console” subsystem.
I still miss iTerm2 immensely after moving from an all-macOS dev group to an all-Windows group. Hoping this will help me feel less homesick.
Haha, the day our PM Rich started on our team 3 years ago, he brought with him an entire presentation of ITerm2 features he wanted in the console. Thankfully now, we're finally getting to them!
Yea, that'll probably be where we announce when we do ship the first versions.
I'd also pay attention to Rajesh Jha's keynote later today, when the Windows Terminal is officially announced. I think that'll have even more information you'll find relevant.
Interesting, I once tried to promote the idea of a new terminal system/app for Windows, but their devs poo-poo'd it on github. Ya know with DirectX and (modern) Unicode front and center. One that bypasses the obsolete design decisions made in the original console, in favor of the Unix design.
Instead they had been shoehorning stuff into the old one, which has been making old legacy users angry due to regressions.
So, what does this announcement mean? They have changed course? Or is it more lipstick on a pig?
This is a major internal architecture change. It simply wasn’t possible to write a proper console before. That’s why you weren’t met with enthusiasm for your idea.
> a major internal architecture change. It simply wasn’t possible to write a proper console before.
Really curious why this would be so. On Linux there's dozen's of terminals/consoles. On MacOS quite a few too.
Why would the GUI (which was the biggest pain point) has to have anything to do with the terminal functionality, except maybe a few keybindings maybe being impossible to implement. There were 3rd party console alternatives since like ~2000 - only they all had horrible UI/X (but still better than the original one), but Microsoft could simply have adopted one of them, normalized it's weird quirks to follow sane conventions, and baked it in as Windows default.
I never understood Microsoft's attitude of "mushing" these and other things together needlessly.
As a Mac & Linux user now, I can only applaud the idea of keeping things separate at all levels. Desktop environment separate from os separate from shells separate from terminal apps etc.. Heck, you often even have the GUIs as separate applications from the main one in Linux land. Never going back to Windows! Dis-integration ftw!
Yeah, I guess the `backwards-compatibility (historically very important at MS)` thing is the root cause for most of the things I violently dislike about the MS platform...
But I get the biz reasoning behind it... dropping backwards-compatibility would mean embracing the fact that software is made to be perpetually re-compiled, modified, re-written. And in an ecosystem embracing these values, closed-source software is automatically at a disadvantage vs. even slightly-worse-but-open-source alternatives.
I find it funny that we care so much about backwards-compatibility in software, but we completely ignore any semblance of it in hardware, where it could actually make a difference w.r.t. climate-change, toxic-chemical pollutions, preventing planned obsolescence etc. :) I mean, if there is any area where actively encouraging "planned obsolescence" in the form of less backwards-compatibility would be good, it would be in software.
Anyway, this is getting offtopic, but just wanted to say that different value systems produce different technologies... even something as boring as a terminal.
I'm not saying we specifically poo-poo'd you, I think we more have been trying to subtly avoid the topic, because this has been a pretty long term goal of our's we've been working on for a while now.
The main difference here is that now that we have ConPTY, we can build a _new_ terminal application that supports all the legacy applications, but that we can also add features to without breaking backwards compatibility. The old console was very hard to add new features to without breaking back-compat, but the new Terminal won't have that problem.
As much as you and I don't care for emoji, there's a non-zero population of developers that _do_ use emoji on a daily basis. In fact, it's one of our top 5 most requested features on our UserVoice page.
I certainly don't care for them in my terminal output, but I live to serve :P
This is really welcome news as getting a decent terminal has been a real sticking point in my move from OS X to Windows. I settled on Terminus [1] (defaulting into WSL) and that works ok, but still not to the level of OSX Terminal or iTerm. Another option people seem to like is Hyper [2], but I had mixed success and it felt sluggish.
Terminus is promising, but the updates are driving me nuts, it seems like each new one breaks something. A February update made the latency unbearable, and then the most recent update fixed that but it broke tabs: when I switch tabs the new one is blank until I hit a keystroke and suddenly the whole history reappears.
A modern terminal, with full support from Microsoft, is badly needed.
Cmder works great for me because from Windows, my main use cases are 1) git and 2) SSH into my linux server. I don't do almost anything local, besides some web stuff. Cmder has helped me with that, when I'm not on my Mac.
If you find cmder not to your liking, realize it's just a repackaging of https://conemu.github.io/ and Clink with a nice looking stylesheet. You might like vanilla ConEmu better (I did).
I struggled the same and just want to add Fluent Terminal [1] to the list as one that felt the most similar to OSX Terminal to me and I barely see it mentioned online.
I don't get it, does it support Unix commands as well as traditional Windows line commands in the same tab? Is there a description or product specifications?
This is related to the underlying console/terminal system in Windows 10, which should be shell agnostic. The same infrastructure is used by PowerShell, the Windows command prompt, and WSL for instance - all are just different shells that use their own implementations of the console subsystem.
Can anyone speak to their experience with either of these? I used choco a few years ago, but eventually gave up because there was very little official support by the developers of most of the packages and choco package updates usually lagged behind official releases. I see choco more often now, though. Have things improved?
I use scoop on my current installation, it works well enough.
Autoupdates of e.g. Firefox will mess with version numbers a lot. Many apps can't handle being run from a shortcut to a `current` folder that symlinks to a version folder, which means if you want to pin any of those to your task bar you will have to update that shortcut with every update.
WSL fails in a lot of use cases due to the NT kernel's poor performance when creating processes, slowness in the translation layer when accessing files, and the like.
It's essentially the reverse case of telling Windows users to "just use Wine" - the emulation isn't perfect and some programs won't work well or at all. In a sense, WSL is worse than Wine in this regard since there's usually a Linux-native alternative if something doesn't work in Wine. If something doesn't work in WSL, you don't have a lot of options.
> WSL fails in a lot of use cases due to the NT kernel's poor performance when creating processes, slowness in the translation layer when accessing files, and the like.
But it's still the NT kernel either way, right? How does having binaries compiled with cygwin or MinGW improve upon what WSL offers here?
It isn't the "NT kernel either way", as you are going through the filesystem translation layer; AFAIK it is implemented as a subsystem, so you are accessing the kernel through an entirely disjoint mechanism.
So like, Microsoft may have fixed this recently, but WSL processes were essentially stuck inside of a filesystem sandbox that uses some inane mechanism to access files via mountpoints that fails to correctly translate the few flags that are supportable by the underlying Windows filesystem, so if you try to do basic things like use WSL's copy of git to manage a git repository stored outside of the WSL sandbox, it just doesn't work correctly.
On the flip side, you also can't run a native Windows process whose binary is sitting inside of the sandbox, as native Windows processes do not have direct access to WSL files. Checking, they seem to have finally added the ability to mount new paths, so that's helpful (if you have network shares or removable media like USB keys, these were previously not accessible via WSL).
The great thing about cygwin and MinGW is that, by and large, it _is_ "just the NT kernel", with nothing more than a userland library sitting between the process and the same kernel interface used by any other Windows application, so tons of stuff "just works" that WSL is having to slowly reimplement.
(FWIW, it could be that Microsoft has fixed some of these filesystem showstoppers since I last tried to seriously use WSL; if so, that's exciting, but it doesn't change the reality of why people are looking at these are very different ways of running programs.)
> In the latest Windows Insider build, the Windows Subsystem for Linux (WSL) now allows you to manually mount Windows drives using the DrvFs file system. Previously, WSL would automatically mount all fixed NTFS drives when you launch Bash, but there was no support for mounting additional storage like removable drives or network locations.
> Now, not only can you manually mount any drives on your system, we've also added support for other file systems such as FAT, as well as mounting network locations. This enables you to access any drive, including removable USB sticks or CDs, and any network location you can reach in Windows all from within WSL.
It's nice to see them improving Windows. It's actually making useful contributions to my workflow. If they could tie in the Windows subsystem for linux it would be very nice. This seems to be Microsft looking at the software people are using and making native clones that are better integrated into the OS. I use ConEmu for this currently and this upgrade seems very similar.
> Indeed, it seems like the Terminal will essentially become the default environment for PowerShell, Command Prompt and Windows Subsystem for Linux users going forward.
I wouldn't say so. I'd say that we understand well that the original Windows Console was sub-par, and we're working hard to provide solid enhancements to it, without breaking existing Windows commandline applications.
You are familiar with the Windows Subsystem for Linux, right? It's really quite good for running linux tools on Windows, and they have other big announcements at the conference today.
Lol I should have updated that issue - in the most recent Windows release, we added a feature to conhost to actually disable the overscroll (under Properties... Terminal... Disable Scroll-Forward). See [this blog post](https://devblogs.microsoft.com/commandline/new-experimental-...)
I'd say if you're looking for linux commandline applications, I'd recommend the Windows Subsystem for Linux, which lets linux binaries run unmodified on Windows.
As far as package managers are concerned, I've had lots of success with Chocolatey. If developers are willing to port their commandline applications to Windows, then I'm sure they'd be welcome additions to Chocolatey
Just to clarify (because TC is shit journalism that’s muddying the console/shell distinction): this is an entirely new replacement for conhost.exe, and PowerShell is staying the same?
Will cmd, PowerShell and WSL all use the new terminal by default?
Unfortunately, registering a "default terminal application" is _not_ something that's made the cut quite yet. It's something we have plans for, but unfortunately not the dev resources for yet. So for the time being, you'll have to launch the Terminal directly to launch it, and running cmd/powershell will still open in conhost.exe.
I don't think we have our release strategy exactly set in stone yet, but I believe the plan is to have a weekly/nightly app users can download that'll be less stable, and an official app, that'll be much more stable.
That's not too bad, considering the primary use of a better terminal would be for WSL use. Can we expect the stable app to launch at the same time as weeklies/nightlies, or will there be a delay?
Probably a bit of a delay - I wouldn't expect a stable v1 of this before late this year. We have a LOT of features we want to add to the new Terminal, so it'll likely be a while before we get into the stabilization phase
LOL yea, seems like the media embargo ended before the actual announcement.
We don't have a link to share quite yet. The first preview builds that will be available from the store will be coming soon(tm). The "now available" part seems to be referencing a part of Jha's keynote that I don't want to spoil quite yet :)
Yes it's using ConPTY as a backend, which means all Windows commandline apps will work in it out of the box.
It's all C++ code. We're using the relatively new XAML Islands framework to allow us to host UWP XAML content in a Win32 process. A lot of the core is C++/WinRT, which is magic that lets you call most WinRT (UWP) APIs from C++ without having to deal with CX.
I'd say the vast majority of the codebase is pure C++, without the C++/winrt magic.
The renderer we're using is DX-based, which provides a pretty substantial perf improvement over the old GDI-based one conhost uses.
C++/WinRT isn't magic, it's just C++ header files. C++ templates are turing complete, which might have something to do with the implementation I'm not sure.
(I only say this because I see a lot of undeserved bad blood around C++/CX and UWP. The legit criticisms of UWP is that if you go to the Microsoft Store and search for any app, you'll get seven apps and ebooks trying to mislead me into buying them and probably not actually the one you want - but that's not a technical issue at all.)
When I had to use Windows for work I would run gnome-terminal inside WSL and VcXsrv just to get a usable terminal emulator, because I use vim/tmux exclusively for writing code. So thank you for making something that will save Unix people from insanity :)
Does this new terminal support Unix/Linux style shortcuts? Another unrelated thing I’d love to see for WSL is windows-XDG integration, so for example the XDG Browser variable would be set to open the default Windows web browser.
The best part of working on the Terminal is that we can feel free to add new features to it's codebase without breaking backwards compatibility, which why such a feature was never added to conhost in the first place
Honestly, I'm not sure I'm the right person to elaborate upon the extensions model. If our PM Rich shows up in this thread, hopefully he'll be able to elaborate. I'll point him this way, but as he's at the conference today, I doubt he'll get a chance to :/
The article talks about "GPU-accelerated text rendering" - can you speak more about what this means in terms of visual performance? Also, are there plans to add subpixel antialiasing (maybe it's part of this)?
What that means is we're using DX/DWrite for text rendering. The old console used GDI to render text, and GDI's text rendering was CPU bound.
By using the GPU for text rendering, we can process more text faster on the CPU, without the rendering of the text getting in the way.
If we're not already doing subpixel AA, then I think it's certainly something we could look into. I'm not really our DX guy, but it DX supports it, I think we could use it.
Very excited about this. I've been following the terminal progress in W10 since it started. Every time something like this happens (this by far the largest), it feels like Christmas.
Not directly related to the terminal, but any updates on the file system slowness issues?
I hope you are optimizing "performance" for latency which is the most important metric for a pleasant experience of them all [1]. The current WSL Terminal absolutely excels in that regard.
All GPU based terminal emulators I tried so far make latency worse. You have to do away with double buffering and V-Sync for small changes (or on key-press-events) to get in the sub 1ms range.
LARGE portions of the new terminal's codebase are taken straight from the code of the existing conhost.exe, so hopefully we'll keep all the performance we already had.
This is an absolutely epic post you've linked, I'll make sure to share with the team.
I just looked at the Terminus project page[0] and I'm really impressed that they seem to have run an entire linux emulator in the browser just to show off a terminal.
1. It's actually largely based off the original terminal on Windows, conhost.exe. We were able to re-use a lot of the codebase for the core of the implementation, with a thin new UI layer. This means that enhancements to the terminal will also help enhance the inbox console.
2. I spent a LOT of time looking at using xterm.js, and eventually decided against it. The main factor was that although it would provide us a nearly complete VT implementation, it was critically tied to the JS ecosystem, and no matter how much time we spent engineering it, we'd still be coupled to having a webview render text. So we instead decided to write it in C++, which meant that we'd initially have less VT compatibility, but our perf would be better in the long run.
The design is actually super prototype-y right now. the UX team is still polishing the design, but I believe the final answer is yes, we'll be trying to be visually in-line with the new chromium-powered Edge
On the WSL2 piece, is this continuing the direction of WSL1 (syscall emulation) or going for a hypervisor based route to enable compatibility with things like Docker?
My biggest issue with the windows terminal is my programs pausing without me noticing. Took me forever to figure out disabling “quick edit” fixes this- apparently programs just pause completely if you have text selected? Something I keep managing to do on accident without noticing. There is almost no indication, other than the fact my loading bar froze or my program appears to be stuck.
Disabling quick edit helps, but now I can’t select text at all.
Ironically, this is actually a behavior lots of developers do want.
The new Terminal fortunately gives us much more flexibility for customizing it's behavior with user settings, so we'll be able to support either pausing output or not, depending on what the user prefers.
Having your selection reset because another line got added to the log you're tail-ing is maddening, having the output pause while you're selecting is convenient --though it probably should have a timeout or some such.
- sudo for editing protected files (using nano to edit the hosts file in system32 for example)
- Good copy/paste functionality, something robust, maybe like linux with the middle click or normal shortcuts is ok
- Non blocking stdio when scrolling out of focus (not sure if this still exists)
- Split screens like iterm2 or terminator. Adjustable, with different colors for each, with the ability to save profiles so they get restored every time the terminal starts up.
- Smart notifications. If a compile/transpile finishes, our scripts could emit an event to the terminal similar to the bell, to produce a gentle notification. Right now the bell results into the taskbar item becoming orange, but it doesn't go away on its own.
- In Cmder when I have multiple split screens, they register as multiple windows, when I hover over the application on the task bar. Split screens should register as one window in my opinion.
- Right clicking on the application's taskbar icon should give an option to launch a new terminal or a new terminal from a saved profile.
Go influence UAC team please. Make sudo first class citizen and just the same as on linux (or comparable). Please let me sudo something without UAC window and new process ...
Actually we spent MONTHS debating the pros and cons of adding a sudo on Windows.
Curiously, Windows is more secure than linux because it _doesn't_ have a sudo.
In Windows, any application can set messages to another window at the same integrity level with SendMessage/PostMessage.
If you had a `sudo` on windows, you could have a medium-IL terminal window which is talking to a high-IL process (running with the hypothetical sudo), and any other medium-il process could drive the console, effectively creating an escalation of privilege attack vector.
You are answering my hopes and dreams for a Windows Terminal. The only thing I need after this is split terminals like how iTerm works (so I can have a big one, a small, thing one below it, one on the side, etc). This helps SO MUCH when doing likes like complicated deployments and I need to monitor many systems at once.
Is this open source? Is there a way for me to help contribute back? Thanks for the hard work!
PowerShell is a huge step forward compared to Cmd.exe. I wouldn't mind another step forward even if that means there are now three binaries. What's your concern? The only one I see is that people still seem to mostly use Cmd.exe, but I feel like a lot of that is the execution behavior of PS1 files (in addition to familiarity and compatibility).
Fortunately you'll be able to use the new Terminal with whatever shell you like - cmd.exe, Powershell, Powershell Core, or WSL (and whatever linux shell you prefer)>
PowerShell has been more usable than Linux or OSX shells for quite a while. It has tab completion for not just commands, but flags and arguments. And the home and end keys work.
And every dev I know that has to deal with Windows still uses CMD instead.
PowerShell having standardized tab completion of flags/arguments is really nice, but it's worth noting that both bash and zsh support pluggable completion. It's one's choice of tools, and the lack of completion therein, that's the real sticking point. Home/end work on every machine I own, though I know that some machines (some Macs, specifically) have issues unless they're configured in the terminal emulator.
(I try to use PowerShell when on Windows. I genuinely like it--just kinda wish it was a little easier to write-on-the-fly, it's very verbose and typey and Tab is just far enough away to cause some wrist strain. ;) )
You can't? I've never done it but I'm pretty sure I know this: in bash, you can get it from pkg-config. If you aren't using pkg-config, you're kind of swimming upstream in the first place, but CentOS and Fedora (the only distro I use, but I think Ubuntu uses the same) look at /etc/bash_completion.d.
In zsh, it's just $FPATH. Your canonical location can also be gotten from pkg-config.
This seems very googleable. Doubly so if you're doing the right thing and...using pkg-config.
(Please use pkg-config. Thank you for coming to my TED talk.)
As someone that grew up on bash the concepts that underlie PowerShell’s syntax are unnecessary reinventions at their best and utterly bizarre at their worst.
That’s the primary reason my hierarchy of Windows shells usually starts with bash (via WSL, MinGW, or Cygwin) for file management, ssh, compile/build/deploy, and text parsing work and ends at CMD and eventually PowerShell for the Windows services management and other Windows internals that require it.
Also, bash’s (and other similar shells’) high degree of customization is both easily portable and massively extensible. With some minor customization it’s possible to match, or even exceed, PowerShell’s tab completion capabilities.
As someone who's pretty familiar with both bash and PowerShell, I don't consider either of them better or worse than the other, just different. I think of PowerShell as something in between a traditional command-line shell like bash and a scripting language like python, with a mix of the strengths and weaknesses of both. It's not the best of both worlds, nor the worst of both worlds (each of which I've seen comments online arguing), it's just "some of the good and bad of both worlds."
Lack of thorough, accurate documentation shipping with modern open-source software is a real problem. While a lot of software written in the 1980s-1990s (GNU project, Solaris, etc.) have fantastic man pages and Info documentation, much that has been written since has been poorly documented, if at all.
Good documentation shows that (a) the author has thought clearly through their work and (b) shows respect for the user's time by not making them experiment or have to delve into the source code, third-party blog posts, etc. to figure out how the software works.
Try fish shell [0]. It's not entirely POSIX compatible, but it's close and it provides the best shell experience I've had. It has sensible defaults so everything works well out of the box
A bit off topic, but how does one use Windows 10 now without sacrificing on speed / resources? Recently purchased Lenovo E480 and E585, they all come with stock Windows 10, so before getting Linux in, I've tested it and it is basically unusable: disk/cpu usage is constantly jumping between 80-95%, fans are always turned on producing a lot of noise. Is this common to all laptops with Windows or just Lenovo?
It might have just been doing windows updates. I've never had problems with it but I've read online that it can spike disk/cpu usage on some hardware configurations. If you just bought it, it might have been doing a major version upgrade (1809->1903 for example)
I have an Asus with Windows 10, and after a day of use, it becomes unbearably slow. It seems there is a lot of activity on the HD. I tried to diagnose this, but was never able to pinpoint a specific process that was slowing it down.
The only solution was to restart it. Web browsing always had a huge delay.
Linux on the other hand: startup is fast, use is fast, runs for months without any restart.
You can fix windows. My media centar runs on 10 for months. Just disable updates (not easily done nowdays tho) and store service which is resource hog.
Use some debloater to remove other stupid stuff. Then it will fly.
My Acer aspire 7 is pretty useable... once you remember that Windows 10 is not truly done booting until it has checked for updates. (I also disabled everything I could too, including the bundled software)
Yeah, at one point they put in a lot of work to get the power on to Windows screen up time fast. But it's a scam.. Windows is not done booting until the hard drive drops below being pegged at 100%, which takes another 4 minutes.
They also greatly increased boot speed with their hybrid shutdown method. Since Windows 8, when you tell the system to shut down, it actually just closes all your programs and then hibernates the kernel.
Learned this the hard way when I was interning as a tester for an audio driver. Sometimes the driver would get into a bad state, and you could power cycle the system and the driver would still be a bad state. I created a batch file that would run the shutdown command with a flag to initiate a complete shutdown rather than a kernel hibernation, which was necessary to reset the state of the driver.
I've never really used Windows as a daily driver until I had to do cross-platform development for PhotoStructure[1]. My windows box is a recent XPS 15 with an m.2 SSD and core i7. My Mac is a 10 year old 17" MBP. My linux box is the cheapest core i5 I could get 2 years ago with an mSATA SSD (not m.2).
Here's this morning's CI job timings (running the same 2K tests that exercise a reasonable mixture of CPU, process management, and disk I/O):
Just saying i5 or i7 is kind of meaningless, because it can be anything between a laptop dual core to a desktop octa core these days.
What's in the 19 additional tests Windows is running? Is the Linux box a laptop as well? I'm personally having trouble believing the Core 2 Duo in your MBP outperforms a modern i7, even after potential Windows overhead.
Yeah, agreed, but these are single-core tests and even the max clock speed of intel chips doesn't seem to correlate exactly with performance. Here's more CPU details, though:
My XPS 15 is HT 4-core Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz.
The ubuntu box is HT dual-core Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
> What's in the 19 additional tests Windows is running?
The 19 additional tests are windows-specific path validation unit tests, and take ~10ms total.
> Is the Linux box a laptop as well?
No, it's on a 3 year old cheapo mini ITX mobo.
> I'm personally having trouble believing
Me too. I've nuked and paved this box a couple times, thinking it was bad interactions with cygwin or MSYS or minGW. CPU bound stuff (like ffmpeg transcoding) is closer across windows and linux, but opening files and forking processes on Windows is just hella slow (even on my desktop windows machines).
> Fork & fs operations, certainly.... nothing to do with Windows itself.
Both of these operations are known to be very slow specifically in windows. The former's the reason why windows has always strongly favored thread-based concurrency (whereas unices tend to favor process-based concurrency)[0], the latter is well know of NTFS, it deals especially badly with lots of small files.
[0] even excluding making the entire thing blowing its gasket as Bruce Dawson triggers with appalling regularity, in fact in one of his posts he specifically notes in the introduction that windows is notorious for its slow file and process operations: https://randomascii.wordpress.com/2018/10/15/making-windows-...
FWIW these are mocha suites running under nodeJS, so if v8 had a really bad windows subsystem, that'd explain it, but as others have stated, the performance difference correlates with other cross platform runtime environments as well.
A minor correction, the i5-6500 is a non HT quad core.
In practice, the i5-6500 is faster than the i7-6700HQ. The i5 enjoys a slightly higher turbo clock speed and less restrictions in TDP, cooling and power supply allowing it to run faster for longer so it's expected to be the fastest, but that doesn't explain the entire gap.
Have you tried using WSL instead? I found it to do excellent in CPU based tasks, but the file IO performance was a bit lacking. Apparently in the next release (along with this new terminal) filesystem performance should improve by a significant amount. Although I would still expect it to be slower than running on Windows/NTFS natively
I have a Core 2 Duo desktop from 2008 with 3GB RAM which I almost never reboot manually running Windows 10, and I can't replicate your experience (the fans are always on, but it's a desktop).
Granted, it has an SSD, so disk access is not slowing the machine down as much, but so do all the computers today.
Depends on a lot of things including bloatware and anti-virus in particular which can slow a machine to an absolute crawl.
In theory windows can be faster than Linux in some cases; but usually isn't because most developers don't actually take advantage of those APIs and just do everything synchronously which is stupid slow on Windows. That said Linux is catching up super quick in terms of those sorts of things.
You basically need to de-bloat your computer from Lenovo's software and also window services (compatibility telemetry was a prime example of an offender). To help with the fan, try undervolting the CPU, my T470p got around -10 to -15mv iirc that helped with throttling and fan/heat a ton.
Windows 10 will take a long time to update and initialize everything. If I power down my machine for a few weeks it will take a few hours for it to calm down when powered on again (I’m on the insider release cycle so there is almost always a major upgrade of some kind). Lenovo stuff doesn’t help, but I suspect things like store app upgrades (whoever needs those?), Windows updates, search indexing, AV scans.
E480 here. I didn't see unusual CPU/IO. Did you let it settle for a day? Noise: Lenovo doesn't enable Speed Shift and the firmware provided fan control is shit. If you want to fix it: Get a tool like tpfan and tweak the fans. Get ThrottleStop to enable Speed Shift and undervolt a bit. - Noise was pretty much fine on Linux out of the box. I just undervolted because why not.
I'm guessing bloatware? I haven't purchased a non-genuine Windows machine in at least a decade at this point so I've never run into this type of issue.
The best way to get a Windows computer is either building it or buying it directly from Microsoft so you can get the genuine versions that have little to no bloatware.
It'll be interesting to see details here, which I guess will come out over the next couple of days.
They could either go the syscall emulation route (as in current WSL), or possibly the "thin hypervisor" route, the fact they're talking kernel versions makes me think that may be what they're planning...
Whilst it doesn't explicitly mention Virtual Machines or Hypervisors, I'd read this as making use of that kind of technology with some additional tech. for interop with Windows to the level of WSL currently.
I've been running WSL for over a year with Docker for Windows and while the experience feels native to WSL (WSL has no problem running the Docker CLI and connecting to Docker for Windows) it'll be a very nice perk to just apt install Docker in WSL and not deal with DfW.
Today, Linux Docker containers on Windows rely on a VM running on Hyper-V.
Tomorrow (by which I mean "in the future," or "June 2019" or whatever the announcement says) Linux Docker containers on Windows will run natively, without the Linux VM crutch. I am assuming that it will use the emulated syscalls the same way that WSL runs today.
Not sure about that, except if their phrasing is astonishingly poor, which is of course possible. I mean, in my book "Linux 4.19 kernel shipping in Windows" means a Linux kernel shipping in Windows, and that would need Hyper-V (Linux is trademarked btw, MS can't just pretend that they ship a Linux kernel if they don't). At the same time, I really hope that this is not the case and that it actually means that they are targeting a syscall compatibility with Linux version 4.19; because I'm certainly not gonna give up my third party VMs for some work, so if WSL is rebased on Hyper-V that means bye-bye WSL for me.
Rewriting WSL to suddenly require a VM would be a HUGE leap backwards and I can't see that being the solution chosen. It doesn't make sense.
Adding the appropriate things to WSL to make Docker for Windows no longer require the Moby VM, or to support Linux Docker within the WSL environment without modification, is an approach that makes much more sense to me.
This article was linked from another article which I guess is where I saw the VM info:
> WSL 2 uses the latest and greatest in virtualization technology to run its Linux kernel inside of a lightweight utility virtual machine (VM). However, WSL 2 will NOT be a traditional VM experience.
My guess is that they mean that they will fully support the syscall surface of Linux 4.19. I highly doubt that they're actually going to include the kernel inside Windows due to the GPL licensing, the linking issues would force open far more than even Nadella would like.
431 comments
[ 3.0 ms ] story [ 270 ms ] threadNow that the cloud is the way to go, they're looking at this in a more holistic way, it seems.
Perhaps it has something to do with Unix tty. Unix systems are mainframes or servers, the tty subsystem only cares about transmitting the text and control sequences, the actual rendering is done by a CRT terminal at a remote location. Meanwhile, the DOS family was designed for microcomputers and PCs, the text output is tightly-coupled with the system and hardware, including how to draw them. The Windows XP console can even switch to the genuine VGA textmode as used by DOS by pressing Control+Enter.
I guess the Unix tty allowed flexibility. It doesn't matter if someone reimplemented it using VGA textmode, or 2D accelerated framebuffer (modern Linux kernel), fancy 3D OpenGL stack (kmscon, but sadly the project is dead), or a cairo-based graphical interface. Meanwhile, Microsoft haven't continue to develop and modernize the console subsystem in a long time (clarify: at least in 8 years of Windows XP era, until recently).
That's just provably false. We've been hard at work on the console for the last 4 years, culminating in today's Terminal announcement.
See https://devblogs.microsoft.com/commandline/ for a few examples of things we've been doing for the last few years.
One in particular: Last year we added support for a pty-like interface in Windows with [ConPty](https://devblogs.microsoft.com/commandline/windows-command-l...)
Midnight Commander, htop, applications that make extensive use of VT command sequences all work fine.
We do however have a pretty solid VT100+ implementation nowadays. Case in point, it'd be pretty hard to run anything in the Windows Subsystem for Linux without a complete VT implementation.
With the Windows Terminal, we've switched to a DX/DWrite based renderer, which no longer uses the CPU to draw text, and moves it to the GPU. Our preliminary testing has a insane perf improvement for applications writing lots of text, something like 10x faster :)
(Thank you for responding to so many comments on this thread!)
Also stay tuned for Rajesh Jha's keynote later today, with our official announcement. It'll have some other relevant information I don't think any of the articles have mentioned quite yet :P
It's live now, and I think Windows is up soon, though I don't know where in the keynote we are.
I'm asking because 10x sounds great, but in my memories the Windows terminal was so slow to ouput text that this might not be enough, compared to the competition.
Presumably, the new terminal will have the same lag now other windows apps have?
One of the things I hate is when the default option is "good enough" so you have the danger of living with mediocrity. Or, worse, the platform doesn't spawn a rich ecosystem of competition.
For example, when I was on OSX I couldn't find a music player I liked. iTunes was bad, but the fact that everyone uses it means there aren't as many alternatives as on Windows.
You can have everything now on all 3, everything important. I almost never use non-cross platform tools.
SMPlayer's homepage says it's only on Windows and Linux. I only ever used VLC for playing one-off files. I never knew about VLC having media collection features, might have to look into that.
Rhythmbox on Ubuntu has been great for me. I just want Rhythmbox on other platforms. I've been using Google Play Music instead. (It lets you upload your music collection into the cloud, which is super useful as I can now use it from devices it's not synced to, though it's not open source or an application I can run offline, and it's pretty limited in how it can sort and display songs. I can't sort songs by date added, etc.)
If you want non-laggy, VLC is the best (both video and audio) but its interface sucks a lot although it is probably tolerable on the long run.
SMplayer could probably be ported in a week or so on OS X given it uses mplayer or mpv which are both available on OSX (its just a fronted to those tools + open sub).
I also used MPD with Cantata in x-platform manner its quite nice and fast.
This is why we added support to optionally set Ctrl+Shift+V as the paste keybinding in conhost.
Fortunately, the Windows Terminal doesn't have a lot of the legacy to maintain like conhost does, so it'll support setting paste to whatever keybinging you like :)
No Windows terminal I've ever seen has the ability to do this.
Edit: Note that I haven't used the new terminal yet, so if it supports an actual right-click menu, than bravo!
Fortunately, the Windows Terminal doesn't have any existing back-compat we have to support, so that's definitely a setting we can add to it :)
Pretty sure that this is one of the biggest requests / frustrations you will hear from users. The issue is that MS has normalized the right-click menu as the go-to method of choosing exactly what one wants to do with a selection of text (, or even anywhere, for that matter), and it's useful, and uniformly available in Office and other Windows apps, and missing ONLY in cmd.
For example, when pasting in Excel, Paste vs. Paste Special vs. Keep Formatting vs. Keep Formulas, etc; via the right-click menu is just great. Going from that to a "We insist on a 1982 MS-DOS experience" in the cmd window is just annoying.
The terminal still has the menu commands, by the way. They're tucked away in the window system menu (the one with Minimize, Close etc, that you can open by clicking on the app icon in the title bar - it's all under Edit there).
You have never heard that people might want to use functionality that has worked on all editable text in the entire rest of the operating system since Windows 95?
Feel free to file it over at https://github.com/Microsoft/Terminal, and we'll triage as appropriate
I do prefer X because of the PRIMARY selection style automatic copy/pasting, but this would go a long way to making my Windows experience more enjoyable. The Windows development experience is hugely improved and my rediscoveries of it in the last few months have been generally very enjoyable.
I'm terrified that, when I'm scrolling, I'll accidentally push down just a little bit too hard on the scroll wheel, and it'll do something awful like paste PII into a chat or paste a passage of text into my terminal and one line of it gets parsed as a valid command.
I'd rather just use my middle button for autoscroll. It's safe, and it's my preferred way to scroll in the few applications that supported it.
Btw. If you want to disable it, you can. But I think you need to be more specific than "Linux" to find instructions, since Linux doesn't have anything to do with your gui. There's presently two major tools responsible for taking applications and putting them on screen, and several other environments responsible for providing you with a useful working environment in terms of the graphical display. But you're probably a troll, because a real Linux user would actually make a useful complaint.
I thought it was clear enough that my complaint is that there's no button in any of the settings screens to disable middle-click paste. I've searched through the settings menus of both Ubuntu and Fedora. I've searched before for solutions, and I remember the solutions mostly looked like "here's a patch for GTK v2, you'll have to compile it yourself, replace your distro's packages for GTK, cut yourself off from updates, it won't work for programs that don't use GTK v2 specifically or your distro's packaged version of it, and you're never going to know if the random issues that happen later are because you compiled the wrong version of GTK or missed some distro-specific patches". I've done that sort of thing before, and it's pain. I don't have the mental bandwidth for that any more. I think it's more than fair for me to criticize a piece of software for not having a toggle exposed for a strange UI feature that's so easy to accidentally misuse.
It's been a while since I've looked harder than checking the settings menu for a solution to this, so I decided to search again, and found https://askubuntu.com/questions/4507/how-do-i-disable-middle.... All but one of the solutions are terrible. There's people suggesting compiling and replacing distro packages, there's people suggesting globally rebinding middle-click (some in ways that don't even persist), and there's even a suggestion for having a script run 24/7 which clears the clipboard out twice a second. There is a decent solution involving a gsettings command. The setting persists, which is great, though it only works with programs using GTK.
To me it helps me not have to use the keyboard. Windows is a very hybrid keyboard/mouse driven environment (e.g. Alt-Tab is almost indispensible - but simply not how I think). Using the keyboard for things that are not typing is actually genuinely difficult.
Something like Gnome with the compromises their X-based history forces onto them basically means you can use the system without touching a keyboard except for typing, which is very nice. Alt-Tab and Ctrl-C/X/V are there, I think, but I've never used them.
The existing windows terminal has supported that for ages.
Click the upper left icon of a terminal window
Properties->Options->Quick Edit Mode.
Uncheck.
It isn't 100% the same, after selecting text right clicking will auto copy it, but other than that, mostly the same.
Clipboard UX is a bit of a mess on Linux, but notably on macOS copy is Cmd+C and SIGINT Ctrl+C, so this isn't an issue at all.
Ctrl+C to interrupt was inherited from TOPS (via DOS and CP/M).
Ctrl+C to copy selected text was introduced on Xerox PARC, the granddaddy of all modern UIs. In DOS, some text-mode UI apps were already using it, although IBM CUA was more common.
EDIT: It is possible you are on an outdated version of Windows, or have upgraded and still retain your old settings.
Be sure QuickEdit Mode is enabled, as well as Ctrl key shortcuts.
I still miss iTerm2 immensely after moving from an all-macOS dev group to an all-Windows group. Hoping this will help me feel less homesick.
[1] https://devblogs.microsoft.com/commandline/
I'd also pay attention to Rajesh Jha's keynote later today, when the Windows Terminal is officially announced. I think that'll have even more information you'll find relevant.
If you'd like to skip ahead before real previews are available, you could always compile from source :)
Instead they had been shoehorning stuff into the old one, which has been making old legacy users angry due to regressions.
So, what does this announcement mean? They have changed course? Or is it more lipstick on a pig?
Really curious why this would be so. On Linux there's dozen's of terminals/consoles. On MacOS quite a few too.
Why would the GUI (which was the biggest pain point) has to have anything to do with the terminal functionality, except maybe a few keybindings maybe being impossible to implement. There were 3rd party console alternatives since like ~2000 - only they all had horrible UI/X (but still better than the original one), but Microsoft could simply have adopted one of them, normalized it's weird quirks to follow sane conventions, and baked it in as Windows default.
I never understood Microsoft's attitude of "mushing" these and other things together needlessly.
As a Mac & Linux user now, I can only applaud the idea of keeping things separate at all levels. Desktop environment separate from os separate from shells separate from terminal apps etc.. Heck, you often even have the GUIs as separate applications from the main one in Linux land. Never going back to Windows! Dis-integration ftw!
Anyway, there is a great series on the technical aspects: https://blogs.msdn.microsoft.com/commandline/2018/06/20/wind...
But I get the biz reasoning behind it... dropping backwards-compatibility would mean embracing the fact that software is made to be perpetually re-compiled, modified, re-written. And in an ecosystem embracing these values, closed-source software is automatically at a disadvantage vs. even slightly-worse-but-open-source alternatives.
I find it funny that we care so much about backwards-compatibility in software, but we completely ignore any semblance of it in hardware, where it could actually make a difference w.r.t. climate-change, toxic-chemical pollutions, preventing planned obsolescence etc. :) I mean, if there is any area where actively encouraging "planned obsolescence" in the form of less backwards-compatibility would be good, it would be in software.
Anyway, this is getting offtopic, but just wanted to say that different value systems produce different technologies... even something as boring as a terminal.
And of course, Microsoft is currently the most valuable company.
But not in the sense that one can just upgrade/replace a cpu, or just add some ram etc.
I'm not saying we specifically poo-poo'd you, I think we more have been trying to subtly avoid the topic, because this has been a pretty long term goal of our's we've been working on for a while now.
The main difference here is that now that we have ConPTY, we can build a _new_ terminal application that supports all the legacy applications, but that we can also add features to without breaking backwards compatibility. The old console was very hard to add new features to without breaking back-compat, but the new Terminal won't have that problem.
> I think we more have been trying to subtly avoid the topic
Sounds reasonable.
Not the onion.
Edit: Snap, it ate my thinking emoji :-(
On a more serious note, I'm not sure we're losing much by not having them. I kind of resort to smileys, anyway.
A more rapid decline into reddit-like meaninglessness of communication?
I certainly don't care for them in my terminal output, but I live to serve :P
1 - https://eugeny.github.io/terminus/
2 - https://hyper.is/
A modern terminal, with full support from Microsoft, is badly needed.
Cmder works great for me because from Windows, my main use cases are 1) git and 2) SSH into my linux server. I don't do almost anything local, besides some web stuff. Cmder has helped me with that, when I'm not on my Mac.
[1] https://github.com/felixse/FluentTerminal
https://chocolatey.org/
wsl wsl-ubuntu-1604 vlc sshfs virtualbox dropbox wireshark irfanview nvim 1password vcxsrv git slack itunes colortool musicbee utorrent vscode etcher steam goggalaxy epicgameslauncher uplay
Autoupdates of e.g. Firefox will mess with version numbers a lot. Many apps can't handle being run from a shortcut to a `current` folder that symlinks to a version folder, which means if you want to pin any of those to your task bar you will have to update that shortcut with every update.
It's essentially the reverse case of telling Windows users to "just use Wine" - the emulation isn't perfect and some programs won't work well or at all. In a sense, WSL is worse than Wine in this regard since there's usually a Linux-native alternative if something doesn't work in Wine. If something doesn't work in WSL, you don't have a lot of options.
But it's still the NT kernel either way, right? How does having binaries compiled with cygwin or MinGW improve upon what WSL offers here?
So like, Microsoft may have fixed this recently, but WSL processes were essentially stuck inside of a filesystem sandbox that uses some inane mechanism to access files via mountpoints that fails to correctly translate the few flags that are supportable by the underlying Windows filesystem, so if you try to do basic things like use WSL's copy of git to manage a git repository stored outside of the WSL sandbox, it just doesn't work correctly.
On the flip side, you also can't run a native Windows process whose binary is sitting inside of the sandbox, as native Windows processes do not have direct access to WSL files. Checking, they seem to have finally added the ability to mount new paths, so that's helpful (if you have network shares or removable media like USB keys, these were previously not accessible via WSL).
The great thing about cygwin and MinGW is that, by and large, it _is_ "just the NT kernel", with nothing more than a userland library sitting between the process and the same kernel interface used by any other Windows application, so tons of stuff "just works" that WSL is having to slowly reimplement.
(FWIW, it could be that Microsoft has fixed some of these filesystem showstoppers since I last tried to seriously use WSL; if so, that's exciting, but it doesn't change the reality of why people are looking at these are very different ways of running programs.)
https://blogs.msdn.microsoft.com/wsl/2017/04/18/file-system-...
> In the latest Windows Insider build, the Windows Subsystem for Linux (WSL) now allows you to manually mount Windows drives using the DrvFs file system. Previously, WSL would automatically mount all fixed NTFS drives when you launch Bash, but there was no support for mounting additional storage like removable drives or network locations.
> Now, not only can you manually mount any drives on your system, we've also added support for other file systems such as FAT, as well as mounting network locations. This enables you to access any drive, including removable USB sticks or CDs, and any network location you can reach in Windows all from within WSL.
This one covers the under the hood work that needed to be done https://devblogs.microsoft.com/commandline/windows-command-l...
From the second paragraph of the article.
Those who do not understand UNIX are condemned to reinvent it, poorly. -- Henry Spencer, programmer
I look forward to the day Windows is a wrapper around a linux sub-system. The convergence is what I hope for.
You are familiar with the Windows Subsystem for Linux, right? It's really quite good for running linux tools on Windows, and they have other big announcements at the conference today.
Lol I should have updated that issue - in the most recent Windows release, we added a feature to conhost to actually disable the overscroll (under Properties... Terminal... Disable Scroll-Forward). See [this blog post](https://devblogs.microsoft.com/commandline/new-experimental-...)
As far as package managers are concerned, I've had lots of success with Chocolatey. If developers are willing to port their commandline applications to Windows, then I'm sure they'd be welcome additions to Chocolatey
Will cmd, PowerShell and WSL all use the new terminal by default?
Powershell, cmd.exe, WSL, they're all unaffected by this change. They all run the same in the new terminal as they did in the old one, thanks to the powerful magic of [ConPty](https://devblogs.microsoft.com/commandline/windows-command-l...)
Also, how stable/unstable will the preview be?
I don't think we have our release strategy exactly set in stone yet, but I believe the plan is to have a weekly/nightly app users can download that'll be less stable, and an official app, that'll be much more stable.
https://github.com/Microsoft/Terminal
[0] https://blogs.windows.com/buildingapps/2019/05/06/developing...
[1] https://github.com/Microsoft/Terminal
> The first preview of the new Windows Terminal is now available.
But does not provide a link. Would you be able to provide one? Or is it part of the Insider preview?
Also, I assume this uses ConPTY, which implies better compatibility with TTY/VT?
We don't have a link to share quite yet. The first preview builds that will be available from the store will be coming soon(tm). The "now available" part seems to be referencing a part of Jha's keynote that I don't want to spoil quite yet :)
Yes it's using ConPTY as a backend, which means all Windows commandline apps will work in it out of the box.
I'd say the vast majority of the codebase is pure C++, without the C++/winrt magic.
The renderer we're using is DX-based, which provides a pretty substantial perf improvement over the old GDI-based one conhost uses.
(I only say this because I see a lot of undeserved bad blood around C++/CX and UWP. The legit criticisms of UWP is that if you go to the Microsoft Store and search for any app, you'll get seven apps and ebooks trying to mislead me into buying them and probably not actually the one you want - but that's not a technical issue at all.)
[1] https://gist.github.com/XVilka/8346728
[2] https://terminal-wg.pages.freedesktop.org/bidi/
As far as bidi text, the underlying console implementation isn't quite there yet, though it it high up on our radar of things to work on.
https://github.com/tonsky/FiraCode
Does this new terminal support Unix/Linux style shortcuts? Another unrelated thing I’d love to see for WSL is windows-XDG integration, so for example the XDG Browser variable would be set to open the default Windows web browser.
The best part of working on the Terminal is that we can feel free to add new features to it's codebase without breaking backwards compatibility, which why such a feature was never added to conhost in the first place
By using the GPU for text rendering, we can process more text faster on the CPU, without the rendering of the text getting in the way.
If we're not already doing subpixel AA, then I think it's certainly something we could look into. I'm not really our DX guy, but it DX supports it, I think we could use it.
Not directly related to the terminal, but any updates on the file system slowness issues?
I believe they have a big announcement later today that I don't want to spoil quite yet :)
Exciting! :)
All GPU based terminal emulators I tried so far make latency worse. You have to do away with double buffering and V-Sync for small changes (or on key-press-events) to get in the sub 1ms range.
[1] https://pavelfatin.com/typing-with-pleasure/
This is an absolutely epic post you've linked, I'll make sure to share with the team.
1. Is this based on Terminus or some previous OSS project?
2. Is this using xterm.js for the terminal emulation?
[0]https://eugeny.github.io/terminus/
2. I spent a LOT of time looking at using xterm.js, and eventually decided against it. The main factor was that although it would provide us a nearly complete VT implementation, it was critically tied to the JS ecosystem, and no matter how much time we spent engineering it, we'd still be coupled to having a webview render text. So we instead decided to write it in C++, which meant that we'd initially have less VT compatibility, but our perf would be better in the long run.
Question - I see in the Techcrunch article that tabs will be supported. Do you know if split windows (like iTerm2!) will be supported?
A. I'm not sure if I'm doing it right. B. If I am doing it right, where does the compiled binary (or is it an installer?) get put?
Thank you for your work!!
Disabling quick edit helps, but now I can’t select text at all.
Is this behavior changed in the new terminal?
The new Terminal fortunately gives us much more flexibility for customizing it's behavior with user settings, so we'll be able to support either pausing output or not, depending on what the user prefers.
I'm not sure which side is misrepresented, but it sounds mad from the outside!
- sudo for editing protected files (using nano to edit the hosts file in system32 for example)
- Good copy/paste functionality, something robust, maybe like linux with the middle click or normal shortcuts is ok
- Non blocking stdio when scrolling out of focus (not sure if this still exists)
- Split screens like iterm2 or terminator. Adjustable, with different colors for each, with the ability to save profiles so they get restored every time the terminal starts up.
- Smart notifications. If a compile/transpile finishes, our scripts could emit an event to the terminal similar to the bell, to produce a gentle notification. Right now the bell results into the taskbar item becoming orange, but it doesn't go away on its own.
- In Cmder when I have multiple split screens, they register as multiple windows, when I hover over the application on the task bar. Split screens should register as one window in my opinion.
- Right clicking on the application's taskbar icon should give an option to launch a new terminal or a new terminal from a saved profile.
Thank you for your efforts!
Curiously, Windows is more secure than linux because it _doesn't_ have a sudo.
In Windows, any application can set messages to another window at the same integrity level with SendMessage/PostMessage.
If you had a `sudo` on windows, you could have a medium-IL terminal window which is talking to a high-IL process (running with the hypothetical sudo), and any other medium-il process could drive the console, effectively creating an escalation of privilege attack vector.
Its very much by design.
Is this open source? Is there a way for me to help contribute back? Thanks for the hard work!
https://github.com/Microsoft/Terminal
Split panes is one of the things I want to see get done next personally!
And every dev I know that has to deal with Windows still uses CMD instead.
Home = Ctrl-A
End = Ctrl-E
Map Caps Lock to Ctrl
(I try to use PowerShell when on Windows. I genuinely like it--just kinda wish it was a little easier to write-on-the-fly, it's very verbose and typey and Tab is just far enough away to cause some wrist strain. ;) )
In zsh, it's just $FPATH. Your canonical location can also be gotten from pkg-config.
This seems very googleable. Doubly so if you're doing the right thing and...using pkg-config.
(Please use pkg-config. Thank you for coming to my TED talk.)
That’s the primary reason my hierarchy of Windows shells usually starts with bash (via WSL, MinGW, or Cygwin) for file management, ssh, compile/build/deploy, and text parsing work and ends at CMD and eventually PowerShell for the Windows services management and other Windows internals that require it.
Also, bash’s (and other similar shells’) high degree of customization is both easily portable and massively extensible. With some minor customization it’s possible to match, or even exceed, PowerShell’s tab completion capabilities.
I'm very familiar with Bash, but I've never used PowerShell. It doesn't seem like e.g. passing structured data would be a bad thing.
Lack of thorough, accurate documentation shipping with modern open-source software is a real problem. While a lot of software written in the 1980s-1990s (GNU project, Solaris, etc.) have fantastic man pages and Info documentation, much that has been written since has been poorly documented, if at all.
Good documentation shows that (a) the author has thought clearly through their work and (b) shows respect for the user's time by not making them experiment or have to delve into the source code, third-party blog posts, etc. to figure out how the software works.
[0] https://fishshell.com/
Whatever shell you want to use, you can still use just the same in the new Terminal
I have an Asus with Windows 10, and after a day of use, it becomes unbearably slow. It seems there is a lot of activity on the HD. I tried to diagnose this, but was never able to pinpoint a specific process that was slowing it down.
The only solution was to restart it. Web browsing always had a huge delay.
Linux on the other hand: startup is fast, use is fast, runs for months without any restart.
Use some debloater to remove other stupid stuff. Then it will fly.
Learned this the hard way when I was interning as a tester for an audio driver. Sometimes the driver would get into a bad state, and you could power cycle the system and the driver would still be a bad state. I created a batch file that would run the shutdown command with a flag to initiate a complete shutdown rather than a kernel hibernation, which was necessary to reset the state of the driver.
I've never really used Windows as a daily driver until I had to do cross-platform development for PhotoStructure[1]. My windows box is a recent XPS 15 with an m.2 SSD and core i7. My Mac is a 10 year old 17" MBP. My linux box is the cheapest core i5 I could get 2 years ago with an mSATA SSD (not m.2).
Here's this morning's CI job timings (running the same 2K tests that exercise a reasonable mixture of CPU, process management, and disk I/O):
Windows 10 (XPS 15):
Mac (10 year old MBP on 10.11): Ubuntu (i5, LTS 18.04): I'd suggest backing up your HD, making a USB stick with OEM Windows 10, and reinstalling just Windows (with no Lenovo bloatware): https://support.microsoft.com/en-us/help/4000735/windows-10-...[1] https://blog.photostructure.com/introducing-photostructure/
That said, this is really a Windows-feature being misused by OEMs and as a user I would be interested in having a way to disable it.
What's in the 19 additional tests Windows is running? Is the Linux box a laptop as well? I'm personally having trouble believing the Core 2 Duo in your MBP outperforms a modern i7, even after potential Windows overhead.
Yeah, agreed, but these are single-core tests and even the max clock speed of intel chips doesn't seem to correlate exactly with performance. Here's more CPU details, though:
My XPS 15 is HT 4-core Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz.
The MBP is https://apple-history.com/mbp_17_mid_10. HT dual-core i5 ("Arrandale") @ 2.53 GHz. It's slow AF.
The ubuntu box is HT dual-core Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
> What's in the 19 additional tests Windows is running?
The 19 additional tests are windows-specific path validation unit tests, and take ~10ms total.
> Is the Linux box a laptop as well?
No, it's on a 3 year old cheapo mini ITX mobo.
> I'm personally having trouble believing
Me too. I've nuked and paved this box a couple times, thinking it was bad interactions with cygwin or MSYS or minGW. CPU bound stuff (like ffmpeg transcoding) is closer across windows and linux, but opening files and forking processes on Windows is just hella slow (even on my desktop windows machines).
Fork & fs operations, certainly.... nothing to do with Windows itself.
Both of these operations are known to be very slow specifically in windows. The former's the reason why windows has always strongly favored thread-based concurrency (whereas unices tend to favor process-based concurrency)[0], the latter is well know of NTFS, it deals especially badly with lots of small files.
[0] even excluding making the entire thing blowing its gasket as Bruce Dawson triggers with appalling regularity, in fact in one of his posts he specifically notes in the introduction that windows is notorious for its slow file and process operations: https://randomascii.wordpress.com/2018/10/15/making-windows-...
In practice, the i5-6500 is faster than the i7-6700HQ. The i5 enjoys a slightly higher turbo clock speed and less restrictions in TDP, cooling and power supply allowing it to run faster for longer so it's expected to be the fastest, but that doesn't explain the entire gap.
Have you tried using WSL instead? I found it to do excellent in CPU based tasks, but the file IO performance was a bit lacking. Apparently in the next release (along with this new terminal) filesystem performance should improve by a significant amount. Although I would still expect it to be slower than running on Windows/NTFS natively
Interesting. TIL, thanks. (I looked at /proc/cpuinfo on my i5, saw 4 entries, and assumed HT dual core).
> Have you tried using WSL instead?
These are tests to ensure PhotoStructure works on stock Windows machines, so I can't use WSL.
> filesystem performance should improve by a significant amount
That'd be awesome. Where'd you read that?
From here: https://venturebeat.com/2019/05/06/microsoft-windows-termina...
https://en.wikipedia.org/wiki/List_of_Intel_Core_i5_micropro...
2.installed from scratch
3.the windows setup only put essential Lenovo stuff - hotkeys and thermal management.
4. ???
5. Profit [1]
It made a real difference to disable the automatic windows updates and run them manually. There were no bloatware installed on my unit.
[1] A joke from the memes, its all good otherwise.
Granted, it has an SSD, so disk access is not slowing the machine down as much, but so do all the computers today.
Bloatware, begone!
In theory windows can be faster than Linux in some cases; but usually isn't because most developers don't actually take advantage of those APIs and just do everything synchronously which is stupid slow on Windows. That said Linux is catching up super quick in terms of those sorts of things.
EDIT: grammar
The best way to get a Windows computer is either building it or buying it directly from Microsoft so you can get the genuine versions that have little to no bloatware.
https://www.microsoft.com/en-us/software-download/windows10s...
"WSL 2 will also support running Linux Docker containers natively, so that VMs are no longer required."
Great news!
They could either go the syscall emulation route (as in current WSL), or possibly the "thin hypervisor" route, the fact they're talking kernel versions makes me think that may be what they're planning...
(I work at Microsoft but have no inside knowledge on this; just speculating.)
Whilst it doesn't explicitly mention Virtual Machines or Hypervisors, I'd read this as making use of that kind of technology with some additional tech. for interop with Windows to the level of WSL currently.
EDIT: and here's the confirmation https://devblogs.microsoft.com/commandline/announcing-wsl-2/ it's a VM
I've been running WSL for over a year with Docker for Windows and while the experience feels native to WSL (WSL has no problem running the Docker CLI and connecting to Docker for Windows) it'll be a very nice perk to just apt install Docker in WSL and not deal with DfW.
Unfortunately the link https://aka.ms/build2019kernelannounce doesn't seem to work for me.
The whole thing of WSL was it that contained no Linux kernel at all.
Today, Linux Docker containers on Windows rely on a VM running on Hyper-V.
Tomorrow (by which I mean "in the future," or "June 2019" or whatever the announcement says) Linux Docker containers on Windows will run natively, without the Linux VM crutch. I am assuming that it will use the emulated syscalls the same way that WSL runs today.
Adding the appropriate things to WSL to make Docker for Windows no longer require the Moby VM, or to support Linux Docker within the WSL environment without modification, is an approach that makes much more sense to me.
> WSL 2 uses the latest and greatest in virtualization technology to run its Linux kernel inside of a lightweight utility virtual machine (VM). However, WSL 2 will NOT be a traditional VM experience.
https://devblogs.microsoft.com/commandline/announcing-wsl-2/