A quick (or rather, a really deep) tour of internals of Windows Subsystem for Linux #backstagetour #wintendev


 

Hi all,

 

For new family members: as some of you found out, this forum uses hashtags extensively. And as many of you found out (some of you the hard way), this forum can get a bit geeky at times – not only we discuss Windows 10 accessibility, sometimes we talk about feature internals and some more technical material. As head list representative (about to retire from that position), I allow these discussions because it is important for you all to come along the ride and let you glimpse what’s going on so you won’t be left behind. And before I continue, let me (re)state that I do not work for Microsoft (at one point I wanted to work for MS from home, but nope), nor do I represent views of screen reader vendors (even though I can describe internals of one particular screen reader, I do not work for the vendor – I’m a volunteer).

 

IMPORTANT: what I write below is a bit more geeky than previous posts with #BackstageTour hashtag as we’ll get into system internals we usually don’t talk about, and also because one or two sections discuss Version 2004 (prerelease) material, hence #WinTenDev hashtag.

 

A few months ago someone wrote about how to use Windows Subsystem for Linux (WSL). I thought I posted a backstage tour about WSL but apparently I can’t find it anymore; so Windows Subsystem for Linux, how it works, and some background info is what we’ll talk about.

 

Windows Subsystem for Linux allows you to run Linux command line tools (someone did attempt to run GUI on top with mixed success). The aim of this feature (or rather, a subsystem) is to allow software developers to use familiar Linux utilities such as Bash (Bourn Again SHell), SSH (Secure Shell), Python, and among others, mostly for programming.

 

But WSL didn’t start out that way: the original intent of a Linux subsystem, which was in development for a number of years, was to run Android apps. Back in 2015, Microsoft announced Project Astoria, a package allowing Android apps to be ported to and run on desktops, laptops, and so on, meant to attract mobile app developers to Windows 10 ecosystem (specifically, Universal Windows platform). All of this changed when it became clear that folks were moving toward web development, and iOS apps were more popular than Android apps (at one point, Microsoft did advertise Islandwood or Bridge for iOS, a tool to port iOS apps to Windows 10). But not all was lost: the Linux subsystem work that was developed until then became basis for WSL in 2016.

 

Bringing Windows Subsystem for Linux to life was both easy and hard. Easy because Windows provided support for operating system personalities, or a way to run or emulate programming interfaces for other operating systems. Hard because Windows and Linux are two completely different operating systems, and while some features were common to both, some Windows API features didn’t exist in Linux and vice versa.

 

Speaking of operating system personalities, Windows defines what is termed an “environment subsystem”. An environment subsystem is a collection of libraries and helpers that allows programs written in one operating system (or an OS API) to work under Windows. Each environment subsystem is composed of:

 

  • Subsystem libraries providing API routines for an operating system.
  • Subsystem process for managing communication between the program and Windows (actually, between programs and Windows kernel).

 

Back in 1990’s, Windows provided support for three environment subsystems: Windows, IBM OS/2, and POSIX (portable operating system interface). By default, Windows subsystem is in use (composed of libraries such as user32.dll and kernel32.dll for Windows API functionality, and CSRSS (Client/Server Runtime Subsystem) and win32k.sys (graphics) for user interface and system communication), as it is after all the reason why the operating system is called Windows. OS/2 support was removed in Windows XP, and POSIX subsystem went through numerous revisions, including Subsystem for Unix-based Applications, and since 2016, Windows Subsystem for Linux – yes, WSL’s “real” root is POSIX subsystem.

 

In terms of composition of Windows Subsystem for Linux, it is slightly different than other environment subsystems. Not only Windows must deal with Linux API, it must deal with expectations of Linux programs (such as fork system call). Because of all this, Microsoft had to add new features for managing programs (or processes).

 

