There are currently three platforms (Palm, H/PC, and H/PC pro) and three processors you can compile for, x86, SH3, and MIPS. Note that there actually aren't any x86 Windows CE devices. Compiling for the x86 platform is actually the format that the on-screen CE emulator uses. I guess that's smart on MS's part to do it that way, as emulating another processor would make debugging slow. As it stands, debugging with the on-screen emulator is pretty quick.
Apparently MS is doing some weird tweaking with their on-screen CE emulators, because they only run on NT, and they don't run in a window. They instead draw themselves directly to the upper-right corner of the screen. They seem to coexist with the debugger fairly well, but I wish MS would've gotten 'em working in a window.
You can debug CE apps on the devices themselves via the serial port. It's actually pretty cool, but it's got a couple of problems. First off, it's about as slow as you would expect debugging via the serial port would be. Second, you've gotta remember that the CE device has its own processor. While debugging a test app, I set a breakpoint on the mouse-click routine. I then tapped the screen. Nothing happened, so I tapped the screen a couple more times. Turns out that it took several seconds for the breakpoint to manifest in the debugger. After hitting "go", my breakpoint hit again as the device sent along my extra clicks. Thankfully, debugging on the device shouldn't be something I'll too to often. The emulator seems to work, and it's much faster.
The CE palm (Pilot clone) devices are very different from the ones with the little keyboards. The version of Windows on the keyboarded versions (called H/PC and H/PC pro by Microsoft) is quite similar to Windows. You launch, load, and kill apps just like ordinary Windows. Loaded apps appear on the taskbar just like ordinary Windows. It's quite familiar, and anyone who knows Windows could adjust to it very quickly. The palms, however are a bit odd. For one thing, you don't have to program a "quit" behavior in your apps, because the apps don't really ever quit! From what I can see, once you launch an app, it pretty-much runs forever. If you re-launch the app from the "start" menu, it just switches to the one currently in memory. You can throw the app outta memory via the control panel, but I think that's only a last resort for a crashed app or if you're running low on memory. Such a thing is certainly gonna force me to change my thinking a bit.
The handwriting recognition is indeed easy to learn. The CE recognition is based on "Jot", which is very similar to the Pilot's Graffiti. The only difference I can see is that there are more strokes to define letters. This will probably make it easier to learn than Graffiti, but more prone to misses. The online help for Jot is cool, animating the strokes necessary for the letter you specify, but it doesn't seem appreciably more useful than the Pilot's little on-screen reference card. One thing that's nice is that the writing area is actually part of the LCD rather than a separate pad below the screen, as on the Pilot. This has a couple of big advantages. First, if your app doesn't require text input, you can turn off the pad and get a much larger screen. Also, you can replace the recognition system if you want. For example, you can opt for a little keyboard or a couple of third-party Jot replacements. Doing the same thing on the Pilot would require putting an overlay over the handwriting area.
Windows CE is a Unicode-only beast, and Unicode is gonna be the biggest brain-changer of all. Just to test, I threw in a couple of MessageBoxes on one of the test apps. The compiler immediately complained "you silly tiny-brained person, strings are not made of chars. They're made of shorts."
MS has a TEXT() macro which does the conversion, but I'm certain I'll do this a hundred times before I get used to it. Getting a good String class that automatically converts is gonna be the first thing on the docket :)