Porting a Windows-CE application to Windows Desktop

Question

I have taken over a Windows-CE 6.0 application that I would like to port to other platforms. It is a relatively straightforward, self-contained GUI application, written in Embedded C++ Version 4.0

The very first target I am interested in would be a regular Windows desktop (i.e. XP, Vista, Windows-7).

I understand that porting a desktop application to CE is nontrivial; but what about the reverse, which is what I am interested in? Is going from Windows-CE to Windows Desktop (somewhat) upward-compatible? I sure would love to hear "buy this $1000 Microsoft XYZ C++ development environment and just compile and go!"

(FYI I have no experience with GUI applications nor with programming in the Windows environment; pretend I am but a simple linux/unix guy with decades of C/C++ experience but absolutely no Windows-Fu... ;-)

Answer 1

Porting up should, actually, be pretty straightforward. CE is mostly a subset of Win32, with heavy emphasis on Unicode.

You can probably make sure UNICODE is defined, build and, with a little luck, most of it will "just work". Places that are going to be hangups are:

• The UI is likely to be set for a resolution that doesn't match your PC - often CE apps are targeted to a specific device and resolution and this doesn't necessarily come out very aesthetic on a PC.
• Anything dynamically loaded (GetProcAddress) from coredll will have to be re-mapped to kernel32/user32/etc
• If the device uses the SIP (software input panel - i.e. on-screen keyboard) then all of that has to get stripped out.
• If the app uses any Notifications (icons, etc) that has to get replaced
• If the app uses any power management, that has to get ripped out
• If the app uses any device-specific stuff - especially direct calls to drivers, all of that has to be replaced
• If the app is using point to point queues, that has to get replaced
• If the app is using the device manager (e.g. to get notifications of copnnected devices) that has to get replaced

Any calls into aygshell.dll are likely to be problematic as well.