[Q] Your hands-on experiences with moving from EVC (C++) to .NET (C#) for mobile application develop

[Gabe]

Hi,

I am currently contemplating moving from EVC (C++) to .NET (C#) for
(large) mobile application development. I have a lot of experience
with EVC and C++ in general, but no experience with the Compact .NET
platform on Windows CE aka Windows Mobile.

What I am looking for is general thoughts on sticking with EVC (C++)
vs. moving up to .NET (C#), suggestions, warnings, pointers to
relevant documents and discussions. For example: how is CPU- and
database-bound app performance in Compact .NET? Any major
"limitations" to watch out for in desktop .NET vs Compact .NET?
Installation or deployment problems that should be carefully
considered? Success stories? How is the new .NET form paradigm working
out for you?

I guess my question is a little bit too broad, but I am looking for
any hands-on information from other developers out there. I think it
will tell me way more than reading dry, optimistic documentation.

Thanks!

Gabe

 

[Paul G. Tobey [eMVP]]

What's driving your thinking about changing? That will help narrow down the
responses a lot.

Paul T.

 

[jaybo_nomad]

When the Framework was Compacted, emphasis seems to have been given to
business style applications over graphically oriented applications.

The most obvious example of this is the Pen class, which only allows
creation of single pixel width pens with no style attributes. WHAT WERE
THEY THINKING?

On the other hand, if you're doing web services, databases, or applications
requiring only single width pens, you're all set with CF. VS.Net 2003 makes
the development cycle pretty easy (compiles are instantaneous, but
downloading to the device can take a few seconds). Anecdotally, I've heard
CF C# performance penalties run around 10 to 20% vs. straight C++.

For my own mostly graphical application, after spending the last few weeks
prototyping with C#/CF, I've pretty much given up and will stay with C++.
If I wasn't mostly doing graphics, the answer probably would have been
different.

Other links:

http://www.msdnaa.com/Resources/display.aspx?ResID=2088
http://www.troobloo.com/tech/dotnet.41.shtml

 

[Hollywood]

Anecdotally, I've heard

CF C# performance penalties run around 10 to 20% vs. straight C++.

Enough so that I'm considering going to C++ development for even lightweight
business applications because the performance is so poor. Even bringing up
a mainmenu item can cause the CPU utilization to skyrocket even under SP1
[Dell Axim X5, PPC2002, SP1]! And thats on a simple test app that displays
one label, and File->Open menu items.

 

[Gabe]

On Fri, 17 Oct 2003 13:22:18 -0700, "Paul G. Tobey [eMVP]"

Paul,

Thanks for the reply.

What's driving your thinking about changing? That will help narrow down the
responses a lot.

Good question, I should have thought of that. What I hope to get out
of the transition is as follows (in order of importance):

1.) A big break when it comes to writing cross-platform
(desktop/PPC2002/PPC2003/SmartPhones) code. Developing large apps in
EVC/C++/MFC/pure Win32 turned out to be a nightmare. Subtle
differences across the platforms when it comes to message handling,
resource file formats, custom draw capabilities, SIP handling, bugs,
etc. caused me to write tons of #defines to get something to work, and
forced almost unbearable amount of testing on each device in question.
Things that work on Dell PPC2003, might not work 100% the same on HP
device. I hope that since .NET and C# are a re-write (in a sense) of
MFC/Win32, code will be more uniform across all platforms.

2.) I like the features and the methodology of the new C# language
over C++. Anyone who has spent a week hunting for that ONE DAMN
MEMSET() will know what I mean. Reflection, multiple-inheritance
elimination and XML stuff are a very nice plus.

3.) Simplification of internationalization and deployment through
assemblies.

4.) Easier accommodation for runtime plugins though assemblies,
instead of dealing with that obscure COM and COM+ stuff, to allow C
and VB guys to write sub-components.

5.) Finally, it seems to me that since Microsoft is investing all its
resources in the new .NET platform, sooner or later plain C++ for
Windows apps will be obsolete. I think it is notorious of Microsoft
to, over time, pretty much drop anything that is not current "focal"
development technology. .NET seems to be it at the moment.

What do you think?

Gabe

 

[P.J. Plauger]

5.) Finally, it seems to me that since Microsoft is investing all its
resources in the new .NET platform, sooner or later plain C++ for
Windows apps will be obsolete. I think it is notorious of Microsoft
to, over time, pretty much drop anything that is not current "focal"
development technology. .NET seems to be it at the moment.

What do you think?

