CF.Next only on WM 2003 and up

  • Thread starter Thread starter www.mobidogs.com
  • Start date Start date
W

www.mobidogs.com

I read a comment during the Chat this afternoon that Version 2 of the
Compact Framework will only run on Windows Mobile 2003 devices or future
versions of the Windows Mobile OS and that it will not run on existing older
PPC 2000 and 2002 devices like the current version of the CF does.

Is this for technical or strategic reasons?

If it is a strategic decision, personally I think it poor one.
 
I assume the reason is technical. The 2003 devices run CE 4.2, which is more
performant than CE 3 which is the basis for PPC2000 and PPC2002.
 
Seems like a shame to rule out millions of devices that would make a great
low end user base of devices simply because they might end up being slower.

Performance doesn't cut it in my books as a technical reason to limit our
target audience even more.

The Palm guys still get a lot of mileage out of claiming the numbers of
devices they have in the market, even though most of them are only a little
more performant that a calculator.
 
on the other hand you could do as many company does.
restrain your development to CF.NET 1 functionalities for a long while
 
My guess is that it's using something introduced in CE 4.2 (which *is* quite
different than 3.0 under the hood) and backward compatibility of 2+ years on
a PDA probably isn't viewed as being worth the work for early OS support.

-Chris
 
As a "Palm guy" and a ".Net guy" I can tell you that Palm has been
impressive in working with their developers to allow for backward
compatibility. They have made it relatively simple to support all OS's from
Palm OS 3.0 up to the latest Cobalt OS using a single SDK. Palm OS devices
are far from calculators. I think both devices have their strong points and
weak points.

Jamie
 
I guess this is certainly worth considering, especially when you take into
account that the carriers all seem very reluctant to allow for easy and
timely upgrades of either the OS or the CF for platforms like the
smartphone.

It just seems a shame that it would mean holding off on both the new
features of the CF and VS, not to mention missing out on the benefit of all
the little fixes to annoying things like how many of the controls do not
expose keystrokes and the like.
 
I agree, I would like to see CF .Net as a single robust development path
that allows us to target the broadest number of CE based devices as
possible. Selling mobile apps is a numbers game and it would be nice to see
better numbers.

My intention was not to knock Palm devices or "Palm guys" with the
calculator performance remark. However, you must admit that there are an
awful lot of low end Palm devices out there that do not have the processing
power of even the oldest Pocket PC or any Mobile Device SmartPhone
available. Those many millions of cheap, old-generation-processor palm
devices (that would not be capable of running even CF v1) certainly make up
a significant part of the claimed user base of Palm.
 
As someone told before, WM 2003 hasn't brought 'much' to the user
experience, but with the new core on a similar shell, the performance on
similar hardware based on XScale is much better than with PPC2002.

I'm sure you don't think that CF shouldn't take this way just because older
hardware won't support it. Besides the comercial side from the companies who
manufacture PDAs, this is what we ask everyday: more, more, more!

Alberto Silva
 
My guess is that it's using something introduced in CE 4.2 (which *is*
quite
different than 3.0 under the hood) and backward compatibility of 2+ years on
a PDA probably isn't viewed as being worth the work for early OS support.
Click to expand...

Chris,

See, I see that as a strategic decision. "isn't viewed as being worth
the work".
Sure, there are limited resources on the mobility dev team (also a strategic
decision in my books), so if the extra work involved to support CE 3.0
(Pocket PC only) were to take up so much time as to cripple the efforts on
CF 2.0 it would then be a resourcing question more than a technical one.
However, they did accomplish the task of supporting CF V1 on CE 3.0 (Pocket
PC only) already, I would expect that CF V2 is an evolution of CF V1 and
would have expected them to build on there previous progress.
 
There are an almost infinite number of good reasons to drop support for old
devices, but the one that jumps out at me is availability of the old
hardware for compatibility testing. Remember that Palm really only has to
have a couple of devices laying around to test with all old versions.
Microsoft manufactured none of the PPC2002 devices itself and, as the number
of second-party manufacturers of Windows CE-based devices increases, the
effort required of MS test guys increases exponentially. This is the right
choice, at this time. You still have the ability to target those old
devices with old tools, but, if you want the latest of everything, the
"everything" has to include the hardware platforms...

Paul T.
 
I'm sure you don't think that CF shouldn't take this way just because
older
hardware won't support it. Besides the comercial side from the companies who
manufacture PDAs, this is what we ask everyday: more, more, more!
Click to expand...

