Microsoft's new pitch: 'Every .Net developer just became a Windows Phone developer'

Microsoft's new pitch: 'Every .Net developer just became a Windows Phone developer'

Summary: Microsoft officials promised more details about the company's Windows Phone 7 development strategy would be revealed in mid-March at its Mix 10 conference. But those details already have begun to leak out. Not surprisingly, Silverlight is at the crux of Microsoft's development platform. XNA, Microsoft's game-development platform, also is part of the puzzle.


Microsoft officials promised more details about the company's Windows Phone 7 development strategy would be revealed in mid-March at its Mix 10 conference. But those details already have begun to leak out.

Not surprisingly, Silverlight is at the crux of Microsoft's development platform. XNA, Microsoft's game-development platform, also is part of the puzzle.

According to documents posted to the XDA Developers Forum and surfaced more widely by, Microsoft will make available a limited set native application programming interfaces (APIs), with the the real focus on managed APIs (meaning .Net-based). The primary tools for developing for the Windows Phone 7 OS will be Visual Studio 2010 and Microsoft Expression Blend (a design tool for Silverlight and .Net), according to the docs.

The XNA Framework, an implementation of the .Net, and its associated tools, also are likely to be part of the mix. Given the XNA Game Studio already supports Xbox 360, as well as the Zune media player,  -- and Windows Phone 7 borrows so liberally from the Zune HD, in terms of its user interface) -- it makes sense XNA tools will support Windows Phone 7. For the record: Microsoft officials have declined to say whether Zune HD apps and games will run on Windows Phone 7 -- and whether new Windows Phone 7 apps will run on Zune HDs.

I've heard a few more specifics from a couple of my contacts who've asked me to keep them anonymous. One described Microsoft's Windows Phone 7 planned developer pitch as follows:

"The dev platform is Silverlight 3, plus elements of 4, using Blend and a Visual Studio add-in. The kicker is that while it is XAML-like, it is not pure XAML (Extensible Application Markup Language). This is actually OK, as it keeps the footprint nice and small.

"In theory you can make an entire app inside of Blend, but I think you will need Visual Studio to hook it all together in C#. In the war vs. Apple for apps, every .NET developer just became a Phone developer."

Microsoft has yet to announce officially (or make available to external testers) the promised add-on(s) for Visual Studio 2010 that will support Windows Phone development. One of my sources said there will be one tool that will be integrated with the Visual Studio 1020 integrated development environment (IDE) and another that will be available as standalone install. Microsoft officials have said they'll have more to say about mobile-development support for Visual Studio 2010 some time this year. (Mix 10 is my guess.)