I think you're shooting from the hip. You leap from a false presumption
(Microsoft is investing all its resources in the new .NET platform),
through a presumption that you can predict what this implies (it seems
to me), to an unlikely conclusion (plain C++ for Windows apps will be
obsolete) with a time scale (sooner or later) that's so vague as to
be worthless for planning. You then characterize Microsoft's behavior
as 'notorious' for stimulating your little fantasy.

There are damn good reasons for switching to .NET, and you cited some
(in the commentary I dropped). But I have ample reason to believe that
Microsoft will be supporting and enhancing one of the best implementations
of C++ available for years to come. The good news is that you'll still be
able to code part or all of your application in C++ even if you do switch
to .NET. So your questionable logic is unimportant.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Gabe]

Thanks for your reply.

I think you're shooting from the hip. You leap from a false presumption
(Microsoft is investing all its resources in the new .NET platform),
through a presumption that you can predict what this implies (it seems
to me), to an unlikely conclusion (plain C++ for Windows apps will be
obsolete) with a time scale (sooner or later) that's so vague as to
be worthless for planning. You then characterize Microsoft's behavior
as 'notorious' for stimulating your little fantasy.

There are damn good reasons for switching to .NET, and you cited some
(in the commentary I dropped). But I have ample reason to believe that
Microsoft will be supporting and enhancing one of the best implementations
of C++ available for years to come. The good news is that you'll still be
able to code part or all of your application in C++ even if you do switch
to .NET. So your questionable logic is unimportant.

I am entirely puzzled why you would join a thread, quote only the
least important of my points, go on a small rant about my "fantasies"
and "questionable logic", and finally fail to contribute anything even
remotely productive to the core topic of the discussion.

Having a bad hair day, perhaps, Mr. P.J.? Just kidding.

At any rate, in the context of at least mobile devices, I do believe
that Microsoft indeed displays a tendency to swiftly move from one
technology to the next (I actually think it's one of their strengths),
but I can offer little "tangible" explanation, since I am not a
Microsoft insider.

Yet, generally speaking:

In terms of application development tools, Windows CE 2.x began with
Win32/ATL and minimal support for MFC. As soon as 3.0 arrived, the
focus switched from Win32/ATL to MFC. With 4.x, .NET is clearly
getting the most attention, with mostly bug fixes for MFC in Windows
Mobile 2003 (and boy, is there still a question of Windows CE MFC
completeness, or what?). The new Smartphone "1.0", however, dropped
MFC altogether, yet the word is that the upcoming SmartPhone "2.0"
version will include .NET framework in ROM.

In terms of database technology, Windows CE 2.x began with the native
Object Store, and minimal support for anything else. As soon as 3.0
arrived, the focus switched from the Object Store to Pocket Access
over COM (actually, Pocket Access *is* the Object Store, but that's a
different story), with little improvement to the Object Store. With
4.x and .NET, Pocket Access is officially "unsupported", you have to
get a third-party COM wrapper to even use it from C#. SQL Server
Mobile is the name of the game.

In terms of mobile device hardware, Windows CE 2.x began with
Palm-sized PCs, Handheld PCs, and Handheld PC Pros. As soon as 3.0
arrived, PalmPCs won the game (renamed to Pocket PCs), Handheld PC
Pros were entirely dropped, and Handheld PCs barely survived with only
one o/s update - HPC 2000 (with only partial SDK available, anyway).
With 4.x, despite NEC (and others) still manufacturing and selling
HPC-factor devices, HPC2000 platform has been retired altogether even
from www.pocketpc.com website.

And so on, and so on. But, again, it is only MHO that often
Microsoft's top R&D dollar goes into "flagship" technology, at the
clear expense of other products. The "wave", at the moment, seems to
be the .NET platform, but I am not forcing anyone to believe me. I
just cannot help but wonder at how much money must have gone into
developing and marketing the .NET framework, versus, say, Visual C++
7.0, and MFC 7.0.

I'm not arguing against C++'s longevity. I love the language, and
agree it is and will be the best tool for certain applications for a
very long time. Yet, IMHO, Microsoft's all-out commitment in the .NET
platform is... very hard to miss.

Gabe

 

[Gabe]

Anecdotally, I've heard
CF C# performance penalties run around 10 to 20% vs. straight C++.

Enough so that I'm considering going to C++ development for even lightweight
business applications because the performance is so poor. Even bringing up
a mainmenu item can cause the CPU utilization to skyrocket even under SP1
[Dell Axim X5, PPC2002, SP1]! And thats on a simple test app that displays
one label, and File->Open menu items.

Thanks for input! Good point about the graphical capabilities, I will
have to make sure to look into this.

About performance: that's bad news... How about working with databases
(basic queries) or GUI controls (like a basic 1000 record list view)?

I guess I should just get to work and write some samples instead of
bugging everyone .

Gabe

 

[P.J. Plauger]

Thanks for your reply.


I am entirely puzzled why you would join a thread, quote only the
least important of my points, go on a small rant about my "fantasies"
and "questionable logic", and finally fail to contribute anything even
remotely productive to the core topic of the discussion.

Having a bad hair day, perhaps, Mr. P.J.? Just kidding.

No you're not. You're indulging in a weasely practice called quoting.
It lets you say obnoxious things without taking responsibility for
them.

And I'm actually having quite a nice day, on vacation in Maui. I just
got a little pissed off by your uninformed syllogisms and your
gratuitous slur. Carry on.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Gabe]

