They didn't make WSL for the benefit of mankind though, they made it so that Windows would be a better, more competitive product for developers.

If Linux distro vendors want to be more competitive for Windows users then they will have to take the initiative to improve Wine, the same way Microsoft took the initiative to support Linux apps on their own platform. It doesn't make any sense for Microsoft to take both torches and kill their own competitive advantage. They would rather have people use their own platform, Windows, which they clearly believe is the better one.

Actually they made it for the developers that buy Apple hardware to develop for GNU/Linux, which are now unhappy that Apple only focus on the developers that actually target their eco-system.

The GNU/Linux developers unwilling to support GNU/Linux hardware vendors are the ones to blame.

> The GNU/Linux developers unwilling to support GNU/Linux hardware vendors are the ones to blame.

Can you elaborate on this?

People that buy Apple hardware, giving money to Apple, then bitch about Apple not supporting developers, when they actually only care about developing for GNU/Linux, and use macOS as a pretty "Linux".

If they really cared, like myself (1215B owner), they would be giving money to Tuxedo, System 76, Dell, Asus, and whatever else that is shipping hardware with Linux distributions pre-installed.

Guilty as charged. But damn, every time I used Linux on laptops up to 2012, batteries would invariably run out in 2 hours max, sleep/hibernate would fail half the time, fans would never stop, and 3d drivers were a tire fire... It has been nice not having to think about all of that for almost a decade.

I am very tempted to go back to Linux sometime next year, but I really fear I'd end up in the same situation (or worse, since I'm also reliant on scaled HiDpi screens now and support for that sort of thing is completely absent in some distros).

A lot of people here talk about Linux making laptops die really soon but I have no clue what the hell y'all are talking about. For me switching to Linux normally makes the battery go 2-5x slower. The laptop on which I'm typing (a T420) lasted half an hour on Windows 10 and two hours on Debian when it had the original battery, now that I've replaced it it gets 5hrs on Linux and maybe two max on Windows 10. About the same on Windows 7.

Of course it depends on how you configure it but if you've really de-bloated your system you can get much more out of the battery than Windows can. I've been able to get more battery out of a recent Inspiron, a less recent Toshiba Satellite, this Thinkpad, and an old Samsung netbook, so I could be biased by my hardware.

Nowadays it's much easier to get higher-level Linux support, too.

He probably means the global bitching about the way nvidia develops their drivers.

Nothing to do with NVidia, see my reply.

WSL's origins are actually as a android subsystem for when they where making a mobile play with the Windows Phone. At the time it ultimately got scraped because it was too ambitious of an undertaking, and got spun off as WSL. Now that android[0], windows OS and WSL[1] are more mature it's going full circle.

[0] maintaining an android subsystem (and various versions as distros) should be easier now for the same reason it's easier for vendors to update phones, project treble.

[1] better filesystem sharing, GPU pass through, WSL is close to natively supporting graphical applications, etc

That's a really interesting story do you have a source where I could read more about this early project that led into wsl?

I don't have a good source at hand, but there was even a preview version of Windows 10 Mobile available that had support built in. You could get it from the insider program. Now that the whole ecosystem gets wound down it becomes incredibly frustrating trying to revisit those old systems. You can easily recreate installs of Windows 98 or XP in various flavors and patch levels, but for Windows Phone this has become mostly impossible.

For example, the store for WP8.1 and older has shut down, so you can no longer get the app for upgrading to 10. There was a tool released by the end of 2019 that can do it via USB, but that stopped working in October since the server it contacts now requires TLSv1.2, and the tool was written in .NET 4 which doesn't do 1.2 by default. So there is a registry hack you can use to enable it again, until eventually that doesn't work anymore either. There are inofficial, incomomplete mirrors of some device specific factory images, and the pretty awsome "windows phone internals" tool for rooting and modding some devices, which was mostly a one man show.

With said tool and a lot of patience, it should still be able to get one of the two insider builds of win10mobile running that had android emulation, given you find the instructions, all the files and images required. And then it's still only an alpha version that emulates the Android 4.4 API.