Typically, a process is defined as a “container” that includes machine code, data needed by a program, and additional metadata that operating systems use (the best known metadata is process ID (PID), a number that represents the process in question). When a program starts in Windows, Windows will load a library named “ntdll.dll” which is used to help Windows programs communicate with the operating system. But a Linux program/process cannot use ntdll.dll, and since Linux works differently under the hood, Microsoft had to define what is called a “minimal process” and a “picoprocess”.

 

A minimal process is an empty process – rather, a process container with Windows specific metadata missing. There is no machine code, no data for use by the program, not even a PID. This is essential because Windows then can add actual information needed by an environment subsystem, or do something completely different with the process at the system level. In contrast, a picoprocess is a process that Windows alone cannot deal with – it includes metadata and other helpers that may represent another operating system. This “operating system representation” is supplied by a pico driver, which fulfills the role of ntdll.dll for other subsystem processes.

 

In short, Windows Subsystem for Linux (at least version 1; I’ll explain version 2 in a moment) is really a collection of libraries and helpers that helps Linux programs run on Windows. This is done through a pico driver named “lxss.sys” (LinuX subsystem). The job of this pico driver is to translate Linux API functions and certain features to Windows equivalent and back.

 

At the high level, Windows Subsystem for Linux (version 1) works as follows:

 

  1. WSL is installed. This in turn installs lxss.sys pico driver and support routines.
  2. Users install one or more Linux distributions optimized for WSL (from Microsoft Store).
  3. Users run Linux programs by running it from the chosen distribution (Ubuntu, for example).
  4. Windows notices that a Linux program has started, so it loads lxss.sys to handle system call emulation. Along the way, a WSL picoprocess for the Linux program is created with metadata supplied by lxss.sys.
  5. A Linux program makes a system call (an operating system routine for use by programs). This is intercepted by lxss.sys and WSL either tells Windows to perform an equivalent task or the library itself will handle it.
  6. Linux programs are closed, and so is lxss.sys.

 

Although it does allow many Linux programs to run, the first version of WSL has one crucial issue: it does not support all Linux API, and if it did, it didn’t support recent updates. To resolve this limitation and to bring other improvements, WSL 2 was born in 2019.

 

Unlike WSL 1 (system call emulation), WSL 2 is a custom Linux kernel running inside an optimized Hyper-V virtual machine. This guarantees better Linux API support and improves speed. In short, when Linux programs are started in WSL 2, the customized Linux kernel will be started inside the virtual machine, take care of calls coming from the Linux program, and terminate when no Linux programs are running. Because it is a virtual machine implementation, third-party virtualization products will not work if WSL 2 is enabled.

 

References:

 

  • Wikipedia entry on Windows Subsystem for Linux
  • Various Microsoft blogs (including some tech press blogs) on WSL internals

 

Hope this helps.

Cheers,

Joseph


 

Hi,

Important note: WSL 2 is part of Windows 10 Version 2004, and you can switch a distribution between WSL 1 and WSL 2.

Cheers,

Joseph

 

From: win10@win10.groups.io <win10@win10.groups.io> On Behalf Of Joseph Lee via Groups.Io
Sent: Wednesday, December 18, 2019 12:38 AM
To: win10@win10.groups.io
Subject: [win10] A quick (or rather, a really deep) tour of internals of Windows Subsystem for Linux #BackstageTour #WinTenDev

 

Hi all,

 

For new family members: as some of you found out, this forum uses hashtags extensively. And as many of you found out (some of you the hard way), this forum can get a bit geeky at times – not only we discuss Windows 10 accessibility, sometimes we talk about feature internals and some more technical material. As head list representative (about to retire from that position), I allow these discussions because it is important for you all to come along the ride and let you glimpse what’s going on so you won’t be left behind. And before I continue, let me (re)state that I do not work for Microsoft (at one point I wanted to work for MS from home, but nope), nor do I represent views of screen reader vendors (even though I can describe internals of one particular screen reader, I do not work for the vendor – I’m a volunteer).

 

IMPORTANT: what I write below is a bit more geeky than previous posts with #BackstageTour hashtag as we’ll get into system internals we usually don’t talk about, and also because one or two sections discuss Version 2004 (prerelease) material, hence #WinTenDev hashtag.

 