Alberto,

I fully agree. I would not want them to dumb down CF V2 because of
legacy mobile devices. I would have no objection if there were some Windows
Mobile 2003 (and up) only features in CF V2 that degraded nicely when run on
older devices.

And I agree I would not be satisfied if the manufacturers did not keep
raising the bar on making the actual devices better.

It just seems wasteful (both of physical devices and customer base) to make
the millions of devices incompatible with our software development efforts.
From my experience with my own customer base, the people who buy these new
devices (the ones demanding more, more, more!) keep buying them and then
they pass along their older devices to a friend, coleague or relative. This
in turn introduces the next generation of users (and ultimately consumers of
new devices) to the fold. However, if the users are forced out of there
older devices because of a strategic upgrade I don't think this will have
the same positive effect, I think instead the old device will be seen as
junk and tossed in the garbage. (who knows for sure, but that is my take).
 
Aww Comon...
Almost infinite...?

I sort of see your point about testing and diversity, but frankly I don't
think it is really that valid. The compatibility that they should be
testing for is with the OS not the device. If an old device has some weird
quirk so be it. I know they test a lot of hardware when they release a new
version of the desktop OS but I really don't think they track down each and
every PC manufactured for the family of processors that they support for a
given version of Windows before they release. Besides, between a few of us
developers we probably have most of the devices covered with what is sitting
on our desks and in our drawers. ;-) I am sure they have a few MIPs and SH3
PPCs kicking around the Redmond office.

Heck, even then, if the cut off point were 2002 even, that would narrow it
down to ARM only devices but they seem to be choosing to cut out that
audience as well.

Although as a user it frustrates me when my device is out of date within a
few months, I don't see "that" as much the issue here. Most of us have come
to grips with the idea that something "better" or "newer" is just around the
corner when it comes to technology stuff.

What I am concerned with here is the size of the compatible user base of
devices. As a ISV, it pains me when I see MS eliminate millions of devices
as potential customers of a new product when we are already struggling with
a user base that has not yet hit a "critical mass" of sorts.

And as a corporate developer and mobility consultant it pains me again when
I have to explain that all of those 2002 rugged devices the customer just
bought for the mobile solution... well they won't work if we use the new and
best development tools for the job, so we either throw those devices in the
closet or we tie our hands and develop with old and less productive
developer tools. And yes, this sets a trend that end user and corporate
customers alike will start to get gun shy from and will be much more
reluctant to buy our message of "Standard, Compatible Platform" (which is
why I personally focus on Windows development in the first place)

If this is indeed a "choice" for strategic reasons as you seem to imply, I
don't agree with you, I don't think it is the "right" choice at this time.
I think it endangers the confidence of corporate and end users and maybe
more importantly it shows disregard and lack of support for the very
developer community who is trying to support the success of the MS Mobile
Device initiative, which frankly is still playing catch up in both the PPC
and Smartphone spaces.
 
I don't think you're really accounting for the cost of testing on the tons
and tons of devices that are out there. We build hardware and the OS
configurations that run on them and, absolutely, if we come out with a
significant new software product and try to test on every version of every
device, even the relatively small set that we have produced over the last
four or five years, the test time dwarfs the time to actually develop the
application. The result of trying to support every old device out there is
a stifling of innovation and it's that, not a loss of confidence in the
development tools, that affects the growth of the market.

I have nothing but amazement at how much really old stuff Microsoft still
supports. Windows 98? Are you kidding me? At some point, the economics of
things require that you drop support for old devices and old versions of the
OS. When the next set of devices comes out, PPC 2002 will be two revisions
removed from the current and PPC 2000 will be three revs out of date. I'm
personally satisfied that that many revisions is far enough out of date that
it's OK to drop support with the latest dev. tools at that point.

Obviously, I don't represent MS in any way, shape, or form, but I understand
that decision at this point in time.

Paul T.
 
We are also an OEM, and from a testing and support standpoint, supporting
the old OSes is a nightmare. We've drawn lines on our products, where
certain hardware just isn't supported above 4.1, and other hardware isn't
supported below 4.2. Could we make it work? Sure, but the cost involved
doesn't make sense. If someone comes to us and says they have old hardware
and it must have the new OS, *and* they're willing to pay for the port and
testing, then sure, we'll do it.

