The most important concept you must have in mind is that Windows doesn't do the screen buffering for you; instead, every application is being
informed via WM_PAINT message that it should update its screen. WM_PAINT is sent whenever a portion of the window is revealed; application is supposed to do a BeginPaint, draw onto supplied device context (DC), and call EndPaint to tell Windows that it has updated the screen OK and that the update rectangle is now valid.
However, if you draw directly (using e.g. Rectangle) on supplied DC, the window contents will flicker during moving/sizing, as updating takes considerable time. Thus, any non-trivial application usually does double-buffering itself -- it creates an off-screen (memory) DC and it just "copies&pastes" its contents onto DC returned by BeginPaint.
I wouldn't say GDI is hard; rather, it's a bit boring, because you have to take care to create and delete GDI objects yourself. Attached workspace uses double-buffering technique and my XFTGDI module, which is a thin wrapper around most frequently used GDI calls; you can find the documentation (.chm)
here. Make sure you read the Platform SDK/Graphic and Multimedia services/GDI/Painting and Drawing chapter first.
(Attachment in the followup. My additions to wizard-generated code are clearly marked).
Jugoslav
