What are the platforms in the .NET Platform Standard?

we code against the framework.

Well, sure you are. When you manipulate strings in your code then you'll always use System.String. And it (almost) always behaves the exact same way with the exact same methods and properties.

But displaying the string does have implementation details that you cannot really ignore:

• If you want to show it in a Unix terminal on Linux or OSX then you need to target Mono or CoreCLR, the framework implementations that can run on such operating systems.
• If you want to show it in a Windows Store app (aka WinRT, aka Windows 8, aka UWP) then it is actually a HSTRING under the hood, an very well hidden detail that you don't have to worry about. But does require an UI gadget, like Windows.UI.Xaml.Controls.TextBlock, a class that is highly specific to WinRT
• If you want to show it in a browser then you need to target ASP.NET or Silverlight, framework hosts that were optimized to run on a web server or as an add-in for a browser.
• If you want to show it on a device that is powered by a small lithium-ion battery, like a phone, then you'll inevitably have to deal with a framework version that was optimized to use as little power as possible. That does affect the code you have to write, there is a huge difference between code that burns 100 Watts and code that keeps a tiny battery alive for 8 hours. Nothing you can directly see, beyond the need to use async/await a lot, but certainly something that affected the runtime very heavily. Targeting Xamarin or WinRT is required.
• If you want to show it on any operating system then you do need to target a framework version that does not use the kind of tricks that .NET uses on Windows to have an EXE launch the CLR virtual machine. That requires dnx.exe, just like you'd use java.exe or python.exe for programs written in Java or Python.

It would be lovely if those implementation details did not matter. But not the way it works in practice, as .NET proliferates and becomes available on more and more devices and operating systems it inevitably also becomes more convoluted. Choose your intended targets early, it is important.

There are many Frameworks (.NET Framework, WinRT, UWP, Silverlight, .NET Core, Windows Phone, Mono, Micro Framework und the old Compact Framework) not just only the .NET Framework.

The new way is to program against a platform standard which supports one or more of this frameworks. The platform standard defines an API which matches one or more frameworks. This means if your application supports platform standard 1.1 you will probably support almost all frameworks. Platform standard 1.4 will support .NET Framework 4.6.x and .NET Core only

Have a look at this document: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

Now this confuses me completely. I always though: we code against the .NET Framework and the framework is the framework no matter what.

No, there are actually plural .NET frameworks or platforms as you like to call them. Prior to .NET Standard, you used to target a single framework (maybe the full one, currently at version 4.6.3, if you develop web applications or windows services). DLLs targeting a framework are not compatible with another one. I.E. a DLL developed for the full .NET framework cannot be executed on Windows phone 8.1.

These frameworks actually implement a quite small common set of librairies, but also specific libraries for dealing with the platform they are intended for. I.E. libraries for managing a web server hosted on IIS in the full .NET framework, or functions for dealing with a mobile phone in the windows phone 8.1 framework.

Before .NET Standard was the PCL

There was although a workaround, called PCL which stands for "Portable Class Libraries". By using only the small common subset of methods/assemblies in two or more .NET frameworks, one could develop a library that could be included in projects targeting different frameworks. For instance, PCL profile 37 means you want your library to be usable in .NET Framework 4, Silverlight 5, and Windows 8 projects.

Please have a look at this for a list of PCL profiles and their compatibilities (I don't know if it's exhaustive): http://danrigby.com/2014/05/14/supported-pcl-profiles-xamarin-for-visual-studio-2/

Now what about .NET Standard ?

The goal with .NET Standard is to simplify this and get rid of PCLs. Roughly, .NET Standard defines a contract (a set of classes and methods), that will be implemented by all .NET frameworks. If you develop a library that targets .NET Standard, you're sure it can run on all .NET frameworks. It's the basic idea/goal behind it (even though it's a bit more subtle).

Have a look at this for the exact compatibility: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/#user-content-whats-new-in-net-standard-20

If you look at the compatibility table, you'll see that a library targeting .NET Standard 1.6 is usable as is (no need to recompile it) in .NET Framework 4.6.3 and .NET Core 1.0 applications.

In other words, we can say that .NET Framework 4.6.3 and .NET Core 1.0 both implement the .NET Standard 1.6 contract: its classes and methods.

If you also want your DLL to be usable in a windows phone 8.1 project, you'll have to target .NET Standard 1.2, which offers less functions than .NET Standard 1.6 (no System.Net.Sockets for instance).

See here for a list of available namespaces in each version of .NET Standard https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#user-content-list-of-net-corefx-apis-and-their-associated-net-platform-standard-version