Practices for packaging/distributing apps to WM 5/6/2003SE?

Chris Writely · Joined: 05 Dec 2007 Posts: 9

Hi,

I was wondering what everyone's general practice was for
packaging/distributing applications to multiple platforms? I should clarify
that...

I'm currently working on the setup for my application. I have a cabinet file
being built, and a simple Windows-based Setup.exe to go with it (currently
made with EzSetup [side-question: is there anything better?]).

But making the .cab/Setup.exe brings up a bunch of questions about how to
package and distribute my application. Namely:

1) Should I be building one cab/setup.exe per supported platform and ask the
user to choose their O/S before downloading? (In this case, I'm targeting WM
2003 SE, WM 5 and WM 6).

2) Should I create a custom Setup.exe that houses all three .cab files and
automatically chooses which one to install at runtime, depending on the
user's system?

3) Should I just create a WM 2003 SE version and distribute that? If so,
i) Is that safe? Is this what other people are doing?
ii) Are there any potential/specific issues with cross-compatibility that
I should watch out for?
iii) Is it good enough just to recompile and run the unit tests for each
O/S, or is there a specific set of extra tests I should be doing in this case.
iv) Are there any performance or visual differences between running a WM
2003/5/6 app on a WM 5/6 device?

....By the way, this is for a native C++ application, using ATL and a GUI
(I'd prefer to stay away from .NET for the setup).

It seems as though I should go with number 3, but then I start to wonder if
that's the best way to go about it. I wouldn't mind making a specialized
setup, as in number 2, if it means that the product performs and/or looks
better on my customer's devices.

As far as I can tell, most of the functions work on both all of the above
platforms. But I did notice a change in my Settings App: my dialog sizes
itself differently between the WM 2003 SE and WM 5 compiles.

It's actually a dialog window over a tab group. Both ran on a WM 5 device.
I'm not sure if that has to do with the ORIENTATION_AWARE define. I didn't
use the pre-generated ATL stuff for my project... could that be an issue?

Other than that, SecureZeroMemory() isn't supported on WM 2003 SE.

To sum up, I'm still pretty new at this. I was wondering if there's some
common/conventional wisdom about how to deploy to multiple O/S's?

If anyone would be so kind as to share your experiences about this, it would
be very much appreciated.

Thank you very much,
Chris Writely

Archived from group: microsoft>public>pocketpc>developer

James · Joined: 23 Jan 2008 Posts: 12

Hello Chris,
Question: When 2003SE was out, was there not more then one cpu, (arm, mips,
etc), supported? From a customer point of view seeing an app that is for
2003SE might not be so appealing. Over the last 2 years a lot of WM phones
have been sold... if you can I would stick to 5 and above.

If you can reliably tell the users OS I think that might be better as some
users might know. Look for "User Agent" when a browser first connects as
this tag has the info needed
(eg. User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022). )

