windows mobile 6.5/7.0 and managed code

[Mike Margerum]

I'm assuming microsoft is going to perform a drastic overhaul of the gui
layer for windows mobile, implementing controls to support finger
gestures and things of that nature. Will these new apis be accessible
only from managed code?

I'm not sure if Microsoft has given any indication to this and i'm about
to embark on a largish application port to windows mobile. I want to
use C++, but I also don't want to be rewriting this application in 18
months to support the new os.

Thanks

 

[Chris Tacke, eMVP]

Microsoft has made no public announcements on what 6.5 or 7 will include (in
fact I don't even know if they've acknowledged 7 exists). Still, WinMo
functionality has historically *always* been done in native with native
wrappers provided after the fact (and sometimes no in the same release
version). I'd say it would be safe to use native code (though for a UI I
personally can't see why anyone would).


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Paul G. Tobey [eMVP]]

Microsoft has not made anything public.

I would seriously doubt that native code would somehow be written out of the
user interface. Choose your implementation language based on how
effectively you can use the language to implement the application you need
to write. If you need things like database access, managed code flogs
native; if you need processing speed, data reduction is going to be needed,
for example, native flogs managed for most things.

If it's an ordinary office-type application, I think I'd be inclined to use
managed code. If it's an image processing application, I'd be inclined,
strongly in that case, to use native code. If it's a database front-end, I
wouldn't even consider native.

Paul T.

 

[Mike Margerum]

Thanks guys for the responses.

What you say about building native apis and then providing managed
wrappers is how ms has always approached things up until .net and WPF.
You *have* to use managed code to use the WPF apis.

I'm concerned they may do the same thing for whatever new way they come
up with for supporting finger based guis.

The reason I prefer C++ is experience, control, performance, and easy
deployment. For the types of apps I build, the compact framework just
doensn't buy me much.

 

[Chris Tacke, eMVP]

WPF isn't supported by the CF at all. Of course Microsoft hasn't announced
anything about CF v. Next that I'm aware, but I'd be shocked to see WPF
support added.

--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Mike Margerum]

WPF isn't supported by the CF at all. Of course Microsoft hasn't announced
anything about CF v. Next that I'm aware, but I'd be shocked to see WPF
support added.

chris that wasn't what i meant. I dont expect wpf to be ported to
windows mobile. I was just pointing out that ms will make a managed code
only api and I wouldn't be surprised if their next gui layer was
accessible only from managed code.

 

[Chris Tacke, eMVP]

Microsoft has (unfortunately) not announced anything, but in order for there
to be some major new non-native API for the UI (that isn't silverlight)
they're going to have to release a new version of the CF. I've heard
nothing about a release, and there have been no community previews or betas
(which every previous version had) so I'd say it's reasonable to assume that
no new CF version is coming in the next quarter or so (and most rumors put
the 6.5 release within that, meaning it has already shipped to device OEMs).
So based on that I'd say there's about zero chance that anything
managed-only would be coming in 6.5.

The way CE works is also widely different than the desktop. In order to
create a new shell allows lots of fun new UI stuff and have it available for
home screens, apps, and everything else so that it's completely pervasive it
has to be done in native code. There's no other option without major
underlying OS changes. From that alone I would say it's very, very unlikely
that any managed-only paradigm is coming in the near future (i.e. 6.5 or 7).
Now after that things may start to change, but you will probably see hosting
support by then (since Silverlight is certainly using it under the hood).
If hosting comes along, then you can use managed code from native, and once
again, you're covered.

In short, I think you have nothing to worry about. Of course I don't work
for Microsoft, I don't make these decisions and I don't get any more public
information than you, so I can't be 100% certain about any of it, but I
think logically you can come to a conclusion solid enough to base business
decisions on without losing sleep.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Mike Margerum]

Thanks chris. some good points. I'm going to continue with native for now.

 

[Simon Hart [MVP]]

Always remember, the tools and languages you use today could be obselete
tomorrow. Microsoft's long term strategy for application development is
managed code.

 

[Markus Humm]

Always remember, the tools and languages you use today could be obselete
tomorrow. Microsoft's long term strategy for application development is
managed code.

Ah? And Windows strategy for component based software once was COM.
So what? Always changing strategy and often without good/easy/clear
migration path? (like VB -> VB.net)

Greetings

Markus

 

[Simon Hart [MVP]]

Some technologies today have evolved from COM. COM in this case was a step
(or an attempt) at enabling distributed system architecture or client server
systems. Today business requirements are very different - COM will not
succeed. Hence the reason for evolution.

You have to in some cases invent new technologies based on new requirements
rather build on older ones not fit for todays problems, this is life though
isn't it?

 

[Markus Humm]

Some technologies today have evolved from COM. COM in this case was a step
(or an attempt) at enabling distributed system architecture or client server
systems. Today business requirements are very different - COM will not
succeed. Hence the reason for evolution.

You have to in some cases invent new technologies based on new requirements
rather build on older ones not fit for todays problems, this is life though
isn't it?

Yes and no!
They often start technologies without thinking out enought first and
several years later they abandon the technology but without feasible
migration path. "Please rewrite your app." is no feasible migration
path. Most admins could have told MS > 10 years ago that COM is too hard
to use esp. in networked environments as DCOM I guess...

Greetings

Markus

 

[Simon Hart [MVP]]

How do you predict the future?

 

[Markus Humm]

How do you predict the future?

I cannot either, but some technologies already look complicated when one
looks at them the first time.

COM is such a beast. (which I do use, don't get me wrong!)

Greetings

markus