A few months ago someone wrote about how to use Windows Subsystem for Linux (WSL). I thought I posted a backstage tour about WSL but apparently I can’t find it anymore; so Windows Subsystem for Linux, how it works, and some background info is what we’ll talk about.

 

Windows Subsystem for Linux allows you to run Linux command line tools (someone did attempt to run GUI on top with mixed success). The aim of this feature (or rather, a subsystem) is to allow software developers to use familiar Linux utilities such as Bash (Bourn Again SHell), SSH (Secure Shell), Python, and among others, mostly for programming.

 

But WSL didn’t start out that way: the original intent of a Linux subsystem, which was in development for a number of years, was to run Android apps. Back in 2015, Microsoft announced Project Astoria, a package allowing Android apps to be ported to and run on desktops, laptops, and so on, meant to attract mobile app developers to Windows 10 ecosystem (specifically, Universal Windows platform). All of this changed when it became clear that folks were moving toward web development, and iOS apps were more popular than Android apps (at one point, Microsoft did advertise Islandwood or Bridge for iOS, a tool to port iOS apps to Windows 10). But not all was lost: the Linux subsystem work that was developed until then became basis for WSL in 2016.

 

Bringing Windows Subsystem for Linux to life was both easy and hard. Easy because Windows provided support for operating system personalities, or a way to run or emulate programming interfaces for other operating systems. Hard because Windows and Linux are two completely different operating systems, and while some features were common to both, some Windows API features didn’t exist in Linux and vice versa.

 

Speaking of operating system personalities, Windows defines what is termed an “environment subsystem”. An environment subsystem is a collection of libraries and helpers that allows programs written in one operating system (or an OS API) to work under Windows. Each environment subsystem is composed of:

 

  • Subsystem libraries providing API routines for an operating system.
  • Subsystem process for managing communication between the program and Windows (actually, between programs and Windows kernel).

 

Back in 1990’s, Windows provided support for three environment subsystems: Windows, IBM OS/2, and POSIX (portable operating system interface). By default, Windows subsystem is in use (composed of libraries such as user32.dll and kernel32.dll for Windows API functionality, and CSRSS (Client/Server Runtime Subsystem) and win32k.sys (graphics) for user interface and system communication), as it is after all the reason why the operating system is called Windows. OS/2 support was removed in Windows XP, and POSIX subsystem went through numerous revisions, including Subsystem for Unix-based Applications, and since 2016, Windows Subsystem for Linux – yes, WSL’s “real” root is POSIX subsystem.

 

In terms of composition of Windows Subsystem for Linux, it is slightly different than other environment subsystems. Not only Windows must deal with Linux API, it must deal with expectations of Linux programs (such as fork system call). Because of all this, Microsoft had to add new features for managing programs (or processes).

 

Typically, a process is defined as a “container” that includes machine code, data needed by a program, and additional metadata that operating systems use (the best known metadata is process ID (PID), a number that represents the process in question). When a program starts in Windows, Windows will load a library named “ntdll.dll” which is used to help Windows programs communicate with the operating system. But a Linux program/process cannot use ntdll.dll, and since Linux works differently under the hood, Microsoft had to define what is called a “minimal process” and a “picoprocess”.

 

A minimal process is an empty process – rather, a process container with Windows specific metadata missing. There is no machine code, no data for use by the program, not even a PID. This is essential because Windows then can add actual information needed by an environment subsystem, or do something completely different with the process at the system level. In contrast, a picoprocess is a process that Windows alone cannot deal with – it includes metadata and other helpers that may represent another operating system. This “operating system representation” is supplied by a pico driver, which fulfills the role of ntdll.dll for other subsystem processes.

 

In short, Windows Subsystem for Linux (at least version 1; I’ll explain version 2 in a moment) is really a collection of libraries and helpers that helps Linux programs run on Windows. This is done through a pico driver named “lxss.sys” (LinuX subsystem). The job of this pico driver is to translate Linux API functions and certain features to Windows equivalent and back.

 

