Just wanted to voice a minor gripe here. MS went through a lot of trouble to port the 2,000 most relevant Win32 function calls to create the Windows CE API. On the whole, they are well-chosen. Whenever there are several functions that do something similar, they tended to choose the best one. For example, TextOut() is gone in favor of the superior DrawText(). In some cases, they chose the function that did the most stuff. For example, MoveTo() and LineTo() are gone in favor of Polyline(). While MoveTo() and LineTo() are a bit more compact, Polyline() can cover its functionality and then some. If given the choice to dump MoveTo() and LineTo() or Polyline(), they made the right choice.

That being said, why oh why didn't anyone remove the friggin' useless hPreviousInst parameter from WinMain()?

For the uninitiated, this parameter provides the handle of the previous instance of the same running program. The last time this parameter had any meaning was in Windows 3.1. It's always zero in all Win32-based OS's, including Windows 95, 98, NT, and CE.

I halfway understand keeping this parameter Windows 95, as it had to maintain a semblance of backward compatibility with Win16. The Windows NT team, however, made it clear that Win16 compatibility was not a priority in 1992. Windows CE is a new rewrite, and is as far removed from Win16 as it is from a Nintendo GameBoy. With the tight memory arena, reduced API's, and lack of virtual memory in Windows CE, the chance of recompiling a Win16 or Win32 app for CE is zero. If your app's gonna require extensive rewrites, why not dump the obsolete parameters rather than leave future generations of Win32 programmers puzzling over why anyone'd keep a fossil parameter that was last released in a Microsoft OS in 1993!

Yeah, I know it's ultimately meaningless. Felt I had to vent somewhere.