 I'm here today to talk to you about Visual Studio and VS Code and how you can use those for embedded C and C++ development. My name's Mark Goodner. I'm a program manager on the C++ team that's part of the developer division. We are a part of the overall Visual Studio family. The mission of the C++ team in Dev Dev is we've got four things that we look after, one of which is we actually work within the C++ standards committee to help drive the language forward. We invest in the Microsoft Visual C++ compiler or MSVC, which is used to build Windows applications. We also improve the Visual Studio IDE, and we also work on the C++ extension for Visual Studio Code. So those are kind of the four areas we work on. I work on the Linux extension for Visual Studio and the Linux workload for Visual Studio, which also supports embedded development. So today we're gonna go over and we're gonna look at VS Code and embed. Then we're gonna look at Visual Studio with embed. I don't seem to be seeing the slides advance on the screen here. Sorry about that. Yeah, I'm not seeing the slides advance on the big screen. Here we go, did I got it? All right, there we go, we covered that and we covered the agenda. So there we go, so let's talk about C++ extension for VS Code. The C++ extension for VS Code, it enables basic C++ IntelliSense, code browsing, code formatting and debugging. It's had about 6 million downloads since it was first released in March of 2016. So it's pretty popular. And one of the things you can do with it is actually supports embed. So let's take a quick look at that. All right, let's get out of presentation mode and come back over here. So if you're familiar with embed, one of the things that you can do with embed. Embed has an online compiler where you can create programs. They've got sample applications for different boards and things like that. You can select the boards that you have. So in my embed environment, I have these boards selected. And the little board that I've got is this little nucleo F4111. And one of the things you can do, if the embed online compiler is great, you can use arms compilers, you can use their little editor up here. But if you wanna work offline, you can actually export your programs and work with them locally as well. They also have a command line tool that lets you, you don't even have to use this online interface. You can actually use a command line interface to generate programs or to select the board that you're using and all of those sort of things. But here, oops. If we look at this, my resolution is getting me. I'm not seeing the export on here. There's this export program. And on export program, you can come in here and you can select things like GCC. This will export a zip file with a make file that you could open in either VS Code or Visual Studio. But they also have options for VS Code specifically that target IAR or they're kind of blurred out. And then VS Code for GCC arm, etc. And there's even now a CMake option, which is pretty great, but that's very new, let's see. So I've already exported my program. And this is what you get when you export the program. So you've got your embed file with or your embed folder with all of your libraries hooked up. And you've got your main CPP with a blink. Let's make that go away. And the C++ extension has recognized that this is C++ code that we've opened in VS Code here. And it's asking me to go ahead and configure IntelliSense, but I'm actually not gonna go through that today. But basically, the extension for VS Code has a couple of different IntelliSense modes. One of which is a fuzzy IntelliSense. It's a tag parser that's very fast. There's also a full IntelliSense mode, which requires exact paths to the includes that you're using. And so this little green squiggle is indicating that I can do some additional configuration here if I want to get better IntelliSense. But you can see here that I'm already starting to pick up some IntelliSense from the tag parser that's showing me some information about the code that I've got. And you can see here that I've set a break point. These files, the launch JSON came with this, as did tasks. I moved those into the .vscode folder and the zip file, they come in the actual root. But you can move these into the VS Code folder and then VS Code will recognize them and use them for build and for launching your application. So this is the tasks file. And here, this came with the export. And right here it's on my command line on my Windows machine here. And so if I go back to my application and do control shift B, it's going to go ahead and run make. And so it's compiling now and it's done. It's built my file ready to flash onto the board. One of the things I love about the embed boards is you can just drag and drop the files onto the devices because they show up as mass storage devices. So you would just drag and drop the file here in order to flash the board. And the other thing, debugging is supported here. And so if I click Configure, this will bring me to the launch JSON that was here. This is largely what came with the export. I made some changes, though. By default, it comes configured to trigger based on the server output that GDB server has started. I had to change that because the SD nuclear boards aren't working with the GDB server OCD that comes with the embed client tools. So I reconfigured this to use open OCD instead. And so you can see it wasn't very many changes I had to make. Basically just point to where my instance is open OCD is, give it a config for that particular board. And then instead of using this, it points to the default installation for the GNU tools for ARM's GDB client. But here I'm pointing to Visual Studio's GDB client, which is actually the same one. Because I installed the ARM tools with Visual Studio. So that's the location I'm pointing to. But I don't even need to flash the board because I already have that code running here. And so let's go ahead and get that running. And we can see the board is blinking here. And if I click Debug, we should hit the breakpoint. So I had this configured to run make before debugging. Because if I forgot to save and build, we get an exception that we can ignore on the first hit. And there we go. We're paused at the breakpoint. And so now we can actually step through our code. And you can see now I'm stepping. And there the light is back on. And so that's pretty great. I can actually debug an embed board from VS Code with some of the files just exported from ARM's online compiler or using the command line tools if I'd prefer to use those. So let's pop back over to the slides. Now let's talk a little bit about Visual Studio. So the Linux, we have support within Visual Studio for a Linux workload. The Linux workload in Visual Studio was introduced in Visual Studio 2017. We had an extension for 2015 prior to that. But you scroll down in the Visual Studio installer, and it's one of the workloads down here at the bottom, that has talks on it. And you can, let me get my mouse over there. It doesn't look like it. But if you see that there's some optional components there as part of the workload, and one of the optional components is embedded in IoT development, that one is not selected by default. But if you select that option, what you're going to get as part of the workload is the ARM GNU GCC tools will be installed as part of your installation, as we'll make so that you can actually work with some of these projects. So basically we have in Visual Studio support for C++ with Linux. It works with any Linux distro or with the Windows subsystem for Linux. It runs a remote compile, so it needs SSH and GDB and GCC on the remote Linux machine. It connects with user, password, or private key. We've got IntelliSense out of the box that supports GCC for the standard Linux libraries. You can get full IntelliSense for your Linux box by cloning your headers down to your local box and pointing us at them. We're going to improve that in the next release of Visual Studio. We have some stuff coming that's going to help start synchronizing headers automatically so that you get IntelliSense per box that you actually connect this to. And then finally, you can debug your projects or attach to a remote process to debug with GDB or GDB server. We've got support for Python pretty printer types, and we also have support for CMake now, starting with, I think it was 15.4 of Visual Studio. So for a little while now. But this link you can learn more about all of the general overview of Visual Studio for Linux there. One of the things we've been improving with C++ in general for Visual Studio is we've been introducing this notion of open folder. We want Visual Studio to be useful to any C++ developer for any code base. And this goes for people who are doing Windows stuff or Linux stuff or anything. And so what we've done is we've made it possible to actually open a folder with C++ code in it without a Visual Studio project. And that means that you can start working with your C++ code, particularly in code bases where you're working with other colleagues who may not be using Visual Studio. So you no longer have to import files into a Visual Studio project in order to work with them. And then you wind up getting out of sync with your colleagues over time. If you're using CMake, we can provide a lot of IntelliSense out of the box through that experience if you open a folder with the CMake list.txt in it, then we'll generate IntelliSense based off of that project for the CMake. But if you have a make or some other build system, then you can, with some JSON files, do some light configuration very similar to VS Code and just point us at some information to start telling us how to configure IntelliSense for your headers. And you can actually then wire things up for debugging into your external, into your build system. So normally I go through all of the different sort of things that we're building these sort of capabilities for around Linux. But here it's really about the internet of things and embedded devices. And so for Linux, it's easy to imagine that obviously we can treat a Raspberry Pi or a BeagleBone or some Yachto Box as any other remote Linux system. And particularly with pies and BeagleBones, you can actually compile on the device. But we also have support for RMGCC through the workload where you can select the option for embedded development as part of the installation. And I should say that the slides are posted. So all of the links and everything, you can go grab these from the website. And I'm showing the same ones I posted. So the RMGCC support adds the ability to do local cross-compile with the RMGCC compiler. And because the embed projects are folder-based, then we can open those folders within Visual Studio and then start configuring the launch templates to debug the devices. And this link will tell you more about that and walk you through an example with all of that. And so with that, let's take a look at the same thing that we just did in VS Code but in Visual Studio. So let's get rid of VS Code here. If I bring out, come over here. So now instead of opening a project, I can open a folder. And this was the same folder of that other project. So if I open that up, you can see that Visual Studio has actually recognized that my make file, it's already configured it to have a build and clean task on it. So if I run clean, you'll see that the build folder disappeared there. And then now if I run build, my build folder is back. And so I'm actually running make from within Visual Studio with the RMGCC tool chain. And so if we take a look at that make file, we actually have support for text make bundles in Visual Studio that gives some syntax highlighting for a whole bunch of different file types, including make files. And one thing I want to show you when you're working with these embed projects in particular is, we scroll down here, I was trying to find the, I went just too far. What I'm looking for is the GCC command. That's not going to be helpful. Basically, there we go. So in the make file, I had to add this dash G to both the CC and CPP commands. Because the make files that come out of the ARM online compiler, of course, are optimized, so they're not going to create debug symbols by default. So if you actually want to debug, you're going to need to add the debug information. So that's what I have there. You can see here the same sort of experience where I can navigate to files. I can do things like peak definition. And so I get all of the goodness of Visual Studio that you'd expect to see here. Now, I already ran to build. One of the other things I want to show you in Visual Studio is that here I have this command called flash off of this binary. You'll notice it's not off of anything else here. Where that came from is you can configure tasks in open folder projects in Visual Studio to do any arbitrary thing that you want. Those are hidden in a .vs folder. And so this icon here will show you all your files. This is a folder view, but it's actually hiding hidden files. So if I show all files, then I'll get the .vs folder. And in there is a file called tasksvs.json, which is very similar to what you have in VS Code. But here I've actually specified this command you see here called flash that is applicable to that binary. And this command is actually just giving me a command prompt. And then it's just going to copy the file to the board. So that's just going to flash the board. So if I were to come over here and let's see. So right now the board is blinking at that rate. And if I were to change this to a faster blink rate and rebuild my app, so now we've got that built. And now I can flash the board. And you can see that it is blinking faster now, because it actually put the binary there on the board just through the copy mechanism. Again, one of the things I just love about these little ST nuclear boards, you just push the binary over there and they reset themselves and start running. But let's take a look at debug. So in Visual Studio to debug in an open folder project, we have debug and launch settings. And so this is a template system. There's a whole bunch of different options here where you can do attach for process, for a remote Linux system, attach for a MinGW or SIGWIN project. We've got this template for microcontrollers, which is what I've got. And I've already configured that. So let's open that file up in the launch.vs.json. And so you'll see here, this is very similar to what we saw in the VS Code example. And so you can see even that my debug server to open OCD and my config file and everything is the same as well as my server-started message. So let's go ahead and do that. Oh, it's decided not to like me. My startup item's not here. Hold on a second and try and redo that. There we go. All right, let's try that now. Makes the screen very crowded at this resolution. Did we miss the breakpoint? The target's already running. Hold on. Sometimes you have to kick these things a couple of times. It's still already running. All right, there we go. We caught the breakpoint that time. So if we bring this back up, and then if I, so you can see I'm just hitting F5. So it's looping back through. And you can see the LED blink as I do that. Now, one of the things you get in Visual Studio, this program doesn't have very much in the way of autos or anything. There's not much going on in terms of variables to look at. But one thing you get in Visual Studio that you do not get in VS Code, for example, is disassembly. So you can see here that I've actually got the disassembly for what's running on the board. And I can actually even step over, step through my assembly. And you'll notice over here in Main, my cursor hasn't moved in Main because I'm only stepping through the actual instruction lines here. So that's what we got here. So we've got Visual Studio building with RMGCC, cross-compiling locally, and flashing a STNucleo board. And we've got it debugging. So let's go on. So now what about Yachto? So this is a little complicated today. Today, we don't have a way in Visual Studio to build on one machine and deploy on another. So effectively, what I've done, or what I'm going to show you, is a solution where I've got two Linux projects where one is an application and one is a make file. The application one, I'm going to override the X64 project defaults to use a Yachto cross-compiler and assist root on a build machine. I've done this in Windows subsystem for Linux before, or it could be another remote Linux machine, but Windows subsystem will work. And then I've got a post-build event that's going to take and copy the output of that X64 project to the ARM configuration of that same build project. And then the make file project is going to grab that output and copy it to a remote ARM device. It's kind of convoluted, but what it does is it lets me work in one project with my source, compile it on an X64 machine, and then the other project picks up the output and pushes it to the remote ARM machine. And then, now the right way to do this I think would be to use CMake and a proper tool chain file for cross-compile and then use tasks to copy it to the ARM output device. But I don't quite have all that set up yet. But let's go ahead and take a look at this. Now, this project is actually posted on GitHub. There's actually quite a bit of documentation on this one on that site on my personal GitHub, which is linked here. The project that's there does not show a Yachto SDK. It shows a Lenaro SDK, just because Lenaro seemed a little more accessible because you could target any random Raspberry Pi with that. So that's what that one shows you, but I'm going to show you one right now that uses the Yachto SDK from Toradex. So let's go here. Let's open the solution. Oops, go to my desktop. This is the one I want. So here in my solution I've got my two projects. You see here I'm configured for x64. What I want to show you is on the project properties. This was configured for a different machine. The reason this looks this way is because that machine was defined on a different machine than the one I'm running this on right now. But at any rate, what I really want to show you is here under All Options, you can see all of these additional options that I'm passing to the compiler, including this sysroot. So this sysroot is a sysroot that came from the Yachto SDK. So you can see what it's actually using there for that. And then you can see that even for the C++ compiler that I've overridden that to not use the default C++ compiler, but I'm using the one that came from the Yachto SDK. And then I mentioned about the build events on the post-build event. What I'm doing is I'm copying the output. When we build in Visual Studio with the project system, we actually copy the output of the remote build process back to the local Windows machine so that you can stash it away or do other things you may need to do with it, and so that you can actually get the symbols back for debugging in particular. And so in this project, what I'm doing is I'm copying that binary from the x64 project because I know it's actually an ARM project, and I'm copying it to the ARM configuration of the project. Because when I debug, I'm actually going to build with this configuration, but I would debug with this configuration. And if I come back here, that comes in here where you can see here on my ARM configuration I have a different machine, because that would be this Toradex board, this little IMX6 board, is to where the app would run, but I don't want to build it here. I actually built it in the Windows subsystem for Linux locally, and I'm going to debug it on this board. Now, my other project is this one. And what this one does is it copies the outputs from that other project to the board. So this is just a dumb project that's copying files over there. And lastly, what I want to show you about this project is that it's wired up so that things go as smoothly as they can. So in project dependencies, the cross-compile project itself doesn't have anything. But the copy files project actually depends on the cross-compile project. And then on the configuration, if I look at the X64 one, you'll notice that I have the copy files when set to depend on the X64 one, but for the ARM variant, because I know that I need to copy to an ARM device with that one. So I've helped myself as much as I can by configuring things so that when I edit my files in the X64 and I build, and then I copy the files to the remote ARM device, and then all I have to do back here is switch to ARM, and then I can debug my code. But I don't have this all set up to actually show you that right now, but that's the idea for that. So let's go back over here. Because what I want to talk to you about next, actually, before I do that, I did want to point out one other thing here, because this is going to be what we're going in to talk about next. Note this platform tool set. So right now, there's only one platform tool set here. There's actually a lot of capability behind these platform tool sets that you can use for extensibility. So if you're somebody who creates your own Yachto SDKs or you have your own compilers, there's a way that you can leverage this in our support for GCC so that you can plug your own GCC compilers in here. And that's what we're going to talk about now. Was that actually on the screen when I was saying that? Great. PowerPoint's lovely the way it takes things over. So if we go back here, this is what I was talking about, this platform tool set right here. So the Linux workload only comes with one platform tool set for remote GCC, but you can actually create your own platform tool sets for other compilers and then package them up into Visual Studio Extensions. And that's what I'm going to talk to you about now. All right. So Visual Studio's C++ project system has a bunch of different extensibility points. One of them is application types. These provide a way for the Visual C++ project system and build system to define things for the MS build system. Basically there's property files that define static values. These are basically named value pairs. And then there's these target files that embed MS build targets and tasks as part of them. Within those there's tool sets within an application type. These allow a lot of reuse of the application type with minimal rework. So it's quite a bit of work to set up an application type itself. The application type that we provide as part of the Linux workload is Linux. But you can go in there and take the tool sets we created to copy them and then create your own tool sets that leverage all of that infrastructure that we already have in place there. And then finally there's property pages. And the property pages are little XML files that define what you saw on those property pages for the project with all of the flags to pass to GCC. So the best advice on how to do this is to start from an existing application type. So you would start from our Linux application type and go down into the Visual Studio install directory and look under the common seven this path here all the way down to VC targets application type Linux. And then within there you'll find the Linux remote GCC tool set. What my advice would be would be that you copy what you find there and create your own tool set in place and make the tweaks that you want to make and then you can restart Visual Studio to use it. And then once you're happy with what you've got or you want to start making additional changes or you need to start adding more tools and you want to ship it to people, then you're going to want to package it up as an extension. So Visual Studio and VS Code both support extensions. These are add-ons that help you customize the experience. They let you add things like menus and toolbars. You can extend existing tool windows. You can customize IntelliSense. You can create new project templates. So there's a whole lot of things you can do here. And there's also the Visual Studio Marketplace where you can provide these things for people to find them from within context of Visual Studio or if it's a VS Code extension from within the context of VS Code. So let's take a look at how this works. This code is also available. I hope you guys like hot bits. These are really hot. We've been working on this over the past couple of weeks to get this together. So I posted this last night, basically. This is a very early preview of what this looks like. This needs a lot more documentation. But we will document this. And I'll have a blog post about it. But it's probably going to be three weeks to a month before I can get that properly written up. So this is a nice preview for you. But the code is available here. So let's go take a look at that. Am I doing on time? So let's go ahead and open. So this is a Visual Studio extension project. I'm going to open here. And while that's opening, I want to show you that path that I was talking about. So this is my Visual Studio installation here. I oddly only have one instance of Visual Studio installed right now. With the new Visual Studio installer, you can have multiple instances of Visual Studio installed at the same time, by the way. You can have Visual Studio preview and RTM installed at the same time. And they don't interfere with each other. In fact, I install Visual Studio from different in-flight branches at work. I have a desktop machine that has six different instances of Visual Studio installed at the same time. So it's very safe to install multiple instances of Visual Studio now. So navigating down into the VC folder and this VC targets. I just want you to get a sense of what this looks like. So here's the application type that I was talking about. I've only got one on here for Linux. And you can see that what I've got here are the props and targets files I was talking about. This is what comes with the system. This 1033 is a language code for English. So these are my localized English files for the property pages. So you can see that there's some stuff to get started from here. If we look into the platforms, then you can see that there's that remote GCC tool set that I was talking about. So this would be the place to start. What would be you could copy this and then start iterating on that here. But I already have that in this folder. So let's take a quick look at that. So you can see I have the same structure here. So this is just a project as part of my Visual Studio extension solution. And you can see here that I've got that same folder structure here. And I've created a new tool set called cross-compile tool set. And in the work that we've been doing, one of the reasons we had to do this, you'll need to start probably from this tool set. Because we've started work on trying to enable cross-compiling scenarios. But we didn't actually provide a tool set to demonstrate using some of the cross-compile support that we were working on. So it was in an interim state. So the best tool set to copy is that one that I posted on GitHub, which is this project here. Because this has a minimal set of properties and targets. So you can see here that the properties, the sort of things that are in the properties are things like what sort of platform architecture it is, the thumb mode. You can see there's a platform triplet. And then there's things where the C++ compile tool, the platform triplet dash GCC. You can see other things further down here, where I've got additional options specifying that I need to pass to the compiler. And then within the tool set target rules, actually this one consumes additional targets. What I want to show is this one. If I scroll down here to the bottom, what you'll see here is some of the property pages that I was talking about. So this one actually references different property pages than what's part of the default. So here I've got additional property pages that were basically cloned from some of those other ones where I was able to, where I want to be able to provide different options or maybe just some additional options. And I can do that as part of a platform tool set. So once I'm happy with all of this, and I've got everything nice and lined up the way that I want, this is my actual Visual Studio extension project. And so with here, what I've got is you can provide some metadata about your extension. You can point to the license that it has, give it a nice icon. I don't have time for any of that, so I didn't. You can also set install targets. Visual Studio Community is the base Visual Studio instance. Visual Studio Community is available basically to everybody for non-commercial use or for anybody doing open source work. It's basically a license restricted version of Visual Studio Pro is the right way to think about it. Basically, if you're at a company and you're above a certain income or a number of employees, you need to pay for a pro license. But as individuals or certain other stipulations, you can use Visual Studio Community. So that's the lowest level one. But you could come in here. And for some reason, if you knew that you were depending on something in enterprise, for example, you could say, no, I only want people who are using enterprise to be able to install this extension. And then prerequisites, I actually, because my toolset depends on the Linux workload, I can actually say that I have a prerequisite that I need the Linux workload to be part of my, you need to have the Linux workload before the Visix will install. So let's go ahead and build this. Or actually, I've already built it. Let's open that up. I think we're running short of time, so let's just go ahead and run what I've already built. So there's my Visix. I'm going to close this, install that. One thing to note here, normally with Visual Studio extension development, you can launch the extension in an experimental instance of Visual Studio and debug your extension that way. With the C++ targets in platform tool sets that we're adding, those don't work in the experimental instance. And I need to go talk to the extension team to understand why we have that limitation. But just so you understand, that experimental instance doesn't work with what I'm showing right now. All right, so there we go. Let's pop open Visual Studio again. And now what I'm going to do is I'm going to create a normal Linux project. And I'm going to use my new toolset that's going to run the local Linaro compilers instead of the remote compilers. So I'll just go ahead and create a console application. I'm not into triple digits yet, so I don't need to clean that folder. So I'm going to change my configuration to ARM. I only provided this toolset for ARM in what I set up there. If I go down to my properties, instead of remote GCC, I'm going to say cross compile. And you can see already some of my options have changed in terms of the output that I've got here. And you can see there's some of the things that I was specifying in the output before. And you can also see that I've got a bunch of intelligence paths here that are pointing to a different directory for the Linaro compilers. And so now if I build, oops, so you can actually see in the output there that I'm actually running the local Linaro compilers instead of the remote compilers. So that's what we've got there. I'm not going to switch back to the slides to show another way to do this. I'm going to talk to it in just a second. But in the interest of time, let's go ahead and do this now. This is also in that same repository that I pointed you at. This is that repo. I don't even have any outstanding checkouts on it. So if I open this folder, what this folder is showing is a CMake variant of basically the same thing. So I've got a CMakeList.txt here, which is pretty basic and simple. But what's really interesting, though, is I have this CMakeToolchain file. And in the CMakeToolchain file, I'm pointing again at those local Linaro compilers. And then I configured my CMake settings to point to, I specified some includes to point to the headers for the Linaro installation. And then I'm not seeing it here. There it is. So then on my CMake command args, this CMake Settings file lets you basically pass additional information to CMake and set up additional config. And so I'm telling CMake to use this Toolchain file. And so when I go and I build with CMake, ah, it's too smart for me. Let's clean it or just rebuild all. So there you can see, again, it picked up the Linaro compilers instead of anything else. So you can see that if you're supporting a lot of different compilers, or if you want to generate things programmatically, the CMake Toolchain files are probably the way to go. And then that's also going to help you support things, you know, additional IDEs as well. So what Visual Studio, you can work with Visual Studio however you want. You can either buy into the project system that we have for the ease of use. It just kind of depends on where you want to go. But the open folder scenario is great for, you know, particularly existing code bases. All right, so we talked a little bit about that. Right, and so the other thing about the, and this is not in the, in that example that I was pointing you to with the extension, but that Toolchain file is up there in that GitHub repo and that little project as well. So you can see either style of solution. But if you wanted to package up your compilers and Toolchains and get them into Visual Studio, you could. But we have a way in Visual Studio now that you can even create an open folder solution because if you want to have like a template to help people get started where you go file a new project and you see your stuff there, you can actually generate something for an open folder. We have one example of that now to create a CMake project from scratch. But that's code, so you instead of having like a template file, there would actually be code that generates the folders and files that you need. So we haven't published anything on that yet, but we'll get something published on that as an example on how to go about things from that way as well. But one of the things that would be interesting, particularly would be to package things like that tasks vs.json folder if you have additional tools that are required for your embedded device, where you may want to ship some SDKs or CLIs that are part of your tool and you may want to automate or provide the capability to trigger those things from Visual Studio you can. So we looked at that. So here's some references for Visual Studio extensions. And again, the slides are online, so you've got all of those links and there's some, I didn't cover anything about VS Code extensions, but I provided that as a resource as well so you can see more about how to create Visual Studio Code extensions. And kind of the last thing before wrapping up, just some tips with the Linux workload in general. Verbose build output is really helpful for troubleshooting. So in the quick launch window up in the upper right, you can type the word verbosity and that will get you to the tools options where the build output options are and you can turn that up to normal or detailed and you'll then see the exact GCC commands that are being emitted and that's very helpful. I mentioned that today you have to copy the include files from your remote Linux machine to your local Windows machine to get IntelliSense for that machine. We're going to be making that better in 15.7, I think, in preview two. We've got some features coming to automatically do that for you. Unexpected debugging results, we will ask you for a log. And so these are the instructions on how to get that log that we were going to ask you for. And if you're using the Windows subsystem for Linux and you start SSH, check if port 22 is really available or not. There's now a Windows SSH service. And it also takes port 22. So finally, here's a list of resources. And so we take feedback for features and stuff through places like user voice. Our blog is a good place to keep up with us. There's my Twitter handle, the Twitter handle for our team. Many of the links that I mentioned there. We have a GitHub where we take public issues and discussion. If you want to discuss something with us that you don't think is that isn't public, there's the support email alias. The support email alias is, it's just myself and the developers. And so with that, I'll open the floor up for any questions. No questions? Yes? Sure. So the question is, can I talk a little bit more about what the integration with the Windows subsystem is like? Today, there's not really any integration with it. When the Windows subsystem for Linux started, there was a conscious decision we made with that team to not treat them special at all. Especially in the early days of the Windows subsystem for Linux, they wanted the point to get across that they were just like any other Linux system. So we went with just using an SSH, even though it was local on the same Windows box, you still have to set up SSH there, and we're treating it just like any other remote Linux box. There's some tricks you can do taking advantage of the fact that you know you're on the same box, because you can reference anything from the Windows side of the house in the Windows subsystem for Linux. Let me bring up a window here, and maybe that'll make it easier to discuss. We've got a lot more distros available now, but I still have Debian. So if you want to see the Windows side of the world, you can go to Mount C. And you can see there's my Windows file system. And so there in that source folder, that's all of the stuff that I've been working with here today. So if you use paths like that, like Mount C to the Windows side of the world, you can do things where even though we're talking to it over SSH, you can do things like say copy files, no, and then open the same source files locally on the Windows side that are mapped appropriately on the Linux side. But that requires a little bit of thinking and prep to set up. But we are looking at whether or not we, and we've done some experiments with, how can I say, driving compilation with WSL. So you can actually run WSL commands directly with bash.exe-c and then just run a bash command. And so we're talking about whether or not we maybe want to create a tool set just for WSL where you could swap to WSL and then you don't have to set up the SSH connection or anything. And then you could just drive it that way. But we haven't shipped anything for that yet. But that's kind of the direction our thinking is going right now, because now that WSL is fully grown up and there's less a concern about treating it special. We're thinking about how we could treat it special by knowing it's WSL. But most likely that would be just running the bash commands directly from the compiler. Yes. Yes. The question is, is there a way to start a GUI application from this? I'm not going to have time to actually run one. But let me just show you. To run a GUI application, let me change this back to remote. So what you would do is a pre-launch command. You would do export, something like that. You would export the display. So if you go to the link I had for the overall Linux workload, aka MS slash VS Linux, there's an example there that shows how to set up the spinning cube OpenGL sample. So yes, you can do GUI applications with it. I think it might be, yes, create an RTAW system. I'm not hearing the last part of the question. Oh, to create a Linux file system? So what kind of license is this? So for what we have in Visual Studio, it's just licensed as part of Visual Studio. So we have not open sourced the Linux workload for Visual Studio. I honestly say that that's probably, we had a decision to make when we were first working on this. Did we prep the source for open source, or did we try and hit a deadline for our first release? We chose to hit a deadline for our first release, and we've never gotten back to actually prepping the source to open source it. I'm hearing the request, we would like to. We just need to get it far enough off our backlog to actually, it's not for free anymore now that we're integrated into our internal build systems and stuff. Obviously, we're consuming a lot of open source as part of this, and all of that should be covered in our third party notices that are part of Visual Studio. I'm going to have to take the second part of your question after the talk, though, because my ears are a little sick, so I think I couldn't quite understand the second part of the question. Okay, so the question's about file systems, but I think I'm going to have to come talk to you now, because I just realized the clock is counting up, so I'm already over time. So let me get out of here, and I'll come talk to you after. All right, well, thank you, everybody.