Microsoft open-sources the Windows Subsystem for Linux

GHACKS ^ | May 20, 2025 | Agencies Ghacks

[Openurmind]

Microsoft has announced that it has open sourced the Windows Subsystem for Linux. WSL, as it's commonly called, allows users to run Linux apps directly on Windows.

All you need to do to install WSL is run the following command in a terminal: wsl --install

Refer to this article for additional details regarding how to set up WSL.

WSL was first announced at the Build 2016 developer conference, and shipped with the Windows 10 Anniversary update. While the original release was based on lxcore.sys, a pico process provider that Windows used to run ELF executables natively. Microsoft released WSL 2 in 2019, with native support for the Linux kernel, to improve the compatibility of apps. It also introduced new capabilities like GPU Support, options to run Linux apps with GUI, mirrored networking, DNS tunneling, session 0 support, proxy support, firewall support, etc.

Ever since WSL's initial release, users and developers had been requesting Microsoft to open source the virtual machine code. That's what happened at the Build 2025 dev conference. Microsoft says it had to work on decoupling WSL from the Windows codebase in order to release the source code as a standalone app.

Developers can now analyze the code, and contribute to it, propose enhancements, thus helping WSL to evolve into a more powerful app. The Windows Subsystem for Linux source code has been released under the MIT License. It is available on GitHub.

[Openurmind]

ShadowAce is right. You might be doing yourself a favor by trying the Libreoffice suite for Windows. It is a package of apps and comes with:

libreoffice-base
libreoffice-calc
libreoffice-draw
libreoffice-impress
libreoffice-math
libreoffice-writer

https://www.libreoffice.org/

And it comes packaged standard as default in almost all Linux Distros should you ever switch to Linux. And it will still handle Win documents an files even when installed in Linux. :)

[vikingd00d]

Cygwin is better than WSL...

[Myrddin]

I upgraded the memory on my Inspiron 3030 to 64 GB yesterday. It is running Windows 11 Home. Just a couple minutes ago, I used wsl --install FedoraLinux-42 and it started right up. Convenient. Much better than it was many years ago. For serious development, I have an i9 with 64GB RAM and a dedicated 1 TB NVMe for Fedora 42 and Windows 11. I just boot the OS I want. Big bare metal runs faster than limping along under VMware. I finally have time to enjoy the toys.

Good to hear Mint is running well on your Asus laptop. I will probably stick to Fedora after 20 years in that world. I have a dedicated ham radio desktop with Ubuntu on board for FT8 and related use. That one comes back online when the company laptop vacates the KVM slot.

Last week I built my first simple Rust web server, wrapped it into a Docker container then deployed it into a minikube kubernetes cluster using a Helm chart and skaffold. It is the identical paradigm that I've been using at work except Rust based instead of Java with SpringBoot inside. Rust builds with cargo. The Java builds with gradle. Next up is a kubernetes pod with Python inside and a node.js flavor built in Javascript/TypeScript.

[Openurmind]

Have you played with Reticulum yet? I just got it set up and going to use it to do TCP and RNodes...

https://markqvist.github.io/Reticulum/manual/

https://unsigned.io/index.html

[CatOwner]

I figured to try out LibreOffice Writer and Calc, the two applications I would use from that suite. Hopefully my macros for Word (some executed from batch files as command line options) will work for Writer. Of course, I will need to convert my batch files to script files.

[Openurmind]

Sounds great, It will of course be a learning experience to get used to it. But it is inevitable that you will eventually need to upgrade to newer apps. So now or later... :)

[oldtech]

I have always used Microsoft Windows & have no ideas about Linux. What is suggested that I do?

[Openurmind]

Check back in a bit. I am going to go see how this windows tool is used to run Linux so you can test drive Linux to see what it is like. :)

I use Linux Mint Cinnamon. It is almost Win 7. So if you can use Win 7 you should be fairly comfortable with it right off the bat.

And then later if you like it you can always install it along side your Windows as a second OS option. Or switch to Linux completely and move away from Windows. :)

[bak3r]

Lmfao, it’s extremely sad microsoft has a whole dev department with complete access and control to the kernels inner workings and they are using P9.

[Myrddin]

Reticulum looks very interesting. In the early 2000s I was using OLSR mesh networking on my research rail cars to solve the problem of extremely long trains communicating with the 802.11b hardware. Trains can be 255 cars and easily wrap in ways that make line of sight fail between widely separated cars. I looked into AODV, but didn't have good implementations that were agile enough to control devices over a link.

