1.0.0

[benhillis]

• Removed the "Preview" label - WSL in the Store is now generally available!
• Use an override in generator.early to prevent the /etc/temp/.X11-unix socket from being removed during boot
• Don't create a pty for systemd to fix issue where systemd would time out during boot

---

This discussion was created from the release 1.0.0.

[elsaco]

Thank you, WSL team! This release brings WSLg to Windows 10, finally.

[Cosmosauras]

Amazing - thank you so much WSL team. You've saved me so much time, and no longer do i maintain a dual boot. Rock solid - you rock!

[flybyray]

Indeed, really nice feature.

An updated list of known issues with wslg would be great.
For some use cases it is too early to check it out.
For example: microsoft/wslg#188

[NotTheDr01ds]

The Windows 10 backport is amazing and truly unexpected! What a pleasant surprise! And that didn't even make the release notes?! 😀

[badihi]

Sorry, but I just do not get what's going on here. I assume WSL was released for like 6 years ago, isn't it? Can someone enlighten me what's new here?

[Biswa96]

tl;dr This is in a packaged format and can be installed/updated from Windows Store.

[brunoborges]

Now that's confusing... Given that there is WSL1 and WSL2 for multiple years now...

[NotTheDr01ds]

@badihi and @brunoborges

Yes, it's a bit confusing, and I'm personally still trying to figure out the best terminology for it. This is release 1.0.0 of the WSL application. The WSL application can be installed from the Microsoft Store (search for Windows Subsystem for Linux) or via Add-AppxPackage (from an elevated PowerShell) using the the package referenced above.

Microsoft started releasing WSL as an application just over a year ago, with Preview 0.47.1. Prior to that, WSL releases only came bundled as a Windows feature that could be enabled or disabled using Settings -> Turn Windows features on or off. Those releases are now known as the "in-box" version of WSL. The in-box version of WSL hasn't been updated since Windows 21H2.

So now, we have:

• WSL1: the "syscall translation layer"
• WSL2: the "virtual environment using a real Linux kernel
• WSL in-box feature: Which included WSL1 and WSL2, but only (currently, at least) older releases. The latest in-box version is still older than the oldest application version.
• WSL application: Where all current improvements have been happening. However, it should be noted that the WSL application only includes WSL2. To use WSL1, you still have to enable the in-box feature. (Unless something has changed here again - I haven't confirmed in the 1.0.0 release).

Let me know if that makes any more sense. Apologies in advance if it doesn't -- Perhaps someone else can explain it better than I.

Can someone enlighten me what's new here?

Well, that's fairly (but not totally) easy, but it depends on what you are upgrading from. If you're coming from the in-box feature, then everything you see in these release notes over the entire last year is new.

That includes:

• Systemd support (added in 0.67.6)
• Lots of fixes
• Kernel update (can likely be installed separately)
• Safe Mode (added in 0.66.2)
• Better error message model (0.64.0)
• --import can now handle VHD files directly rather than requiring a tarball (0.58.0)
• Dynamic maximum size of a WSL VHD now defaults to 1TB (up from 250GB) (changed in 0.58.0)
• debugShell for examining the root namespace
• Ability to mount vhd files and other --mount improvements (0.47.10)
• wsl --version command for listing various component versions

For Windows 10 users, this is the first official release with:

• WSLg for running graphical Linux applications in Wayland/Xwayland (using an RDP extension)
• wsl --mount for accessing other drives, partitions, and filesystems.

And probably some other stuff that I missed.

[brunoborges]

The way it looks for me is this:

WSL1 is basically "WSL Legacy".

WSL2 is "WSL".

And "WSL Application", well, it should be shipped as "WSL".

If I add to the mix that Windows Terminal is the application to which users use to access a WSL box, then we make things even more confusing.

And I'm talking as an end user of Windows Subsystem for Linux.

To me, there's no such thing as "WSL Application". Only WSL.

[NotTheDr01ds]

To me, there's no such thing as "WSL Application". Only WSL.

And eventually I think that will be the case. For now, however, there's still a lot of "WSL the Windows Feature" out there.

Also confusing is that turning on the Windows Feature to enable WSL1 support will automatically also enable WSL2 with the older feature set (assuming the the VMP is also activated), unless the Application is installed over it. The Application will priority over the Feature.

[NotTheDr01ds]

Windows 10 users, please note that KB5020030 is currently needed.

It's not clear to me if Windows 10 22H2 is required, or just KB5020030, since KB5020030 runs on older Windows 10 releases as well.

[Biswa96]

It's not clear to me if Windows 10 22H2 is required

That condition is enforced by MinVersion="10.0.19041.0" string in AppxManifest.xml.

[NotTheDr01ds]

@Biswa96 Hmmm. Not sure that's totally accurate either, though, as KB5020030 isn't even available for 10.0.19041.0 according to the release notes, right?

But I guess you are saying it will install on any of the older builds as long as they are .2311 or later? I haven't dug into the manifest, but is the .2311 build number enforced somewhere?

[Biswa96]

AFAIK, AppxManifest.xml just allows which Windows OS builds can install it. But it can not guarantee WSL will work in older builds. One needs the runtime bits from KB5020030. So, it will probably update the host Windows OS eventually.

[phil-blain]

For what it's worth, I'm on 10.0.19042.2251 and the msixbundle indeed installed correctly, but after a log out/log in, gcm wsl still pointed to C:\Windows\system32\wsl.exe. So no harm done (I uninstalled the package afterwards).

[NotTheDr01ds]

gcm wsl still pointed to C:\Windows\system32\wsl.exe

This appears to be normal. As far as I can tell, C:\Windows\system32\wsl.exe becomes some type of "stub" or "proxy" to the app version.

After the package is installed, however, the first thing you can do to confirm that it's using the Store/UWP version is:

wsl --version

Even with it pointing to the "old" wsl.exe, it should still report a 1.0.0 or later release at that point.

[phil-blain]

yes, thanks, that is indeed what I tried, and wsl --version was not a recognized option (confirming that I was still using the inbox version).

[mmmuir]

Can the /tmp/.x11-unix/X0 socket be used with other X-servers like MobaXterm and VcXsrv, or are such alternatives still limited to TCP? I was under the impression Unix domain sockets are not supported by design (per #8321) -- is WSLg the only exception?

[NotTheDr01ds]

The key difference here is that VcXsrv (et. al.) are running as Windows processes, so you are correct that they can't use Unix domain sockets to communicate between Windows and Linux processes. However, WSLg's Weston implementation is actually running as a Linux process inside the "system" distro, and the /tmp/.X11-unix/X0 socket is mapped (via bind mount) into the WSLg implementation itself (which is running "all Linux").

(At a high level), the WSLg Windows-side of things is an RDP implementation, which I'm assuming (although I haven't confirmed) does communicate with the WSLg implementation using IP (probably/maybe UDP, though). It's this Windows RDP process that actually displays the Linux app on the Windows desktop.

So ultimately, regardless of whether we're using WSLg or a third-party X server, at some point there is a transfer to IP. Just, in the WSLg case, there's also a middleman socket between the two Linux distributions.

[Biswa96]

...does communicate with the WSLg implementation using IP

Hyper-V socket specifically 🤓

[mmmuir]

Makes sense, thanks for the detailed answer.

[seankovacs]

This version, 1.0.0 found on the App Store, 100% has a speed issue when reading/writing to /mnt. Completely useless to get any work done. Originally thougtht it was a Win 11 vs Win 10 issue, but having flipped between installing both multiple times, this is the single thing that stands out.

[blakeduffey]

KB5020030 is a 'preview' patch. Any idea when this version of WSL will be runnable on 'mainstream' Win10 (so it can be used on corporate systems that aren't running preview versions of the OS?

[Biswa96]

There is a KB5021233 for stable ones.

[blakeduffey]

Outstanding Thanks!

…

On Thu, Dec 15, 2022, 1:50 PM Biswapriyo Nath ***@***.***> wrote: There is a KB5021233 <https://support.microsoft.com/en-us/topic/december-13-2022-kb5021233-os-builds-19042-2364-19043-2364-19044-2364-and-19045-2364-44e774aa-60c4-4e38-b7e7-c886d210db3b> for stable ones. — Reply to this email directly, view it on GitHub <#9155 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABH7HTVG4N44DEAXUUHFEW3WNNR7BANCNFSM6AAAAAASBOJHM4> . You are receiving this because you commented.Message ID: ***@***.***>