"Chris Writely" wrote in message @microsoft.com...
> Hi,
>
> I was wondering what everyone's general practice was for
> packaging/distributing applications to multiple platforms? I should
> clarify
> that...
>
> I'm currently working on the setup for my application. I have a cabinet
> file
> being built, and a simple Windows-based Setup.exe to go with it (currently
> made with EzSetup [side-question: is there anything better?]).
>
> But making the .cab/Setup.exe brings up a bunch of questions about how to
> package and distribute my application. Namely:
>
> 1) Should I be building one cab/setup.exe per supported platform and ask
> the
> user to choose their O/S before downloading? (In this case, I'm targeting
> WM
> 2003 SE, WM 5 and WM 6).
>
> 2) Should I create a custom Setup.exe that houses all three .cab files and
> automatically chooses which one to install at runtime, depending on the
> user's system?
>
> 3) Should I just create a WM 2003 SE version and distribute that? If so,
> i) Is that safe? Is this what other people are doing?
> ii) Are there any potential/specific issues with cross-compatibility that
> I should watch out for?
> iii) Is it good enough just to recompile and run the unit tests for each
> O/S, or is there a specific set of extra tests I should be doing in this
> case.
> iv) Are there any performance or visual differences between running a WM
> 2003/5/6 app on a WM 5/6 device?
>
> ...By the way, this is for a native C++ application, using ATL and a GUI
> (I'd prefer to stay away from .NET for the setup).
>
> It seems as though I should go with number 3, but then I start to wonder
> if
> that's the best way to go about it. I wouldn't mind making a specialized
> setup, as in number 2, if it means that the product performs and/or looks
> better on my customer's devices.
>
> As far as I can tell, most of the functions work on both all of the above
> platforms. But I did notice a change in my Settings App: my dialog sizes
> itself differently between the WM 2003 SE and WM 5 compiles.
>
> It's actually a dialog window over a tab group. Both ran on a WM 5 device.
> I'm not sure if that has to do with the ORIENTATION_AWARE define. I didn't
> use the pre-generated ATL stuff for my project... could that be an issue?
>
> Other than that, SecureZeroMemory() isn't supported on WM 2003 SE.
>
> To sum up, I'm still pretty new at this. I was wondering if there's some
> common/conventional wisdom about how to deploy to multiple O/S's?
>
> If anyone would be so kind as to share your experiences about this, it
> would
> be very much appreciated.
>
> Thank you very much,
> Chris Writely

Chris Writely · Joined: 05 Dec 2007 Posts: 9

Hi James,

"James" wrote:

> Hello Chris,
> Question: When 2003SE was out, was there not more then one cpu, (arm, mips,
> etc), supported? From a customer point of view seeing an app that is for
> 2003SE might not be so appealing. Over the last 2 years a lot of WM phones
> have been sold... if you can I would stick to 5 and above.
>

Actually, I just posted a topic on this same question about two days ago. Smile

As it turns out, from WM 2003 and up, all WM devices have been standardized
and use ARM processors.

See my post titled "Do we need to build for MIPS, SH for WM 2003+?" for more
details. There's lots of great responses in there.

> If you can reliably tell the users OS I think that might be better as some
> users might know. Look for "User Agent" when a browser first connects as
> this tag has the info needed
> (eg. User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
> 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022). )
>

Thanks for your response. This would work but, at least for the time-being,
I think most of the people who download my application will be browsing from
their desktops. So this would only work part of the time.

It's a good idea for the .mobi site though.

Thanks,
Chris Writely

>
>
> "Chris Writely" wrote in message
> @microsoft.com...
> > Hi,
> >
> > I was wondering what everyone's general practice was for
> > packaging/distributing applications to multiple platforms? I should
> > clarify
> > that...
> >
> > I'm currently working on the setup for my application. I have a cabinet
> > file
> > being built, and a simple Windows-based Setup.exe to go with it (currently
> > made with EzSetup [side-question: is there anything better?]).
> >
> > But making the .cab/Setup.exe brings up a bunch of questions about how to
> > package and distribute my application. Namely:
> >
> > 1) Should I be building one cab/setup.exe per supported platform and ask
> > the
> > user to choose their O/S before downloading? (In this case, I'm targeting
> > WM
> > 2003 SE, WM 5 and WM 6).
> >
> > 2) Should I create a custom Setup.exe that houses all three .cab files and
> > automatically chooses which one to install at runtime, depending on the
> > user's system?
> >
> > 3) Should I just create a WM 2003 SE version and distribute that? If so,
> > i) Is that safe? Is this what other people are doing?
> > ii) Are there any potential/specific issues with cross-compatibility that
> > I should watch out for?
> > iii) Is it good enough just to recompile and run the unit tests for each
> > O/S, or is there a specific set of extra tests I should be doing in this
> > case.
> > iv) Are there any performance or visual differences between running a WM
> > 2003/5/6 app on a WM 5/6 device?
> >
> > ...By the way, this is for a native C++ application, using ATL and a GUI
> > (I'd prefer to stay away from .NET for the setup).
> >
> > It seems as though I should go with number 3, but then I start to wonder
> > if
> > that's the best way to go about it. I wouldn't mind making a specialized
> > setup, as in number 2, if it means that the product performs and/or looks
> > better on my customer's devices.
> >
> > As far as I can tell, most of the functions work on both all of the above
> > platforms. But I did notice a change in my Settings App: my dialog sizes
> > itself differently between the WM 2003 SE and WM 5 compiles.
> >
> > It's actually a dialog window over a tab group. Both ran on a WM 5 device.
> > I'm not sure if that has to do with the ORIENTATION_AWARE define. I didn't
> > use the pre-generated ATL stuff for my project... could that be an issue?
> >
> > Other than that, SecureZeroMemory() isn't supported on WM 2003 SE.
> >
> > To sum up, I'm still pretty new at this. I was wondering if there's some
> > common/conventional wisdom about how to deploy to multiple O/S's?
> >
> > If anyone would be so kind as to share your experiences about this, it
> > would
> > be very much appreciated.
> >
> > Thank you very much,
> > Chris Writely
>

r_z_aret · Joined: 15 Aug 2007 Posts: 2774

On Tue, 26 Feb 2008 19:33:01 -0800, Chris Writely
wrote:

>Hi,
>
>I was wondering what everyone's general practice was for
>packaging/distributing applications to multiple platforms? I should clarify
>that...
>
>I'm currently working on the setup for my application. I have a cabinet file
>being built, and a simple Windows-based Setup.exe to go with it (currently
>made with EzSetup [side-question: is there anything better?]).
>
>But making the .cab/Setup.exe brings up a bunch of questions about how to
>package and distribute my application. Namely:
>
>1) Should I be building one cab/setup.exe per supported platform and ask the
>user to choose their O/S before downloading? (In this case, I'm targeting WM
>2003 SE, WM 5 and WM 6).

