You and I both - first time I ever touched an IBM PC XT (in my Dad's office), I immediately fired up BASIC and went to town (had already been programming BASIC for 18 months by that time).
It was the first time I ever saw him just stare in awe at me like I was an alien's child! :)
WSL uses a Hyper-V derived virtual machine that is
* Sparse & light - they only allocate resources from the host when needed, and release them back to the host when freed
* Fast - it can boot a WSL distro from cold in < 2s
* Transitional - these lightweight VMs are designed to run for up to days-weeks at a time
Full Hyper-V VMs aim to (generally) grab all the resources they can and keep hold of those resources as long as possible in case they're needed. Full VMs are designed to run for months-years at a time.
WSL's VMs are MUCH less impactful on the host - FWIW, I run 2-3 WSL distros at a time on my 4 year old 16GB Surface Pro 4 and don't even notice that they're running.
Hi. Microsoft PM working on WSL, Terminal and Windows.
WSL2 literally runs user-mode distros (and their binaries) in containers atop a shared Linux kernel image (https://github.com/microsoft/WSL2-Linux-Kernel) inside a lightweight VM that can boot an image from cold in < 2s and which aggressively releases resources back to the host when freed.
So when you run a binary/distro on WSL2, you are LITERALLY running on Linux in a VM alongside all your favorite Windows apps and tools.
If some of the tools you run within WSL can take advantage of the machine's available GPUs etc. and integrate well with the Windows desktop & tools, then you benefit. As do the many Windows users who want/need to run Linux apps & tools but cannot dual-boot and/or who can't switch to Linux full-time.
This will (and already has) resulted in MANY Windows users getting access to Linux for the first time, or first time in a while, and are now enjoying the best of both worlds.
Imagine if you could run AI/ML apps and tools that are coded to take advantage of DirectML on Windows and/or atop DirectML via WSL.
Now you can run the tools you want and need in whichever environment you like ... on any (capable) GPU you like: You don't have to buy a particular vendor's GPU to run your code.
If you're old like me and remember the dark ol' days when games shipped with specific drivers for (early) GPU cards/chips, but failed to run at all if you didn't have one of the supported cards, you'll understand why this is a big deal.
Appreciate your feedback, but we solicited and received feedback from many, MANY sources. UserVoice, Stack Overflow, Github Issues, customer interviews, email, Twitter, comments after speaking at events, comments from customers at booths at OSCON, Build, Ignite, JSConf, PyCon, etc. to name just a few.
We received an OVERWHELMING number of asks for unicode text support. Emoji are simply one class of unicode glyph but they're pretty important for those working with tools/scripts that use emoji to indicate the state or outcome of an operation.
Further, many users speak non-Latin languages which require non-ASCII glyphs, some of which can be quite challenging to support in a grid-based display format (e.g. Arabic, Hebrew).
This whole class of asks around "Unicode Support" required not just a brand new renderer that could actually draw the correct glyph in the correct cell, but also a whole new way of storing, iterating, and navigating variable-width code-points qucikly and efficiently.
These asks (and many others like them) vastly outnumbered asks for mouse support.
The Console/Terminal team first took-ownership of the Console & Cmd codebases in late 2014, so it's been ~5.5 years.
Until v. recently, the team averaged ~2.5 devs and 0.5 PM (I had to split my time across Console and WSL).
Since spring 2019 when we began the effort to build Windows Terminal, we've grown the team to 4 devs and 1.25 PM (I am now the .25 since Terminal now has a dedicated PM).
During this time, we have shipped improvements to Console in every release of Win10, including transparent background, VT, 24-bit color, and many perf, stability, etc. fixes. But we can only do so much to the Console before we start to break users' existing systems, apps, and tools.
Since Console & Cmd's key responsibility is backward compat, we're pretty much leaving them alone.
But we're plowing ENORMOUS effort into building Windows Terminal which is shaping-up nicely for its v1.0 release this summer. Please give it a try and if you find problems, find/file issues in the github repo because, yes, Windows Terminal and Console are open-source!
1. You're confusing Cmd (the command-line shell) with Console (the terminal UX you see and interact with on-screen)
2. Development for NT started in Oct 1989 and the first version of NT shipped in 1993
Hey Nick. I'm the PM for Windows Terminal, and formerly, WSL:
Thanks for your thoughts on WSL & the new Terminal.
Re. release mechanisms, etc: Terminal will be delivered via the Store so we can ship out-of-band.
We're aiming to deliver new Terminal preview builds every 2 weeks or so which, since we're delivering via the Store, will auto-upgrade everyone soon after each release.
Re. Insiders: We do NOT gather any personally identifiable information. We only collect anonymized statistics about some of the features you use and/or issues you experience. Why? To ensure that we can find and fix issues as effectively as possible.
For example, with WSL, we collect the number of times an un-implemented syscall is called, or # of times a syscall returns an unexpected error. We couldn't care less WHO experiences these issues, only how OFTEN they occur. This info (esp. combined with bug reports in our repo, etc.) has been essential in helping us prioritize which syscalls are being called, which we've implemented, which are failing, and thus, which we need to pay attention to. Without this info, we wouldn't have been able to make WSL as good as it is.
We understand the community's concern about data collection - heck, EVERYONE should be - but in the general scheme of things, I think it fair to say that Microsoft's telemetry data collection is pretty well contained and is not egregious.
You should give WSL a try now - a couple of years ago would have been shortly after it was first released, when it was VERY early, and only barely able to run some of the more sophisticated tools you'd want/need.
WSL has come a LOOONG way since then, and yes, we are still working to improve disk IO perf.
That said, yes, the Console cannot currently support font-fallback and thus cannot display glyphs that are not present in your currently selected font. We are, however, working on fixing this in an up-coming OS release.
Bear with us - lots of exciting things afoot with the Windows Console.
I recommend enabling WSL, installing your favorite distro from the Windows store and giving it a try. I think you'll be surprised by what WSL CAN do and the scenarios in which it's more useful than a full VM.
Distros running on WSL also consume FAR fewer resources (esp. memory) compared to full VM's, so runs well alongside all your usual tools.
It doesn't (and wasn't designed to) replace a full Linux instance, but often goes ~80% of the way towards meeting the every-day needs of a lot of developers who just need their code to build and run locally.
IFSHLP.SYS was originally created during the implementation of OS/2 1.2, and later released in Windows 3.11 running on 32-bit 386 Enhanced Mode.
Its job was to provide 32-bit file access (bypassing 16-bit DOS file IO mechanisms), and ensuring nothing else on the system could intercept INT 21h calls.
ME didn't depend on MS-DOS (though it did provide support for running MS-DOS apps).
I am not comparing performance of a terminal window - Cmd and PowerShell both run connected to the same terminal app - Windows Console (conhost.exe) as discussed ad nauseum in the posts that are the subject of this thread.
But you're comparing a 30+ year old command-line shell that was built in 1989 to primarily provide compatibility with MS-DOS, with a modern object-based shell that runs atop the .NET CLR and provides VASTLY more power and capability than the MUCH older, simpler, shell that it supersedes.
It's like comparing startup perf of Notepad and VSCode … and saying that you won't use VSCode until it starts up as quickly as Notepad, even if VSCode saves you HOURS more per day/week than using Notepad would.
Remote Procedure Calls have many implementations. CORBA and Java implement RMI, Microsoft implemented DCOM. And for serializing API calls, they do great.
However, what's REALLY hard about remote object systems like CORBA, COM+, etc. is reliably managing object lifetime semantics. It turns out that trying to manage stateful object lifetime via an inherently unreliable network connection is tricky, if not impossible.
All the reliability semantics, security infrastructure, etc. layered on top add considerable processing cost.
By comparison sending text back and forth via networks, and/or tunneling pipes (e.g. ssh) is a piece of cake.