At the high level, Windows Subsystem for Linux (version 1) works as follows:

 

  1. WSL is installed. This in turn installs lxss.sys pico driver and support routines.
  2. Users install one or more Linux distributions optimized for WSL (from Microsoft Store).
  3. Users run Linux programs by running it from the chosen distribution (Ubuntu, for example).
  4. Windows notices that a Linux program has started, so it loads lxss.sys to handle system call emulation. Along the way, a WSL picoprocess for the Linux program is created with metadata supplied by lxss.sys.
  5. A Linux program makes a system call (an operating system routine for use by programs). This is intercepted by lxss.sys and WSL either tells Windows to perform an equivalent task or the library itself will handle it.
  6. Linux programs are closed, and so is lxss.sys.

 

Although it does allow many Linux programs to run, the first version of WSL has one crucial issue: it does not support all Linux API, and if it did, it didn’t support recent updates. To resolve this limitation and to bring other improvements, WSL 2 was born in 2019.

 

Unlike WSL 1 (system call emulation), WSL 2 is a custom Linux kernel running inside an optimized Hyper-V virtual machine. This guarantees better Linux API support and improves speed. In short, when Linux programs are started in WSL 2, the customized Linux kernel will be started inside the virtual machine, take care of calls coming from the Linux program, and terminate when no Linux programs are running. Because it is a virtual machine implementation, third-party virtualization products will not work if WSL 2 is enabled.

 

References:

 

  • Wikipedia entry on Windows Subsystem for Linux
  • Various Microsoft blogs (including some tech press blogs) on WSL internals

 

Hope this helps.

Cheers,

Joseph


Devin Prater
 

How does this work with accessibility focuses? Does WSL support mapping sound to Windows’ sound protocols? Could this, for example, be used to install Toxin, and use Emacs with Emacspeak with the Outloud speech server?

On Dec 18, 2019, at 2:37 AM, Joseph Lee <joseph.lee22590@...> wrote:

Hi all,
 
For new family members: as some of you found out, this forum uses hashtags extensively. And as many of you found out (some of you the hard way), this forum can get a bit geeky at times – not only we discuss Windows 10 accessibility, sometimes we talk about feature internals and some more technical material. As head list representative (about to retire from that position), I allow these discussions because it is important for you all to come along the ride and let you glimpse what’s going on so you won’t be left behind. And before I continue, let me (re)state that I do not work for Microsoft (at one point I wanted to work for MS from home, but nope), nor do I represent views of screen reader vendors (even though I can describe internals of one particular screen reader, I do not work for the vendor – I’m a volunteer).
 
IMPORTANT: what I write below is a bit more geeky than previous posts with #BackstageTour hashtag as we’ll get into system internals we usually don’t talk about, and also because one or two sections discuss Version 2004 (prerelease) material, hence #WinTenDev hashtag.
 
A few months ago someone wrote about how to use Windows Subsystem for Linux (WSL). I thought I posted a backstage tour about WSL but apparently I can’t find it anymore; so Windows Subsystem for Linux, how it works, and some background info is what we’ll talk about.
 
Windows Subsystem for Linux allows you to run Linux command line tools (someone did attempt to run GUI on top with mixed success). The aim of this feature (or rather, a subsystem) is to allow software developers to use familiar Linux utilities such as Bash (Bourn Again SHell), SSH (Secure Shell), Python, and among others, mostly for programming.
 
But WSL didn’t start out that way: the original intent of a Linux subsystem, which was in development for a number of years, was to run Android apps. Back in 2015, Microsoft announced Project Astoria, a package allowing Android apps to be ported to and run on desktops, laptops, and so on, meant to attract mobile app developers to Windows 10 ecosystem (specifically, Universal Windows platform). All of this changed when it became clear that folks were moving toward web development, and iOS apps were more popular than Android apps (at one point, Microsoft did advertise Islandwood or Bridge for iOS, a tool to port iOS apps to Windows 10). But not all was lost: the Linux subsystem work that was developed until then became basis for WSL in 2016.
 
