A Useful Addition
Another example is the window style WS_EX_NOACTIVATE. This style prevents a window from ever getting keyboard focus. It critically aided the writing of a software keyboard and still came in handy elsewhere (software keyboards are probably the reason it was added to Windows CE in the first place). Recently, one of the authors even found himself missing it when he worked on an NT application. Therefore, before beginning a particular task, it's worth while to browse through the documentation that's related to the subject in question, even the headers. You never know what might turn up.
When developers write software for a desktop Windows operating system, it's usually to be run on an x86 platform. Windows CE, on the other hand, is intended to run on an entire range of very dissimilar types of intelligent computing devices. That comprises anything from digital set-top boxes to bar code scanners. Hence, Windows CE supports a wide and growing variety of processor families, including MIPS, SHx, PowerPC, ARM, and x86. If a Windows CE application is to be as widely available as possible, it must be built and tested on each.
What sort of issues can arise when targeting different processors? Any assembly code, of course, needs to be written for all target platforms. The same holds true for any bit-twiddling that makes assumptions about the target architecture. That's another reason to avoid such code whenever possible. Further, alignment issues surprise a lot of people who haven't worked with RISC processors before. For example, code like:
BYTE buf\[10];
DWORD pdw = (DWORD*)&buf\[5];
*pdw = 15;
will work fine on x86 processors, but it will cause unaligned access exceptions on RISC processors. Always try to avoid unaligned access. In addition, compiler, header, and chip bugs crop up occasionally. In fact, it's possible for a piece of code to mysteriously crash on only a single platform. Eventually it's discovered that a compiler bug was at fault. These situations are rare but, because no tools are perfect, they will occur on occasion.
For all of these reasons, diligent quality assurance (QA) on every single target processor is of the utmost importance. BSQUARE Corp. offers a QA product that provides application and system-level testing for any Windows CE device.
For those of you looking for additional information on programming for Windows CE, there are a number of resources you can turn to (see "Windows CE Resources" on this page) PC, ARM, and x86. If a Windows CE application is to be as widely available as possible, it must be built and tested on each processor.
What sort of issues can arise when targeting different processors? Any assembly code, of course, needs to be written for all target platforms. The same holds true for any bit-twiddling that makes assumptions about the target architecture. That's another reason to avoid such code whenever possible. Further, alignment issues surprise a lot of people who haven't worked with RISC processors before. For example, code like:
BYTE buf\[10];
DWORD pdw = (DWORD*)&buf\[5];
*pdw = 15;
will work fine on x86 processors, but it will cause unaligned access exceptions on RISC processors. Always try to avoid unaligned access. In addition, compiler, header, and chip bugs crop up occasionally. In fact, it's possible for a piece of code to mysteriously crash on only a single platform. Eventually it's discovered that a compiler bug was at fault. These situations are rare but, because no tools are perfect, they will occur on occasion.
QA Is Critical
For all of these reasons, diligent quality assurance (QA) on every single target processor is of the utmost importance. BSQUARE Corp. offers a QA product that provides application and system-level testing for any Windows CE device.
For those of you looking for additional information on programming for Windows CE, there are a number of resources you can turn to (see "Windows CE Resources" on this page).