• Forum
  • Lounge
  • Linux vs Windows Round 0: Watch a Micros

 
Linux vs Windows Round 0: Watch a Microsoft Dev Build the Linux Kernel

closed account (z05DSL3A)
Linux vs Windows Round 0: Watch a Microsoft Dev Build the Linux Kernel
https://www.youtube.com/watch?v=a6uR-iGVh7k
Honestly I'm still confused about what problem WSL is supposed to solve. If it's a Linux kernel running inside a (basically) Hyper-V VM, then I assume that means the kernel and any processes under it don't have access to my files under Windows. In that case, what's the point? Why wouldn't I just run a Linux distribution normally in a VM?
If the Linux kernel does have access to the Windows file system, then how on earth is that working?
closed account (z05DSL3A)
then I assume that means the kernel and any processes under it don't have access to my files under Windows
/mnt/c is the C: drive. How its working? I don't know enough about hypervisors to say but it has (almost?) direct access to the hardware.

It is a damn sight faster (my experience) than running a VM on a Windows host. I'm just playing with it, I don't have a specific use case for it at the moment.
closed account (z05DSL3A)

WSL2, Visual Studio Code, Windows 10, Ubuntu/Linux + more - Computer Stuff They Didn't Teach You #19
"In this video we are blurring the lines between operating systems and showing you the future of software development using Visual Studio Code, WSL2, Ubuntu, the Windows Terminal, Oh My Posh, and the Remote Extensions for VS that enable a Windows Developer to be a Linux Developer! We also see .NET 5 as I debug my website running in Linux from Windows!"
https://www.youtube.com/watch?v=Owrk9UxnMdI
Last edited on
@helios

Well, one might observe there are fewer resources consumed and efficiency is a bit higher, but other than that, a VM is a VM.

An older, related service allows consumers to run XP while in Windows 10 when the compatibility mode just isn't quite enough, which is also a bit more efficient than running XP in a VM - though, I must admit, not enough to make much of a difference in modern hardware.

That said, mounting a drive is already a feature of shared drives in VMWare Workstation, though that is not as fast. The transport layers are more like mapped network drives than actual hard disk access.

@Grey Wolf

It isn't actually direct access to the hardware from Linux when mounted, but instead a close level access to the hypervisor's marshaling of disk access as a host. In other words, when compared to VMWare's shared folder option, there are more "direct" calls to OS functions opening files and transporting data, but only 1 thing is ever going to actually control the hardware itself (or there would be chaos) where disks are concerned, unless, as in the case of hardware drives in Workstation, the host explicitly surrenders control to one and only one guest.

All of this came come to a more pertinent question, why does one want to?

There are lots of reason, of course, and lots of "gotchas".

I find myself developing and debugging Linux application code from Visual Studio, preferring that to most of the IDE's I find in Linux.

In my cases, so far, I have no concern for where that Linux is - only as much as required to connect to it.
I find myself developing and debugging Linux application code from Visual Studio, preferring that to most of the IDE's I find in Linux.
How does it compare to debugging a Windows process in VS? I've yet to find a debugger that can match VS's.
@helios

First, let me say I agree entirely that I've never found a debugger to match VS. If I go way back, though, before Windows 95, there was the Borland IDE, in DOS, that was fairly good for it's time (...and of course, that's way over).

So far, debugging in VS for Linux is very much the same experience as debugging a Windows application, with the caveat that the build is different, and there is one minor catch.

There are times when I need to debug on Linux where I just can launch from the debugger. I do have a few text mode/console style applications (which control the display in the 80's style), supporting a legacy system ported from AIX to Linux. In that case, in order to "see" the console with cursor control (like a Wyse 50 terminal used to do), I must launch the application in Linux. For this situation I use the "attach to process" feature after launching the application on Linux, and all then proceeds like any VS debugging session.

I'm using the cmake build system for this, which is better than MSBuild on Linux. There is a pause on the build process while the IDE ensures all of the source has been uploaded to Linux, and that VS has all of the required headers for debugging/intellisense.

The project control is a tad brittle sometimes. Where in a typical VS project one merely starts adding new source files, a cmake project does fairly close to the same thing. However, if I remove or rename a source file, I may have to manually edit the cmake project file to account for that change.

So, it's not just the debugger, but the entire project development workflow of VS IDE that is supported on Linux, with just a few of the same caveats one might run into just using other compilers with VS (beyond the official support for clang in VS).

I'd also argue that debugging an app in a VM running on the same host is faster than debugging a Linux application on a computer attached over a network wire - network latency and throughput are noticeable, but barely, for the most part.

Cool, cool. I don't really target non-Windows very often, but it's good to know this option exists and works this well.
Topic archived. No new replies allowed.