Bringing Windows Subsystem for Linux to life was both easy and hard. Easy because Windows provided support for operating system personalities, or a way to run or emulate programming interfaces for other operating systems. Hard because Windows and Linux are two completely different operating systems, and while some features were common to both, some Windows API features didn’t exist in Linux and vice versa.
 
Speaking of operating system personalities, Windows defines what is termed an “environment subsystem”. An environment subsystem is a collection of libraries and helpers that allows programs written in one operating system (or an OS API) to work under Windows. Each environment subsystem is composed of:
 
  • Subsystem libraries providing API routines for an operating system.
  • Subsystem process for managing communication between the program and Windows (actually, between programs and Windows kernel).
 
Back in 1990’s, Windows provided support for three environment subsystems: Windows, IBM OS/2, and POSIX (portable operating system interface). By default, Windows subsystem is in use (composed of libraries such as user32.dll and kernel32.dll for Windows API functionality, and CSRSS (Client/Server Runtime Subsystem) and win32k.sys (graphics) for user interface and system communication), as it is after all the reason why the operating system is called Windows. OS/2 support was removed in Windows XP, and POSIX subsystem went through numerous revisions, including Subsystem for Unix-based Applications, and since 2016, Windows Subsystem for Linux – yes, WSL’s “real” root is POSIX subsystem.
 
In terms of composition of Windows Subsystem for Linux, it is slightly different than other environment subsystems. Not only Windows must deal with Linux API, it must deal with expectations of Linux programs (such as fork system call). Because of all this, Microsoft had to add new features for managing programs (or processes).
 
Typically, a process is defined as a “container” that includes machine code, data needed by a program, and additional metadata that operating systems use (the best known metadata is process ID (PID), a number that represents the process in question). When a program starts in Windows, Windows will load a library named “ntdll.dll” which is used to help Windows programs communicate with the operating system. But a Linux program/process cannot use ntdll.dll, and since Linux works differently under the hood, Microsoft had to define what is called a “minimal process” and a “picoprocess”.
 
A minimal process is an empty process – rather, a process container with Windows specific metadata missing. There is no machine code, no data for use by the program, not even a PID. This is essential because Windows then can add actual information needed by an environment subsystem, or do something completely different with the process at the system level. In contrast, a picoprocess is a process that Windows alone cannot deal with – it includes metadata and other helpers that may represent another operating system. This “operating system representation” is supplied by a pico driver, which fulfills the role of ntdll.dll for other subsystem processes.
 
In short, Windows Subsystem for Linux (at least version 1; I’ll explain version 2 in a moment) is really a collection of libraries and helpers that helps Linux programs run on Windows. This is done through a pico driver named “lxss.sys” (LinuX subsystem). The job of this pico driver is to translate Linux API functions and certain features to Windows equivalent and back.
 
At the high level, Windows Subsystem for Linux (version 1) works as follows:
 
  1. WSL is installed. This in turn installs lxss.sys pico driver and support routines.
  2. Users install one or more Linux distributions optimized for WSL (from Microsoft Store).
  3. Users run Linux programs by running it from the chosen distribution (Ubuntu, for example).
  4. Windows notices that a Linux program has started, so it loads lxss.sys to handle system call emulation. Along the way, a WSL picoprocess for the Linux program is created with metadata supplied by lxss.sys.
  5. A Linux program makes a system call (an operating system routine for use by programs). This is intercepted by lxss.sys and WSL either tells Windows to perform an equivalent task or the library itself will handle it.
  6. Linux programs are closed, and so is lxss.sys.
 
Although it does allow many Linux programs to run, the first version of WSL has one crucial issue: it does not support all Linux API, and if it did, it didn’t support recent updates. To resolve this limitation and to bring other improvements, WSL 2 was born in 2019.
 