No you're not. You're indulging in a weasely practice called quoting.
It lets you say obnoxious things without taking responsibility for
them.

And I'm actually having quite a nice day, on vacation in Maui. I just
got a little pissed off by your uninformed syllogisms and your
gratuitous slur. Carry on.

<BEGIN The Twilight Zone tune>

What in the name of... ?

"Shooting from the hip", "leap from a false presumption", "presumption
that you can predict what this implies", "stimulating your little
fantasy", "your questionable logic", "weasely practice called
quoting", "say obnoxious things", "without taking responsibility",
"uninformed syllogisms", "gratuitous slur".

I had no idea that I would offend anyone, and yes, I was kidding, we
all have our "overload days". Nevertheless, I apologize. Also, since I
feel like I just lost touch with what is going on here, let's don't
continue this thread, please. Have a great vacation.

<END The Twilight Zone tune>

Gabe

 

[Dennis]

Having lurked through the evolution of this thread, I have to say I have
seldom read anyone here who writes and thinks as clearly as Gabe. It seems
obvious from what he's written that he has had a lot of experience
developing software for handhelds. I personally happen to agree with him
about how Microsoft promotes one technology as the "next big thing" only to
drop it after awhile and promote the "next big thing". As a desktop
programmer, I've been annoyed over the years as C has changed to C++ to MFC
to Object Linking and Embedding to COM to .NET and C#. On the other hand,
I've realized that the level of abstraction and the power of the tools has
increased as well. I've often wondered, though, why I need a kit to build
a Maserati when the old Volkswagen kit would do just fine - I only need to
get to the corner store, after all.

But all that's not really why I'm writing this. I want to say that P.J.
Plauger's responses to Gabe have been inexplicably nasty in their tone. The
contrast between the clarity of Gabe's questions and the experience implied
by them and the cutting, biting responses from P.J. Plauger remind me a lot
of a few programmers I've met over the years. And here I am referring to
Plauger, not Gabe. These folks have been bright but they've worn their
professional egos on their sleeve and they will reflexively try to put down
anyone who comes into their area that might seem to be more knowledgeable
than themselves. Pissy primadonas I suppose one might call them.

Gabe, I just wanted you to know that you were not the only one surprised and
annoyed by Plauger's responses to what I thought were reasonable and well
put questions.

Plauger, I think you should stay in Maui. Don't call us - we'll call you,
eh?

 

[P.J. Plauger]

But all that's not really why I'm writing this. I want to say that P.J.
Plauger's responses to Gabe have been inexplicably nasty in their tone. The
contrast between the clarity of Gabe's questions and the experience implied
by them and the cutting, biting responses from P.J. Plauger remind me a lot
of a few programmers I've met over the years. And here I am referring to
Plauger, not Gabe. These folks have been bright but they've worn their
professional egos on their sleeve and they will reflexively try to put down
anyone who comes into their area that might seem to be more knowledgeable
than themselves. Pissy primadonas I suppose one might call them.

If that's the way I came across, then I offer you my sincerest apologies.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Steve Maillet \(eMVP\)]

You're missing some information and definitely have a bias here. (From what;
I won't speculate)

With Windows CE V2.0 Both ATL and MFC were available and were used in many
applications. A version of VB was also available
Both ATL and MFC are still available today as of V4.2. That version of VB is
still supported under Pocket PC devices. due to the large number of
developer complaints and issues with the fundamental architecture of that
(Basically an extended VBScript) MS chose to drop it entirely in favor of
VB.net and the CF.

