
Pico Process Overview – Linux binaries on Windows - danieldk
https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/
======
nix0n
Compare to the way Cygwin does things:
[https://www.cygwin.com/faq.html#faq.api.fork](https://www.cygwin.com/faq.html#faq.api.fork)

~~~
nitrogen
That link contains some fascinating insight into the machinations required to
get POSIX-like behavior on a Win32 backend. Thanks for posting.

------
dbm5
Instead, MS should create a properly supported Win ABI for Linux. That might
actually be useful.

~~~
TazeTSchnitzel
WINE and ndiswrapper are doing just fine.

~~~
alfalfasprout
I don't know when the last time you used Wine was but there's a ton of
incompatibility still. A properly supported compatibility layer from Microsoft
would remedy a lot of problems.

------
zxcvcxz
I realized I was constantly programming services that would be run on Linux
servers, through a Linux container dev environment, running on a Linux VM
running on Windows. I finally just cut out the middle man and installed Linux
(Fedora w/ GNOME3) and it was the best decision I ever made.

I might try "bash on windows" but there have been compatibility layers like
this for years and there are always drawbacks. For instance it'll be years
before this can be considered stable for production, so this is purely for
developers. As most developers know, when you go to deploy on a production
machine things don't always work the way you expected them to because the
production environment is slightly different than your development
environment. If your development environment is a frankenstein OS with
different parts sewn together to make it work then it's going to just add
further complication to the process (Will a Linux service interface with a
windows service?).

My workflow involves spinning up containers (usually gentoo) on a remote
server for each new project and just sshing into them and using vim and other
cli tools to build projects. This has been the most superior workflow I've
found. I can use a light laptop for pretty much everything because a remote
server does all the hard work.

I know many developers who use this workflow and for large projects that
require powerful computational resources this is essential.

The only reason I see to use Windows for development is if you were developing
Windows desktop apps and I don't know anyone who's building new windows
desktop apps, most people are targeting mobile. Those who do work on Windows
desktop apps are usually maintaining something that's been around for years.
There are a few other reason to use Windows over a unix or unix-like OS but
most of them come down to Microsoft and other companies releasing proprietary
software which is locked into their ecosystem, and I'd like to avoid software
like that.

Also I'd just like to add that I never realized how bad fonts were on Windows
until I tried other operating systems. If MS wants to attract developers they
need to fix their fonts. IMO this is even more important than a Linux
compatibility layer because all I do is stare at text all day.

~~~
blackoil
Mac is very popular in developers, while not being used on servers. Reason?
You get high end laptops with drivers and a linux like command line. But the
applications and frameworks are all different, osx and linux have separate
binaries for node, java etc.

Luckily that doesn't matter, most of the programming and testing is done at a
high level, where base OS doesn't matter. This is the market they are after.

~~~
fla
>Mac is very popular in developers, while not being used on servers. Reason?

Linux is free ?

~~~
jasonjei
UNIX utilities on Win32/64 still feel weird. You don't really have forward-
slash paths adopted everywhere, and you have weird volume drive mounts.
Writing a Windows app means you have to deal with the realities of Win
specifics (e.g file systems) and the fact that you can't link to a UNIX-shared
library like you can with OS X. Windows line-endings have screwed me over with
running bash scripts (easy to fix with git settings). Have to deal with cmd as
default shell. Windows out of the box loves the wchar_t type and std::wstring,
a 2-byte character which doesn't even really encapsulate Unicode (UTF-8 is
used just about every other operating system).

While OS X binaries aren't compatible with Linux, it's usually just a
recompile. Sometimes there's a little more to it. But generally a lot less
work than Win32/Cygwin. Yet to be seen with Ubuntu on Win32/64, but apps
written in Windows Linux subsystem have been said not to be fork able from
Win32/64 apps.

However, Mac's file system HFS+ is terrible. That's a good reason not to use
it for servers on top of parts of it being proprietary.

------
ac2u
The video in the post is worth a watch, very informative whiteboarding.

------
cmdrfred
This is part of the 'drawbridge project', I wonder if the idea is to pull up
the bridge at some point. Embrace, extend and extinguish.

~~~
pkaye
Describe how the "extinguish" process would work.

~~~
Sir_Substance
Hypothetically, it comes after the "extend" phase, during which Microsoft
alters, extends or replaces the functionality of GNU tooling in attractive
ways under non-free licenses so that, over the course of several years, users
end up building their applications on non-free foundations that Microsoft has
made available both in windows and in linux distributions.

When moving to the "extinguish" phase, Microsoft uses their non-free licenses
to unilaterally retract support for linux, leaving windows server as the only
option.

There's no concrete evidence that this technique is what's going to happen,
but Microsoft has a history of it and everyone who invests in this platform
should be aware that even if that is not the plan right now, it is possible
for the plan to change at any point down the track. I recommend maintaining a
healthy level of suspicion for the next few years.

~~~
xorblurb
Well for now their top priority is to make a binary compatible way to run pre-
existing (parts of) Linux distro, and it works quite well for beta software (I
would not have said the same if it was released software in the same state,
but they seem to very actively be working on it and fixing bugs, and progress
is shown between builds)

Some technical console details are far from perfect IMO, but already good
enough for common scenarios and given the context they are in its quite
impressive (even if shortcuts are taken in regard with Windows interop)

What will come after will largely depend upon the reception on the first
release, I guess. Loads of people already want to at least be able to spawn
Windows processes from the WSL env, but that's quite understandable and
present no serious risk of extinguishing the GNU/Linux ecosystem by some kind
of miracle. I would not see any point of MS going further; they have their own
complete ecosystem which in some aspect is technically far more advanced
and/or has far more potential than competing solutions (UWP is all about
convergence and unless they reboot once again, which I think they have no
reason to do anymore, they will eventually get it right on mobile, now maybe
from a time to market point of view this will be too late but I highly doubt
that the android subsystem will be resuscitated so I don't see what WSL could
bring to that story anyway), most people are not even going to want to run WSL
in production for server workloads (and would have not wanted to even if MS
told them it's OK, which they did not).

The dev target is a very good choice and the approach solve 90% of the issues
previous attempts (Posix subsys, SUA) had (not used enough, separate target
with small ecosystem, eventually buggy because of that), and for some other
applications Cygwin is already available right now and good enough for what it
does and how it does it. The Posix subsys had actually been instrumental for
MS to a wide take over of US public markets in an impressive bad faith stunt
(and that actually was the only reason for its very presence), but the
situation is radically different now and the expectation have moved to higher
layers, so if they manage to use it like that again I think it will only be in
anecdotal proportions.