Unlike WSL 1 (system call emulation), WSL 2 is a custom Linux kernel running inside an optimized Hyper-V virtual machine. This guarantees better Linux API support and improves speed. In short, when Linux programs are started in WSL 2, the customized Linux kernel will be started inside the virtual machine, take care of calls coming from the Linux program, and terminate when no Linux programs are running. Because it is a virtual machine implementation, third-party virtualization products will not work if WSL 2 is enabled.
 
References:
 
  • Wikipedia entry on Windows Subsystem for Linux
  • Various Microsoft blogs (including some tech press blogs) on WSL internals
 
Hope this helps.
Cheers,
Joseph


 

Hi,

I don’t think so.

Cheers,

Joseph

 

From: win10@win10.groups.io <win10@win10.groups.io> On Behalf Of Devin Prater
Sent: Wednesday, December 18, 2019 5:16 AM
To: win10@win10.groups.io
Subject: Re: [win10] A quick (or rather, a really deep) tour of internals of Windows Subsystem for Linux #BackstageTour #WinTenDev

 

How does this work with accessibility focuses? Does WSL support mapping sound to Windows’ sound protocols? Could this, for example, be used to install Toxin, and use Emacs with Emacspeak with the Outloud speech server?



On Dec 18, 2019, at 2:37 AM, Joseph Lee <joseph.lee22590@...> wrote:

 

Hi all,

 

For new family members: as some of you found out, this forum uses hashtags extensively. And as many of you found out (some of you the hard way), this forum can get a bit geeky at times – not only we discuss Windows 10 accessibility, sometimes we talk about feature internals and some more technical material. As head list representative (about to retire from that position), I allow these discussions because it is important for you all to come along the ride and let you glimpse what’s going on so you won’t be left behind. And before I continue, let me (re)state that I do not work for Microsoft (at one point I wanted to work for MS from home, but nope), nor do I represent views of screen reader vendors (even though I can describe internals of one particular screen reader, I do not work for the vendor – I’m a volunteer).

 

IMPORTANT: what I write below is a bit more geeky than previous posts with #BackstageTour hashtag as we’ll get into system internals we usually don’t talk about, and also because one or two sections discuss Version 2004 (prerelease) material, hence #WinTenDev hashtag.

 

A few months ago someone wrote about how to use Windows Subsystem for Linux (WSL). I thought I posted a backstage tour about WSL but apparently I can’t find it anymore; so Windows Subsystem for Linux, how it works, and some background info is what we’ll talk about.

 

Windows Subsystem for Linux allows you to run Linux command line tools (someone did attempt to run GUI on top with mixed success). The aim of this feature (or rather, a subsystem) is to allow software developers to use familiar Linux utilities such as Bash (Bourn Again SHell), SSH (Secure Shell), Python, and among others, mostly for programming.

 

But WSL didn’t start out that way: the original intent of a Linux subsystem, which was in development for a number of years, was to run Android apps. Back in 2015, Microsoft announced Project Astoria, a package allowing Android apps to be ported to and run on desktops, laptops, and so on, meant to attract mobile app developers to Windows 10 ecosystem (specifically, Universal Windows platform). All of this changed when it became clear that folks were moving toward web development, and iOS apps were more popular than Android apps (at one point, Microsoft did advertise Islandwood or Bridge for iOS, a tool to port iOS apps to Windows 10). But not all was lost: the Linux subsystem work that was developed until then became basis for WSL in 2016.

 

Bringing Windows Subsystem for Linux to life was both easy and hard. Easy because Windows provided support for operating system personalities, or a way to run or emulate programming interfaces for other operating systems. Hard because Windows and Linux are two completely different operating systems, and while some features were common to both, some Windows API features didn’t exist in Linux and vice versa.

 