Other than the one case of VB ( and that with good reason) they have NOT
dropped anything in the way of the tools or technologies. (The Object Store
is still there and usable, although it's not a particularly good place to
put much info as it is so limited). Just because marketing pushes for
whatever is new doesn't mean that everything else is no longer available.
Microsoft got to where it is by supporting backward compatibility and they
take that seriously. (I can still run DOS applications on Windows XP!) They
can't guarantee that everything will always be 100% backward compatible but
dropping or breaking features is no small matter and must be reviewed and
challenged multiple times before it occurs. (Obviously the accidental break
could occur but that's a bug!)

So, while PJ's comments here could have been phrased better, the idea behind
them still remains valid and tie directly to why Paul asked what are you
expecting to gain.

The .NET CF is an extended subset of the desktop. You will have a number of
differences and incompatibilities between the 2 much like you do for MFC. In
fact there is a reasonable parallel with those 2 technologies. (assuming you
ignore the C++ exception handling difference, which causes significant
re-writes of desktop code to work on CE devices). It will take about the
same amount of effort as ultimately it all rests upon what is or isn't
available in the underlying Win32 APIs and what can FIT in a limited device
scenario.

Performance is difficult to say. Generally benchmarks are only meaningful to
marketing (e.g. "Your actual mileage will vary") and depend greatly on what
your app is doing and the hardware it will run on.

Generally I'd say you need a REALLY good reason to convert an entire
existing application from one to the other as that is effectively starting
over from scratch. You need to weigh the cost of that effort against the
cost of maintaining/updating the existing code base. There is no hard answer
that applies to everyone on that.

 

[Gabe]

On Sun, 19 Oct 2003 11:20:55 -0400, "Steve Maillet \(eMVP\)"

Steve,

Reading your post I finally realize that I have phrased my point (5.)
rather poorly, and that's where the trouble might be coming from. The
"obsolete" was too strong a word, and probably implied that I think
Microsoft will not be supporting existing development technologies at
all. I agree that Microsoft takes supporting backward compatibility
seriously, and I find comfort in knowing I can always fall back on C++
even when using the .NET framework. Also, I should have mentioned that
I do not look to migrate an existing application from C++ to C#, I am
making a decision on what development technology to use on a brand
new, upcoming project.

My main concern here is the question of whether it might be true that
Microsoft, at the moment, seems to "favor" the .NET technology over
the others. By "seems to favor", I do not mean the question of general
availability; I mean the availability and "timing" of updates, bug
fixes, tools, samples, documentation, compatible hardware, and, very
importantly, community support. In short, where the most r&d money is
going. In other words, what the "mainstream" is. I do believe that in
certain situations going against such "mainstream" will, in the long
run, needlessly cost a software development company a lot of money and
effort. To rephrase, I am wondering whether it appears that Microsoft
plans to make the .NET platform the next "mainstream" of Windows
application development.

Perhaps let me illustrate (just generally speaking, I do not mean the
paragraph below literally, and examples might not be "hard facts").

Yes, you can still develop a Windows application in, say, assembly or
C-based Win32 pure API, but, unless you have a very good reason to go
that route, it might turn out to be quite a poor decision. With time,
you might find out that your tools have not been updated as fast and
thoroughly as other tools. With time, you might find out that you will
not be able to buy third-party libraries and components to boost your
project since they work with MFC or COM. With time, you might find out
that you have a lot of research to get done, since samples and advice
from other developers are hard to find. With time, a new processor
family might be coming out and you suddenly learn that
processor-specific optimizations for your favorite assembler will not
be available before 6 months out. Coup de grace comes when you learn
that you have to either implement a new hypothetical Web protocol all
in-house, or buy a $100,000 toolkit from some obscure company.

The r&d dollar is simply going elsewhere, and there is nothing you can
do about it.

put much info as it is so limited). Just because marketing pushes for
whatever is new doesn't mean that everything else is no longer available.

Definitely. But I also hope you will agree that the previously-raised
question of "absolute" technology availability was not exactly what I
meant to take up by this thread (my fault, I should have explained
myself better). I am only asking whether, given the signs of strong
backing of the .NET platform by Microsoft, you guys and gals out there
think .NET will become the next "mainstream" of Windows application
development, and whether it might be a good idea to make the switch
now and, long-term, capitalize on Microsoft's efforts.

I mean, come on. It appears that .NET is the very first major Windows
development environment "re-write". For the very, very first time
(since I can remember), Microsoft has DECISIVELY addressed the object
methodology itself, addressed the question of language inter
operability, addressed the DLL Hell, addressed internationalization
and localization, worked on ADO paradigm structure, addressed Web
integration (and so on and so forth) ALL AT THE SAME TIME. One can't
just ignore it.

