Mary Jo FoleyModeratorNov 21, 2019 at 10:35 am #624950
Our next MJFChat, scheduled for Monday November 25, is between me and Microsoft Senior Program Manager Rich Turner. We’ll be talking about Microsoft’s new Windows Terminal app and the quest to make the Windows command line cool (again).
What questions do you have for Rich about Microsoft’s console/Terminal directions? No question is too big or too trivial. I’ll be chatting with him on November 25, and will ask some of your best questions directly to him. Just add your questions below and maybe you’ll be mentioned during our next audio chat.
nunixParticipantNov 21, 2019 at 2:53 pm #624969
Dear Mary Jo and Rich,
using WSL on both Windows 10 (insider fast, what else) and Windows 2019 vNext, I would like to ask if we will see one day the Windows Terminal on Windows Server core (2019).
Currently my go to Terminal on 2019 is Cmder (installed with Chocolatey).
Thanks both for all your work and community oriented work.
The WSL Corsair :)
GyorgyParticipantNov 25, 2019 at 1:22 pm #625038
For me the tabbed Sets are the most appealing feature that shouldn’t be removed! That’s my only question :)
Brad SamsKeymasterDec 02, 2019 at 9:13 am #625124
You can find an audio replay of the conversation, here.
Mary Jo Foley: <u>00:00</u> Hi, you’re listening to the petri.com M J F chat show. I am Mary Jo Foley, AKA your Petri.com community Magnate and I am here to interview tech industry experts about various topics that you, our readers and listeners want to know about. Today’s MJFChat is going to be all about how Microsoft is working to make the windows command line cool again. My special guest today is Microsoft senior program manager, Rich Turner, welcome Rich and thank you so much for doing this chat with me.
Rich Turner: <u>00:37</u> Hi Mary Jo. Thanks so much for inviting me. It’s always great fun to talk with you.
Mary Jo Foley: <u>00:41</u> Yeah, same. It’s been too long. So, Rich has been at Microsoft like four years now. Is that right?
Mary Jo Foley: <u>00:51</u> In this tour of duty? Yeah, this tour of duty.
Rich Turner: <u>00:54</u> I actually was at Microsoft from 2003 2010 when I left and I went on to the real world and did real worldy things, running startups and all kinds of stuff, and I came back to Microsoft at the beginning of 2006. Having sent some flame mail to my now boss complaining about the state of the windows command line and what was Microsoft doing about it and so on and so on. And he said, come for lunch. And I came for lunch. Two weeks later, I’m interviewing, two weeks later I’m walking into NEO and thinking, well, here we go again. It’s been an amazing ride this last four or five years we’ve been doing incredible things that I’d, I’d never even have thought we’d have been alive to think about in my first tour of duty.
Mary Jo Foley: <u>01:37</u> I don’t think you would have bet. Yeah, I know. I know, right? Yeah, exactly. It’s funny to think, just like a few years ago, if you said to someone, by the way, there’s going to be a Linux Kernel in Windows, they’d be like, what?
Rich Turner: <u>01:56</u> Exactly. I know, it’s quite an amazing thing and it just goes to show just how much the company has changed. It’s so much more fun now than.
Mary Jo Foley: <u>02:09</u> Yes, I agree. Yeah. And then this year at Build, back in the spring, Microsoft unveiled the Windows Terminal app, which also was kind of surprising to people. I remember thinking, Oh wow, I can’t believe they just did that. That’s very interesting.
Rich Turner: <u>02:22</u> Yeah. Yeah. It’s interesting that the Terminal, has turned out to be one of the, one of the most popular, both open source projects, Microsoft and shipped recently. And also one of the most popular apps that we’ve shipped. So there’s who, who wants to just use the Terminal, they just want to install it from the store and they can go to the Windows Store and they can just click a button, download the Terminal, and a few seconds later they’re up and running with, a new fresh take on the Windows Command line user experience, which lane fairly neglected and unloved for many years until our team took it over and started working on it. So we’ve added a bunch of the features that the users have been asking for for years and years and years and that we’ve been asking for for years and which I actually asked my now boss in that, in that flame mail, when are you getting around to adding tabs to the terminal and so on.
Rich Turner: <u>03:12</u> We finally be able to ship those things, which is incredibly exciting for us.
Mary Jo Foley: <u>03:18</u> So yeah, I was going to say you’re a group does WSL and terminal, what else do you do in your group that you can talk about?
Rich Turner: <u>03:27</u> So we own the, the interesting thing is the Terminal itself will, we’ll leave WSL to the side for just a second. WSL itself. Sorry, sorry. Windows Terminal itself is built out of many of the components that used to live deep within the windows console. They, when you, when you run CMD or you run PowerShell today or you run any command line application from Windows, it will pop up a command line UX on the screen. That thing that you see on screen is the same application whether you’re running PowerShell, CMD or whatever app you run.
Rich Turner: <u>04:00</u> And that’s the thing that’s been in windows since NT 3.51. It was one of the very first apps I ever built for NT when they were building NT itself. It has had a few owners over the years and has had many people contribute to its code base over the years. But no one owned the code until about 2014 when they formed a new team here in our division to take over that code base. The console UI that you see on the screen there isn’t, isn’t just UI. It’s actually a monolithic application that provides the entire windows command line infrastructure. So when you build a command line app like a get or a node or Midnight Commander or whatever Windows command application you use, when you call an application to set foreground, sorry, call an API to set the foreground color to set the background color to output text to move the cursor to the given location.
Rich Turner: <u>04:58</u> Every time you call one of those API APIs, your command line application is essentially making core across process to the terminal to which it’s attached to the console to which is attached. And the console provides the API server, so your application every, every time it tries to write to the screen, for example, is calling of a method exported by exposed by the Windows console and the Windows console then draws the thing on the screen and then returns back. And then the command application continues. This is a very different way compared a way of operation compared to most terminal applications, especially those built against the next platform, the Unix Linux platforms, which basically sit there and accept keyboard input in and then write text back just by emitting text to whatever’s on the other end. So with Windows Terminal we wanted to really overhaul things and really modernize things and we wanted to continue to support existing Windows Command line applications.
Rich Turner: <u>06:02</u> So none of them had to change in any way. And we continue to do that by probably providing a API server, essentially that performs the functions requested by the terminal. And then also adopts a more Linux like behavior of being able to pause a stream of text and pull out to that stream of text. The, the VTE sequences, the character sequences that describe, how the text should be formatted, colored, where the cursor should be moved to clearing the screen and all those kinds of operations. They’re embedded as codes within the text, essentially in Linux and Unix. And we wants to adopt that world as well. So we essentially now do both things.
Mary Jo Foley: <u>06:44</u> Okay. Well, so what, what provided the impetus for Microsoft to create the Terminal app? I mean, did people say we want a terminal app or did or did you have a specific audience who are trying to get to when you thought about creating this kind of a terminal app? I’m looking for a little historical thinking about how it came to be.
Rich Turner: <u>06:59</u> Right. So, it’s interesting when you, when you look back through, especially through the two thousands, you look back at the world we were living in then when, everything had to gooey and in order to operate windows in particular, you use the GUI and you click buttons and you moved sliders and you click check boxes and so on to administer things, to change settings on things and so on. That was the world in which we lived, especially in the early half of the two thousands. But then the rapid growth in especially open source projects and especially cross platform or NIX platform, open source projects meant an awful lot more stuff was being done at the command line. If you think about things like Git, when Git came along, it was a purely command line application.
Rich Turner: <u>09:24</u> That kind of stuff was becoming really prevalent by the, by the, 2010ish mark. Anybody on windows then goes, Hey, I’m going to try and use node and Python and Ruby and Git and so on and so on. And they using this command line interface, which was designed in 1989.
Mary Jo Foley: <u>09:43</u> Yeah, exactly.
Rich Turner: <u>09:44</u> It hasn’t changed much and has numerous frustrations and weaknesses, a lot of missing features. And it drove people nuts. It was a continual source of feedback from the community that they wanted a decent command line interface. And eventually it got to a point where even the likes of myself saying send flame mail to Microsoft. And luckily I just sent the flame mail at the point where they were literally forming the, or the team had just been formed and given the remit of overhauling the windows command line, modernizing it, enhancing it and making the windows command line a much, much nicer place to be for those people to work in that environment.
Mary Jo Foley: <u>10:25</u> Okay. Which came first then the redo of the terminal app or WSL — or how are those two things connected?
Rich Turner: <u>10:34</u> So they came about in parallel. Actually WSL is an interesting one because essentially what happened was at the very beginning of Windows 10, my now boss that I sent flame mail to had begun a process with a bunch of other people to create a User Voice forum to ask the community directly what they would like to see happen in various areas of technology. So in the Windows UI tech stack, what would you like to see as a UI developer in the windows command-line world? What would you like to see as a development user of that, of those tools and technologies? And we essentially allowed the community to send in feedback and use a voice, had a really good way of, of handling, upvoting and, you know, you originally they changed their voting policy later, but ultimately you had 10 votes and you could only spend 10 votes and until a feature was implemented, you didn’t get a vote back.
Rich Turner: <u>11:31</u> So you have to spend your votes votes wisely. And it meant that people tended to apply votes to things that really mattered to them. As if you look at the, the list of things that people asked for with regard the command line. The number one thing was I want to be able to run this next application or tool on Windows. Number two was overhaul the console. I want to have someone to emoji. It’s too slow, yada, yada. So WSL was, was really born from that ask from the community of saying, you know, I want to be able to run Grep and Awk and Git and Node and then Pearl and Ruby and all of those things that they run on Linux on a daily basis. But I wanna be able to run those things on Windows.
Rich Turner: <u>12:17</u> So we, we took a look of a bunch of options from doing something similar to Cygwin where we recompile a bunch of the new tools to run on Windows. Unfortunately, that approach is a very short lived one for what we wanted to achieve because we would have an endless long tail of things that we hadn’t yet recompiled to in 32. Trying to keep up with updates for all of those technologies would be extremely difficult. So that wasn’t really a, a comprehensive solution to the problem. Running a VM at the time with the VM technology that we had at the time wasn’t really feasible because booting up an entire VM took a lot of time, took a lot of memory and so on. So we said, what, what would happen if we could literally run or create a layer in NT that pretended to be Linux?
Rich Turner: <u>13:07</u> Could we build enough of that to allow, next applications unmodified by Luke’s binary’s to run on Windows? And that’s essentially what we did. So we worked with a team in the Windows kernel based team here who’d be working on an Android runtime platform. Then we said, Hey, what would it take to actually extend that and run Linux? And they said, well, actually it would be not too much work. And then in huge inverted comments, we spent about eight, nine months or so putting, you know, implementing a few more of the Linux calls. And we started getting these Linux binaries to be able to light up and run on top of that Linux kernel layer on top of the NT Colonel to run those tools natively and unchanged as well, which is really important.
Mary Jo Foley: <u>13:56</u> So does that mean that WSL came out of the work that Microsoft was doing on the Android bridge, the Astoria thing?
Rich Turner: <u>14:05</u> Yes.
Mary Jo Foley: <u>14:05</u> Oh good.
Rich Turner: <u>14:05</u> It came from the team that built WSL was a story of team members.
Mary Jo Foley: <u>14:12</u> Oh really, I don’t know if I knew that. Or maybe I knew it and forgot.
Rich Turner: <u>14:14</u> The breadth of the landscape you cover, I’m not surprised. But yeah, the Astoria thing was, you know, was a very interesting project for Windows to try and run Android on top of Android apps on top of Windows. And so they’d implemented an awful lot of what we already needed. And we just said, Hey, just keep going. Just keep going, build a few syscalls, build a few more syscalls. And then things started running and then we got hello world in, you know, GCC compiled hello world to run. And then we got Java to run and we got Node to run. And each time we implemented a new syscall the, which are essentially the functions that Linux kernel exposes.
Rich Turner: <u>14:54</u> Every time we added a new syscall or implement improve the implementation of a syscall suddenly would unlock 20 or 30 things sitting on top of it. And we just kept going like that until we announced WSL. And then we kept going with the community and said, Hey, let us know what’s not working. And then we’ll go and figure out which this calls are missing and we’ll try and implement those things. And that’s where WSL came from. So in parallel to that. Of course, if you’re running again WSL especially WCL 1 was primarily focused on the command line. We didn’t focus on running Linux GUI apps, although many eventually did end up working quite well on WSL one. But primarily focusing on the command line. So if we’re running these Linuxy command line things, then wouldn’t it be awesome if we had a command line user experience that actually was able to run them well, that was able to understand the stream of text coming back from these applications.
Rich Turner: <u>15:49</u> When you type in a command and you get text output out from the tool you’re running, we need to be able to understand the embedded VT codes, the embedded virtual terminal codes that say turn the foreground color to red, turn the background color to blue image, emit this text, move the cursor to this location to have the screen, etc. So we then started adding an implementation of a VT posit to the Windows Console as it was, as it is, and will always remain built into windows itself. So that we could actually use many of the Linux command line tools which use VT and embed VT into their output text. So those two things basically evolved side by side. As WSL started running more things, we would start seeing more and more unexpected and unimplemented VT sequences. So we then go and implement those VT sequences, which let those tools run well.
Rich Turner: <u>16:43</u> And then WSL would go and implement another syscall and that would unlock another tool which would emit another VT pattern we hadn’t necessarily seen. And so in partnership going back and forth on a very rapid cycle, especially during the Insiders program with the help of our amazing community, we were able to, to track down an implement the sort of the 80% case. Both of the 80% of all assist calls that Linux tools used as well as 80% of the VT sequences that, that the Terminal had to implement. And we ran like that for the good, for a good year or so to, to dramatically improve windows console’s ability to understand VT, also adding accessibility features as well to expose the console’s contents to screen readers and various other assistive technologies, which we found it to be incredibly important and which the community seems to agree and really appreciates that work, which is great.
Rich Turner: <u>17:38</u> We have a great relationship with our accessibility folks and our accessibility community and we continue to do that work today in Terminal itself. In fact, in the last couple of releases we’ve reattached that accessibility engine, essentially it’s a Terminal as well. So that we have the same level of compatibility and support for assistive technologies across Windows Console and Windows Terminal. And of course we’re doing it all in the open as well. That was the other big thing about it was we didn’t want to have to build this thing in house with only us seeing the code and understanding how it worked. We wanted to work with the community and to be able to expose that code to the community. And have their assistance in helping us figure out where really wonky, really unusual VT sequences work in this particular way. If someone’s got experience, especially specializes in that area, then we want to be able to learn from them and, and to have them help contribute as well. And that’s certainly been born out to be the case.
Mary Jo Foley: <u>18:35</u> So is the terminal app a UWP app?
Rich Turner: <u>18:44</u> No, no, not at all. We’ve actually been relatively transparent about this but, for example, in many of the comments and issues around the Terminal of itself, so it’s good to talk about this from a higher level as well. Wen we first started selling the idea internally of building a Terminal, cause of course, remember, you know, Microsoft is a corporation, they want to know that when they’re going to spend developer dollars on, on, on hiring people and paying people to work on a project, they want to know there’s going to be a good return of the customer base and the users are going to appreciate the work. So that they need the work. And it’s important to them. So we had to go through a process of validating why we had to build a terminal and who, how many people it would impact.
Rich Turner: <u>19:24</u> So one of the things we wanted to make sure was that when we built the Terminal that it was a good citizen in terms of the modern Windows App platform. We wanted to be able to show if you wanted to build a Terminal-like application, here’s how you might go about doing so. And here are some of the UX design choices and also here are some of the implementation details behind the scenes. So we wanted to build a the Terminal as a full UWP application. The challenge is the terminals have very unusual in compared to most Windows applications. Most applications in general. In fact, most applications don’t need to run elevated, don’t need to run with admin rights. Most windows applications these days, since Vista first plugged all of those Windows XP security holes most applications have now been modified and upgraded and updated to no longer depend upon an assumption that they’re able to go and touch and fiddle with whatever they want throughout the assistant, which makes it much safer, makes it much more reliable, etc.
Rich Turner: <u>20:31</u> But for Command Line applications, you often do need to run a script that goes and modify some system wide setting or copy a file into a particular location on the hard drive that may be a protected area and so on and so on. So you need to be able to run many line tools elevated, which means the Terminal to which they’re attached needs to run elevated as well. So we avoid many, forms of security, vulnerability and weakness. So UWP applications are not allowed to run elevated. UWP applications are also not allowed to launch arbitrary external binaries, which terminal is, that’s basically what it does. The terminal fundamentally is very, very simple. It accepts keyboard input and squirts it out as characters to a listening application. And then it takes text emitted by that listing application and draws it on the screen.
Rich Turner: <u>21:27</u> The terminal itself does very little in fact. In reality, it’s the command line application to which it’s attached that does all the work, like PowerShell, Bash, WSL, CMD etc., etc. So when we started building the Terminal, we figured out that we couldn’t actually use the, the full UWP platform quite in the way it was originally implemented. We’ve continued to work with that team. We’ve actually got work ongoing to help make it easier for us to actually build a UWP terminal in the long run. But for now, what we basically had to do was to create a Wind 32 standard windows desktop application host, in which we host a XAML Island, which is the technology that allows you to essentially integrate next modern, Wind UI XAML controls on top of the traditional Win 32 application.
Rich Turner: <u>22:22</u> That’s all housed on top of the XAML Island, essentially. And so we build 90% of the Terminal itself has built a top on top of the XAML Island . The Terminal itself, the innards of the console and the terminal innards are all essentially stored in a set of DLLs and labs. And we then wrap those in a UWP control so that we have a Terminal control and we embed that Terminal control inside the Terminal app along with the wind new UI tap control that we worked in partnership with our friends. So essentially we are building the Terminal as, as most developers would. You start with an application you put in XAML Island if you’re gonna use them all UI. And then we have a tap control and a Windows Terminal Control. We build the application, a very modular fashion in that way.
Rich Turner: <u>23:17</u> That means that when the platform eventually does evolve and is able to support our requirements in terms of being able to launch a binary launch, arbitrary binary and to run elevated, then we’ll be able to literally do very little work. Maybe maybe a week or so’s work, maybe a couple of weeks that devs are going to kill me for saying this. But a couple of weeks worth of work to simplify the app and pull away the Wind 32 stuff, leaving just the Wind UI stuff other than the modern application is left behind essentially.
Mary Jo Foley: <u>23:50</u> So is the only way to get the app right now through the store or not? I know I’m asking all these like is it this or that, but it’s kind of both, right?
Rich Turner: <u>24:00</u> It’s a little bit of both. Yeah. Primarily if you’re on Windows 10 and if you’re on Windows 10 1903 or above, we recommend that the majority of users, especially those who don’t want to delve into the innards of the console terminal, just go and grab it from the store and install it and you’re good. If you’re a developer who wants to work on the innards of the console or customize it to your needs, then you can go and get the code itself, you can, all of the code for the console is open source. So you can in the terminal that’s open source so you can build the whole thing yourself. You can modify it, tweak it as you wish. If you’d like to help us, uh, fix issues and round out features and add new features, then we’re happy to work with you on that as well.
Rich Turner: <u>24:42</u> So if you want to do that, you can build your own and you can run the one that you build yourself alongside the one that you get from the store if you wish, which is sometimes useful if you are working on something and break the behavior behavior and you still need to be able to use a Terminal. You can run both side by side. But for those people who work in enterprises that block the Windows Store or if you’re working in an environment where you might want to run on Windows Server for example, um, your, you will basically have to go to a manual install scenario. For that scenario, you’ll need to go and get the build from the GitHub repo. Every build we publish to the store. We also publish to get up to manual install that stuff.
Mary Jo Foley: <u>25:27</u> You just gave me the perfect segue to the next question by the way. So, one of our readers “Nunix” in the Forums. He said: I’m using WSL on both Windows 10 in the Insider Fast ring and Windows 2019 VNext I would like to ask, will we see one day Windows Terminal on Windows Server Core 2019. And he said, the reason I’m asking this is my go-to terminal on 2019 is Commander CMD installed with Chocolately.
Rich Turner: <u>26:01</u> Yes. Okay. So I’m sorry, could you restate the beginning of his question?
Mary Jo Foley: <u>26:08</u> So he said he’s using, yeah, he’s using WSL right now on Windows 10 and windows, Windows 2019 V next. So I think he’s meaning the Server insider builds, right? He said: I was wondering if I’m going to see windows Terminal, running on Windows Server Core 2019.
Rich Turner: <u>26:30</u> So for the Server story, Server is moving more to a world where it’s genuinely recommended — and I’m talking as someone who used to run Server on every laptop and desktop I owned until about while really until Windows 7 came along and Hyper V and IIS 7 were available on Windows 7 and I no longer needed to run server. But I run Server on every machine I had for many, many years. The general, the general approach has been, to treat servers a largely headless environment these days and to do the work on Windows 10 and then to deploy your to server. However, we do know that there are many people who, especially those who work in network administration and says ops and dev ops and so on, they prefer to work on the platform that they’re going to be deploying applications to in production.
Rich Turner: <u>27:25</u> We’ve totally understand that. So yes, you can actually get Windows Terminal to run on Windows Server today with a desktop experience pack if you install the correct Visual C plus plus a runtime. That’s the one dependency that we have. It’s a little bit tricky to find it right now and to install the correct VC runtime dependency. But once you’ve installed that, then you can manually download the Terminal Build from GitHub and then you can install that application on your machine and you can run the on server. There are a few hoops that you currently have to jump through that we’re working hard right now. Literally, I’ve got conversations this week with a couple of other teams to figure out a smoother path for all of this. But ultimately we do want you to be able to run this thing on Windows 10 or Windows Server with a desktop experience pack, so that you can run on the platform that makes most sense to you.
Mary Jo Foley: <u>28:27</u> Okay. That’s good. So I have, I have one last question for you before we sign off. I’m not asking you to break any NDAs here. I’ll start with that. But any broad hints you can give us about what’s next for Terminal / WSL like just kind of like, in a general sense.
Rich Turner: <u>28:49</u> Okay. So that’s one of the great things about the way that we’re running the Terminal project in particular. And it’s, is that because we’re doing everything in the open, we’re being very open and transparent about our future.
Mary Jo Foley: <u>29:02</u> Okay.
Rich Turner: <u>29:02</u> So for Terminal itself, we are literally the back end of November right now as we speak. Our goal is to get to what we call feature complete by the end of this year. In reality, because a lot of the team are disappearing for Christmas. We’re aiming to get to feature complete by about December 13th, Friday, December 13th. Because the we can off to where or disappearing to go various parts of the world. So we’re trying to get to feature complete this side of Christmas. After Christmas, we then switch into a mode of stabilizing, tuning, polishing, and really going to town on quality as opposed to building new features.
Rich Turner: <u>29:52</u> For V1, we’ve actually published on our repo what the list of V1 features are that we’re aiming at. Right. We’d like to at least get the basics and the fundamentals of those features in this side of Christmas. And then from Christmas out until spring next year, we’re basically going to be focusing almost all of our time on quality, on polish, on fixing bugs, fixing perf issues, compatibility issues, making sure accessibility mechanism rocks, etc. And so we’d like to be able to get to call Terminal V 1 spring next year.
Mary Jo Foley: <u>30:26</u> Okay.
Rich Turner: <u>30:27</u> Calling it V1 in particular is important. And in particular for many enterprises that don’t allow their developers to use technology that is in a beta or non released form.
Mary Jo Foley: <u>30:38</u> Right.
Rich Turner: <u>30:40</u> So we want to be able to get the Terminal into really good shape where both we and the community sign off and say, yes, this is great.
Rich Turner: <u>30:48</u> This has, you know, there are no major blocking security or reliability or perf issues, no major blocking compatibility and quality issues. We think this is a really good solid V one at that point we’ll call it the V one with help from our community as well. So we really need your feedback on that. But we really want to be able to call V one and say, right, we now feel confident that this is a V 1 quality product and the enterprises can trust this and rely upon this in a production enterprise environment. As we wind down through that process, there will be fewer and fewer bugs that we’ll be able to take later on later in the process. And as we pull developers off from quality work, or as they run out of quality workers, we start to fix it more and more issues.
Rich Turner: <u>31:33</u> Would they then transition on to the features for after V 1 and we have a long list, long and growing list of features where you want to add for v-next. We’re looking at all kinds of things right now but including an extensibility mechanism so that you can writing, build extensions for Terminal that run inside and along the side terminal but without having to modify the guts of the Terminal itself. Which would be really exciting that we expect that to be really, really quite exciting in a similar kind of way to visual studio code with a huge raft of community driven and Microsoft provided extensions as well. We would hope to see as some of the things with the terminal. WSL they are working on WSL V2 right now. WSL V2 fundamentally changes the architecture of WSL to use some, some new container based virtual machine technology.
Rich Turner: <u>32:31</u> Instead of having a layer at the top of the empty Kernel pretending to be Linux, we’ve actually run a, a lightweight VM that boots up in less than two seconds, upon which we then run all of your limits distros and they run with 100% limits compatibility cause they’re actually running on top of a Linux Kernel, which we ship in NT in Windows itself, which still blows my mind to say that that planning on shipping that again spring-ish next year.That will round out the first implementation of V2. And then after that they got a long, long list of procedures that are continuing to work on for WSL as well.
Mary Jo Foley: <u>33:12</u> Cool. All right, well thank you again, Rich for doing this. This was super interesting. I feel way more caught up now on what’s going on in Terminal.
Rich Turner: <u>33:22</u> Thanks so much for inviting us to talk and for sharing this information with the audience and let’s see if we can do this maybe more frequently.
Mary Jo Foley: <u>33:28</u> I agree. I love this. I love that idea. And, and for everyone else who’s listening to this, all you MJF chat readers and listeners, we’re getting ready for our next chat right now. I’ll be posting that information on Petri very soon so you can see who I’m going to be chatting with and you can submit your questions through the forums. In the meantime, if you or someone you know might make a good guest for one of these MJFChats, please don’t hesitate to drop me a note. All my contact info is available on Petri.com thanks again.
You must be logged in to reply to this topic.