bitcrazed

You think there weren't codes of conduct back in 1983? ;)

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.

Hi. PM on Windows & WSL here.

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.

As a matter of interest, have you tried WSL? It's a much more integrated experience than the isolated VM approach.

PM for Windows Command-Line here.

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.

Hi. PM on Windows Command-Line here.

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!

Repo: https://github.com/microsoft/terminal

Hi. PM on Windows Command-Line here:

A couple of things:

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

You might find it interesting to read my series of posts on the evolution of the Windows Command Line: https://devblogs.microsoft.com/commandline/windows-command-l...

HTH.

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.

If you'd like to see what telemetry is being collected, on your machines, this may be of help: https://docs.microsoft.com/en-us/windows/privacy/diagnostic-...

HTH.

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.

Re. Color: Not true - Windows Console supports 16M 25-bit RGB colors since Creators Update (build 1703): https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-b...

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.

We hear you re. disk perf, and Linux filesystem access from Windows - we're working on it. Bear with us.

Also, we added a decent amount of libusb support back in Creators Update: https://blogs.msdn.microsoft.com/commandline/2017/05/10/bash...

In short ... DON'T!

Assume that your distro's are locked away behind a one-way wall - Linux can see Windows files, but Windows cannot (safely) use Linux files. More details here: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...

And yes, we're working to close this gap in future releases, so stay tuned!

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.

YMMV.

You mention Hyper. Are you running PowerShell connected to Hyper or Console?

If you're running Hyper, note that this alone takes 6s to (warm) start Cmd on my 16GB RAM Core-i7 Surface Pro 4.

PowerShell takes ~1.2s to (warm) start connected to Console, while also starting a half dozen modules and scripts in my PowerShell user profile.

PowerShell takes < .7s to start when run with `-NoProfile`

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.

You're conflating two things here:

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.

Fixed! Let me know if you prefer the updated version I posted this afternoon.

Thanks for the feedback :)

You would be hard pressed to find DOS-era software that bangs on buffer starting at 0xB800:0000 that still works in 64-bit Windows.

True, though 32-bit editions of Windows still include NTVDM which runs Win16 apps!

Microsoft is pretty fanatical about backward compatibility.

Why? It's the #1 reason most enterprises and many users continue to pay to install/upgrade to Windows.

Breaking backward compatibility with existing executables (not source-code) is a violation of the trust that we've earned with customers for the last 40 years or so.

Of course, some products/features/etc. are discontinued on newer OS', etc. but the core essential platforms are rarely discontinued.

True fact: Windows still runs VB6 apps - millions of them. EVERY DAY!

Console now enumerates and allows selection of monospace TTF fonts.

Alas, as one of our dev's says often "Fonts are just files containing collections of lies"!

Some fonts claim to only contain monospace, glyphs, but don't and include non-monospace or irregularly sized chars. Others just lie completely.

But if you have well-formed TTF fonts, that express correct metdata, and ARE monospace, then they should be selectable.

As a matter of interest, have you tried Windows 10's Console?

Actually, no - Windows ME did not depend on MS-DOS.

For all the bad rap it got (some of which was deserved), ME bypassed real-mode MS-DOS (and its config files) at bootup, and loaded its own protected-mode drivers, etc. in IO.SYS. It also loaded the main registry hive only once, and parallelized PnP resolution, significantly improving boot-up time. It also incorporated Windows 2000's networking stack, and added support for UPnP.

In many ways, ME was a stepping stone, getting some users on less-capable hardware onto Windows 2000 class OS features, without requiring a complete hardware upgrade.

Refactoring spaghetti would have been a breeze compared to the Console.

What stands as a HUGE testament to the Console team's effort, however, is the fact that, while re-engineering what was truly a nightmare code-base, apart from a few newly-introduced bugs (most of which were caught before release), the rapidly improving Console didn't break any any existing command-line apps or users' workflows.

The engineering team deserve a medal for pulling this off, quite frankly!

G'ah - PLEASE read the posts about which you're commenting - Cmder is a terminal/Console, not a shell.

Cmd.exe is a (headless) command-line shell.

A shell accepts input from a terminal/Console and emits text to its connected terminal/Console to be displayed back to the user.

All this is covered in some detail in the posts thus far.

<img src="Eyore_looking_glum.jpg /> ;) :D

I'd swear at you in Welsh but I fear I may wear-out my 'l', 'e', and 'u' keys ;)

Thanks all - appreciate that some of my enthusiasm came through, though the previous poster had a point about the sheer density of my excitement so I toned it down a little while making a few corrections, clarifications, and improvements in the update I posted this afternoon.

Keep the feedback coming though - you'll also find me on Twitter a lot more than in here: https://twitter.com/richturn_ms

Fair comment - I agree and so removed a bunch of !'s and emoji for you, though I did leave a few in to convey some of my (and the team's) excitement - we're genuinely buzzed to be able to massively improve the Console.

Hope you find the latest updated version more palatable.

LOL - nothing nefarious - made a few corrections and improvements to the post - aaaaand managed to bork the publishing process which took a few mins to re-generate and refresh the cache!

Ugh!

Should be back up and available now!