Speaking of operating system personalities, Windows defines what is termed an “environment subsystem”. An environment subsystem is a collection of libraries and helpers that allows programs written in one operating system (or an OS API) to work under Windows. Each environment subsystem is composed of:

 

  • Subsystem libraries providing API routines for an operating system.
  • Subsystem process for managing communication between the program and Windows (actually, between programs and Windows kernel).

 

Back in 1990’s, Windows provided support for three environment subsystems: Windows, IBM OS/2, and POSIX (portable operating system interface). By default, Windows subsystem is in use (composed of libraries such as user32.dll and kernel32.dll for Windows API functionality, and CSRSS (Client/Server Runtime Subsystem) and win32k.sys (graphics) for user interface and system communication), as it is after all the reason why the operating system is called Windows. OS/2 support was removed in Windows XP, and POSIX subsystem went through numerous revisions, including Subsystem for Unix-based Applications, and since 2016, Windows Subsystem for Linux – yes, WSL’s “real” root is POSIX subsystem.

 

In terms of composition of Windows Subsystem for Linux, it is slightly different than other environment subsystems. Not only Windows must deal with Linux API, it must deal with expectations of Linux programs (such as fork system call). Because of all this, Microsoft had to add new features for managing programs (or processes).

 

Typically, a process is defined as a “container” that includes machine code, data needed by a program, and additional metadata that operating systems use (the best known metadata is process ID (PID), a number that represents the process in question). When a program starts in Windows, Windows will load a library named “ntdll.dll” which is used to help Windows programs communicate with the operating system. But a Linux program/process cannot use ntdll.dll, and since Linux works differently under the hood, Microsoft had to define what is called a “minimal process” and a “picoprocess”.

 

A minimal process is an empty process – rather, a process container with Windows specific metadata missing. There is no machine code, no data for use by the program, not even a PID. This is essential because Windows then can add actual information needed by an environment subsystem, or do something completely different with the process at the system level. In contrast, a picoprocess is a process that Windows alone cannot deal with – it includes metadata and other helpers that may represent another operating system. This “operating system representation” is supplied by a pico driver, which fulfills the role of ntdll.dll for other subsystem processes.

 

In short, Windows Subsystem for Linux (at least version 1; I’ll explain version 2 in a moment) is really a collection of libraries and helpers that helps Linux programs run on Windows. This is done through a pico driver named “lxss.sys” (LinuX subsystem). The job of this pico driver is to translate Linux API functions and certain features to Windows equivalent and back.

 

At the high level, Windows Subsystem for Linux (version 1) works as follows:

 

  1. WSL is installed. This in turn installs lxss.sys pico driver and support routines.
  2. Users install one or more Linux distributions optimized for WSL (from Microsoft Store).
  3. Users run Linux programs by running it from the chosen distribution (Ubuntu, for example).
  4. Windows notices that a Linux program has started, so it loads lxss.sys to handle system call emulation. Along the way, a WSL picoprocess for the Linux program is created with metadata supplied by lxss.sys.
  5. A Linux program makes a system call (an operating system routine for use by programs). This is intercepted by lxss.sys and WSL either tells Windows to perform an equivalent task or the library itself will handle it.
  6. Linux programs are closed, and so is lxss.sys.

 

Although it does allow many Linux programs to run, the first version of WSL has one crucial issue: it does not support all Linux API, and if it did, it didn’t support recent updates. To resolve this limitation and to bring other improvements, WSL 2 was born in 2019.

 

Unlike WSL 1 (system call emulation), WSL 2 is a custom Linux kernel running inside an optimized Hyper-V virtual machine. This guarantees better Linux API support and improves speed. In short, when Linux programs are started in WSL 2, the customized Linux kernel will be started inside the virtual machine, take care of calls coming from the Linux program, and terminate when no Linux programs are running. Because it is a virtual machine implementation, third-party virtualization products will not work if WSL 2 is enabled.

 

References:

 

  • Wikipedia entry on Windows Subsystem for Linux
  • Various Microsoft blogs (including some tech press blogs) on WSL internals

 

Hope this helps.

Cheers,

Joseph