Microsoft made the decision with PPC to support a single processor
architecture for this reason - testing was out of control. Now expecting
them to take a new CF and test it on a platform that hasn't event been
tested on a processor core is unrealistic. So that kills any support other
than ARM. Of course customers won't understand that, so the next logical
step is to not support PPC 2000.

Well then you still have to support CE 3.0 and 4.2, which again are quite
dissimilar. That immediately doubles your test requirement. Couple that
with the fact that many PPC02 devices have a flashable OS, so say 75% can be
easily upgraded to PPC 03. You now have higher costs, for an even smaller
market slice.

Now look at the thought that the PPC itself is targeted more at enterprise
users. These users typically have newer hardware because they cycle their
inventories quicker (I've got PPC SW customers that are lucky to get 6
months of service out of a device before it's destroyed).

From a business perspective, you really get into a diminishing return
situation by trying to maintain backward compatibility. Any decision other
than full support for eternity is going to piss someone off, the key is to
bring the support cutoff time to a reasonable level where you're not just
burning resources for limited return.

I'm quite sure Microsoft studied the break even points on this before making
the support decision and the support they announced is based on that.

--
Chris Tacke, eMVP
Co-Founder and Advisory Board Member
www.OpenNETCF.org
---
Windows CE Product Manager
Applied Data Systems
www.applieddata.net


Paul G. Tobey said:
I don't think you're really accounting for the cost of testing on the tons
and tons of devices that are out there. We build hardware and the OS
configurations that run on them and, absolutely, if we come out with a
significant new software product and try to test on every version of every
device, even the relatively small set that we have produced over the last
four or five years, the test time dwarfs the time to actually develop the
application. The result of trying to support every old device out there is
a stifling of innovation and it's that, not a loss of confidence in the
development tools, that affects the growth of the market.

I have nothing but amazement at how much really old stuff Microsoft still
supports. Windows 98? Are you kidding me? At some point, the economics of
things require that you drop support for old devices and old versions of the
OS. When the next set of devices comes out, PPC 2002 will be two revisions
removed from the current and PPC 2000 will be three revs out of date. I'm
personally satisfied that that many revisions is far enough out of date that
it's OK to drop support with the latest dev. tools at that point.

Obviously, I don't represent MS in any way, shape, or form, but I understand
that decision at this point in time.

Paul T.

www.mobidogs.com said:
Aww Comon...
Almost infinite...?

I sort of see your point about testing and diversity, but frankly I don't
think it is really that valid. The compatibility that they should be
testing for is with the OS not the device. If an old device has some weird
quirk so be it. I know they test a lot of hardware when they release a new
version of the desktop OS but I really don't think they track down each and
every PC manufactured for the family of processors that they support for a
given version of Windows before they release. Besides, between a few of us
developers we probably have most of the devices covered with what is sitting
on our desks and in our drawers. ;-) I am sure they have a few MIPs and SH3
PPCs kicking around the Redmond office.

Heck, even then, if the cut off point were 2002 even, that would narrow it
down to ARM only devices but they seem to be choosing to cut out that
audience as well.

Although as a user it frustrates me when my device is out of date within a
few months, I don't see "that" as much the issue here. Most of us have come
to grips with the idea that something "better" or "newer" is just around the
corner when it comes to technology stuff.

What I am concerned with here is the size of the compatible user base of
devices. As a ISV, it pains me when I see MS eliminate millions of devices
as potential customers of a new product when we are already struggling with
a user base that has not yet hit a "critical mass" of sorts.

And as a corporate developer and mobility consultant it pains me again when
I have to explain that all of those 2002 rugged devices the customer just
bought for the mobile solution... well they won't work if we use the new and
best development tools for the job, so we either throw those devices in the
closet or we tie our hands and develop with old and less productive
developer tools. And yes, this sets a trend that end user and corporate
customers alike will start to get gun shy from and will be much more
reluctant to buy our message of "Standard, Compatible Platform" (which is
why I personally focus on Windows development in the first place)

If this is indeed a "choice" for strategic reasons as you seem to imply, I
don't agree with you, I don't think it is the "right" choice at this time.
I think it endangers the confidence of corporate and end users and maybe
more importantly it shows disregard and lack of support for the very
developer community who is trying to support the success of the MS Mobile
Device initiative, which frankly is still playing catch up in both the PPC
and Smartphone spaces.

for
old
Click to expand...
has
to efforts
Click to expand...
make
a
Click to expand...
only
a
Click to expand...
Click to expand...
 
The more I think about this and consider some of the responses of others the
more it bugs me.