WMPoweruser points to the newly leaked documents (which Microsoft isn't confirming are real, but sure look as though they are) as proving that Windows Phone 7 will enable multitasking. I'm still not 100 percent convinced of this, as I've heard from my contacts that Microsoft will be playing fast and loose with what "multitasking" means with Windows Phone 7 so as to be able to claim that's the case. (The aforementioned source gave me a pretty definite 'no' when I asked whether Windows Phone 7 would support multitasking to the same degree that Windows Mobile 6.x devices do.)

Another developer issue that still remains murky is whether and how easily the existing Windows Mobile 6.x application base (1,245 apps in the Windows Marketplace for Mobile store, plus countless custom apps) will be able to run on Windows Phone 7 devices. It's obvious because of user inteface differences, existing apps will need to be modified to some degree to work. But Microsoft officials also have refused to provide details about the backward-compatibility story, saying more will be shared at the Mix show.

On a related note, for those developers still interested in writing apps for the Windows Mobile 6.x platform (for whatever reasons), Microsoft released this week a developer toolkit for Windows Mobile 6.5.3.

Topics: Operating Systems, Microsoft, Mobility, Software, Software Development, Windows


Mary Jo has covered the tech industry for 30 years for a variety of publications and Web sites, and is a frequent guest on radio, TV and podcasts, speaking about all things Microsoft-related. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008).

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Ok, and every Java developer "just" became an Android developer.

    Really a pretty ridiculous statement. There is
    more to learning to program a phone than the
    programming language.
    • An oversimplification, yes, but...'s not a bad analogy. Developers are constantly adding and using new API's and methods, but it doesn't mean they're unable to leverage the knowledge they already have either.

      Besides, Java and .NET are both designed to be less interested in the core platform as they are interested in the programming platform (ignoring, of course, that .NET is inherently a Windows development platform and not agnostic the way Java is).
      • .NET is just Microsoft's implementation of the standard CLR ...

        ... and incorporates a bunch of functionality that provides access to most of Windows' features so that .NET developers don't have to write too much interop code.

        Novell implements the CLR on Linux via Mono.

        Others implement the CLR for other platforms and architectures. GemAlto, for example, implements the CLR to run on a smart card.

        The CLR is platform and implementation agnostic and, depending on what external assemblies your code consumes, may in fact be fully interoperable with other vendors' assemblies.
      • Totally wrong

        Completely ignorant statement:
        >>(ignoring, of course, that .NET is inherently a Windows development platform and not agnostic the way Java is).

        CLI is ECMA/ISO standard and C# is also ECMA/ISO standard. Derivative of CLI is CLR and CLR is available for a while on Mac, Linux and SmartCards. .NET has become open standard long before Java has become.

        Ram U
        • Actually you're wrong...

          Java being agnostic has nothing to do with it being open. He's simply referring to the write once run anywhere principal that Java adopted and was in practice well before .Net ,the CLI, the CLR or any other .Net related technology you want to throw out there came to be. If you know how and why .Net actually came to be then you already know there is no rebuttal.

          And its also important to note that while theres Mono on Linux (don't know about the Mac scene) its still not completely write once run anywhere. For instance if you write your GUI using Swing it run relatively anywhere at least in the PC realm. You can't take a WinForms GUI and run it on Mono. I believe there are other Windows specific components as well. The only thing thats really common is the C# language.
    • A little different...

      I think the main thing that is different is that Windows Phone will use Silverlight, which is a very popular app platform (the "most" popular) for .NET developers. So it's not just that it uses C# and .NET Fx, but the key being Silverlight.

      It may be the case with Android that they do something similar. If so then I think that is a reasonable case to make. Not being a Java developer any more, the Android story isn't really that interesting to me.
      • little correction

        Mobile does not run .NetFX but .NetCF. Many differences are there.

        Such as:
        no generational GC
        Static construction blocks all .Net threads until construction is complete
        Many Many classes/methods/namespaces don't exist in .NetCF
        Code is pitched if app is backgrounded
        there is no pre-compiler (like ngen) so everything is IL and JIT compiled as needed
        debugging tool set is weak at best.

        Think of .NetCF as .Net spec compliant but it is just a wafer thin slice off the top of the spec in implementation.

        Not as easy as just port and play that is for sure.
        • Don't jump the gun ...

          ... you may be surprised at what gets announced at MIX ;)
        • Actually.... it might be CoreCLR...

          Windows Mobile 6.5 uses Compact Framework which was a flop. It had all the limitations you mentioned while at the same time lacking all the good features of .net.

          IMHO Windows Phone 7 [i]Series[/i] (I have highlighted what I think is essential) would lean more on a CoreCLR implementation similar to Silverlight 2.0 and 3.0, but with a more extensive set of classes like SL 4.0.

          With that said, WP7S UI might as well be just a Silverlight shell in substitution to the explorer.exe app.

          As for multitasking, everybody knows Mac OS X is preemptive while Win95 and Mac OS was cooperative. So theoretically the iPhone would multitask. Wrong!!! The OS can but the app framework is built so the OS kills the apps after exit. Same could apply to WP7S. This will be used so no errant process are left sucking RAM since most SmartPhones have 1Gb of RAM or less.
          • CoreCLR

            .NetCF 3.7 is .NetCF 3.5 with winforms pulled out, and silverlight pushed in.

            No matter how you slice it, Windows Phone does NOT run .NetFX

            Other than interface stuff, .NetCF 3.7 has no generational GC, still blocks all threads on static construction etc etc etc. Just like .NetCF 3.5

            Don't get me wrong, silverlight is cool to have on the device. I'm a bit taken back that it isn't a pre-emptive OS and there is no enterprise goo put in, like domain join etc, but maybe later.
          • Why would WinPhone7 NOT be pre-emptive

            It's based on WinCE 6+ and WinCE has pre-emptively multi-tasked since v1.

            MS have already stated that apps will still be able to play music in the background and respond to push notifications, for example.

            I hope like hell this doesn't get abused by every WinPhone app phoning home and requesting a push notification that their service is still up and running ever 60s.

            In all reality, so long as your app is paged back in seamlessly and quickly when required, most apps won't care if they're suspended anyhow.

            What apps do you feel MUST stay up and running at full speed in the background on a phone ... other than phone, SMS, Email and music?
          • it isn't

            it is single app. do a bit of research and you will agree.

            I don't feel any app MUST stay up and running. But I do think this is a step backwards. Although iPhone has the same issue with multi-tasking.

            I personally see the consumer device as an eventual replacement of a laptop. To do that the tech can't go backwards and needs to implement enterprise connectivity. phone is just one type of enterprise connectivity.
          • @TardHugger: Read my post again ...

            ... it's not opinion, it's FACT.

            Specifically: [WinPhone7 is] based on WinCE 6+ and WinCE has pre-emptively multi-tasked since v1.

            The OS *does* multi-task - that's how it managed to handle incoming mail via push-sync while you're doing something else.

            Wait for MIX2010 - you'll find more FACTS there.
        • That was story with Windows Mobile

          But Windows Phone would be different, I know they both are built on Windows CE, but it sounds like Microsoft might release something more than .NET CF for Windows Phone.
          Ram U
    • Get a clue!

      I can sell you one for a discounted rate! :-)

      Seriously, it's not .NET platform developers target, not a phone or an operating system or a web platform. There is less that's unique to developing a .NET application that targets a particular piece of hardware than for other programming languages/frameworks.

      As a WinForms/ASP.NET developer, I was able to begin developing a Windows Mobile 6 application after only a few minutes of tinkering with no prior experience.

      This is just another example why .NET is by far the best development platform available.
      • Yea that attitude pretty much ensures WinMo apps will suck...

        I'm just being realistic even though my title is flame bait. The whole ASP.Net Webforms mantra was "A WinForms developer can easily become a web developer". And I personally watched these newly made web developers crash servers because they didn't understand the request/response paradigm that ASP.Net attempted to abstract from them. True web devs hated the idea. Thats why you now have the arguments between the ASP.Net WebForms and ASP.Net MVC camps with the MVC folk being the true web devs.

        All that to say this. If you know Java then yes you can develop for Android without a problem. You just need to read up on the Android specific API's. That doesn't mean you have thought about UI design for the form factors you will encounter. It doesn't mean you have thought about the amount of processing power or RAM you have even though MS has set minimum limits. It doesn't mean you have thought about what it means for your application to hog resources and potentially get in the way of the primary function of the device which is being a phone and potentially causing phone calls to be missed for example.

        Its not a knock on .Net at all by the way. Its really a knock on the way MS tries to market this stuff as being so easy to switch from platform to the next. The API may not change but concerns do and that obstacle will never be removed. So yes I do believe if they keep this marketing up the first batch of WinMo7 apps will contain alot of garbage just as many other platforms that have given quick and easy access to inexperienced developers have had to deal with their initial round of garbage code....nothing more nothing less.
        • Webforms aren't that much different...

          than java server pages. I don't know what you mean by "true web devs"...but for me ASP.Net Webforms where a welcome change from classic ASP. Sure it abstracted request, response, cookies...and all the plumbing between the browser and the webserver. However, it was an improvement because it allowed the developer to organize code in classes (yes...I know you could create classes in classic asp...but it was pretty crappy), use master pages, and incorporate object oriented programming principles (no more com/dcom and include pages). It allowed you to pass objects by value. Classic asp/vb6 had no native serialization...everything was passed by reference. Back in my classic ASP coding days...I saw some stream of consciousness coding that would make your hair curl. Poor programmers need not a marketing ploy to write crappy applications (nor are they limited to one development platform).

          So some inexperience developers throw out a few crappy applications...well...sometimes...that's how you get some experience. I think that the exposure to the development community can only be a good thing in the long run. I'm more concerned with MS's inability to develop a phone OS that stays relevant.
          • Who said I like JSP?

            And for that matter you'll find a TON of people in the Java world that don't like JSP. Thats why you have frameworks like Spring MVC, Struts, Tapestry and on and on. In the PHP world you have Zendd Framework, Symfony, CakePHP and on and on. They all follow the MVC design pattern just like .Net MVC. WebForms is a constricted attempt on MVC and SOME classic ASP devs liked it yet some hated it. The problem here is that just like MS people normally do you assumed everyone using MS products have ALWAYS used MS products ONLY. People do have experience with other products you know. True web devs that are used to either a full MVC framework or the ability to build their own (which was simple in PHP but more difficult in ASP) hated ASP.Net WebForms. Again thats why you have the camp hovering around .Net MVC because it finally gives them the power to do true web development instead of trying to shoehorn the web into a desktop development paradigm. And my "true web dev" comment actually came from one of the most die hard .Net fans I know. He specifically said the real devs will move to MVC and the ones that just want to play around will stick with WebForms. So this isn't some anti-MS rhetoric either.
        • You are Completely Wrong

          Java to Android is huge change. .NET Winforms to .NET CF WinForms it is same. I develop apps for most of the mobile platforms and desktop platforms. Eventhough .NET CF is limited in capabilities, any regular .NET Developer who could develop Windows Apps, can develop Mobile Windows Apps easily with .NET CF without going through learning curve. Visual Studio will take care of a lot of stuff. Android is different story. You need to understand the architecture of the platform first. It is not reading a book or two and develop.
          Ram U
          • didn't read a thing I said did you?

            Again. Having the same API's for two different platforms DOES NOT make both platforms the same. A PC is not a phone. A PC monitor is not a phone screen. And your second to last sentence sums up what I said nicely.

            "You need to understand the architecture of the platform first"

            Thats pretty much true no matter what. MS with its development platforms tries to make that an incorrect statement and most times it doesn't work out. As a matter of fact I was just reading a blog from a Softie on developing without understanding.


            Yet ironically thats exactly what MS is encouraging here and what some of you seem to think is the right way to go.