Asking users to make such a choice is asking for trouble; they
shouldn't need to know about CPU type, platform, etc. and many really
don't. Part of a developers' job is to shield users from such choices,
unless the only solutions are unreliable. In this case, they are not.

(Note on possible inconsistency in my attitude: One of my pet peeves
is the tendency to half hide details in a vain attempt to protect
users from details. All too often, the result hides ways to fix
problems that show up because users were not given enough info. So I'm
a bit surprised by how adamant I am in the previous paragraph. But I
think the details in this case can be hidden safely and thoroughly,
without much trouble for developers.)

You can support only one platform per CAB. You should have one setup
per program, and that setup should choose the appropriate CAB.

>
>2) Should I create a custom Setup.exe that houses all three .cab files and
>automatically chooses which one to install at runtime, depending on the
>user's system?

You should definitely have one setup that "houses" all cabs, and
chooses. I'm not sure it has to be fully custom. That depends on how
easily standard tools (most notably the ini files used to build CABs)
can distinguish among the platforms. In my case. I needed to
distinguish between Pocket PC and "other" (the old HPC and several
industrial devices that don't conform to any of Microsoft's
platforms). I couldn't find any way to make this distinction using the
ini files, so I wrote my own setup that chooses and installs the right
CAB. I think you will have far fewer problems, so you can probably use
a "retail" installer.

>
>3) Should I just create a WM 2003 SE version and distribute that? If so,
> i) Is that safe?

Folks at Microsoft have been very good about making sure newer
versions of the base operating system (Windows CE) support apps built
for older versions. They have been pretty good (with a few notable
exceptions) about making sure newer versions of each platform support
apps built for older versions. So running apps built for older
platforms on newer platforms is pretty safe. If you can make sure you
test new platforms before your users, you should be safe.

> Is this what other people are doing?

I actually build for the original Pocket PC and use that build for all
newer Pocket PC/Classic/Professional platforms. But I'm pretty sure
I'm a small minority.

See threads I mentioned in an earlier post for more details.

> ii) Are there any potential/specific issues with cross-compatibility that
>I should watch out for?

Folks at Microsoft are prone to getting and implementing Good Ideas
that break older apps. Not easily predictable, especially for folks
outside Microsoft.

You must always be aware of compatibility issues. And you will mostly
stick to functions and features that are available on all platforms,
with a few key features supported dynamically; I use LoadLibrary and
GetProcAddress for some. So adopting new features will be slower.