So let me approach it from a slightly different point of view...



What is the basic premise of the .Net Framework? (and in turn the Compact
Framework)

Is it not intended to be a common development platform that abstracts us
away from the specifics of a particular version of the OS and makes for a
more standardized way to develop and deploy to an every growing number of
machines, devices, OSs etc.. in a less language dependant manner?



Some talk has been made about "why not make a CLR for Palm devices"... and
frankly I see both of the fairly strong arguments there.. 1) many of the
Palm devices don't have the horsepower to support a decent implementation of
CF, and 2) it is of questionable strategic value for Microsoft to support
such an initiative (after all they have enough on there plate trying to
succeed in the CE device space).



However, that same idea takes on a much more significant meaning when you
look at the devices within the CE space. We are not talking about
supporting the CE 4 family of Operation System on the older devices... we
are not even talking about supporting Windows Mobile 2003 or .Next user
shells (sorry "platforms") on these devices. We are simply talking about
supporting the common .Net development platform that Microsoft is betting
the farm on and that we are all (or most) buying into, on a generation of
devices that has already seen and supported a version of this "development
platform" already.



Isn't it kind of early to already be dropping support for .Net Framework (CF
or otherwise) when the promise and the focus of the .Net Framework message
has been about the spread of the support for .Net Framework? If Microsoft
is unwilling to support it on their own family of products for more than one
generation, what is this saying to the rest of us and to our customers?



I starting by asking is it a "strategic" or "technical" decision and the
more I think about it the less I can see how it would indeed be a
"technical" one since the framework is in fact an abstraction layer. Fine,
there might be individual things (maybe even a bunch of them) that get added
to version 2 that are technically difficult or impossible to support on
older OS's or platforms, however as an abstraction layer it shouldn't be
that technically challenging to not support those features if the device or
OS does not support them.



One point that I haven't heard stressed much yet is the limited footprint
for CF and I could see some of the dev team arguing that it might be
technically too challenging to fit support for both generations into the
allotted footprint if some fundamental low level stuff were leveraged from
the CE 4 generation of OS. If that is the case so be it.. however I think
strategically that the decision to drop .Net Framework support for millions
of devices at this early stage in the history of the .Net Framework is a
significant one, that may speak louder than the praises of the .Net
Framework message itself.
 
Paul, Chris,

Sorry I was busy typing in a different/new branch to this thread which I
think expresses my concerns in a different way that may (or may not) clarify
where I am coming from on this.

Please don't get me wrong, I too believe in a "drawing a line in the sand"
approach and I too understand that there are many practical tradeoffs that
need to be considered for this type of decision to drop support for
something. I don't mean to come across as one of those "I want it all and I
want it now" types (although I admit I really am). ;-)

Please take a look the Spirit of .Net Framework branch that I just posted
which talks more about how CF is a developer platform and an abstraction
layer. I really believe there is more to this than just the issue of "out
with the old and in with the new".

Chris Tacke said:
We are also an OEM, and from a testing and support standpoint, supporting
the old OSes is a nightmare. We've drawn lines on our products, where
certain hardware just isn't supported above 4.1, and other hardware isn't
supported below 4.2. Could we make it work? Sure, but the cost involved
doesn't make sense. If someone comes to us and says they have old hardware
and it must have the new OS, *and* they're willing to pay for the port and
testing, then sure, we'll do it.

Microsoft made the decision with PPC to support a single processor
architecture for this reason - testing was out of control. Now expecting
them to take a new CF and test it on a platform that hasn't event been
tested on a processor core is unrealistic. So that kills any support other
than ARM. Of course customers won't understand that, so the next logical
step is to not support PPC 2000.

Well then you still have to support CE 3.0 and 4.2, which again are quite
dissimilar. That immediately doubles your test requirement. Couple that
with the fact that many PPC02 devices have a flashable OS, so say 75% can be
easily upgraded to PPC 03. You now have higher costs, for an even smaller
market slice.