The question is: what does it, long-term, mean to the good'ol' C++/MFC
development, if anything? I venture to say that corporations want
quick, cheap, reliable software development, and couldn't care less
about language purity or availability. Should .NET really deliver (and
do I understand that is still to be determined), everyone will start
jumping on board without thinking twice about it. Hence, the topic of
this thread: "[what are] your hands-on experiences [so far] with
moving from EVC (C++) to .NET (C#) for mobile application
development"? If it's easier in C# without too many compromises, I'm
sold.

Other than the one case of VB ( and that with good reason) they have NOT
dropped anything in the way of the tools or technologies. (The Object Store
is still there and usable, although it's not a particularly good place to (...)

With Windows CE V2.0 Both ATL and MFC were available and were used in many
applications. A version of VB was also available
Both ATL and MFC are still available today as of V4.2. That version of VB is
still supported under Pocket PC devices. due to the large number of
developer complaints and issues with the fundamental architecture of that
(Basically an extended VBScript) MS chose to drop it entirely in favor of
VB.net and the CF.

I would agree with what you are saying in general, but I believe "the
devil is in the details" - not only whether a technology is available,
but how well it gets the job done. At any rate, there are still
unanswered questions here. As an example: why give up on all those
countless MFC programmers for the brand new SmartPhone platform but
immediately go with the young, unproven, .NET CF? Can you develop C++
SmartDevice applications under Visual Studio .NET 2003, or do you have
to do back to (less than stellar) EVC 4.0? Why are we getting "free"
packaging and deployment with Visual Studio .NET 2003 only, but there
is no news of such for EVC 5.0?

That's where I ask of your, dear ladies and gentlemen, wisdom and
experience .

You're missing some information and definitely have a bias here. (From what;
I won't speculate)

That's a keen observation... After some thinking, I have no choice but
admit that I might be little over-cautious and trying too hard to
sniff out the future. Probably also a bit too excited about what .NET
seems to be promising. That probably comes for the fact that I was
involved with a corporate Windows/Windows CE application from 2.0
through 4.20, and, oh boy, was that hell or what.

Thank you for your thoughts,

Gabe

 

[Steve Maillet \(eMVP\)]

Sounds to me like you have already made your choice. Are you trying to
convince everyone you are right?

Personally I like .NET and the CF simplifies a number of tasks. However, the
CF just has to many limitations (Look at all the issues people are having to
go p/Invoke to resolve) The interop scenario is pretty poor at present so
you can't just fall back on good ol' ATL COM components to get the extra
functionality/performance you need. I'm certainly biased there as I mostly
do OS porting and device drivers and industrial applications so it's usually
simpler to use MFC/ATL the to futz with lot's of interop hacks.

MS is still reving the C++ compilers, their stated goals for that is to be
the most standards conforming compiler on the market. (A welcome change for
many!) The dev tools scenario for C/C++ on Windows CE devices is less then
stellar. Eventually what is now eVC will be folded into Visual Studio.NET so
you can do both native and managed code from the same tool. Unfortunately
that isn't available yet. The reasons are not particularly relevant except
that you have attributed the lack of better tools with a lapse on
Microsoft's focus on those languages. I can only say that this situation is
only temporary and will improve in time. C/C++ MFC and ATL will be around
for a long time.

You talk about updates like they were something that could make or break a
project. But I'd say who cares if MFC/ATL is NEVER updated from what it
currently supports? [I've recommended MS put it into the bug fixes only
status category (after putting back C++ Exceptions) - that doesn't mean it's
dead, just mature] Does it do what is necessary to accomplish the task at
hand? (Probably!) Don't just use whatever is new because new is supposed to
be better. That gets you caught in the endless trap of continuous upgrades.
Certainly learn the Compact Framework and use it whenever it makes sense.

Bottom line is that YOU need to do your homework evaluating the
functionality of your application and determining if the CF has that
capability, if not how much is missing and what can you do to achieve it
some other way.

For actual specifics of issues faced in using the CF just scan the compact
framework newsgroup and see what people are struggling with. There's far
more detail there then anyone could put into a single response.

 

[Chris Tacke, eMVP]

Inline....

1.) A big break when it comes to writing cross-platform
(desktop/PPC2002/PPC2003/SmartPhones) code. Developing large apps in
EVC/C++/MFC/pure Win32 turned out to be a nightmare. Subtle
differences across the platforms when it comes to message handling,
resource file formats, custom draw capabilities, SIP handling, bugs,
etc. caused me to write tons of #defines to get something to work, and
forced almost unbearable amount of testing on each device in question.
Things that work on Dell PPC2003, might not work 100% the same on HP
device. I hope that since .NET and C# are a re-write (in a sense) of
MFC/Win32, code will be more uniform across all platforms.

Using the CF will definitely make multi-platform code a bit more readable.
Code written with the CF should produce identical behavior across platforms.
That said, platform architecture can affect behavior beyond the CF's control
(look at the Tab control on a PPC and a non-PPC device). So while it should
work cross-platform, as always test, test, test.

2.) I like the features and the methodology of the new C# language
over C++. Anyone who has spent a week hunting for that ONE DAMN
MEMSET() will know what I mean. Reflection, multiple-inheritance
elimination and XML stuff are a very nice plus.

