Compiler Support Page
or
How do I build apps for PocketPC 2003???

Updated 11/1/04

WE FEEL YOUR PAIN!

At some point in 2002, soon after PocketPC 2002 arrived, Microsoft also came out with an early version of embedded Visual C++ v4.0.  This was generally a better compiler and allowed for useful things like smarter try/catch exception handling.  And it was generally ignored by everybody.  It also allowed you to build C++ code to run in something called the .Net Compact Framework.  Yeah.  Like THAT was going to catch on!

Then suddenly we all knew what .Net Compact Framework was.  People started getting beta versions of the new Visual Studio .Net tool (which was decidedly NOT free).  That let you build cool new applications for the PocketPC devices in C#, or even "managed" C++ .Net or Visual Basic .Net code. These would run under the .Net Compact Framework, the version of .Net for PocketPC devices.  It even let you write true old-fashioned unmanaged C++ code to create desktop applications, if you really had to. Life was really good.

Except for the native C++ programmer of PocketPC devices.  Because it turns out the one thing Visual Studio still does NOT support was the ability to write old-fashioned unmanaged C++ code for the PocketPC.  And eVC v3.0 cannot be used to generate and download code to a PocketPC 2003 device.

Then in May 2003, Microsoft released Pocket PC 2003 which they now call "Windows Mobile".  This is a version of Pocket PC based on Windows CE v4.2, or "CE .Net".  It has the .Net Compact Framework built in to the operating system.  But people quickly figured out that not every .exe and .dll application that worked on PocketPC 2002 would still work on PocketPC 2003.  Including our products.  Other people (like Widcomm, the makers of the low-level Bluetooth stack software) discovered that the new operating system also changed significant fundamental things like how device drivers are loaded and unloaded.  Life was not good.

Now What?
Enter embedded Visual C++ v4.0 (again).  It turns out this is currently the ONLY way we know of to  create native unmanaged C++ code for PocketPC 2003 / Windows Mobile devices.

This however comes with its own problems, including:

1) eVC 4.0 does not understand project files (.vcp) from eVC 3.0.  And there is no utility to convert project files.  The only solution we've found is to manually create an empty project with the wizard, then manually add all of your application's files to that project. Bummer.

2) The .exe and .dll files created by evc 4.0 do not work on PDAs unless they are running PocketPC 2003.  That means you cannot simply "upgrade" to building only evc 4.0 applications and distribute them to all your users on any platform.  You have to create multiple binary images of your .exe or .dll file, one for PocketPC 2003, and one for everything that came before that (PocketPC 2002 and the original PocketPC 2000).  Big bummer.  
(***Recent note: we have heard some customers say you can install the PocketPC 2002 developer SDK into the evc 4.0 environment.  That means from within evc 4.0 you COULD target builds for PPC02 or PPC03 devices.  But it would still require 2 separate builds.  Act on this information at your own risk!).

Supporting Multiple Platforms
One small ray of hope is that it turns out you CAN still have a single set of source code files, while supporting multiple operating system-specific platforms.  But you still have to have 2 different "project" files (one for eVC 3.0, and one for eVC 4.0) which create two different .exe or .dll files.  You can have your eVC 3.0 project and source files in a directory like "\dir3", and over in "\dir4" you can have your eVC 4.0 project file which contains references to the source files over in "\dir3".  

The reason this works pretty well is that the object file directories are different between the two compilers, because the "target platform" is different.  Thus for eVC 3.0 you build for a "PocketPC" target and binaries are stored in "\ARMRel".  And for eVC 4.0 you build for a "PocketPC 2003" target and binaries are stored in "\ARMV4Rel". 

The technical term for this situation is "Maintenance Nightmare".

There are two reasons this strategy may not work for you if you want to have a single set of source files but support multiple PDA platforms:

1) If you want to take advantage of the newer compiler's features, like try/catch exception handling, it won't compile under the older eVC 3.0.

2) If you want to take advantage of the newer special PocketPC 2003 SDK, the code would only work on a PPC03 device.

How We Do It
The BTAccess and BTSuperPak products are created as several separate binaries for the reasons explained above.

It turns out our new "BTAccess Mobile" version is completely identical at the source level to the "BTAccess54" version.  The only difference is we had to use the new eVC 4.0 compiler and the new Widcomm v1.4 stack SDK to build for the PocketPC 2003 platform.  No source code of ours changed at all.  But we ended up with two different .dll files, and neither one works on the "other" platform.  We consequently sell both versions as a single package to make life easier for everybody. (The reason we still sell BTAccess "Classic" as a separate product is that there really are some major code differences between it and BTAccess54 / BTAccess Mobile).

We tried very hard to at least make the API the same between all these products.  So theoretically you can create a single application based on the BTAccess API which would run on all platforms.  On a 3870, you would install MyApp.exe and the BTAccess Classic dll.  On a 5450 you would install the same MyApp.exe and use the BTAccess54 dll.  No change to your code at all.

This would have continued to work for PocketPC 2003 - just use MyApp.exe with the BTAccess Mobile dll.  But you can't - because MyApp.exe was compiled with eVC 3.0, and the .exe file won't run on PocketPC 2003! (Frankly, we still don't fully understand why this is the case but we think it has do with MFC).

So even at your application level you need to create a SECOND version of the .exe (from the exact same MyApp source code), but this time compiled with eVC 4.0.  Now to support your users on an iPAQ 1940 or 5550, you would install your "MyApp Mobile.exe" and our BTAccess Mobile dll.

In fact this is how we build our BTSuperPak utilities (and StackDemo for that matter), since they are simply "user applications" that use BTAccess, just like your applications.  We have to create separate executable images with the 2 different compilers and distribute them in one big package.  It's a ridiculous way to run a business.

But hey, it could be worse - at least we don't have to litter your source code with a bunch of #ifdef statements!

How About .NET and C#?
We now have a .Net compatible version of BTAccess.  That means if you're writing in C# or VB.Net, NONE of the above discussion applies to you!  You can happily use Visual Studio to create applications for the SmartDevice target (this includes PocketPC).

Welcome to 2004!