Thanks for the pointer to Reticulum. Fun, new things to do in retirement. I also learned about use of polar modulation this evening as a reference from the recent Dayton Hamvention. FlexRadio and QRP Labs have products that use polar modulation to simplify hardware and reduce power consumption at the expense of some sophisticated DSP. It is possible to mix AM and FM and produce SSB using polar modulation techniques. Another excuse to dust off my interest in DSP. If I can get the latency down between kubernetes pods, it might possible to modularize the elements into a mix and match in a minikube cluster.

Some of the content on the unsigned.io page reminds me of the early days of amateur packet radio. My local ham buddies in San Diego had just left MA/Comm-Linkabit and were looking for something new to do. They found it. It's Qualcomm. They were the founders of the company. At the time in 1985, we were just playing with TAPR TNCs for packet radio. I was helping tweak parts of Phil Karn's Net/NOS code to work more effectively over both packet radio and inside my office as just a simple TCP/IP network. Playing with some of the new LoRA hardware looks interesting as well. Lots of my current gear is APRS capable. The locals in Pocatello are putting up some AREDN nodes. Lots of room to play.

[Bikkuri]

I can run Photoshop CS6 on my Linux fine.
Using Lutris.
Have also successfully installed and ran MS Office in the past, the same way, although I haven’t recently; still using OpenOffice.

[Openurmind]

“Thanks for the pointer to Reticulum.”

My pleasure. I saw “HAM” and thought you might be interested. I find it pretty interesting myself because it is multidevice and platform compatible. Recently I found a couple others here interested also. And all platforms can be used to communicate with each other simultaneously with Reticulum as the common application connecting them all together.

I am learning as I go with it. And yes it also reminds me of Packet Radio. But I like that on the wild web there is no need for central servers. And tunnels can be created directly from one machine to another on the other end truly P2P without need of hop nodes. Or just selective trusted nodes can be added to create a true unique encrypted private node network.

If you play with it please update me on how it goes for you. My biggest hurdle is researching the terminology they use with instructions. What they explain as simple is lost to me in the terminology they use. I have been forced to create my own glossary because they do not use any layman’s analogies to make it easier. They assume everyone understands what they are explaining when their instructions just are not simple or clear.

Like right now I am stuck on configuring the common “Nomadnet” app to play over the net by TCP. I have tried all the configuration edit examples and settings still to no avail. Somehow I am still not clear on how to make it all connect to their test net to make sure it is working. How they word it is a bit confusing and I am losing it in translation somehow. :)

[Myrddin]

I've been an active developer and user of network APIs back to 1983. Most of that was early TCP and UDP code written in C. The earliest depended on a single machine in the room with a 32 port serial board. It was the center of a star topology network running at 19,200 bps. After demonstrating a significant improvement in productivity, we were granted permission to put Ethernet boards in the mini-computers. $3,000 EACH. The cost savings rapidly paid for that upgrade. Next, we were set up with a high speed network between San Diego and Hayward data centers. 45 machines in San Diego, 40 more in Hayward. Networked to do distributed processing (1986) with fault tolerant queuing. Another big money savings. Soon, we connected the network to the IBM/Amdahl side of the house and had another huge operational saving. It was a great time to be at the right place to pull off some huge wins with networking. Each of the 80 machines eventually fanned out to 100 telephone switches each. The fun ended for me at PacBell in Dec 1991 when I moved on to my current employer. Time for new customers and new places.

I had some interesting VPN setups in the late 2000s. I used Linksys VPN capable routers to connect the locomotive shop in Bolingbrook, IL and the train hardware shop in Fairfax, VA to my VPN in Pocatello Idaho. I was the developer for the train hardware. Bolingbrook did the locomotive hardware/software. The locomotive shop enjoyed the range of control of handbrakes, anglecocks and cutlevers. The remainder of the data was non-actuator elements included brake piston position, ride quality accelerometers, bearing temperature, GPS data and bearing accelerometer data. A full working lab without need to travel. All software fully tested before deployment to the 5 research cars in the field.

Your NomadNet may be hindered by firewall settings. Assuming ping replies aren't blocked by the firewall, that is the first end to end to check. Next is level 2 (IP) layer firewall permissions, then level 3 (TCP). It can be difficult to fully analyze without access to network logs.

[Openurmind]

Holy cow! You are a wealth of knowledge going way back and I am honored you are sharing with me. I actually understand some of the train stuff you speak of. I worked on “fly by wire” garbage trucks for about ten years. “Limit switches” and such like would be needed to monitor the hydraulic ram position, air piston cylinder systems and such.

They are electric over air over hydraulic. An electric switch controlled an air solenoid that activated an air piston to push a hydraulic spool valve. And it was all limited by mechanical lever limit switches and hall magnetic sensor switches.