This is specifically one of the goals of managed code (though I'd love to
see a D compiler, which would give a lot of the managed benefits with the
perf of C++).

3.) Simplification of internationalization and deployment through
assemblies.

The CF can do this pretty easily, though I don't think it was too bad with
C++.

4.) Easier accommodation for runtime plugins though assemblies,
instead of dealing with that obscure COM and COM+ stuff, to allow C
and VB guys to write sub-components.

Don't count COM out. There are way too many companies that spent a lot of
resources putting business logic into COM libraries and it's unrealistic to
assume they'll just rewrite them. COM interop is a major shortcoming of the
CF.

5.) Finally, it seems to me that since Microsoft is investing all its
resources in the new .NET platform, sooner or later plain C++ for
Windows apps will be obsolete. I think it is notorious of Microsoft
to, over time, pretty much drop anything that is not current "focal"
development technology. .NET seems to be it at the moment.

C++ will never (well, not in the foreseeable future) be obsolete. Microsoft
will continue to support it, and it will still be required for intesive
processing (graphical stuff, high-order math) as well as for time critical
(real-time) applications.

What do you think?

IMHO, the number one, most important thing a successful developer needs is
the ability to blend native and managed code into a seamless solution.
Those who rely on cut-and-paste P/Invoking without understaning the how's
and why's behind the code they paste will always remain mediocre and their
code unreliable. Learning the CF is a good idea, as it will greatly improve
productivity, but more importantly you need to know when it fits and when it
doesn't.

-Chris

 

[Ginny Caughey [MVP]]

Gabe,

Steve gave you a really thorough answer from the technical side. I have apps
in eVC++/MFC and also in C#, and I want to make a suggestion from the purely
pragmatic side: this brand new app might be a good opportunity for you to
explore C# and the compact framework and make a decision for yourself. If
you find yourself frustrated by the things you can't easily do with the
compact framework that you can do with MFC, then maybe C++/MFC is a better
choice for you. On the other hand, if you find yourself happy with the
productivity of the compact framework, then that is probably the better
choice for you. Microsoft will be supporting both and will definitely be
enhancing the compact framework.
--
Ginny Caughey
Windows Embedded MVP

On Sun, 19 Oct 2003 11:20:55 -0400, "Steve Maillet \(eMVP\)"

Steve,

Reading your post I finally realize that I have phrased my point (5.)
rather poorly, and that's where the trouble might be coming from. The
"obsolete" was too strong a word, and probably implied that I think
Microsoft will not be supporting existing development technologies at
all. I agree that Microsoft takes supporting backward compatibility
seriously, and I find comfort in knowing I can always fall back on C++
even when using the .NET framework. Also, I should have mentioned that
I do not look to migrate an existing application from C++ to C#, I am
making a decision on what development technology to use on a brand
new, upcoming project.

My main concern here is the question of whether it might be true that
Microsoft, at the moment, seems to "favor" the .NET technology over
the others. By "seems to favor", I do not mean the question of general
availability; I mean the availability and "timing" of updates, bug
fixes, tools, samples, documentation, compatible hardware, and, very
importantly, community support. In short, where the most r&d money is
going. In other words, what the "mainstream" is. I do believe that in
certain situations going against such "mainstream" will, in the long
run, needlessly cost a software development company a lot of money and
effort. To rephrase, I am wondering whether it appears that Microsoft
plans to make the .NET platform the next "mainstream" of Windows
application development.

Perhaps let me illustrate (just generally speaking, I do not mean the
paragraph below literally, and examples might not be "hard facts").

Yes, you can still develop a Windows application in, say, assembly or
C-based Win32 pure API, but, unless you have a very good reason to go
that route, it might turn out to be quite a poor decision. With time,
you might find out that your tools have not been updated as fast and
thoroughly as other tools. With time, you might find out that you will
not be able to buy third-party libraries and components to boost your
project since they work with MFC or COM. With time, you might find out
that you have a lot of research to get done, since samples and advice
from other developers are hard to find. With time, a new processor
family might be coming out and you suddenly learn that
processor-specific optimizations for your favorite assembler will not
be available before 6 months out. Coup de grace comes when you learn
that you have to either implement a new hypothetical Web protocol all
in-house, or buy a $100,000 toolkit from some obscure company.