I have a friend whos working on software archival, so through him I became aware of the importance of trying to preserve these kind of things, and those very closed and additionally niche platforms are the second hardest thing to preserve, after cloud services.

It's called Project Astoria if you want to look it up.

It's been a good while since I read the original story, but Wikipedia [0] has some background and should have some citations if you want to dig in further

[0] https://en.m.wikipedia.org/wiki/Windows_Subsystem_for_Linux

>They would rather have people use their own platform, Windows, which they clearly believe is the better one.

They likely don't believe this. Any sane technical person should believe that a Unix-based OS (or something better) that can run Windows programs would be superior. They just need to keep everyone in that awful crabpot because it gets them money.

Same with DirectX vs. OpenGL, historically: "In December of 1996, Carmack released a document that outlined his grievances with the Direct3D API. He outlined the differences between the APIs by comparing the code required by both APIs to draw a triangle to the screen; OpenGL required only four lines of code in his samples, while Direct3D required a plethora of commands and assignations.

Carmack's blunt way of explaining things was so damaging to Direct3D's reputation that Direct3D developer Alex St. John posted a follow up in February of 1997 defending his API and strangely enough for Microsoft admitting its flaws."[0]

0: https://openglbook.com/chapter-0-preface-what-is-opengl.html

I don't develop for Windows but saying "sane technical person" is just self selecting for UNIX users.

Also 1996 was 24 years ago. DirectX has had significant overhauls where I doubt any comparison from so long ago has any merit.

DirectX is very much alive. Apple has deprecated OpenGL support.

Vulkan was made to be a better OpenGL as well.

Also wasn't OpenGL considered too bloated for embedded devices and they created OpenGLES?

>> Any sane technical person should believe that a Unix-based OS (or something better) that can run Windows programs would be superior.

I find that such statement always lack a well-stated assumption/goal: i.e. superior "for what"?

It's easy for most of us to say a Ferrari is superior to RAV4... but if we don't explicitly scope-limit, there's going to be some disappointed IKEA shoppers :D

In terms of Unix, I use AIX full time at work for servers (let's not go there;), Linux on some servers and desktops. But I'm certainly not going to install Linux for my wife or mother in law - I'm a proponent and an enthusiast but not a masochist and I do not want to constantly fix and explain the differences.

Perhaps less controversially, for my gaming & photo-editing PC, Windows "just works". I don't worry about install, drivers, maintenance, distros, anything. It's been rock stable through Win7-Win10 updates from 2013 through now with no reinstalls or hassle.

Is that a personal anecdote - of course it is; but if we're going to make sweeping "it's superior" statements, I feel we must state the scope/goal. So very very very few things in life are superior for everything to everybody :-/

If you refer to Carmack, then you should also link to the article where he mentions having changed his opinion regarding DirectX.

"John Carmack now thinks DirectX is better than OpenGL"

https://www.bit-tech.net/news/gaming/pc/carmack-directx-bett...

Even the OpenGL hero no longer buys into it.

> 'It is really just inertia that keeps us on OpenGL at this point,'

That's 1996. 24 years ago. A quarter of a century.

WSL2 is a VM. If you want excellent Windows compat, run Windows in a VM. If you merely need application not using very Windows specific feature, or if you need game compat, run something like Wine. Is there a need for yet another reimplementation of (necessarily a subset of) Windows API? Doubtful.

What would be ideal for linux would be for KVM/QEMU to come up with "seamless" mode where your running windows app in a VM but it appears as any other app on the system not as a VM

That exists, have a look at https://github.com/Fmstrat/winapps

This is nothing new, it's just using RDP with a bit of extra integration with the desktop. I think freeRDP has supported this single-app mode for ages, but you won't get good performance for anything using the GPU.

You want a foss Parallels. I don't know if you've used WSL but its not there yet.

Why would they do that? What they should really do is a Windows subsystem for macOS, so I don't have to buy a Mac to develop for iOS. That's wishful thinking though of course, Apple would never allow it.

>If they really care about us people,

They're a corporation. They do not care about anything other than increasing their shareholder's profits.

>they must either release Windows subsystem for Linux/MacOS or contribute to wine to make it fully windows compatible.

This would not increase their shareholder's profits.

That's not true. They only need look out for shareholders, profit is one way of doing that. Increasing trust of the company, making devs happy, etc are other ways to ensure the company sticks around.

I don't know if you heard already, but Microsoft did release a Windows Subsystem for Linux! Here's the wikipedia page and everything!

https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux

I find the naming scheme kind of confusing though.

WSL is well-known ;) OP asked for the reverse: being able to run Windows applications on Linux.

