That feeling when a stable version of Wayland will be released on Windows faster than on Linux ;(
(disclaimer: i've tried to use it on Nvidia, but it's far from being usable, also tried to use it on Radeon 5700, it hangs on start, even mouse didn't work)
I had problems with wayland the first time I tried it with an AMD gpu as well, the solution was to simply install a new kernel. I was running debian stable so the old kernel wasn't exactly unexpected.
This type of interaction is like a defining meme for linux on the desktop. One person's experience is horrible (mouse not working, monitor resolution not working, some other minor thing not working) and another person says "It's always worked for me."
Notice how people almost never have these conversations about MacOS or Windows? Consistency in experience takes A LOT of investment, and it's a very weak point for linux on the desktop (speaking as someone who tries it every few years and goes back to Mac).
People have these conversations about Windows all the time. And it's usually worse when it comes to Windows because the software is closed both in the "source" sense and the "visibility" (logs, etc) sense, so nobody has any idea what to do except "try restarting", "try reinstalling the software", "try reinstalling Windows".
(No idea about Macs; I don't pay attention to conversations about them.)
They really, really don't. This is one area where Stockholm syndrome usually kicks in hard for people who desperately want it to be true that Linux is polished and ready for the masses. Truthfully, I think I have the same issues on Linux nowadays as I had in the late 00's, just less consistently.
The things that might work better nowadays (sound is a somewhat fixed issue?) work inconsistently (`pulseaudio -k`) and for some people might not work at all. Open source has done very little to remove inconsistencies and all three of your "try ..." remain very relevant with tons of software on Linux.
Having used a Windows 10 box primarily for the last two years I can say there are way less issues and way less blockers involved when using Windows for development than Linux. I'm almost mad I didn't give up on Linux as a daily driver earlier, because in hindsight it really wasn't a productive experience.
They merely said other platforms have issues too, not that linux doesn't have any. It's funny you mention Stockolm syndrome, then continuing on with an anecdote how Windows always works for you. I had win8 installs that would search for updates for hours on end with no result, weird error codes from windows update, windows 10 updates that left the system unbootable, broken .NET installs that couldnt be fixed without a windows reinstall. So where does that leave us? Exactly the "Linux meme" mentioned a few comments up.
> It's funny you mention Stockolm syndrome, then continuing on with an anecdote how Windows always works for you.
I didn't say "Windows always works for me", but rather that these imagined conversations about issues like these aren't a regular fixture among Windows users. The perceived polish of Linux that supposedly made things like these much rarer is just that, perceived.
Windows doesn't always work perfectly, it just works for hundreds of times more people way more of the time than Linux. You seem to take someone calling this a "meme" as saying it's not real. It's not a joke as much as it's just something that is and something that naturally happens in an ecosystem where nothing is made to work with anything else.
> I had win8 installs that would search for updates for hours on end with no result, weird error codes from windows update, windows 10 updates that left the system unbootable, broken .NET installs that couldnt be fixed without a windows reinstall.
I've had equivalents of these (unbootable computer after an update being the most exact match) with OS X. It doesn't mean that OS X isn't all-in-all a much more well put together operating system than Linux + userland or Windows. Does that mean it's perfect? No. But let's at least establish that Linux is nowhere near close to offering the same quality experience overall as neither OS X or Windows, even in a ballpark sense.
As an additional point to this: Do you believe, once non-enthusiasts start using Linux, that issues will be more or less visible? I know what my bet is.
> You seem to take someone calling this a "meme" as saying it's not real.
My take on this was that this is generally a moot way of discussing a complex software setup because it usually doesn't get any more specific than that. It shouldn't come as a surprise that a certain tech stack neither works for everybody nor nobody, be it Linux- or Windows-land.
> I didn't say "Windows always works for me", but rather that these imagined conversations about issues like these aren't a regular fixture among Windows users
Might have misread that then.
Likewise yes Linux definitely isn't a flawless experience compared to OSX or Windows, but I do however think that Windows is getting worse in that regard since a few years now (less internal QA because of telemetry?), there were a few pretty severe issues with updates, while at the same time Linux is making progress. Which brings me back to
> It's not a joke as much as it's just something that is and something that naturally happens in an ecosystem where nothing is made to work with anything else.
That is the root cause indeed with Linux, the user space really. It's not coordinated by a central authority, so you don't get a smooth experience combining arbitrary components in arbitrary versions. This is where distros come into play. They go through the pain to pick a combination of components at a certain version and make them work together with a sledgehammer. If you only ever use the package manager to install software, you will have an experience on par with windows or osx, but it's love it or leave it. Need anything that's not offered there and you have a good chance of messing things up.
Regarding your last point: My bet is on the web, eventually casual users only need a browser, which even linux can manage to offer you without blowing up, but then a Chromebook is probably what people go with.
> It's funny you mention Stockolm syndrome:
but I recently came across this one by Ken Dodd: "Just read a book about Stockholm Syndrome. It started off badly but by the end I really liked it."
>The things that might work better nowadays (sound is a somewhat fixed issue?) work inconsistently (`pulseaudio -k`) and for some people might not work at all.
"pulseaudio doesn't work" meme in 2020, lol.
Windows audio is a completely solved problem, right? Let's see some web search results for variations of "windows audio problem":
>In this case I would look to reinstall the manufacturer audio drivers as they have probably been replaced by Windows 10 built in drivers.
>ok after testing this on several games the sound is noticeably better but not completely normal should i download another driver ?
---
Some lets-players I watch regularly complain about how W10 updates break their audio capture / microphone settings. They work around it by uninstalling the update and trying as hard as possible to not let it be reinstalled automatically.
---
Like I said, not only are there problems, but nobody knows how to figure out what the problem is. Just "run the built-in troubleshooter" (which both clueful and clueless Windows users will tell you rarely fixes anything), "update your drivers", "install Windows updates", "restart your computer".
When I have issues with OSS on Linux, I have logs with filenames and distinctive error messages, publicly viewable sources that I can correlate the logs to if I want to, and forums of other people who can do that if I don't. If it's an absolutely novel problem, I can contact the authors of the code and have a high expectation of getting a response. If it's an issue that needs a fix, I can track the progress and release of the fix.
And before you say "I don't have any of these problems with audio on Windows", I too haven't had any problems with pulseaudio for the almost 10 years that I've used it.
If you are arguing that Windows audio is as troublesome as Linux audio, I think you'll find a lot of people willing to debate you.
The windows troubleshooters will fix the things they are designed to fix. They're just powershell scripts with a wizard-style interface. I've had them fix many networking issues on certain computers reliably. I haven't ever had an audio problem on Windows that wasn't caused by me, so I've never needed to run an audio troubleshooter for audio.
Windows has log files too, you just need to know where to look. Usually event viewer will have what you need, but sometimes you'll need to run a diagnostic that generates logs, or you'll just need to know where the logs are.
Saying "Windows troubleshooters never work" will often lead to someone never trying Windows troubleshooters, which only reinforces the idea that they never work.
None of them are perfect, of course, and none of them will fix any given problem, but I always try them first, even if I have low hopes for success. Sometimes I am surprised. Sometimes I have to find a fix for myself.
Troubleshooters never worked for me as well. It's hard NOT to try a troubleshooter, because it's suggested by Windows on every occasion, but after I've discovered that "troubleshooting" in Windows terms means "first try restarting the service, then try restarting the computer, then try reinstalling windows" then indeed I've stopped trying them completely.
I mean, if the user doesn't change system settings at all and uses external drives for their cat pictures then reinstalling the system isn't such a bad advice. The problem is that if someone uses Linux, then this person isn't satisfied with this style of system usage.
Exception Code 0xc0156734 ...Thanks Microsoft, now i need bing to find google, just to find 1000's of "registry cleaners" and "Antivirus" sites to find out whats wrong or what that error even means.
How many windows users do you think have never looked in the windows logs because they’ve never had to?
This is coming from a Linux fan, and someone whose tried to do linux on the desktop many times, and a technical user at that. I stick with macOS not because I want to but because I have to.
Afaik compatibility should be much better on AMD/Intel GPUs than NVidia. If you can work out the hang on start issue you might have an alright time.
(This is because AMD and Intel have proper first party open source drivers, whereas NVidia has a closed source binary blob or reverse engineered open source drivers)
The top comment was talking about their hopes for a wayland that is stable in general across normal hardware, not just in specific cases, since they couldn't get it working on nvidia nor AMD GPUs.
You said it works on ChromeOS, but that's missing their point unless ChromeOS is stable in general across normal hardware. So I asked if it was.
Just like regular GNU/Linux, when one supports companies like System76, if you want to be sure it works across normal hardware, buy it pre-installed Chromebook.
Everything else is just a pain I have grew too old to even care about.
This is so irritating: Project Astoria worked great on Windows Mobile at the time. It seemed solely as a strategic choice they didn't launch it. And now they're doing it again... even though they already killed their mobile platform? Why?
Remember that you're talking about a company that had the problem of a lack of apps/developer attention on their original mobile platform (Windows Phone 7) and decided that the solution was to reset the ecosystem in a backwards-incompatible way... twice. (first with WP8, then with W10).
After that kind of stupidity, I'm not sure anything else would be much of a surprise. It saddens me to say this because Windows Phone could've actually been a great platform and alternative to iOS/Android had idiots not been in charge of it.
Yes those resets were bad, but another factor was arrogance. They thought just because they're the ones with the dominant desktop OS, they'll automatically win the smartphone market somehow.
So if we ignore that stupid WP7 thing, they were 4 years late to the party. There were two players already in the market, the dominant one open sourcing the core of their OS, giving OEMs a lot of freedom for customization, users can sideload apps easily, the SDK was free and you could start testing on your device right away or distribute the apk directly.
Microsoft then thought it was smart to require a registration (for $$$ iirc) just for starting to use the IDE. You could only push one app to your phone, tied to your dev account, at a time. Sideloading didn't exist. That probably helped adoption a lot /s. Device pricing also didn't seem too competitive. At least with Nokia they could have done much more agressive pricing to gain market share. But the Nokia aquisition was the next stupid move: Nokia now got Windows for free while others still had to pay licensing fees, pulling a 3dfx Voodoo 3. Surprise, most switched to Android exclusively.
Instead of trying everything to get users and devs on board they copied mostly Apple's policies, who could really only get away with it since they were there first to market, and already had an established user base when Google came along and gave Android away almost for free and made copying (pirating) apps as easy as possible. Microsoft pretended they already own the place from day one.
> Microsoft then thought it was smart to require a registration (for $$$ iirc) just for starting to use the IDE. You could only push one app to your phone, tied to your dev account, at a time. Sideloading didn't exist. That probably helped adoption a lot /s.
Honestly, that probably didn't affect adoption a lot -- at least, not directly. Most users aren't developers. But it did probably scare off some developers, and the resulting lack of native apps probably hurt them quite a bit in the long run.
Now with Project Reunion, for those that don't know, is basically merging the Win32 and UWP worlds, by moving the UWP stack outside of the kernel into Win32 userspace frameworks.
It feels like going back to Windows 7 development stack, alongside an improved COM runtime and eventually in a few years down the line pretend that Windows 8 linage never happened.
My second device, and main phone while travelling is still a trusty Lumia.
I'm not even sure what's the recommended API to write Windows apps at this juncture. It might be more interesting to ask which APIs are being use by well-known desktop applications.
Just Win32, it is the only one that wont be abandoned in a couple of years when someone at Microsoft decides to make a new UI stack that will solve all the problems all of their previous stacks had.
Here is a good test to see if some new UI functionality from Microsoft will catch on: can you use it with CreateWindow and/or pure C without feeling like someone is hammering nails under your fingernails (so that it can also be bound to all the languages out there that have C interop and/or existing toolkits can build on top of the new functionality without rewriting everything from scratch)? If so, then it'll be UI functionality that you can rely on for the future.
If not, just ignore and stick with Win32. Microsoft will do the same anyway.
>Now with Project Reunion, for those that don't know, is basically merging the Win32 and UWP worlds, by moving the UWP stack outside of the kernel into Win32 userspace frameworks.
Interesting, I hadn't heard about that until now. Would this make it possible to run UWP software through Wine? That hasn't been possible so far.
> Now with Project Reunion, for those that don't know, is basically merging the Win32 and UWP worlds
From what I have read of project Reunion, my prediction would be this technology will be a flop.
From what I can tell the parts of Win32 that are supported are the non-GUI elements.
For most Win32 applications the GUI is tightly bound to the application logic and from what I can tell Reunion is not going to help fix that.
Now again I might be wrong, but if the Reunion solution is to replace Win32 GUI with UWP, just keeping the non GUI Win32 parts, then I would say you might as well throw away the whole application and start again.
If someone out there has used Reunion to migrate/modernism a Win32 application then I would love them to share their experience.
OS was great. Apps ecosystem sucked though, they really needed to have Android apps compatibility mode till they gained enough market share.
We would have three players then, instead of two players and maybe some great devices from players like Nokia.
It annoys me so much that MS failed in this, just like they have failed in premium laptops. One player dominates the premium smartphones and laptops in some markets by a good margin.
While official apps were nonexistant or severely lacking, a guy named Rudy or so made a lot of 6-branded apps that worked better than the originals on Android at the time. The snapchat, instagram etc clients he made were really good. While at the same time the snapchat app for Android constantly crashed and had really bad image quality (a screenshot of the camera seeker or so??). Of course, the apps were simpler then. Mostly images and a feed / chat, not all this AR and advanced filters. Not sure one could compete today without official backing.
But I really do miss some of the apps I had on my Lumia 920. The rebuilding of apps and new thinking about UI made some stellar apps. The HERE maps were so much better than Google Maps still is (and GMaps only gets worse and slower each iteration), and the HERE public transport app (Transit?) had a UI layout and interaction I've never seen anyone else have, but which was really intuitive and nice to use. WP8 also had a reddit reader that's far above anything else I've tried since.
While I never liked the look of the earlier iPhone UI widgets (blue gradient top row with back button etc) at least most of the apps worked consistently at the time. And that was even better with WP8, the way one could almost see the next screen and could swipe etc worked really well. Now however, apps are made with their own design and not made for the OS they run on. So they look the same on iOS and Android, and out of place on both. So I have one way of interacting with Instagram, and then a completely different way of interacting with Google's material apps.
> While official apps were nonexistant or severely lacking, a guy named Rudy or so made a lot of 6-branded apps that worked better than the originals on Android at the time. The snapchat, instagram etc clients he made were really good.
Several of them were taken down. Snapchat notoriously refused to develop for Windows Phone and refused any unofficial client.
Yeah, and around the same time most 3rd party Twitter clients got shafted (on all platforms).
As for Snapchat, someone at my university made accounts that would repost snaps sent to it and some other stuff. It quickly became a huge thing, and a kind of mini social network of stuff happening on campus. As they used Snapchat APIs directly for this they were quickly banned, though. It took years before Snapchat added similar features, but for me those felt DoA and no one uses them. Sad when innovation is quenched. Instead they went on to make their own app, Gobi or something.
Some devs really loved the platform and made fantastic apps for it. I remember really great third party Twitter clients as well, but there is only so much you can do if you are not a first party app. You are not going to be intimated of internal API changes. Limits can be imposed on your apps by the API provider. If I remember correctly there wasn't a good Youtube first party client for a while as well.
> But I really do miss some of the apps I had on my Lumia 920
Was it Lumia 920 itself that had the best camera of that gen? It just feels sad that the Lumia family doesn't exist anymore.
> Now however, apps are made with their own design and not made for the OS they run on.
While great for third party devs, this really sucks. Everything felt as a part of the OS with the really fresh UI.
I didn't end up publishing an app but really loved the developer tooling as well, it was very easy to write apps at that time compared to other platforms. Also, for gaming with things like XNA framework for games which a lot of indie devs were familiar with it would have been a great platform.
It annoys me so much that MS failed in this, just like they have failed in premium laptops
Not sure if they did (literally, I don't know the numbers) but laptops like Dell XPS or Surface Pro are still premium range I think, maybe just not as polished as MBP, and do seem to have quite some market share?
“they really needed to have Android apps compatibility mode till they gained enough market share”
I think Microsoft remembers how that approach worked for OS/2 and Windows compatibility mode.
Developers would think “we don’t need to develop for Windows phone” and users would think “I’ll buy a real android phone and not a phone that emulates it, and lags its software by half a year, and will have bugs”
the way to get market share is to combine two paths
- support apps from as many popular platforms as possible
- provide developers a framework native to your platform that gives their apps support for other platforms with zero effort
At the time,I speculated that it was related to legal exposure. Microsoft filed an Amicus brief supporting Oracles view that API's are copyrightable (in Oracle v Google, a case which is about to be heard by SCOTUS). Should Oracle prevail, Microsoft could be on the hook for implementing Androids API's, and their amicus would ironically be evidence of their willfulness.
> No, actually Microsoft filed an amicus brief supporting Google's view:
You are wrong to say "No" (but overall partially correct). The SCOTUS amicus is the second amicus Microsoft has filed on this long-running case - initially they were supporting Oracle's appeal[0] to the federal appeals circuit[1] in 2013.
Rough timeline: Microsoft files amicus in support of Oracle in 2013 (on appeal). Project Astoria was killed in 2016. Supreme court agrees to hear Oracle v Google 2019/20. Microsoft files amicus in support of Google 2020. Microsoft announces new Android runner late 2020.
After Project Astoria, Microsoft and Google sign pact to not sue each other anymore[0]. At the time I was speculating that's because Microsoft was using Android code which is licensed under Apache license.
I had no concrete proof over this speculation beyond the fact that using Android code means dealing with Apache license, which forbid the licensee to do patent litigation against the licensor/licensee.
That’s how Blackberry 10 ended up for me. Very few native apps but lots of good FOSS Android ones that were just never perfect on the device. Overall poor experience that I wanted to love.
I still have my BB Classic kicking around somewhere. It's neat to load up for interests' sake because the app store and BB services are mostly still operational, and all the apps on the store are _free_; albeit, those apps which are wrappers around proprietary services tend to be grossly out of date.
As a phone, it's still a better daily driver than my Pinephone. The camera is fast and decent, the audio is top-notch, it never crashes, and so on.
Nobody was going to develop for UWP anyway since (1) the community with knowledge of XAML and the app model was telling to fuck off with Windows Phone being shutted down (I was part of that community), despite its success in Europe, (2) Microsoft never sold any good amount of tablets to make the cross-device story believable and finally (3) UWP didn’t worked on the most deployed OS of the time... Windows 7. It never made any business sense to develop for UWP for a small market share when developing traditional app meant targeting almost every Windows machine out there.
I think Microsoft did the exact reverse of what they had done: they should have open a cross-platform (OS X + Windows) store delivering Silverlight out of browsers app. The Mac App store never had a lot of success, there was a golden opportunity for Microsoft to bank on a concurrent platform.
I also was enjoying C++/CX, until their WinDev team decided to kill it, replace it with C++/WinRT, without comparable tooling, and now we are told to wait until ISO C++ manages to come up with the features that C++/CX already offered to tooling authors.
And I am not the only one complaining, but since they have decided to reboot UWP into Project Reunion, having nicer tooling for C++/WinRT users seems to be at the very bottom of their priority list.
The core thing to understand about Windows leadership over the past decade is that the mobile product went so well that when the project was clearly dying, all Windows leadership was fired so the mobile folks could take their place. No joke.
With that information decisions like this become significantly less murky, though still ridiculous.
It did, but only for a small portion of applications. Others would run very poorly, if at all, depending on the degree in which the application hooked into google services//android api. The original project was more analogous to WINE for *nix systems, a compatibility layer; there where many edge cases that simply didn't work and supporting new versions of Android would require almost completely rewriting it (pre project treble).
The VM route is simply more workable and sustainable. While WINE has achieved some great success, it's still a spectrum. Some software simply doesn't work, some mostly works, some works but performance is abysmal, and some work flawlessly - depending on how deeply they integrate with windows and what APIs they utilize.
It looks like the obvious answer.
My questions:
- Would they be legally able to bring the google play store there?
- How will they manage multiple android apps running on the Front-End. That is a major issue with anbox
Amazon has a still function Android app store. Windows has a massively greater marketshare than Blackberry ever had; if it's easy for developers to add drop their apk onto another app store, why wouldn't they?
Most phone apps made little sense on desktop. And for a lot of them there are more compelling native or web offer. Finally for games, editors usually forbids running them on PC via emulators since it’s easier to cheat than on mobile.
Quite frankly because Microsoft’s management has been a fucking shit show for the last decade. Watch this get abandoned in a couple of years.
Basically their entire methodology is come up with something alpha quality, throw it on the market with lots of marketing fanfare, then shoot random products at will.
Trust is earned. And I think they’re somewhere below zero at the moment.
True... but there are tangible signs that MSFT's latest CEO (Satya Nadella) is substantially more coherent on long-term strategy than the previous CEO Balmer. It's certainly still no guarantee they'll continue being smarter but it is some justification for not entirely writing them off and perhaps cautious optimism.
IIRC, the previous attempts to run Android apps on Windows were killed due to patent risks. Maybe this time the legal team finally found a workaround...
Why are they going off and doing their own thing instead of improving and using anbox?
EDIT: I don't normally ask why my comments are downvoted but I feel like the two people who did must know more than I do and probably have a good answer to my question. Why did you downvote this?
> To achieve our goal we use standard Linux technologies like containers (LXC) to separate the Android operating system from the host.
I don't know much about what Microsoft is working on, but "running Linux inside of Linux inside of Windows" probably isn't what they really want to do.
Containers aren't "running Linux inside of Linux" they just give you new namespaces for lots of kernel managed resources. The only thing that's really duplicated is the userspace which you have to do with android anyway.
They may be trying to avoid running a virtualized linux altogether. If their goal is just to run Android apps, and not a full general purpose Linux operating system, then that would point to why they're not interested in Anbox. But like I said, I don't know what they're doing.
The previous impl used the tech that became WSL1, and I'm not sure you can in practice bypass the Linux syscall. WSL1 is now deprecated and I don't think it is actually reasonable to try to follow the fast paced dev of Linux, even more so since a few years. So the WSL2 approach seems perfectly fine.
> I don't think it is actually reasonable to try to follow the fast paced dev of Linux
That's not quite the reason why it's deprecated. Microsoft can emulate a stable kernel's ABI for a long time before needing to update, so it's not the "fast paced dev" of Linux. The problem that Windows simply can't 100% emulate the behavior of all syscalls with the way NT functions. As a result, WSL1 will always be a subset of the syscalls available on WSL2. It won't matter if they don't keep up with new ones, however it starts to make WSL1 less useful over time.
WSL1 is _not_ deprecated. it is just recommended you use WSL2 since theres a wide range of incompatibilities in WSL1 with various Linux tools. However if all you need is a basic toolchain in some ways it’s superior to WSL2 because it doesn’t require a VM.
You are right although in my mind it is frozen, and given Linux continues to move, I see WSL1 has almost deprecated.
For a few years it may continue to be useful, however soon enough you won't be able to run a modern distro on WSL1. At this point it would actually be defacto deprecated.
Thus probably nobody, neither MS nor 3rd parties, will base a medium/long term plan on WSL1 now. It's already legacy tech; still maintained for essential things (security, etc.), but already legacy.
No it isn't. Canonical now offers a SaaS solution named again Anbox-something but it's not based on the original Anbox, it's just the same concept of running Android apps but in the cloud for development purposes.
I allway wondered why there is nothing like that. Also why DEX is not pushed more. I'm still waiting for something like HP tried with there Elite X3 phone. Just connect my phone to a notebook and just use the display and keyboard from the notebook, while the data and CPU is used from the phone.
Yep, I'm currently using DeX a lot with my NexDock but mostly in anticipation of getting my Librem 5 and Phosh working better as a daily driver. This has been my dream for a long time, and it finally feels so close.
A few things:
- Having to dig out a cable to dock to the NexDock each time is a bit cumbersome. I have a small one but it's still one more thing to manage/keep with the dock. A mounting arm on the lapdock with something like Apple's MagSafe (wireless charging+NFC to initiate a Miracast connection) would be very nice
- The available lapdocks right now... aren't great. The one with the best touchpad I've found is the Elite x3 lapdock, but Samsung phones don't seem to be compatible with it. Works with my PinePhone though, so it's the one I hope I'll be able to use with the Librem 5. (This is something I expect would be improved if lapdocks gained popularity)
That aside, though... connecting my phone to a dock and using it as my computer feels super futuristic and I'm loving it so far.
The HP Elite lapdock works well with Dex on the Note8 and Note 10. Samsung SW used to just mirror the phone display, but some Android update allowed Dex over any detected HDMI connection and has been working well since.
But these days generally prefer to run Dex on Windows instead of carrying another device. Would love to see Dex on Linux happening officially. The workaround, although admirable, seemed too clunky to try [1]
Ah, interesting - it doesn't work at all on my S20 which was pretty disappointing. I've heard something changed with the update to Android 10 on these.
The DeX client on Windows is interesting, I tried it briefly since I still have one Windows machine lying around. I think overall I still prefer the idea of having my phone be the brains and docking to effectively dumb terminals though, provided there are high-quality docks out there I can use. That's also provided the phone/software is powerful and flexible enough though... DeX isn't that for my personal needs, but some of the upcoming Linux phones/DEs might be.
Last time I set it up on my Pixel 2 it took a few app clears to get it going, along with doing the initial setup on the same wifi network.
It did end up working great but no one here uses SMS (WhatsApp is practically a monopoly), I already had Google Photos for photo sync, and apps/screen sharing was Samsung-only.
Ive used dex on my note 5. It works very well. One annoyance though is the connection/disconnection process should be more streamlined. When I leave my desk to wander around im always taking my phone with me but of course I would leave my laptop behind if I was using that instead. With my phone it was very annoying to disconnect, close things on my phone so it isnt eating battery, just to come back and have everything be out of wack.
Mobile app compatibility is becoming really important now that so many popular apps/services spend all their money into iOS/Android development. If they even offer a web version it's pretty much guaranteed to be a crippled bad experience these days and native apps are a rare luxury.
Microsoft previously reimplemented some Android and iOS APIs in Project Islandwood and Astoria. Is this a continuation of that effort in the spirit of WSL1 or does this use the WSL2 method of using a VM?
> The biggest obstacle will be the graphical user interface requirement of Android apps, but with the release of WSL 2, Microsoft has begun working on a project called 'WSL-G,' or 'WSL - Graphics Architecture.' This project utilizes a built-in Wayland display server to run Linux GUI apps directly in the Windows 10 user interface.
Seems to be WSL2. Interesting as I had trouble getting graphical applications to work in Ubuntu under WSL2.
The concept of "explicitely" not supporting graphics did not make much sense with the X architecture and X servers under Windows being available. Of course MS dis not ship one, and of course X is considered deprecated by its own maintainers.
But de facto it is more a lack of support as in "we don't ship or own implementation yet" than "explicitely it does not work". It works already, Wayland just takes more effort and is just way more coupled to all parts of the stacks, as usual (but don't get me wrong, this sometimes has benefits too)
This would be killer app feature for Android gaming on PC since you wouldn't have to install emulators anymore to play Android exclusive games on your Windows PC.
First Linux, and now Android too, have become "subsystems," i.e., optional components in all but name, of Windows.
It's only a matter of time before Microsoft starts offering newer libraries and APIs that mediate and abstract away the idiosyncrasies of both operating systems, you know, to make life easier and more convenient for developers who use Windows to access these subsystems.
We badly need more competition in the OS space. Perhaps Android can become an open standard for application delivery, with commercial vendors and non-profits competing in providing runtime environments.
I kind of hope that Microsoft buys Android from Google. Last summer John Gruber wrote [1] that he feels that Google has lost interest with Android and I think he might be right.
When Google announced they would start charging for photos storage I think it signaled that maybe user data isn't as valuable as it once was. If that's correct, then maybe Android isn't as important as it once was. Maybe it's time to find better owners for the OS.
> I wouldn't be surprised to hear they make more from iOS users.
So in that scenario, you think their response would be to kill alternate revenue streams they control, and become fully dependent to Apple?
Google can make money off iOS users precisely because other platforms exist and Apple needs to compete. Once that is over, Apple will charge monopoly rent on any application or service they allow near their userbase.
Yes, but not about making money directly from it, but in denying any other plaftform maker an effective monopoly.
Chrome was that for the desktop browser space before it actually became dominant; ChromeOS is an attempt at that for desktop OS; Android is that for mobile.
There are plenty of competition in the OS space, Linux: (Canonical (Ubuntu), IBM (RedHat/Fedora), System76 (Pop!_OS)), MS, Apple, Google, and so on.
How would using Android or AOSP (open) as the platform to run apps on many platforms better than using Electron with the web as the backend, which, despite all of the negativity going around for it, is likely to be more free/open and integrated with the OS than Android runtime would be?
Monstrosities such as Electron ar the simptom of the problem, not it's solution. Competition in this context means that the end user is free to select any device from any manufacturer, and can expect his applications to run roughly in the same way and with similar performance on comparable hardware, without repurchasing them, without getting locked to a proprietary application store that takes a pound of flesh from the developers etc.
The competition between walled gardens, ex. Apple vs. Android, is not conducive to a consumer friendly outcome, see for example the Windows vs. everybody else competition of the previous era. A single proprietary platform will gain a critical mass and people will orient themselves naturally to the system that can run their applications.
An Android subsystem running on Windows has the chance to be exceptionally close to the hardware and provide a near native experience.
Competition in this context means that the end user is free to select any device from any manufacturer, and can expect his applications to run roughly in the same way and with similar performance on comparable hardware, without repurchasing them, without getting locked to a proprietary application store that takes a pound of flesh from the developers etc.
That would require the operating systems to become a commodity with little to distinguish between them. There is no way any of the OS developers is going to allow that to happen.
Electron isn't the answer. It's just a decent (if exceptionally bloated) solution to the problem that Microsoft intentionally created by making it so much of a pain in the ass to make truly cross platform apps.
Other, better solutions will be popularized soon enough. My money's on some of the promising new Rust GUI frameworks. Because even if they're limited in functionality at first their foundation is just too good to ignore.
Problem I've encountered with building Unix projects on windows is symlinks. Either the build process creates them or worse they'll part of the project itself. Which is really not nice.
Why can't Electron be the answer? I am of the opinion that WebKit/HTML5 are the most advanced, flexible, accessible UI toolkits we've ever created. I don't think some small Rust project will be able to upset that massive undertaking which has been decades in the making. Consider also that Electron can be improved and made more efficient.
Electron is not merely a HTML5 renderer for GUIs, though; it's a whole OS abstraction layer that translates native paradigms to a platform independent format that can be scripted. An Android subsystem would be exactly that, and more, with near native performance, a shared runtime etc. And yes, even HTML5 applications that Android supports.
And it would be more than just a hack. Microsoft will have all the incentives to make it run properly, since it gives them access to a whole world of non-WinOS applications that their users will become dependent on.
Let's have a thought experiment: Tomorrow the government passes a law that outlaws the sale of Windows or any Microsoft alternative OS starting 1 year from now. This law is absolute and cannot be undone before the deadline.
What do you think would happen? Would the world just stop buying new computers? Would Windows programmers just give up and become say, blacksmiths?
Hell no! What would happen is the world would move on from Windows and the world would be a better place for it.
I suspect that dozens of alternative OSes would pop up (many based on Linux) and we'd start to get some real competition in the consumer space. Something that's been desperately needed for like two decades now.
It would be like a gold rush as developers, big companies, and startups in seemingly limitless number arise to fill every "gap" in the market that opened up.
Microsoft would sell something else (e.g. Office365, or hardware) and give free Windows licenses with it, or sell them via a different government (international sales), or lobby so the law gets undone 1 minute after the deadline, or some other loophole.
> "Hell no! What would happen is the world would move on from Windows and the world would be a better place for it."
Linux users can't make Linux desirable, so they want authority to ban the competition. So much for "freedom".
> "Something that's been desperately needed for like two decades now."
People weren't interested enough in buying BeOS, and Linux organisations can't even give it away for free. What evidence of "desperate need" are you seeing?
Back when BlackBerry were an exciting innovative phone manufacturer (IMHO) they implemented an Android runtime on top of their QNX OS. It was a great idea, and worked (modulo whatever lockin Google were doing at the time).
Bowden states that it is unlikely that this new subsystem will support Google Play as Google does not allow this service to be installed on non-native Android or ChromeOS devices
So how does Bluestacks get away with that? Or is it considered a native Android device?
This is a lot less exciting than it seems to be at first glance. Opening apps from my phone on desktop: yes, I can see utility at that. But opening standalone phone app installations on my desktop? Why? There is almost no phone app I can think of that doesn't have a much better desktop equivalent - save, maybe, for games, but this doesn't seem to be aimed for that.
Since app developers need to make extra effort here to make it work (repackaging, maintaining store presence) and the experience is definitely worse, I don't see why big brands would do so. Microsoft should instead aim for improved general Android integration, like what they did for Samsung phones.
This is aimed I suppose for Android exclusive apps like games but for apps like WhatsApp for example it doesn't make sense since you have WhatsApp Web and WhatsApp for Windows PC.
Android apps are made mainly for Android smartphones and they are meant to bring mobile experience to the users. You won't be using Android jogging apps and be running together with your PC in the pocket like you can with your Android smartphone.
WhatsApp (even the Web/"Windows" versions) don't work without a smartphone though, do they?
I know I'm in a minority here, but I don't own a smartphone but still have to use WA to stay in contact with some people. I have to run it using the BlueStacks emulator on my PC. I'd love to replace that with native support for Android.
A better question would be, why would Uber make the effort of maintaining a Microsoft Store conversion of their app? Is there really a need for an Uber desktop app? They built their business on iOS/Android already.
>This is a lot less exciting than it seems to be at first glance. Opening apps from my phone on desktop: yes, I can see utility at that. But opening standalone phone app installations on my desktop? Why? There is almost no phone app I can think of that doesn't have a much better desktop equivalent - save, maybe, for games, but this doesn't seem to be aimed for that.
People are raving about being able to use iOS apps on M1 Macs - but then again native iOS apps are usually better than Android.
One advantage Apple has is the massive collection of iPad apps available on the app store. The Android tablet app ecosystem is quite lacking in comparison.
Are they raving, though? In the reviews I’ve read running iOS apps has been a disappointment — many apps have opted out of being available, those that haven’t have issues like viewing movies in small windows, and the “touch alternative” interface is reportedly difficult to use.
it's going to be more intersting when developers start building windows desktop versions of their apps on top of their android apps. It could be a trojan horse for MS to benefit from the vast android ecosystem.
Their target group is different. If they would be interested in a desktop app, they would have done it already - and even with this, they wouldn't rely on a repackaged Android app.
I expect this to be the case with all the big players. For small app devs, if the cost is really near zero, maybe - but looking at how barren the Microsoft Store is, I doubt many would bother.
And I will keep using that because MS can kiss my ass. Windows 10 has been nothing but trouble, on years old machines, which you'd think would be rock stable.
Linux is. Linux is more reliable than Windows 10 for me, even though it takes days to properly configure every little thing, and it can crap out because the bootloader decided to quit one day.
Windows 7 was the pinnacle of this OS, now it's just a bunch of trash.
Everyone, including Microsoft, realized the desktop OS is just a host for everything else. Why they keep pushing ridiculous "features" and installation-breaking updates I don't understand.
And Windows 10 users are just beta testers for all this crap.
This is all speculation, considering original Project Asturia didn't go anywhere. It is very unlikely to launch.
The only case this could work would be for Surface Neo and Duo devices. That way, those devices can actually run Windows and run the same Android apps.
Fair. I think the relevant audio and graphics apps already had Windows versions. I reckon a bunch of communities have been migrating away from macOS since Catalina.
Mac-first development has not been a thing for a long time, in practice.
Now, for the benefit of Mankind , Microsoft must release Linux/MacOS subsystem for Windows (Subsystem which is capable to run Windows applications in Linux/MacOS) .
I know Wine do exist, but it is not 100% Windows compatible. If they really care about us people, they must either release Windows subsystem for Linux/MacOS or contribute to wine to make it fully windows compatible.
Solely benefitting off Open Source Projects adding those to their closed system is not so nice imo , they must do it in other direction too.
Just imagine frustration to dualboot windows just because of one application which runs only in Windows.
On other hand, Just imagine the application running perfectly in subsystem in Linux/MacOS without any dual boot. Many wouldn't bother even if it's paid application imo.
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.
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.
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
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 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
>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]
>> 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 :-/
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
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.
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.
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.
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....
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.
> 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.
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).)
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.
(disclaimer: i've tried to use it on Nvidia, but it's far from being usable, also tried to use it on Radeon 5700, it hangs on start, even mouse didn't work)