The r&d dollar is simply going elsewhere, and there is nothing you can
do about it.

put much info as it is so limited). Just because marketing pushes for
whatever is new doesn't mean that everything else is no longer available.

Definitely. But I also hope you will agree that the previously-raised
question of "absolute" technology availability was not exactly what I
meant to take up by this thread (my fault, I should have explained
myself better). I am only asking whether, given the signs of strong
backing of the .NET platform by Microsoft, you guys and gals out there
think .NET will become the next "mainstream" of Windows application
development, and whether it might be a good idea to make the switch
now and, long-term, capitalize on Microsoft's efforts.

I mean, come on. It appears that .NET is the very first major Windows
development environment "re-write". For the very, very first time
(since I can remember), Microsoft has DECISIVELY addressed the object
methodology itself, addressed the question of language inter
operability, addressed the DLL Hell, addressed internationalization
and localization, worked on ADO paradigm structure, addressed Web
integration (and so on and so forth) ALL AT THE SAME TIME. One can't
just ignore it.

The question is: what does it, long-term, mean to the good'ol' C++/MFC
development, if anything? I venture to say that corporations want
quick, cheap, reliable software development, and couldn't care less
about language purity or availability. Should .NET really deliver (and
do I understand that is still to be determined), everyone will start
jumping on board without thinking twice about it. Hence, the topic of
this thread: "[what are] your hands-on experiences [so far] with
moving from EVC (C++) to .NET (C#) for mobile application
development"? If it's easier in C# without too many compromises, I'm
sold.

Other than the one case of VB ( and that with good reason) they have NOT
dropped anything in the way of the tools or technologies. (The Object Store
is still there and usable, although it's not a particularly good place to

(...)

With Windows CE V2.0 Both ATL and MFC were available and were used in many
applications. A version of VB was also available
Both ATL and MFC are still available today as of V4.2. That version of VB is
still supported under Pocket PC devices. due to the large number of
developer complaints and issues with the fundamental architecture of that
(Basically an extended VBScript) MS chose to drop it entirely in favor of
VB.net and the CF.

I would agree with what you are saying in general, but I believe "the
devil is in the details" - not only whether a technology is available,
but how well it gets the job done. At any rate, there are still
unanswered questions here. As an example: why give up on all those
countless MFC programmers for the brand new SmartPhone platform but
immediately go with the young, unproven, .NET CF? Can you develop C++
SmartDevice applications under Visual Studio .NET 2003, or do you have
to do back to (less than stellar) EVC 4.0? Why are we getting "free"
packaging and deployment with Visual Studio .NET 2003 only, but there
is no news of such for EVC 5.0?

That's where I ask of your, dear ladies and gentlemen, wisdom and
experience .

You're missing some information and definitely have a bias here. (From what;
I won't speculate)

That's a keen observation... After some thinking, I have no choice but
admit that I might be little over-cautious and trying too hard to
sniff out the future. Probably also a bit too excited about what .NET
seems to be promising. That probably comes for the fact that I was
involved with a corporate Windows/Windows CE application from 2.0
through 4.20, and, oh boy, was that hell or what.

Thank you for your thoughts,

Gabe

 

[r_z_aret]

On Sun, 19 Oct 2003 11:20:55 -0400, "Steve Maillet \(eMVP\)"

clip

Other than the one case of VB ( and that with good reason) they have NOT
dropped anything in the way of the tools or technologies. (The Object Store

CEF (Common Executable Format) came and went. For those of you not
familiar with Windows CE, CEF was a technique that let executables
support multiple CPUs. I think it was supported for version 2.1x of
the operating system. Not before. Not since.

clip

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

Robert E. Zaret
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com

 

[r_z_aret]

On Fri, 17 Oct 2003 13:22:18 -0700, "Paul G. Tobey [eMVP]"

Paul,

Thanks for the reply.

What's driving your thinking about changing? That will help narrow down the
responses a lot.

Good question, I should have thought of that. What I hope to get out
of the transition is as follows (in order of importance):

1.) A big break when it comes to writing cross-platform
(desktop/PPC2002/PPC2003/SmartPhones) code. Developing large apps in
EVC/C++/MFC/pure Win32 turned out to be a nightmare. Subtle
differences across the platforms when it comes to message handling,
resource file formats, custom draw capabilities, SIP handling, bugs,
etc. caused me to write tons of #defines to get something to work, and
forced almost unbearable amount of testing on each device in question.
Things that work on Dell PPC2003, might not work 100% the same on HP
device. I hope that since .NET and C# are a re-write (in a sense) of
MFC/Win32, code will be more uniform across all platforms.

I've been using common source code for all Win32 platforms (CE 2.0 -
3.0, plus 95, 98, NT, 2K, and XP) for 1 month short of 5 years. I have
a library with about 40K lines. Less than 300 lines are pre-compiler
macros to control platform. I haven't completely eliminated platform
dependencies from my actual programs, but am close. I do load some
libraries dynamically, depending on platform. And I do use some
tricks ("cheats").

Virtually all bugs that showed symptoms on only a subset of platforms
turned out to be bugs in my code that should have caused problems in
all platforms. I learned quickly to test on at least 2 or three
platforms often. I think building for multiple platforms helps debug
the code for all platforms. If you really want to test your code, try
running it on a Casio PA-2400 (SH3 CPU running at 70 MHz - and very
sensitive to bugs).

I do code for the "lowest common denominator", which means I sometimes
need to write/adapt code myself so it works across platforms. And I do
need to work a bit harder to make sure everything works across
platforms. I also avoid MFC, ATL, COM, the C++ standard library, and
C++ exceptions.

My user interfaces do tend to look a bit sparse on big screens. But
I've been adding code to dynamically add more info on big screens. One
of the first things I did was to write library functions that support
dynamic control positioning on all screens. That means I support
odd-sized screens (like the small portrait-mode screen on some
industrial Windows CE computers) with very little extra code.

I'm not sure how to measure complexity in this context, but I don't
think my main program is simple. It does about as much as the version
my boss wrote using VB. That program uses about 2 dozen DLLs that must
be installed explicitly. Mine uses none.

The first year was rough, while I tuned the dynamic screens and
eliminated most of the bugs that showed on only one platform. But the
result is _very_ gratifying. Being able to do most debugging under NT
(rather than CE) is a big win. Minimizing the potential for
platform-specific bugs is a big win. Installation is almost trivial.
Being able to quickly support new platforms is a big win. Being
insulated from changes in Microsoft's vision is a big win.

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

Robert E. Zaret
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com

 

[r_z_aret]

clip


In terms of application development tools, Windows CE 2.x began with
Win32/ATL and minimal support for MFC. As soon as 3.0 arrived, the
focus switched from Win32/ATL to MFC. With 4.x, .NET is clearly
getting the most attention, with mostly bug fixes for MFC in Windows
Mobile 2003 (and boy, is there still a question of Windows CE MFC
completeness, or what?). The new Smartphone "1.0", however, dropped
MFC altogether, yet the word is that the upcoming SmartPhone "2.0"
version will include .NET framework in ROM.

I've been happily using C++ with the Win32 API for 5 years. MFC, ATL,
etc. come and go (or at least get emphasized and deemphasized), and I
have had no real reason to care. My code and tools work pretty much
the same now as when I started. I might prefer to have Microsoft fix
known bugs in the tools I use, rather than chase after hot new
technology. But I've either avoided or worked around most bugs by now,
so I'm not really anxious.

In terms of database technology, Windows CE 2.x began with the native
Object Store, and minimal support for anything else. As soon as 3.0
arrived, the focus switched from the Object Store to Pocket Access
over COM (actually, Pocket Access *is* the Object Store, but that's a
different story), with little improvement to the Object Store. With
4.x and .NET, Pocket Access is officially "unsupported", you have to
get a third-party COM wrapper to even use it from C#. SQL Server
Mobile is the name of the game.

I don't use, so I can't comment intelligently.

In terms of mobile device hardware, Windows CE 2.x began with
Palm-sized PCs, Handheld PCs, and Handheld PC Pros. As soon as 3.0
arrived, PalmPCs won the game (renamed to Pocket PCs), Handheld PC
Pros were entirely dropped, and Handheld PCs barely survived with only
one o/s update - HPC 2000 (with only partial SDK available, anyway).
With 4.x, despite NEC (and others) still manufacturing and selling
HPC-factor devices, HPC2000 platform has been retired altogether even
from www.pocketpc.com website.

See my reply to an earlier not in this thread.

And so on, and so on. But, again, it is only MHO that often
Microsoft's top R&D dollar goes into "flagship" technology, at the
clear expense of other products. The "wave", at the moment, seems to
be the .NET platform, but I am not forcing anyone to believe me. I
just cannot help but wonder at how much money must have gone into
developing and marketing the .NET framework, versus, say, Visual C++
7.0, and MFC 7.0.

I'm not arguing against C++'s longevity. I love the language, and
agree it is and will be the best tool for certain applications for a
very long time. Yet, IMHO, Microsoft's all-out commitment in the .NET
platform is... very hard to miss.

Gabe

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

Robert E. Zaret
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com