Now look at the thought that the PPC itself is targeted more at enterprise
users. These users typically have newer hardware because they cycle their
inventories quicker (I've got PPC SW customers that are lucky to get 6
months of service out of a device before it's destroyed).

From a business perspective, you really get into a diminishing return
situation by trying to maintain backward compatibility. Any decision other
than full support for eternity is going to piss someone off, the key is to
bring the support cutoff time to a reasonable level where you're not just
burning resources for limited return.

I'm quite sure Microsoft studied the break even points on this before making
the support decision and the support they announced is based on that.

--
Chris Tacke, eMVP
Co-Founder and Advisory Board Member
www.OpenNETCF.org
---
Windows CE Product Manager
Applied Data Systems
www.applieddata.net


Paul G. Tobey said:
I don't think you're really accounting for the cost of testing on the tons
and tons of devices that are out there. We build hardware and the OS
configurations that run on them and, absolutely, if we come out with a
significant new software product and try to test on every version of every
device, even the relatively small set that we have produced over the last
four or five years, the test time dwarfs the time to actually develop the
application. The result of trying to support every old device out there is
a stifling of innovation and it's that, not a loss of confidence in the
development tools, that affects the growth of the market.

I have nothing but amazement at how much really old stuff Microsoft still
supports. Windows 98? Are you kidding me? At some point, the
Click to expand...
economics
of
things require that you drop support for old devices and old versions of the
OS. When the next set of devices comes out, PPC 2002 will be two revisions
removed from the current and PPC 2000 will be three revs out of date. I'm
personally satisfied that that many revisions is far enough out of date that
it's OK to drop support with the latest dev. tools at that point.

Obviously, I don't represent MS in any way, shape, or form, but I understand
that decision at this point in time.

Paul T.

a
new each
and
Click to expand...
for
a
Click to expand...
of
us and
SH3
Click to expand...
narrow
it
Click to expand...
within
a have
come around
the new
and in
the
Click to expand...
imply,
Click to expand...
 
Well I certainly don't know, but here are some things that you may not have
considered:

CFv2 will have more low-level stuff than the version we have now including
more sophisticated marshalling and support for COM interop. Although we work
at a layer than abstracts away the OS when we use .NetCF, the guys at
Microsoft who are writing the CF core runtime certainly don't have that
luxury. If somebody at Microsoft asked me if I'd rather have more features
wrapped inside the CF for version2 or have the CFv2 support more legacy
versions but fewer new features, I'd certainly vote for more features and
especially since I already have CFv1 and VS 2003 which won't suddently stop
working as soon as I install VS 2005. Similarly, VS 2005 will allow me to
develop for CE devices in C++ if I want to, but I still have eVC++ 3 for
older versions of CE if I want to continue to support those (and I do and
will actually).

I guess I should turn the question around and ask you which features planned
for CFv2 you'd rather not have if you could have support for older versions
of CE instead?
 
Ginny,

I need to catch up on the details of what new features are actually in the
CFv2 mix.

I agree that the MS team would need to connect the abstraction layer to the
OS in question and that if some of the underlying support they expect for v2
is not there in the give OS it would be difficult. In cases like that I
would much rather they said that particular feature will not be implemented
on any pre2003 devices and still have the core functionality (v1 stuff and
less problematic v2 stuff) in the v2 version so that we could all move
forward on a standardized platform and the same set of tools. That may not
be practical, I don't know the details. Agreed it may require more resources
and this is a Strategic issue/opportunity that Microsoft has to position
themselves on. I don't think anyone would argue that if it were important
to MS and their go forward strategy that they couldn't afford to put the
resources to it to make it happen.

I guess I am saying this seems like an important enough issue to the
potential success and future of our Mobile Device platform that I think it
is worth discussing and thinking about. No doubt there are people at MS
that have done so. I am wondering if enough thought and discussion went
into it and if it wouldn't hurt for us to provide them some more feedback on
the issue.
(Grant it, I have only seen a dribble of support for my concern so far in
this thread).

As for your question of what would I rather give up... as I mentioned I am
not up on the entire CFv2 list and which items fall into that trade off
category but I will say that I would be able to accept COM interop only
working in 2003 and forward if that were in fact a potential trade-off
(although I doubt it as the Odyssey guys seem to have a simple solution that
works on CE 3). I would like to hear examples of features from MS that
would be have to be cut in order to support compatibility with existing CF1
generation devices but I doubt they have time for that.

I think you raise a valid point with the turning around of the question but
I don't see it as a strong enough argument to say "fine... forget about the
millions of devices out there already" when we are desperately trying to
build a base. No more so than saying ... should we give up the Pocket PC
form factor all together in order to put more features into a better CFv2
for Smartphone.

Sorry, I seem to be ranting a lot today ;-) I'll try and stop now.
 
Rant away. <g> Seriously, well presented positions are always interesting -
to me anyway and I think also to Microsoft.
 
Back
Top