Maintain a Single Binary for Pocket PC and Smartphone

[Andy Sjostrom]

http://msdn.microsoft.com/mobility/default.aspx?pull=/library/en-us/dnppcgen/html/mantsngbin.asp

This is quite unique for the Pocket PC and Smartphone platforms! I am not aware of any other mobile platforms that can actually run the same binary on both a touch screen PDA and a mobile phone. Be that as it may... Check out the MSDN article "How to Maintain a Single Binary for Pocket PC and Smartphone" which helps you get started writing code that maintains one binary for Pocket PC and Smartphone. Here are some hints from the article:

"• Do a runtime check for the platform
• Check for the screen resolution
• Minimize your menus entries
• Minimize the use of Common Dialog Boxes
• Save and load only from "My Documents"
• Create a resource for each platform or use the "condition" property
• Load Pocket PC and Smartphone specific libraries dynamically
• Do not assume a touch screen"

I believe some applications could be developed this way. And if the downsides of walking down this alley is too significant, then at least parts of the code base could leverage these development hints.

[Andy Sjostrom]

http://msdn.microsoft.com/mobility/default.aspx?pull=/library/en-us/dnppcgen/html/mantsngbin.asp

This is quite unique for the Pocket PC and Smartphone platforms! I am not aware of any other mobile platforms that can actually run the same binary on both a touch screen PDA and a mobile phone. Be that as it may... Check out the MSDN article "How to Maintain a Single Binary for Pocket PC and Smartphone" which helps you get started writing code that maintains one binary for Pocket PC and Smartphone. Here are some hints from the article:

"• Do a runtime check for the platform
• Check for the screen resolution
• Minimize your menus entries
• Minimize the use of Common Dialog Boxes
• Save and load only from "My Documents"
• Create a resource for each platform or use the "condition" property
• Load Pocket PC and Smartphone specific libraries dynamically
• Do not assume a touch screen"

I believe some applications could be developed this way. And if the downsides of walking down this alley is too significant, then at least parts of the code base could leverage these development hints.

[Skitals]

I noticed most pocket pc apps actually work on the Smartphone and install fine, its just not usable with the UI. For example, SmartNES doesnt work on the i600 (button mapping doesnt work and default config is useless) so for kicks I installed my favorite Pocket PC app... PocketNES. The my suprise it installed without and conflicts. It runs, and you see the PocketNES background, you just cant access the menus cause its meant for the touchscreen. This really shocked me yeterday as I thought the two platform were more largely different. If other things are the same, it seems it would be easy to port such open source projects to smartphone by just changing the UI. Just a thought, and I dont know much :P

[The PocketTV Team]

Yes, it's possible, but in general there is *no advantage* to having a single binary for different platforms. There are mostly drawbacks:

The binary is slightly larger because it includes support for the two different UI, and it is more complex because may tests must be performed at run time.

Also, in many cases it is just not possible to have a single binary for both platforms, because some dll's and libraries exist on one platform and not on the other. So unless your application only uses basic API's available on both platform, you won't be able to create a multiplatform binary.

Having a single source tree and compilation flags for the different targetted platforms is, in general, a much better solution.

Specific modules to deal with UI or specific API's of each platforms are only compiled when building for that platform.

That's the approach we use in PocketTV.

[James Sonne]

I also see no benefits to a single binary. Maybe less consumer confusion, but with two platforms as different as the SmartPhone and PocketPC I would believe that a SINGLE binary would INCREASE confusion. The binary would also be larger, taking up more room on the limited memory on the phone, take a longer time to download, and become more difficult for the developer to troubleshoot.

[kennyg]

I agree with you both, there is no real benefit to consumers as far as I can see, the platform interfaces are so different that it would likely cause more problems than anything.

It is interesting though that I've had a number of support questions from people that installed the Pocket PC version on a Smartphone, even though me Smartphone version isn't even available yet. I have to explicitly exclude Smartphone from the CAB.

Kenny Goers
Code City, Makers of CityTime

[The PocketTV Team]

> I have to explicitly exclude Smartphone from the [Pocket PC] CAB.

Of course that's what you are supposed to do.

It's even strange than the Smartphone installer lets you install CAB files not created with CapWixsp.exe ...