Yeah I know. Before he edited his post he literally asked for a Windows Subsystem for Linux which is what it should be called. But Microsoft calls their Linux environment for Windows that. So....

Following that scheme I believe varbhat meant “Linux subsystem for Windows”, I.e. Windows emulation as a Linux Software.

But Linux doesn't have the concept of a "subsystem", that's pretty much a Windows NT exclusive (inherited from its core predecessor OS/2). User mode like WINE is the correct approach on Linux.

It's pretty wild that Microsoft actually managed to reactivate the subsystem concept for (first generation) WSL after it had been dormant as an 1:1 boundary for so many iterations of Windows and even wilder how quickly (and elegantly) they switched to a completely different abstraction for WSL2. This switch was mostly motivated by cross-environment filesystem performance afaik, so it might be perfectly reasonable to take the other approach (an actual NT level subsystem) for the android use case: the guest apps won't do much file I/O outside of the subsystem's dedicated playground because of how Android is discouraging free-form filesystem use.

So I see the historical NT subsystem story restated all the time and that makes little sense. WSL1 used little (if any?) of the historical NT subsystem concepts and WSL2 even less.

SFU and its successor were, but that was a completely different architecture, never intended for binary compat. The short lived and of limited scope OS/2 subsys was for binary compat, but given the origin and NT and the similarities of some techs it is not surprising. MS-DOS support was way more a low level and VM thing and the bulk of it not that much different from the Dosemu approach.

The classical NT subsys was more of a userspace thing than a kernel space one. And Linux is already way more userspace neutral than the NT kernel is, anyway. You could do a Win compat userspace on top of the Linux syscall if you wanted. Of course it is heavily inspired by Posix, but NT syscall are heavily mapped to Win32.

> The short lived and of limited scope OS/2 subsys was for binary compat, but given the origin and NT and the similarities of some techs it is not surprising

They could have used a more classic NT environment subsystem architecture for WSL1, it would have mostly worked. The primary reason they didn't was performance, and to a lesser extent compatibility.

Unix systems create lots of short-lived processes, because processes on Unix are relatively cheap. By contrast, NT processes are much heavier weight. This is part of why the POSIX subsystem / Interix / SFU / SUA and Cygwin too always have had performance problems. Introducing a new lightweight process concept, the picoprocess, helped get over the performance issue. But these new lightweight processes can't be allowed to make arbitrary NT syscalls, which rules out the classic NT environment subsystem implementation pattern - have DLLs which make NT syscalls instead of e.g. OS/2 syscalls.

If they'd followed the classical Windows NT environment model, they would have enhanced NT to be able to load ELF executables and then shipped their own libc.so which made NT syscalls. That would have worked fine for most apps which don't make Linux syscalls directly, but would have had worse performance than WSL1 had. It also would have meant more work for them, since they'd be emulating not just the syscall layer but the libc layer too. (They could have sped things up by reusing the GNU libc code; to do that, they would have had to have open sourced most of the code of their subsystem, which would have probably been a positive overall, but I'm not sure how feasible that would have been given internal Microsoft politics around open source.)

