title: How does an operating system draw windows on the screen?
body: <p>I realized after many years of using and programming computers that the stack of software that actually draws on the screen is mostly a mystery to me.</p>
  
  <p>I have worked on some embedded LCD GUI applications and I think that provides some clues as to a simplified stack but the whole picture for something like the Windows operating system is still murky.</p>
  
  <p>From what I know:</p>
  
  <ul>
  <li>Lowest level 0 is electronic hardware (integrated circuits) that provide a digital interface to turn a pixel on the screen a certain color or grey scale shade.  The interface is documented in data sheets so you know how to toggle the digital lines to turn any pixel the way you want it.</li>
  <li>Next level 1 is a hardware driver.  This usually abstracts the hardware into a common interface.  Something like SetPixel() etc.</li>
  <li><p>Next level 2 is 2D/3D graphics library (of which I have limited widget/single screen experience).  The lower levels seem to provide a buffer or range of memory that represents the pixels on the screen.  The graphics library abstracts this so you can call functions like DrawText("text", 10, 10, "font") and it will set the pixels for you in the right way.</p></li>
  <li><p>Next level would be the magic of the OS.  The windows/buttons/forms/WPF/etc is created in memory and then routed to the appropriate driver while also being directed to a certain part of the screen?</p></li>
  </ul>
  
  <p>But how does something like Windows really work?</p>
  
  <ul>
  <li>I would assume that the GPU fits between level 0 and level 1.  The GPU drives the pixels on the display directly and now the level 1 drivers are a GPU driver.  There are more functions available to enable the added functionality a GPU provides.  (what would this be though?  Does the OS pass on an array of triangles in 3D space and the GPU processes this into a 3D perspective view and then chuck it on the screen?)</li>
  </ul>
  
  <p>The biggest mystery to me though is when you get into the windows part of things.  You can have sketch up, visual studio and a FPS game all running at the same time and be able to switch between them, or in some cases tile them on the screen or have then spread across multiple screens.  How is this tracked and rendered?  Each of these would have to be running in the background and the OS would have to say which graphics pipe should be connected to which part of the screen.  How would Windows say this part of the screen is a 3D game and this part is a 2D WPF app etc?</p>
  
  <p>On top of that all you have DirectX used in one application and Qt in another.  I remember having multiple games or apps running that use the same technology so how would that work?  From what I can see you would have Application->Graphics library (DirectX, WPF etc)->Frame Buffer->Windows director (where and what part of the screen should this frame buffer be scaled to)->Driver?</p>
  
  <p>In the end it is just bits toggling to indicate which pixel should be what color but it is one hell of a lot of toggling bits along the way to get there.</p>
  
  <p>If I fire up Visual Studio and create a basic WPF app what is all going on in the background when I drop a button on the screen and hit start?  I have seen the VS designer to drop it on, created it in XAML and I have even manually drawn things pixel by pixel in an embedded system but what happens in between, the so-called meat of this sandwich?</p>
  
  <p>I have used Android, iOS, Windows and Linux and it seem to be a common functionality but I have never seen or heard an explanation of the how behind what I outline above, I only have a slightly educated guess.</p>
  
  <p>Is anyone able to shed some light on how this works?</p>