This would become the most compelling Mobile Enterprise Application Platform of the last decade.  In 2006 I created the Windows Mobile Line of Business Accelerator to help jumpstart the efforts of corporate developers + enterprise ISVs with advanced tools and technologies like the .NET Compact Framework, SQL Server Compact and Visual Studio.

It’s a new decade and we’ve created the most powerful Mobile Enterprise Application Platform ever with Windows Phone 7.  Next week at Tech Ed North America 2010, I will begin the process of jumpstarting your enterprise development efforts again with Silverlight, WCF, Azure and Visual Studio 2010.  Give yourself an edge and come check out my sessions:

Developing Occasionally Connected Applications for Windows Phone 7

The Silverlight development environment has proven itself to be a rich, capable, and adaptable runtime that has reached across platforms to support Windows, the Mac and the Web. Silverlight has now become the application platform for Windows Phone 7, which is great news for new and existing Silverlight developers looking to support this exciting new phone platform. To ensure the best experience for mobile users, apps built for Windows Phone 7 must implement an occasionally-connected pattern of development that Silverlight developers for the other platforms may find unfamiliar. In this session, learn how to build mobile apps that adjust their behavior based on changing network conditions. Also learn how to conquer unreliable wireless networks by implementing RESTful principles to ensure your messages are both compact and fast. Then take those WCF REST services and use them to retrieve database tables, rows, and columns in order to drive the behavior of your mobile applications. Finally, learn how to build an in-memory database that you can query with LINQ and save its data to Isolated Storage to ensure that your Windows Phone apps keep working regardless of network conditions.

Microsoft’s Next Generation Mobile Enterprise Application Platform (MEAP)

A Mobile Enterprise Application Platform (MEAP) allows corporate IT departments to support multiple mobile applications on a single platform. Gartner states that this market currently tops $1 billion and forecasts that 95% of the world’s organizations will standardize on a single MEAP offering by 2012. Companies looking for a better ROI are moving to reusable platforms instead of building tactical, ad-hoc mobile solutions that support only a single app. Attendees of this session will learn how to save money by steering away from point solutions and on to Microsoft’s MEAP stack. Come see what Microsoft’s Next-Gen Mobile Enterprise Application Platform looks like and learn how it will support a broader range of mobile platforms and operating systems including Windows Phone 7 and Azure.

See you in New Orleans!

- Rob

At MIX10, it was time to show application and game developers that we not only have the best mobile platform for them, but we also have the best tools.  We launched a Windows Phone 7 Developer Tools Preview that includes:

• Visual Studio 2010 Express for Windows Phone
• XNA Game Studio 4.0
• Windows Phone Emulator
• Expression Blend 4 for Windows Phone

The tools are free and can be downloaded from http://developer.windowsphone.com.

We’ve gone from eMbedded Visual Basic and eMbedded C++ to the .NET Compact Framework and now we’re making the jump to Silverlight which allows mobile developers to build the richest, most visually stunning apps ever seen on a phone.  Game developers get the same easy-to-use XNA tools that are used for Xbox, Windows and Zune HD.

Go to the site, download the tools, and start building apps and games for Windows Phone 7!

- Rob

Some of us even switched to OS/2 which could give us 740 KB to our DOS sessions while providing them with preemptive multitasking.  Yes, I could run multiple DOS games in multiple windows simultaneously with no degradation.  Wow, now I had a bunch of crash-protected slots each with 740 KB of memory.

If you fast forward to today, you’ll see that Windows CE 5.0 and Windows Mobile 6.x shares some commonalities with their forefathers from the 80’s and 90’s.  The 32-bit embedded operating system that we rely on to power our Windows phones is made up of a bunch of slots.  The mobile applications that you build run inside one of these slots and unlike DOS with its 640 KB memory space, your app gets 32 MB of virtual memory space.  But just like with DOS, you don’t get access to the whole space because other things like system DLLs are already eating into your free virtual memory. 

Many of you might not care because you build simple apps that use very little memory.  On the other hand, most of the people and organizations I work with build the largest, most memory-intensive applications ever seen on the mobile device.  Needless to say, these folks aren’t too pleased that they don’t get the whole 32 MB of virtual memory that’s coming to them.  They probably wish they a utility like QEMM or MemMaker to put things in high memory.

I recently met with a good friend of mine who wanted to share some interesting findings with me.  Keep in mind, not only do I consider this person and his colleagues to be some of the top Compact Framework developers in the world, his team members designed and developed of one of the world’s largest, most complex managed apps running on a Windows Mobile device.  Like many organizations that have built very large Windows Mobile applications, free virtual memory issues and the “DLL Crunch” have deprived this app from of all the memory it would like to have.  One of the architects on this “Dream Team” noticed that by keeping their application’s EXE empty and putting all the forms, code, resources, and data in managed DLLs, he reduced the amount of virtual memory his app uses inside its slot while at the same time taking advantage of memory outside the slot in the 1 GB shared memory area.