To support the minority of apps which make Linux syscalls directly, bypassing libc, they needed something in the kernel to intercept the SYSENTER/SYSCALL/INT 0x80. They could have redirected it back to user mode for handling in their libc.so. That would have worked, it just would have been slower than WSL1 is. (And WSL1 already has enough performance issues, that performance was one of the main motivators for switching to the new architecture in WSL2.)

There are tons of programs that do not go through "the" libc under Linux, everybody and their dogs seem to reimplement their own locks recently for example. Plus the libc actually makes a way greater surface to cover given it gives you access to most of the syscall plus other functions.

Plus you still want all the fine semantics of Linux (mmap, cow or at least cow-like, etc.) and for tons of calls the libc is a trivial layer anyway, so you are not gaining much. The layout of processes also. At this point you are back to a big part of picoprocesses again, because you don't want the classic NT layout, nor cb to userspaces, etc.

Maybe would have been more of a practical idea for a BSD, but even then the remark about the surface of the libc API vs syscalls apply.

But Linux has a stable API, so it does not make much sense to do Linux compat without re-implementing it and given you can do just that, well do just that.

And you rightly note at the end that syscall support is needed, but at this point the whole architecture would have made absolutely no sense: if you are going to implement syscall eventually, just implement them in the first place, and not more code.

Also I doubt the only issues of WSL1 were performance. I doubt they would have been able to follow the upstream quickly enough, at least not without a pretty big dedicated team, and it seems difficult to justify. The WSL2 approach leverages techs that are used for many other things.

> There are tons of programs that do not go through "the" libc under Linux

I agree with you there. This is a big problem with using the classic environment subsystem model.

> Plus you still want all the fine semantics of Linux (mmap, cow or at least cow-like, etc.) and for tons of calls the libc is a trivial layer anyway, so you are not gaining much.

One potential advantage to the environment subsystem model – it might have pushed them to enhance the NT API to be closer in feature parity to the Linux API, which could then have benefited Win32.

> I doubt they would have been able to follow the upstream quickly enough, at least not without a pretty big dedicated team, and it seems difficult to justify.

Well, one relevant difference is that Linux is much more of a moving target than POSIX or OS/2 are. POSIX is a formal standard, and changes in formal standards are slow, they take years.

