The DirectDraw API has been more or less deprecated for game developers since the release of DirectX 9.0 SDK back in 2002. The last time we shipped samples or documentation on DirectDraw dates back to the DirectX 8.1 SDK. Game developers looking to do 2D rendering should be using Direct3D, or on systems with DirectX 11 the Direct2D API could also be a good choice. The DirectDraw documentation can still be found on MSDN. A few lingering issues, however, has kept the DirectDraw header and import library in the DirectX SDK for many long years...
In the DirectX SDK (June 2010) release, the DDRAW.H and DDRAW.LIB files are no longer there. The DirectDraw header, DDRAW.H, is included with Visual Studio 2008 because it includes the Windows SDK 6.0A release, and is present in all the newer versions of the Windows SDK including the most recent 7.1 release. Because we do not officially support Visual Studio 2005 in the June 2010 release, we finally removed the header and import library. There are only two samples in the DirectX SDK (June 2010) that even need the DDRAW.H header: the rather dated Direct3D 9 era sample ConfigSystem and the more recent sample VideoMemory. These compile fine with VS 2008 or VS 2010 due to the Windows SDK. It is worth noting, however, that the import library DDRAW.LIB is not present in the Windows SDK. It is therefore recommended that if you do make use of DirectDraw, you use explicit linking (i.e. LoadLibrary and GetProcAddress) to get any DDRAW.DLL entry-points. This technique is used by these two samples.
These samples also highlight the one area of DirectDraw that game developers continue to make use of even in modern games: getting the amount of video memory on the graphics card. It turns out that this functionality is not available in the Direct3D 9 API, so many game developers use DirectDraw just to get this information as part of their game configuration and user settings. There are some problems with this use, however, as noted in the VideoMemory sample. With the growth of physical memories both RAM and VRAM, this API is also having problems coping since it returns 32-bit DWORD counts of the size in bytes. It is recommended that when DXGI is available (Windows Vista, Windows 7, etc.), that is the most reliable API to use for getting video memory size information. For Windows XP, the Windows Management Instrumentation (WMI) interfaces are generally a better choice than DirectDraw, although this requires special-case logic on integrated graphics parts.
Another reason game developers continue to use the DDRAW.H header is that DirectDraw-era structures (DDSURFACEDESC2 and DDCAPS2) are used to define the .DDS file format, a format which is still in use today for Direct3D 11. Instead of using DDRAW.H, we recommend using more generic file-related structures if you have your own DDS codec. These structures are documented in the Windows DirectX graphics documentation in the DDS Reference. You can also find a DDS.H header in several samples that defines these documented structures, notably DDSWithoutD3DX or DDSWithoutD3DX11. As of the DirectX SDK (June 2010) release, all samples that need DDS structures use DDS.H instead of DDRAW.H.
While many legacy DirectX APIs were left behind in the 32-bit only world (DirectPlay, DirectMusic performance layer, etc.), DirectDraw (or at least DirectDraw7) is available to x64 native applications.
In general for video processing it is recommended that you make use of DirectShow or Windows Media Foundation. For low-level video operations on Windows Vista and Windows 7, you can make use of the DXVA 2.0 API. On Windows XP, DXVA 1.0 is supported through VMR9 via DirectShow.
Update: I have made some improvements to the DDSWithoutD3DX11 sample and updated the DDS.H header since the June 2010 release. See my blog post on this topic.