To help you visualize this, I’m going to show you 2 pictures of the Windows Mobile process slots running a Compact Framework application two different ways.  The virtual memory viewer you see running in the emulators below shows the 32 slots in the User space of the OS.  Everything in Red is free virtual memory, Blue is committed memory and Green is reserved.  Slot 1 is crammed full of ROM DLLs and you can’t help but notice the area of Blue at the top of every other slot.  That’s space out of everyone’s slot being used by system and other native DLLs which means nobody’s going to get their fair share of their 32 MB slot space.

On the left you’ll see a NETCF app called StandardExe.exe running in slot 14 of the operating system.  This simple managed EXE has a 2.25 MB bitmap bound to it as a resource and a single form that compiles to the same size as the bitmap inside it.  If you look at the picture on the left, you’ll see a 2.25 MB Blue area coming up from the bottom of slot 14.  This represents the space being taken up by the EXE.

On the right a NETCF app called OptimizedExe.exe running in slot 11 of the operating system.  This managed EXE is completely empty.  The Main function calls into a static class of a managed DLL and that’s it.  No mas.  This results in an EXE with a file size of 5 KB.  In the managed DLL we have the same 2.25 MB bitmap bound to it as well as a simple form.  This compiles into a 2.25 MB DLL called OptimizedDLL.dll.  When you look at the picture on the right, you’ll be hard-pressed to see any Blue area coming up from the bottom of slot 11.  A closer look reveals the 2.25 MB DLL is nowhere to be found either.

This is pretty cool and has the potential to unleash the largest, most powerful games and applications Windows phones have ever seen.  So the big question is, how is this happening?  Is it magic? 

Those of you who have read Steven Pratschner’s blog know that the Compact Framework memory maps your managed EXE and DLLs into the 1 GB shared memory area outside the slot your app is running which is cool.  What you may not know is that the OS automatically blocks out virtual memory at the bottom of your slot that’s the same size as your EXE.  So even though the CLR is in control of app execution and is giving you lots of love by putting your managed EXE up in the shared memory area, Windows CE takes away a valuable chunk of memory because it thinks that’s where your EXE is running.  Guess what, your app isn’t running there and it’s not native.  For those of you with giant managed EXEs, you’re losing out on a lot of virtual memory in your slot that could be put to good use.  So the first lesson here is to do what Brian did and make your EXE nothing but an empty stub used to launch your app which really lives inside managed DLLs.

Your empty EXE code should look like the following:

using System;

namespace OptimizedExe
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [MTAThread]
        static void Main()
        {
            OptimizedDLL.StartUp.Main();
        }
    }
}

Your DLL code should look like the following:

using System;
using System.Windows.Forms;

namespace OptimizedDLL
{
    public class StartUp
    {
        public static void Main()
        {
            Application.Run(new Main());
        }
    }
}

So now that you’ve learned how to instantly give your managed apps more memory by beating Windows CE at its own game, let’s talk about the curious case of your managed DLL.  If you’ve read Reed Robison’s blog discussion about Slaying the Virtual Memory Monster, you know that DLLs seem to take up everyone’s virtual memory from the top of the slot down which doesn’t sound too fair.  DLLs keep pushing their way down everyone’s slot causing something we call the “DLL Crunch” as free virtual memory get’s squeezed between the DLLs and EXEs.  I’ve got some good news for you.  Managed DLLs do not exhibit this same behavior.  In fact, not only do they not use up memory in all the other slots of your Windows phone, they don’t even push downward on the memory of your own slot.  How could this be?

Managed DLLs are not DLLs.  The CLR just treats them as files that it memory maps into the 1 GB shared memory area.  To the Compact Framework, managed EXE and DLL assemblies are just files full of IL that it maps outside your process slot.  So now you know where the 2.25 MB bitmap that we bound to OptimizedDLL.dll is.  It’s beyond the 32 MB barrier of your slot and therefore not using up your valuable memory. 

So if I follow this new pattern for NETCF development, will my slot ever have virtual memory allocated or do I get a free lunch?

While there’s no free lunch, you did get a buy one get one free discount.  The JIT compiler is running in your slot and it pulls in IL from the 1 GB space as needed to compile the current call stack.  Resources that aren’t designed to be compiled or executed will never be pulled down here.  The GC Heap is in your slot and that’s where your currently allocated Objects and instance variables are hanging out.  Your slot maintains a 64 KB Stack for every Thread your app spawns and the AppDomain Heap maintains a representation of the data structures found in your assembly’s IL.

So what are the big takeaways here?

You can eliminate the erroneous and wasted allocation of EXE virtual memory in your slot by following the pattern of using an empty stub managed EXE to kick off your application.  Windows CE will now only block out 5 KB of memory.

You can take better advantage of the 1 GB shared memory area by putting your entire application inside managed DLLs.  This will make your app a good neighbor by not creating the dreaded “DLL Crunch” for all the other apps on your Windows phone.  It also reduces the amount of memory that has to be allocated inside your slot.

This new pattern of managed development on the Windows Mobile platform is a true breakthrough in memory management.  Come join me at Tech Ed 2009 this May in Los Angeles for a complete deep dive on this new way of building memory-intensive games and applications.

- Rob