But these were all hardwired, I can imagine the complexity of putting them all on radio. I have lived next to a rail most of my life and went to school with those who operate them locally and they have shared how all that works with me. It is truly amazing... :)

Thank you for the pointer about my firewall. I absolutely did not check that and it makes sense. I will check that. I can get logs if you would be willing or have time to look them over? I think you are as interested as I am in Reticulum so it just might do us both some good to solve that problem?

By the way... I have been reading your stuff here for awhile now and have asked myself “Why isn’t anyone paying any attention to this wealth of knowledge?”

I’m paying attention, and have already learned some stuff from you... :)

[Myrddin]

I'm retiring on June 8th after 11 1/2 years at PacBell and 33 1/2 years at my current employer. Most of it has a software developer/system admin. The railcar work and Wingcast required doing a mix of EE component level design and device drivers. UNIX kernel device drivers as well for HP-UX, Linux, BSD UNIX. I'm finally getting time away from custom deadlines to pursue things of interest.

The anglecock actuators had bi-directional motors and limit switches on each end. Brake piston position indicator was a simple limit switch. Handbrake was bi-directional motors and two limit switches. Cut-lever was a single-action solenoid and an indicator for "open/closed". Temperature sensors ran the range from -20F to about 300F. Principally watching for a bearing burn-off. Accelerometers on the bearing adapter had a range of +/- 80g up to 100 KHz. In practice, I sampled at 100 KSPS and had an interest in the frequencies between 8 KHz and 20 KHz for purposes of bearing defect detection. Using known defective bearings, I had signatures for 55 common defects. The tri-axial accelerometers were mounted on the "bolster" and each end and assessed ride quality in vertical, lateral and longitudinal axes. If I had a little more time, measurements of roll, pitch and yaw would have been interesting to assess. The GPS provided speed and position. A 1xRTT cellular modem provided connectivity to the network using TCP/IP to upload data to the server in Fairfax, VA. More details are present in my paper delivered at the 10th International CAN Conference in Rome, 2005. It was a fun project. Lots of embedded software on PIC18F devices. More on the PC104 CPU where everything was coordinated.

I'm going to pull in the Reticulum references to the Fedora 42 server this evening and see what is necessary to get some code up and running with that API.

[Openurmind]

I find that extremely interesting that you were experimenting with frequencies. Absolutely, heat and cold changes frequencies. And with the right equipment set up you can accurately measure something like the temp of a truck or Bolster bearing. Absolutely fascinating and thank you for sharing that! I actually understand it all because of my own experience...

“I’m going to pull in the Reticulum references to the Fedora 42 server this evening and see what is necessary to get some code up and running with that API.”

Please share!!! And thank you for being interested! Hopefully we can connect and make it work! That would be huge for me!

[Myrddin]

I installed Reticulum with pip. Easy, because I use Python often. A scan through the "getting started" shows useful utilities, but I immediately see a huge security concern with remote command execution and ability to read remote files. That is a hacker's delight. My DoD customers would never allow Reticulum in their environment. As a developer, it would be exceptionally useful to work with remote nodes. One of my challenges with the railcars was my stripped down Debian Linux kernel. It is hard to do "apt get update; apt get upgrade" on a remote system. If it fails, that car is offline. Not good if it occurs in the Powder River basin fetching coal. I removed all the device drivers that didn't serve a purpose and put BusyBox on the disk in place of the full range of command files. BusyBox is an all-in-one utility that responds to argv[0] from a symlink to decide which internal command to execute. The stripped kernel booted in 5 seconds from power on. The daemon processes launched in another 5 seconds. Daemons included handlers for GPS, CAN bus, 1xRTT module and the OLSR mesh network. A PIC16F monitored the tachometer pulses coming from the Timken bearing generator. At 18 PPS, the generator was creating enough power to charge the lead acid storage battery. That was the threshold to boot the PC104 Linux to run the rest of the system. The PIC16F also did a wakeup at least every 24 hours to get a GPS fix, read the battery voltage and transmit status back to the server in Fairfax, VA. Upon status update, the PC104 would shutdown to preserve the battery.

I had another subsystem using the DigiMesh boards that would allow the otherwise shutdown PC104 to become aware of nearby cars and provide A/B end orientation to help in the derivation of the car "consist list" with serial order and orientation. The orientation was important to decide whether to trigger the A or B end cutlever when remotely disconnecting. Of course the same applied to closing the anglecock A or B before tripping the cutlever on that end. TI has an 802.15.4 chipset that does the spatial interrogation task. The last generation of brake piston position sensors was low power Bluetooth and derived power by energy harvesting from just vibration. Nordic had the first chipsets to do that. Less physical wiring. The same motivation for moving to CAN bus to connect all of the sensors back to the PC104.