Back in the 1990s, OS/2 was a moving target, with IBM coming out with new versions with new features (2.x, 3.x, 4.x). But, Microsoft had decided they only wanted to support OS/2 1.x, and to ignore all new features in OS/2 2.x and higher, which made Microsoft's task much simpler. And even back when IBM was actively developing OS/2, they couldn't attain anywhere near the pace of change which is happening with Linux. Linux has far more people working on it than IBM ever had working on OS/2; and IBM, certainly back then (I don't know whether it is still true today), was notorious for slow, cumbersome and overly bureaucratic development practices, which was another limit on OS/2's velocity.

WSL1 actually doesn't use the NT subsystem capability like the older Interix/SFU system did. Instead it uses a new feature called "pico processes". See: https://docs.microsoft.com/en-us/archive/blogs/wsl/pico-proc...

> But Linux doesn't have the concept of a "subsystem", that's pretty much a Windows NT exclusive (inherited from its core predecessor OS/2)

Mainstream OS/2 doesn't have "subsystems" in the sense that Windows NT does, so it is mistaken to suggest that Windows NT got the idea from OS/2.

Something like the NT "subsystem" concept is in the abortive IBM Workplace OS which became OS/2 PPC edition. Workplace OS is based on the Mach microkernel and designed to run both Unix and OS/2 as "personalities". But this was never released for x86, and the PPC port was only ever released in beta form and abandoned before GA.

I think Windows NT more likely got the idea from Mach than mainline OS/2. Mach calls them "personalities" not "subsystems" (although some people will use the word "personality" when talking about NT). If you look at the internals of macOS/iOS/Darwin/XNU, the Mach personality concept survives in highly vestigial form – XNU has its core Mach APIs (Mach personality) and BSD APIs (BSD personality). In principle Apple could add some third personality (e.g. Windows personality, Linux personality, Android personality, etc) but they probably never will. (CMU Mach was always intended to support multiple OS APIs, but the CMU Mach developers only ever implemented a BSD Unix personality, and Workplace OS's OS/2 personality was one of the few cases of anyone ever implementing a non-Unix personality on top of Mach; the BSD personality of XNU is a descendant of CMU Mach's original BSD personality, but updated with a lot of newer code from FreeBSD and also of NeXT/Apple's own devising)

NT drew a lot of influence from VMS, and VMS also has "subsystems", although VMS' subsystems have little in common with NT's other than the name. Other operating systems also have subsystems – for example, the Job Entry Subsystem (JES) is a major component of IBM's mainframe operating system z/OS (formerly known as MVS), but z/OS subsystems and NT subsystems have little in common other than the name as well. "Subsystem" is popular as a generic term for an OS component.

Also, as other respondents have pointed out, WSL1/WSL2 are not subsystems in the classic Windows NT sense.

Thanks for the clarifications everyone!

Subsystems is an idea that Windows NT copied from mainframes, it isn't an exclusive at all.

I don't agree with you on that. (I am not the person who downvoted you, however.)

Both z/OS and Windows NT use the word "subsystem" to refer to OS components, but the commonality is purely at the terminological and most abstract conceptual level, I don't see any commonality at the level of technical details, and I see no evidence of any concrete technical influence from z/OS on Windows NT.

"Subsystem" is a highly generic term used to refer to an OS subcomponent across many operating systems – z/OS, OS/400, OpenVMS, Windows, Linux, among others. The meaning of the term varies widely, and what counts as a subsystem isn't always precisely defined. In z/OS, "subsystem" is a quite precisely defined term – it is something which is installed by calling the "IEFSSI REQUEST=ADD" macro, and which then is displayed in the output of the "DISPLAY SSI" console command. By contrast, in Windows NT, the term "subsystem" is never clearly defined – for example, is Client/Server Run-Time Subsystem (CSRSS) a subsystem or part of the Win32 subsystem (a subsystem of a subsystem)? Is the Session Manager Subsystem an integral subsystem or a part of the integral subsystem? I'm not sure there is a clear answer to these questions, whereas the question of what counts as a subsystem on z/OS is quite clear – is it visible in the "DISPLAY SSI" output?

(Slightly complicating the issue is that z/OS has both subsystems and functional subsystems, which are different things despite the similar name – subsystems implement the Subsystem Interface (SSI), functional subsystems implement the Functional Subsystem Interface (FSI).)

Also this WSL was life changing for me. Also I perfered to use the OpenSUSE version. It is just awesome.

> Microsoft must release Linux/MacOS subsystem for Windows

Linux and MacOS do not have subsystems, that is an NT architecture feature.

Microsoft could, instead, contribute to Wine.

I used to think that this would never happen, but now I wonder. MS makes lots of money from, say, office on ipad and android. MS makes tons of money from Linux via Azure. To this end, MS supports dotnet, squirrel server, and lots of other stuff on Linux really well. So maybe, just maybe, this could happen.

Yes, that playing field has shifted a lot. But Microsoft will just make more and more of their own code cross-platform (e.g. Office now exists in a modern version that's surely not very OS-specific and in a barely maintained Windows-only legacy version for anything but in name). They can sell to non-Windows customers just fine without ruining the only relevant USP Windows has, compatibility with a quarter century worth of win32 API clients.

It makes sense to port their application software to other platforms so more people can use it.

But what would they get out of giving their competitors the ability to run non-Microsoft products made for Windows? That is a big, non-trivial task which they'd be spending a lot of engineering effort on, for free, and wouldn't benefit them in any way. It would strictly reduce the number of reasons to use their products.

Nope, this is just MSFT eating market share to try to starve out competitors

I'm not sure why they would, what's in it for them?

Windows is the better Linux and the better Android ... Wonder where I heard that before!

Would you pay for a windows 10 license to enable that use case?

you mean windows subsystem for linux?