C/C++ standard library?
why would you want to?
rename DllEntryPoint to DllMain then set the appropriate linker options.
hook the DirectDraw functions in memory at a later point in time(after the loading screen) rather than make a redirect DLL?
anything is possible... IMO it is best to hook DirectDrawCreate at the very beginning then redirect internally between real and emulated functions. Using a "ddraw.dll" file is optional, if one wants to inject some other way. A full answer to this question would be a long essay :p
too slow for competitive play
The game(s) actually do all their ddraw drawing in software.
They only uses ddraw as a way to copy "the output" to video memory.
War2 does not use GDI in-game (I assume). So plain ddraw only output could be ported away from the emulated ddraw and to anything one wants... The patch current uses GDI for "in-game" "output", which is notoriously slow(?)... Using OpenGL, Direct2D, Direct3D, D3DKMT, or (insert favorite graphics api here ) would probably be faster at the needed tasks: DMA, color conversion, and optionally updating only the dirty rectangles. We could even switch back and use real ddraw in-game on Win8 and Win10.
If starcraft mixes GDI and DDraw "in-game" then things don't look too good. The mixed gdi and ddraw areas are the frustrating part of this patch... as GDI can not be easily redirected. I don't know how well the other APIs would mix with GDI, they might have the same compatibility problems as ddraw. Which forces us to keep using GDI to do output... However, one could try different GDI functions like MaskBlt instead of GdiTransparentBlt or try blitting only dirty rectangles instead of the whole screen, etc.. One could also try to beat GDIs performance by doing color converstion and detecting dirty rects by hand using SSE2, thread tiling, etc.
The performance of FindWindowEx is unknown. The function could probably be replaced, if needed.
