I got an SDK from my hardware vendor and installed it for use with EVC
4.0/4.2 to create and run programs for Windows CE 5.0 on the target
hardware. The vendor does not include all available Windows CE 5.0
features, only those that correspond to the target hardware other than
their own proprietary BSP.

I created a new project for the target hardware using the MFC App
wizard to produce a simple dialog-based executable.

When I compiled the project, afxwin.h came up with LPDOCINFO as an
undefined symbol.

Next, I exported an SDK from my version of the target hardware's PB
project in release mode (using the vendor's BSP) which includes almost
all features for Windows CE 5.0 (My NK.bin is about 32Mb with all the
options I selected). After installing my SDK, my MFC project
compiled. Seemed strange to me.

Digging further, I found that my SDK's wingdi.h file defines
LPDOCINFO, but my vendor's wingdi.h file does not! Furthermore, the
definition is surrounded by the lines




and whereas my wingdi.h file contains definitions, structures, and
function declarations, my vendor's version contains nothing!

Am I to believe that when you export an SDK from Platform Builder,
only those components of MFC (and perhaps ATL) that support features
of the custom platform will be exported? In this case, I'm assuming
that my vendor not including printer support has prevented their SDK
export from including the definitions my app requires.

How in the world can you develop MFC (and/or ATL) applications unless
ALL MFC (and/or ATL) support exists in your SDK? I didn't choose to
include LPDOCINFO in afxwin.h, yet I can't compile programs that
include that header using my vendor's SDK because it's an undefined

Is this just the tip of the iceberg where, depending on your vendor's
platform choices, you could end up with a miriad of SDKs, no two of
which are guaranteed to let your programs compile?

Am I missing something?