Deep in the bowels of Microsoft Windows, little nuggets of data hold valuable information about all the open windows on a screen. Quite frequently, programmers need access to those nuggets if they ever want to draw to that screen. But who wants to travel through the technological jungle that is Windows, just to get at the necessary info?
This is where device contexts come in. In Windows code, a programmer makes a request for a device context from the operating system. Windows responds with a handle to a device context. Now, anytime a programmer wants to display something, he would just give the handle back to Windows and Windows would take care of the rest. This may seem like a roundabout way of working, but there's a reason why Microsoft makes programmers jump through so many loops just to draw on a screen.
When programming graphical applications for a computer, one wants to strive for code that is as general as possible. This means the same code that puts lines and words on your monitor should also be able to put lines and words on a piece of paper. "Device independence" is what people smarter than myself call it. With well-designed code, a programmer can write code one time and have it work in a variety of ways on a variety of devices.
The designers of Microsoft Windows hoped to achieve some device independence by introducing the device context. A programmer should know absolutely nothing about where certain display code is going; he lets Windows take care of that.
Luckily, this means the programmer can use the same code to send those lines and words to the printer as the monitor. That's device independence in action.
Since each individual application gets its own device context when running, no one program can be a bully and take over the operating system. A device context only allows a program to mess with its own windows and nothing outside of it. And, in practice, a program only uses a device context for a little while before it throws it away. This allows programs to change when the overall system’s display settings change.
Thus device contexts allow Windows to act as referee, designating it to decide what programs get to display and where certain data gets to go. And while Microsoft nowadays tries to hide the complexities of device contexts from programmers, it still plays an integral role in all Windows development.