Switching to newer tools (IDE, SDK, ...) is especially tricky, because
they often come with access to features not supported by older
platforms. So you can easily slip in an incompatibility.

Debugging will be more difficult, because IDEs can be fussy about
mismatches between target platform (settings in the IDE) and actual
platform (hardware).

> iii) Is it good enough just to recompile and run the unit tests for each
>O/S, or is there a specific set of extra tests I should be doing in this case.

We really should run full tests, including regression test, on each
supported platform each time we release a new executable. Clearly,
this takes a lot of time, along with money and space for all the test
devices.

When I first started writing apps for Windows CE, I found bugs that
showed on one platform but not others. Just about all turned out to be
bugs in _my_ code that should have showed on all platforms. For the
others, I took a little time twiddling my code so one executable
worked well despite the real differences in platforms (been a long
time, but I think they were timing and/or windows painting issues).
Now that my code has been through several versions of itself and the
platforms, I'm more confident of my code's portability. So I try to
test thoroughly on at least two platforms and spot check on others.

> iv) Are there any performance or visual differences between running a WM
>2003/5/6 app on a WM 5/6 device?

I have no relevant info about performance.

The only visual difference I've noticed is the menus. Newer devices
have two soft keys, so having only two top-level menus makes sense. I
try to conform, but that seems too restrictive for one of my apps.

For a while, I actually built only for HPC Pro, and ran those
executables on all platforms. On Pocket PCs, they ran in "emulation
mode", which meant the Start menu was at the bottom of the screen, and
that definitely made them look different from other apps. When
"emulation mode" stopped working in Pocket PC 2003, I gave up.

>
>...By the way, this is for a native C++ application, using ATL and a GUI

>(I'd prefer to stay away from .NET for the setup).

I use straight C/C++ - (no MFC, .NET, ATL, ...) with my own framework.

>
>It seems as though I should go with number 3, but then I start to wonder if
>that's the best way to go about it. I wouldn't mind making a specialized
>setup, as in number 2, if it means that the product performs and/or looks
>better on my customer's devices.
>
>As far as I can tell, most of the functions work on both all of the above
>platforms. But I did notice a change in my Settings App: my dialog sizes
>itself differently between the WM 2003 SE and WM 5 compiles.

That may well be related to screen resolution. I just spent some time
dealing with symptoms that seem similar, and think I solved them with
a kludge that depends on the ratio between standard font height and
screen resolution.

>
>It's actually a dialog window over a tab group. Both ran on a WM 5 device.
>I'm not sure if that has to do with the ORIENTATION_AWARE define. I didn't
>use the pre-generated ATL stuff for my project... could that be an issue?
>
>Other than that, SecureZeroMemory() isn't supported on WM 2003 SE.
>
>To sum up, I'm still pretty new at this. I was wondering if there's some
>common/conventional wisdom about how to deploy to multiple O/S's?
>
>If anyone would be so kind as to share your experiences about this, it would
>be very much appreciated.
>
>Thank you very much,
>Chris Writely

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

Packaging a Demo in an emulator Hello All, I was wondering if any has any information about packaging a Visual Studio 2008 mobile app in an emulator. In other words I'd like to send to a potential customer an exe file that, once installed, will display a Windows Mobile 6 emulator with

ANN: Patterns & Practices Application Block - CAB Beta 1 Cheers Daniel --

Running apps on PPC from PC I've seen some old references to this or similar questions but don't know the current state of affairs. Given that one has an app copied onto the PPC, is it possible to have it starated up via the connection to a PC? Could that command (if there is one)

Does .NET Framework have to be installed 4 C# Mobile apps? Hello I have hired a programmer to create a mobile application to compliment my website. He has created what I requested but the installation installs the program and then installs .net onto my Windows Mobile 2005. As a user, when I install a program I e

Importing managed DLL in Native Apps Hi All, Is it possible to call a managed DLL (C#) from a native application? I like to do some SOAP access from a native application. Regards, S.Kumar