Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


PerfectPhase PerfectPhase "This is not war, this is pest control!" - Dalek to Cyberman
  • Window container support on client

    , cbae wrote

    But having Windows containers run on a Linux VM means that you won't have to spin up another Windows VM and pay the compute hours just to host a small subset of your application infrastructure that depends on Windows. Likewise, if you're primarily a Windows shop, being able to run Linux containers from a Windows VM means you won't have to spin up an entire Linux VM because you want run some NoSQL database runs only on Linux.

    It's really not that difficult to understand the motivations.

    No that's wrong

    Hypervisor (optional) -> Container Host -> Container

    The hypervisor can be Windows or Linux, but the Container Host OS has to match the container type, Windows Containers on Windows, Linux on Linux.

    If you have a dontnet application running on coreCLR and you want to deploy this to a Linux container host then that's a Linux container not a windows container, so there is no windows OS licence involved.

    If Microsoft decide to license the number of containers running on a host, like they've done for windows VMs on a Hyper-V node, they might as well just throw in the towel and go home now.



  • Window container support on client

    , fanbaby wrote

    In any case, it makes little sense to deploy windows container to a Windows VM running under Linux vs deploying to a windows server directly.

    'In the real world' you'd be using something like a Mesosphere cluster to scale out and deploy the containers, which would send each kind to their native host types anyway.

    The whole windows on Linux, Linux on windows is only really interesting from a dev point of view anyway.

  • Window container support on client

    @kettch:Yep, there is nothing special about writing to a container, you just write platform independent code in you project and rely on platform specific containers below you to bring in the platform specific versions of the required runtimes.  Your build system just spits out a container per OS, with the correct container layers built in.  Assuming you have platform agnostic code of course.


  • Window container support on client

    @TexasToast: @kettch: What's this container abstraction you speak of?

    My understanding is containers comprises just the application and its dependencies. It runs as an isolated process in userspace on the host operating system, sharing the kernel with other containers while benefiting from resource isolation.  As I understand it there is no special container API inside the container.


  • Too much gloom here lately, even for my taste ;-)

    , kettch wrote

    @BitFlipperThis video indicates that UAP now provides non-Async methods. File system access is specifically mentioned.

    Yep, they said while you should use the aync methods as a default, they are putting back no-async methods to make porting easier.  Same with Ex methods, they're adding non-Ex versions back for back compat.

    There was talk about adding Roslyn code analysis rules that would push you to the async methods if you choice to enable it.

  • Window container support on client

    @ketch: Is this what you where thinking of?  http://channel9.msdn.com/Events/Build/2015/KEY01 (22:00)

    In that case he built an ASP.NET 5 app (i.e. cross platform CoreCLR) which he built into a container on windows and ran on a windows server.

    When he re-targeted it against Linux, the docker tools for VS rebuilt the container as a native Linux container on the Linux VM he had deployed on Azure; the container is actually built and packaged on the VM, not the machine running VS.  It was the same app, but it was not the same container.

  • Best of //build/

    @Bass: As stated in pretty every talk given on VS code over the last week, their aim in this preview is to support an excellent experience for their languages (C#, TypeScript) as well as basic web technologies such as HTML and CSS on as wide range of platforms as possible first and then to move onto other (community supported via extensions) languages after that.

    They seemed pretty pragmatic, saying if it doesn't work well for your language then use something better, there are lots of options, but over time they'd like you're choice to be VS-Code :)

  • Raspberry Pi and Windows 10 hands on

    @Bass: My take on this is they will not port the desktop shell to the PI for some of the same reasons that RT crashed and burned. 

    Zero of the currently deployed software will run as it will have to be re-compiled as ARM.  Yes, you could run some windows store apps, buts lets not even bother with that as there are so few.

    Driver compatibility. Again while there is promise of the support of the entire windows driver eco-system and the Windows Universal Driver Model, but again there is near zero not-in-box support of this until the OEMs recompile and re certify their drivers for ARM, as evidenced by the fact there is not even WiFi support on the pi image yet.

    More likely will be a third party BSP being released to support porting of the Windows Mobile SKU to the Broadcom BCM2836 SoC and hence the raspberry PI, this would get you a shell (tablet launcher, basically the start screen from windows phone) and support for Windows 'Metro' and UAP apps (i.e. windows store and windows phone) and Continuum support. Legality of distributing a full OS image based on this is another question at this point.

    As the team that is doing the 'Windows IoT Core for Small Devices' port to the Pi is called the 'self-enablement' team, I'll let you extrapolate where this is going.

    Personally I'll stick to one of the excellent Linux distros for the PI when I want a desktop OS on it, and use the Windows IoT OS when it makes sense.

  • Window container support on client

    Hence my question, the Build and ignite talks reference container support as part of the NT kernel, but every product reference refers to Windows Server Containers (coming in server 2016) and all the demos shows the containers being based off the 'windowsservercore' container. 

    My questions is purely of interest for, if while developing windows native apps (i.e. win32 API) using containers (still Docker containers) that will run on the windows OS, if I'll have to run my development environment on a server SKU, or if I can just use the client SKU for dev.

    If I have to do the dev on a server SKU or even remote debug into a server OS in a VM is of no concern to me at this point, I'm just wondering if it will be possible to run on the container on the client directly, even if only as a 'for development only' licence as they have done with some of their other server products.

  • Window container support on client

    , Bass wrote


    True, but Docker solves this issue by using a thin Linux virtual layer on Windows. It worked quite well in my own testing.

    But that would result in me running a Linux container on a Linux OS while controlling it from the Docker client on windows.

    So the questions remains, will it be possible to run a native windows container on a windows OS client SKU?