I built and led a team of engineers to add container support to Windows. One of the goals was to add Linux style container support to Windows. However, we also aspired to go beyond this to create a version of containers suitable for hostile multi-tenant environments. My team extended the windows kernel to enable processes to run with a virtualize namespace and enlightened several kernel mode components for containers.We enabled two key scenarios: the first allows a set or processed to have a custom view of various namespaces, and second, we allow booting a copy of the user mode portion of the OS in a container essentially creating a very light virtual machine type environment. We also worked very closely with the Hyper-V team to create a light weight bubble to run this container in to enable hostile multi-tenant scenarios.The initial release of container was with Windows 10 Anniversary update. Containers were used to enable legacy win32 applications to be packaged up in an App-X package and distributed in the Windows Store. Windows Server Containers and Hyper-V containers were released a few months later with Windows Server 2016.Since this release my team has been contributing to the Windows Defender Application Guard feature. This feature allows Edge to run in a Hyper-V style container to better protect the host machine and user from malicious web sites.This was a very ambitious project that required large portions of windows to run in an environment slightly different from which it was originally designed to run. The team needed to become familiar with, and tweak large portions of the code base, and across several depots. We worked with numerous teams across the Windows org to enable various namespace virtualization, to enlighten various kernel components, to work out our story for build, servicing, etc.

I was originally a member of, and eventually led the app model team in Midori. Midori was an incubation software project which looked at applying modern software engineering approaches to OS design. The app model team was responsible for the full lifecycle of an application including authoring, distribution, activation, runtime support, and servicing. Midori applications were designed to be compiled to IL by a dev, and then uploaded to our variant of a store. There they’d be compiled for various target architectures, and available for distribution to user’s machines as needed.Midori was a capability based OS. Application had no inherent capabilities other than the ability to execute code & allocate memory without capabilities. Our team was responsible for wiring up capabilities from the various providers to the application at activation time. We also provided capabilities for persisting & updating state.One of my early contributions to the team was work to improve process launch time. I improved our process launch time by about 70% (from about 1ms to about .3ms). I also wrote the Midori Design Note laying out the plan for how our cloud distribution would work.

I was responsible for designing and building the Azure Fabric Controller. If you think of a data center as a large computer, the Fabric Controller (FC) can be thought of as the OS for this computer. Like a regular OS it is responsible for providing an idealized environment for its applications. What makes Azure unique, is that the applications span multiple machines. The FC is responsible for all the physical hardware in the data center, and has its own notion of driver models for supporting various data center equipment from physical hardware, to switches, load balancers, etc.Azure applications include binaries to run, but also something known as a service model that describes the relationship and requirements of various roles of the application. These can be deployed and run on separate hardware nodes. The FC is responsible for analyzing this graph and making allocation decisions that meet of the application and the data center as a while. The application learns the location of other role instances by communicating with the Azure runtime. In addition to allocation decisions, the FC is also responsible for moving the hardware from its current state, to the state where the application is running. It is also responsible for health management, software updates, etc. The goal is to do all of this automatically, with no human interaction.Originally, I had a very small team with just a handful of devs. But I grew the team to over 20 developers with three leads reporting to me. We worked very closely with several other teams in Azure including many of the early services deployed on the FC, the hardware folks setting up the datacenters, and the various teams providing the web facing UI, etc. The project was very ambitious, and on a very tight timeline. We went from our very first FC checkin, to being commercially available serviced in 1,000 days. I presented at the PDC in 2008 where we first announced Azure to the public.

I was responsible for the IO subsystem in an experimental OS known as the Genesis OS. A primary goal was to move drivers into user mode. I created a floppy disk driver as a proof of concept to demonstrate that we could handle the issues related to handling interrupts, mapping hardware resources to user mode, and double buffering memory to handle devices with access to only a portion of physical memory. Later I helped move a portion of the USB stack to user mode and demonstrated a USB sound driver running in user mode and interacting with media player running in Windows. Later the project was refocused to concentrate on defining an application model for Windows. As part of this project we created a set of primitives to allow the OS to enforce some of the concepts we were investigating. I implemented changes to the OS kernel to and associated namespace filters to allow namespace isolation. Different applications could be placed in different “silos” and would be given different views of various namespaces. We later extended this work to create something known as “server silos” which essentially meant booting multiple copies of the user mode portion of the OS, providing an environment like a VM but with minimal overhead.As the investigation wrapped up I helped cost the work to productize the feature and educate management so they could decide on how to proceed.

I managed a development team tasked with simplifying the process of finding, installing, securing and using drivers in Windows. We worked closely with internal driver teams, and key industry partners to allow the hardware community to create robust, compelling new device experiences. My team drove the core technologies and its adoption across the industry, and regularly presented at WinHEC, PlugFest, and the device driver conferences to educate and evangelize the to the driver community.

I worked to help design and build the Windows Driver Framework. The goal was to deliver a framework which would drastically reduce the knowledge required to write a Windows driver. To do this we worked closely with internal tams and external consultants to understand customer requirements. We analyzed customer and partner feedback and used this information to guide our prototypes and ultimately the product. I lead the development of the Plug and Play and Power Management portions of the framework as well as contributing to the overall framework architecture.

I worked closely with the display community to refine and extend the driver model to meet the needs of new hardware designs. I maintained close relationships with the base OS team, the GDI team, and the DirectX teams. I worked with vendors to provide third party drivers as part of the Windows product. Various projects include: adding graphical boot support, adding VESA support to the inbox VGA driver, enhanced x86 bios emulation support, AGP support, Multimon and DualView support, and enabling the video driver to act as bus drivers and report child devices. I received a gold star award for work enabling the system to continue running even if a thread got stuck in kernel mode waiting for an event to complete on a hung hardware device.

I worked closely with vendors to write NT display drivers before some vendors were interested in the NT platform. I fixed bugs and added features, and ported code to non-x86 platforms including PowerPC, MIPS, and Alpha. I significantly enhanced the display miniport model to support Plug and Play without impacting backward compatibility.