[DISCUSSION] Windows Subsystem for Linux (WSL)

You need to login to view this posts content.

 

You need to login to view this posts content.

 

LOL I don't know, I don't use it for gaming.

 

on Windows side: X Server (VcXsrv) and audio server (Pulseaudio)
on WSL: sudo apt install frozen-bubble

 

Could you provide linst to X Server, and Pulseaudio please?

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

the Store claims Fedora is available:

Spoiler

but I only see Ubuntu, openSUSE, and SLES:

Spoiler

(As an aside, who uses SLES??)

 

Fedora is probably the best to make WSL a tool in Windows, ie for development. I've not been overjoyed by the fact you need unofficial Ubuntu repositories to get decent versions of clang and gcc. I wonder about fedora support from Microsoft though, so perhaps sticking with Ubuntu is the best overall.

 

So I updated to Fall creators update and decided to test the (at least for me) crucial things - symlink compatibility. Until now this have been true (I'm not in Insiders):

1. WSL do not understand windows symlinks
2. Windows do not understand WSL symlinks

This have made me to still use for example Git for windows and not WSL for git (even if symlinks are rare in git). So what is the use of WSL if you still need a winunixy "shell" environment? Well, SUA was excellent for configurations in for example GNU Autotools and BSD make. My hope is WSL can at least be equally good. These scenarios typically involve a lot of symlinks though.
--------------------------------------------------------------------------------------
The tests - try to understand
cmd:

Code:

F:\dev\UWP>ver
Microsoft Windows [Version 10.0.16299.15]

WSL:

Code:

/mnt/f/dev/UWP$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial

cmd:

Code:

F:\dev\UWP>mklink /D cmdsymlink C:\TEMP\tankmapp

WSL:

Code:

/mnt/f/dev/UWP$ ln -s /mnt/c/TEMP/tankmapp wslsymlink

cmd:

Code:

F:\dev\UWP>dir /A
 Directory of F:\dev\UWP

2017-10-08  17:34    <DIR>          .
2017-10-08  17:34    <DIR>          ..
2017-10-08  17:29    <JUNCTION>    wslsymlink [...]
2017-10-08  17:34    <SYMLINKD>     cmdsymlink [C:\TEMP\tankmapp]

WSL:

Code:

/mnt/f/dev/UWP$ ll
drwxrwxrwx 0 root root 4096 okt  8 18:20 ./
drwxrwxrwx 0 root root 4096 okt  8 10:44 ../
lrwxrwxrwx 1 root root   20 okt  8 17:29 wslsymlink -> /mnt/c/TEMP/tankmapp/
lrwxrwxrwx 0 root root    0 okt  8 17:34 cmdsymlink -> /mnt/c/TEMP/tankmapp/

--------------------------------------------------------------------------------------
etc

So now we can conclude:

1. WSL do understand windows symlinks
2. Windows still do not understand WSL symlinks

Terrific! This is good enough for me. One can either somehow convert the WSL symlinks to NTFS symlinks or redirect WSL ln utility to mklink.

 

Undocumented API for installing and running custom distributions both online or offline... You can find both the C and C# definitions below.

I reversed these definitions from symbols so they should be correct but I might have missed something so if you run into issues then let me know

C# definitions:

Code:

[Flags]
public enum WSL_DISTRIBUTION_FLAGS : uint
{
    NONE = 0,
    ENABLE_INTEROP = 1,
    APPEND_NT_PATH = 2,
    ENABLE_DRIVE_MOUNTING = 4
}

[DllImport("wslapi.dll", EntryPoint = "WslConfigureDistribution", ExactSpelling = true, CharSet = CharSet.Unicode)]
public static extern uint WslConfigureDistribution(
    [In] string distributionName,
    [In] uint defaultUID,
    [In] WSL_DISTRIBUTION_FLAGS wslDistributionFlags
    );

[DllImport("wslapi.dll", EntryPoint = "WslGetDistributionConfiguration", ExactSpelling = true, CharSet = CharSet.Unicode)]
public static extern uint WslGetDistributionConfiguration(
    [In] string distributionName,
    [Out] out uint distributionVersion,
    [Out] out uint defaultUID,
    [Out] out WSL_DISTRIBUTION_FLAGS flags,
    [Out] out StringBuilder envvars,
    [Out] out uint envvarCount
    );

[DllImport("wslapi.dll", EntryPoint = "WslIsDistributionRegistered", ExactSpelling = true, CharSet = CharSet.Unicode)]
public static extern uint WslIsDistributionRegistered(
    [In] string distributionName
    );

[DllImport("wslapi.dll", EntryPoint = "WslLaunch", ExactSpelling = true, CharSet = CharSet.Unicode)]
public static extern uint WslLaunch(
    [In] string distributionName,
    [In] string command,
    [In] bool useCurrentWorkingDirectory,
    [In] IntPtr stdIn,
    [In] IntPtr stdOut,
    [In] IntPtr stdErr,
    [Out] out IntPtr processHandle
    );

[DllImport("wslapi.dll", EntryPoint = "WslLaunchInteractive", ExactSpelling = true, CharSet = CharSet.Unicode)]
public static extern uint WslLaunchInteractive(
    [In] string distributionName,
    [In] string command,
    [In] bool useCurrentWorkingDirectory,
    [Out] out uint errorCode
    );

[DllImport("wslapi.dll", EntryPoint = "WslRegisterDistribution", ExactSpelling = true, CharSet = CharSet.Unicode)]
public static extern uint WslRegisterDistribution(
    [In] string distributionName,
    [In] string tarGzFilename
    );

[DllImport("wslapi.dll", EntryPoint = "WslUnregisterDistribution", ExactSpelling = true, CharSet = CharSet.Unicode)]
public static extern uint WslUnregisterDistribution(
    [In] string distributionName
    );

Native definitions:
EDIT: Removed since they are now available with the wslapi.h header included with the Windows SDK.


You can GetProcAddress these functions using LoadLibrary(L"wslapi.dll") but only from x64 applications... If you use the C# definitions make sure the platform target is x64.

If you want to launch Bash from a console application use "WslLaunchInteractive" while from GUI applications you must use "WslLaunch".

Examples...

Installing a custom shell:
if (!SUCCEEDED(WslIsDistributionRegistered(L"mydistro")))
{
WslRegisterDistribution(L"mydistro", L"install.tar.gz");
}

The tar file must be located in the same directory as the executable. The Linux distro will also be installed into the same directory as the executable.

Launching the custom shell:
HRESULT hr;
ULONG errorCode;

if (!SUCCEEDED(hr = WslLaunchInteractive(L"mydistro", NULL, TRUE, &errorCode)))
wprintf(L"Unable to start distro: '%s', errorcode: 0x%Ix", L"mydistro", hr);

If you've installed the distro from the store then instead of "mydistro" you should use:
"Ubuntu"
"openSUSE-42"
"SLES-12"

If you copy the "install.tar.gz" file from your existing Ubuntu, SUSE etc... installation from the store (or from another source) you can use it for offline installation into a custom directory...

Now we just need an offline installer for the store distros...

 

Seems nice. I'll try to rewrite LxRunOffline using this API (if I have time...).

 

Appx can be problematic...
1. Appx packages require a certificate and signed binaries.
2. You can't modify them, make changes or use custom homebrew distros.
2. You can't install an older package and a newer package side-by-side.
3. They're installed into the WindowsApps folder with a DACL that blocks Windows Explorer (including backup applications) and you can't reset the permissions without breaking other stuff.

This API doesn't have any of these issues and lets you install modified distros into custom locations just like normal desktop programs. All you need is the tar file and a executable to start the console.