SilverlightShow: Windows Phone 8: Compile in the Cloud Comments

Re: Windows Phone 8: Compile in the Cloud

MisterGoodcat — Sun, 25 Nov 2012 15:13:59 GMT

Hi Panospace,

compiling to MDIL has the same degree of "inherent obfuscation" as using native code. When you look at the output you'll realize that it generates assembly that is dependent on the CPU architecture, with some place holder tokens and specific instructions the "linker" knows how to treat. However, do not forget that what you as a developer upload to the Phone Store still is IL, and if your application supports 7.x those users will get the same IL assemblies like before - so no, I wouldn't say it eliminates the need for obfuscation at the moment, if you're sensitive about your code.

The concept of MDIL is compelling and there have been hints that it is thought about how or if it can be brought over to other platforms to make them benefit from it too. However, at the moment there are no official announcements on this (that I'm aware of), and it is currently not used on other platforms than Windows Phone (8).

Re: Windows Phone 8: Compile in the Cloud

panospace — Sat, 24 Nov 2012 17:36:44 GMT

Hi Peter, does compiling to MDIL eliminate the need to obfuscate code?

Do Win RT apps also get compiled to MDIL or is this just used in Windows Phone?

Re: Windows Phone 8: Compile in the Cloud

MisterGoodcat — Sat, 24 Nov 2012 10:29:35 GMT

Hi Tarek,

although it may seem similar at first, no static linking happens here. However, the native images very much depend on the exact version of dependencies they were built against. The problems particularly arise with the way derived types work. They need to copy the physical layout of fields from their base classes, and also the layout of the method tables. Now, if for whatever reasons these layouts change in a platform update (and these changes may be completely unrelated to the functionality your derived classes are using), there's a mismatch between what's now the current, correct layout in the base classes and what your derived types have copied over when their images were built before. This leads to inconsistencies or even crashes, so these images all need to be recreated.

I didn't want to scare people away by getting too technical :), but if you're interested in more details, I highly recommend watching the Channel 9 video with Mani Ramaswamy and Peter Sollich. He provides some very nice explanations that demonstrate when and why generated assembly becomes stale and needed to be recreated, and how MDIL solves this problem.

I hope this helps.

Re: Windows Phone 8: Compile in the Cloud

TarekWahab — Fri, 23 Nov 2012 19:43:31 GMT

Hi Peter,

Great article. I understand the benefits of such an architecture over what was done in WP7. My confusion though arises from what you say regarding native images becoming stale when the platform is updated.

" In the process of creating these images all kind of information about the physical layout of references is baked into the result, in particular address offsets. That data potentially becomes stale when those dependencies are changed, for example when new members are added to them"

I don't understand why this should happen? If the libraries are linked dynamically (as is done on other native platforms) shouldn't the linking step take care of this? Or is it the case that the .NET libraries are statically linked to an application when we build it? Perhaps I don't understand how managed libraries work, and it would be good to get the clarification.

Thanks.