Microsoft recently released tools and documentation for its new Phone 7 platform, which to the dismay of those who have a big C++ codebase (like me) doesn't support native development anymore. Although I've found speculation about this decision being reversed, I doubt it. So I was thinking how viable would be to make this codebase available to Phone 7 by adapting it to compile under C++/CLI. Of course the user interface parts couldn't be ported, but I'm not sure about the rest. Anyone had a similar experience? I'm not talking about code that does heavy low-level stuff - but there's a quite frequent use of templates and smart pointers.
+2
A:
The whole development idea is built on Silverlight. I think you can add your managed dll written in C++ without any problem to this Silverlight project, but it could not use native code.
I am planning to install the tools on my machine tonight and will try this out.
gyurisc
2010-03-16 15:07:46
OK, I was guessing about that. But how much work it would be to make a typical modern C++ codebase (templates, smart pointers) compile under C++/CLI? Notice that it's not my idea to lose the ability to keep compiling native (to those platforms that support it, like WM6 and iPhone), but be able to mantain only one set of sources.
Fabio Ceconello
2010-03-16 15:13:09
I would say that is closer to a complete rewrite than to a simple port.
gyurisc
2010-03-16 18:23:50
+5
A:
You can generate verifiable managed code in C++/CLI using the /clr:safe option. The problem is that most of your normal c++ code will not compile with that option.
adrianm
2010-03-16 15:20:01
Could you elaborate a little more? What kinds of constructs, is it viable to make workarounds via conditional compilation, etc.
Fabio Ceconello
2010-03-16 15:24:12
A:
I'm working on a game for the iPhone which I'm hoping to release sometime this summer. I'd love to eventually port it to Android or Windows Phone 7, or whatever other device of this type is popular enough to make it worth it. But, what MS is doing pretty much guarantees that this wont happen. I have hundreds of files of C/C++ code, plus the front-end in Objective-C. There is zero, ZERO, chance that I'm going to waste time porting all that code. So, once again to MS... nice try, but no cigar.
0r0d
2010-03-27 06:53:23
Note that WP7 doesn't support C++ in its initial release. This means two things:1) C++ support is likely to arrive after RTM via Managed C++2) Managed C++ compiles down to IL (just like C#, VB, etc. do) so if your C++ code is clean, doesn't do pointer arithmetic, doesn't try to do "clever" direct-memory manupulation (which will largely kill any x-platform ambitions you may have) then you may well find that compiling said C++ code in Managed C++ may well run on WP7!
bitcrazed
2010-07-12 19:35:04
+4
A:
C# is currently the only supported language for WinPhone7.
I fully expect that MS will add support for VB and C++/CLI in the future too, but don't expect to open up the native-code kimono anytime soon.
Native code just has too many issues to overcome, specifically around security, reliability, etc. Managed code is FAR easier to statically verify and FAR easier to control while running.
If you're upset about porting C++ code to C#, just be glad MS didn't force you to have to move to Objective-C ;)
From our own experience, the proces of porting well-written C++ to C# actually takes a lot less effort than one might at first expect. Sure, there's a learning curve, but you have that with any port. We actually got so much benefit from porting our core app and data engines to C# that we re-tooled our entire team to code in C# and port our C# back to C++ where necessary rather than the other way around! So far, we've only ported two modules back to C++ and call our C# code from our native code via interop instead.
Again, remember, WinPhone is a brand new platform using best of breed, highly-productive, next-generation development tools and platforms. It is not your father's WinMo.
If support for C++ is something you find to be crucially important, then make sure MS know - (respectfully and professionally) state your position in the MSDN forums and at developer events near you.
bitcrazed
2010-05-20 23:21:41
+2
A:
It is fine if MS decides to leave the path and create something new, that is MS' decision. So let's face the facts. Silverlight is no success yet. MS lost significant share due to Apple, Android and RIM. Application developers simply have to evaluate the business case for their own applications and decide if they trust in a share gain of Windows 7 phone or not. For the company that I run, we decided not to support any more MS Windows phone 7, not because of this or the other technical reason, but just because that we don't believe in the return of our investment for the port. We start supporting Apple, Symbian, Andoid and MeeGo in the future if we see a market success of this new platform. All support C/C++ and enable us to reuse our proven application cores. So why worry at all. Personal technology preferences should not be gating. If personal preferences worry, then I would kick MS out for their to me ugly looking UI.
Thomas
Thomas
2010-06-15 19:48:52
Of the platforms you chose to adopt, MeeGo and Symbian are likely to crumble before your very eyes.At the end of the day, Managed C++ compiles down to IL which is packaged into assemblies and executed by the CLR. If you're careful, you may well be able to get your code to port pretty cleanly to Managed C++ and thus run unhindered on WP7. If it doesn't work, however, you're on your own.Things to avoid include direct memory manipulation, pointer arithmetic, etc., but then you're avoiding such things anyhow, right?
bitcrazed
2010-07-12 19:31:35
A:
What? Windows Phone 7 does not support C++? Then how can I replace pointers in C++ codes to C#? And how about Windows APIs? Especially DirectX, DirectShow, Media Foundation?
CharlieC
2010-07-11 16:08:14
the main problem is not about the available APIs, MS will make available through C# classes everything you had before using C-style calls (not necessarily on launch, though.) What's more to worry is about the existing codebase, which will have to be rewritten - as adrianm stated.The main reason I posted the question was to look for a workaround, but as you can see by all the answers, there's none.
Fabio Ceconello
2010-07-12 15:27:44
Do you means that C++ programs on Windows 7 will be hard to port on Windows Phone 7? WP7 drop off the Win32 API? Objective-C can compatible to C program much better. Its object-extension is for GUI code. It is more like C++ with less complex.
CharlieC
2010-07-20 13:40:26
+1
A:
No native support? No multitasking? You got to be kidding me! No way I will rewrite my native WM5-6.x app to WP7/silverlight. I'm on my way to android now... I really like the WM architecture, too bad MS couldn't just replace the userinterface with a new, hot and easy to understand UI. Goodbye MS.
Nicholas
2010-07-24 18:37:33
A:
Can someone prove this is impossible to link a C++ lib in a wp7 project ?
Thanks
rzr
2010-08-27 09:23:00
+1
A:
c++/cli can theoretically be used with WPF/Silverlight using the trick of replacing the C# generated from the XAML with a macro definition that can be used inside the main class in a code behind file. I worked out this technique but haven't had the motivation to take it beyond theory - I'm quite happy mixing languages.
As far as using c++/cli in a pure safe mode for your logic code, this may still not be possible but I'd love to hear how someone goes trying it now. Whilst researching it for Silverlight back in 2008 I found this daunting silverlight forum comment:
I just gave Silverlight&C++ it a try by compiling the MSIL from my C++ project into a Silverlight-compatible DLL. The good news: it works, and you can call this code from a Silverlight project. The bad news: The C++ compiler apparently uses MSIL instructions that Silverlight disallows.
So, if you try this, even with the simplest of programs, you'll almost immediately get the exception "Operation could destabilize the runtime." To me, this makes it seem less likely that we'll see Silverlight for C++ soon, as the compiler will need to behave quite a bit differently.
Andy Dent
2010-09-30 00:17:57