AWS

Business users: How does a 10.1-inch slate running Windows 8 Pro with eight to ten hours of battery life sound to you? Source: All About Microsoft

A new iteration of the Redis on Windows in-memory database technology is now available in GitHub. Source: All About Microsoft

Microsoft publicly says Bing is a core strategic asset for the company. But privately, could the Softies be exploring ways to offload it? Source: All About Microsoft

The patched version of the latest set of updates for Microsoft’s Office for Mac 2011 is available for download. Source: All About Microsoft

Severity Rating: Critical Revision Note: V2.0 (April 26, 2012): Added Service Pack 1 versions of SQL Server 2008 R2 to the Affected Software and added an entry to the update FAQ to explain which SQL Server 2000 update to use based on version ranges. These are informational changes only. There were no changes to the security update files or detection logic. For a complete list of changes, see the entry to the section, Frequently Asked Questions (FAQ) Related to This Security Update. Summary: This security update resolves a privately disclosed vulnerability in Windows common controls. The vulnerability could allow remote code execution if a user visits a website containing specially crafted content designed to exploit the vulnerability. In all cases, however, an attacker would have no way to force users to visit such a website. Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that takes them to the attacker's website. The malicious file could be sent as an email attachment as well, but the attacker would have to convince the user to open the attachment in order to exploit the vulnerability. View this security bulletin

Microsoft’s streaming music-service complement to the current Zune Music platform may get its debut at the E3 conference in June, according to a new report. Source: All About Microsoft

Add another patent-licensee to the pool of Android/Chrome-based device makers Microsoft is convincing to pay for its IP. Source: All About Microsoft

Microsoft has released a new version of its Security Essentials software for Windows XP, Windows Vista and Windows 7 PCs. Source: All About Microsoft

The recent blog post await[/b] keyword in C# and Visual Basic enables developers to use WinRT asynchronous operations while still maintaining and reasoning about good control flow. In this follow-on post, I dive much deeper into exactly how await works with WinRT. This knowledge will make it easier for you to reason about code that uses await, and as a result, will enable you to write better Metro style apps. To start, let’s ground ourselves by taking a look at a world without await. Reviewing the basics All of asynchrony in WinRT is rooted in a single interface: IAsyncInfo. Every asynchronous operation in WinRT implements this interface, which provides the base functionality necessary to walk up to an asynchronous operation and inquire about its identity and status, and to request its cancellation. But this particular interface lacks what’s arguably the most important aspect of an asynchronous operation: a callback to notify a listener when the operation has completed. That capability is purposefully separated out into four other interfaces that all require IAsyncInfo, and every asynchronous operation in WinRT implements one of these four interfaces: These four interfaces support all combinations of with-and-without results, and with-and-without progress reporting. All the interfaces expose a Completed property, which can be set to a delegate that is invoked when the operation completes. You may set the delegate only once, and if it’s set after the operation has already completed, it is immediately scheduled or invoked, with the implementation handling the race between the operation completing and the delegate being assigned. Now, let’s say I wanted to implement a Metro style app with a XAML Button, such that clicking the button queues some work to the WinRT thread pool to perform a computationally-intensive operation. When that work completes, the content of the button is updated with the result of the operation. How might we implement this? The WinRT ThreadPool class exposes a method to asynchronously run work on the pool: We can use this method to queue our computationally-intensive work so as to avoid blocking our UI thread during its run: We now successfully offloaded the work from the UI thread to the pool, but how do we know when the work is done? RunAsync returns an IAsyncAction, so we can use a completion handler to receive that notification and run our continuation in response: Now when the asynchronous operation queued to the ThreadPool completes, our Completed handler is invoked and tries to store the result into our button. Unfortunately, this is currently broken. The Completed handler is unlikely to be invoked on the UI thread, and yet, to modify btnDoWork.Content, the handler needs to be running on the UI thread (if it doesn’t, an exception with the error code RPC_E_WRONG_THREAD will result). To deal with this, we can use the CoreDispatcher object associated with our UI to marshal the invocation back to where we need it to be: This is now functional. But what if the Compute method throws an exception? Or what if someone calls Cancel on the IAsyncAction returned from ThreadPool.RunAsync? Our Completed handler needs to deal with the fact that the IAsyncAction may end in one of three terminal states: Completed, Error, or Canceled: That’s a fair amount of code to write to handle a single asynchronous invocation imagine what it would look like if we needed to perform many asynchronous operations in sequence? Wouldn’t it be nice if we could instead write code like this? This code behaves exactly like the previous code. But we don’t need to deal manually with completion callbacks. We don’t need to marshal back manually to the UI thread. We don’t need to explicitly check completion status. And we don’t need to invert our control flow, which means this is now trivial to extend with more operations, e.g. to do multiple computations and UI updates in a loop: Take just a moment to think through the code that you would have had to write to achieve that using the IAsyncAction manually. This is the magic of the new async/await keywords in C# and Visual Basic. The good news is that you can in fact write this exact code, and it’s not actually magic. Through the rest of this post, we explore exactly how this works behind the scenes. Compiler transformations Marking a method with the async keyword causes the C# or Visual Basic compiler to rewrite the method’s implementation using a state machine. Using this state machine the compiler can insert points into the method at which the method can suspend and resume its execution without blocking a thread. These points aren’t inserted haphazardly. They’re inserted only where you explicitly use the await keyword: When you await an asynchronous operation that’s not yet completed, the compiler’s generated code ensures that all of the state associated with the method (e.g. local variables) is packaged up and preserved on the heap. Then the function returns to the caller, allowing the thread on which it was running to do other work. When the awaited asynchronous operation later completes, the method’s execution resumes using the preserved state. Any type that exposes the await pattern can be awaited. The pattern consists primarily of exposing a GetAwaiter method that returns a type that provides IsCompleted, OnCompleted, and GetResult members. When you write: the compiler generates code that uses these members on the instance something to check whether the object is already completed (via IsCompleted), and if it’s not completed, to hook up a continuation (via OnCompleted) that calls back to continue execution when the task eventually completes. After the operation is completed, any exceptions from the operation are propagated and/or a result returned (via GetResult). So, when you write this: the compiler translates that into code similar to this: For the method btnDoWork_Click, the compiler generates a state machine class that contains a MoveNext method. Every call to MoveNext resumes the execution of the btnDoWork_Click method until it reaches the next await on something that’s not yet completed, or until the end of the method, whichever comes first. When the compiler-generated code finds an awaited instance that’s not yet completed, it marks the current location with a state variable, schedules execution of the method to continue when the awaited instance completes, and then returns. When the awaited instance eventually completes, the MoveNext method is invoked again and jumps to the point in the method where execution previously left off. The compiler doesn’t actually care that an IAsyncAction is being awaited here. All it cares about is that the right pattern is available with which to bind. Of course, you’ve seen what the IAsyncAction interface looks like, and you’ve seen that it doesn’t contain a GetAwaiter method like that expected by the compiler. So how is it that this successfully compiles and runs? To best understand that, you first need to understand the .NET Task and Task types (the Framework’s core representation of asynchronous operations), and how they relate to await. Converting to tasks The .NET Framework 4.5 includes all the types and methods necessary to support awaiting Task and Task instances (Task derives from Task). Task and Task both expose GetAwaiter instance methods, which respectively return TaskAwaiter and TaskAwaiter types that expose the necessary IsCompleted, OnCompleted, and GetResult members sufficient to satisfy the C# and Visual Basic compilers. IsCompleted returns a Boolean indicating whether the task is done executing as of the moment the property is accessed. OnCompleted hooks up to the task a continuation delegate that is invoked when the task completes (if the task is already completed when OnCompleted is invoked, the continuation delegate is scheduled for execution asynchronously). GetResult returns the result of the task if it ended in the TaskStatus.RanToCompletion state (it returns void for the non-generic Task type), throws an OperationCanceledException if the task ended in the TaskStatus.Canceled state, and throws whatever exception caused the task to fail if the task ended in the TaskStatus.Faulted state. If we have a custom type that we want to support awaiting, we have two primary options. One option is to implement the whole await pattern manually for our custom awaitable type, providing a GetAwaiter method that returns a custom awaiter type that knows how to deal with continuations and exception propagation and the like. The second is to implement the ability to convert from our custom type to a task, and then just rely on the built-in support for awaiting tasks to await our special type. Let’s explore this latter approach. The .NET Framework includes a type called TaskCompletionSource, which makes these kinds of conversions straightforward. TaskCompletionSource creates a Task object and gives you SetResult, SetException, and SetCanceled methods that you use to directly control when and in what state the corresponding task completes. So, you can use a TaskCompletionSource as a kind of shim or proxy to represent some other asynchronous operation, such as a WinRT asynchronous operation. Let’s pretend for a moment that you didn’t already know you could directly await WinRT operations. How then could you enable doing so? You could create a TaskCompletionSource, use that as a proxy to represent the WinRT async operation, and then await the corresponding task. Let’s try. First, we need to instantiate a TaskCompletionSource such that we can await its Task: Then, just as we saw in our earlier example of manually using WinRT async operations’ Completed handlers, we need to hook up a callback to the async operation so that we know when it completes: And then in that callback, we need to transfer the IAsyncOperation’s completion state over to the task: That’s it. WinRT async operations ensure that the Completed handler is invoked appropriately even if the handler is signed up after the operation has already completed, so we don’t need to do anything special for signing up the handler racing with the operation’s completion. WinRT async operations also take care to drop the reference to the Completed handler after the operation has completed, so we don’t need to do anything special to set Completed to null when our handler is invoked in fact, the Completed handler is set-once, meaning that after you set it, you get an error if you try to set it again. With this approach, there’s a one-to-one mapping between how the state in which the WinRT async operation completes and the state in which the representing task completes: Terminal AsyncStatus Converts to TaskStatus Which when awaited... Completed RanToCompletion Returns the operation’s result (or void) Error Faulted Throws the failed operation’s exception Canceled Canceled Throws an OperationCanceledException Of course, the boilerplate code we wrote to handle this one await would become tedious very quickly if we had to write it every time we wanted to await a WinRT asynchronous operation. As good programmers, we can encapsulate that boilerplate into a method we can use over and over again. Let’s do so as an extension method that converts the WinRT async operation into a task: With that extension method, I can now write code like: or even more simply as: Much better. Of course, this kind of cast-like AsTask functionality will be in hot demand by anyone using WinRT from C# and Visual Basic, so you don’t actually need to write your own implementation: there are already such methods built into .NET 4.5. The System.Runtime.WindowsRuntime.dll assembly contains these extension methods for the WinRT async interfaces: Each of the four interfaces has a parameterless AsTask overload similar to the one we just wrote from scratch. In addition, each also has an overload that accepts a CancellationToken. This token is the common mechanism in .NET used to provide composable and cooperative cancellation you pass a token into all of your asynchronous operations, and when cancellation is requested, all of those async operations will have cancellation requested. Just for illustration (because as you now know such an API is already available), how might we build our own such AsTask(CancellationToken) overload? CancellationToken provides a Register method that accepts a delegate to be invoked when cancellation is requested we can simply provide a delegate then that calls Cancel on the IAsyncInfo object, forwarding along the cancellation request: Although the implementation that ships in .NET 4.5 isn’t exactly like this, logically it’s the same. For IAsyncActionWithProgress and IAsyncOperationWithProgress, there are also overloads that accept an IProgress. IProgress is a .NET interface that methods can accept to report back progress, and the AsTask method simply wires up a delegate for the WinRT async operation’s Progress property so that it forwards the progress info to the IProgress. Again, just as an example for how this might be implemented manually: Directly awaiting WinRT async We’ve now seen how it’s possible to create tasks to represent WinRT async operation such that we can then await those tasks. But what about directly awaiting the WinRT operations? In other words, it’s fine to be able to write: but for cases where we don’t need to supply a CancellationToken or an IProgress, wouldn’t it be nice to avoid coding the call to AsTask at all? Of course, this is possible, as we have seen at the beginning of this post. Remember how the compiler expects to find a GetAwaiter method that returns an appropriate awaiter type? The aforementioned WindowsRuntimeSystemExtensions type in System.Runtime.WindowsRuntime.dll includes just such GetAwaiter extension methods for the four WinRT async interfaces: Note the return type from each of these methods: TaskAwaiter or TaskAwaiter. Each of these methods is taking advantage of the existing task awaiters built into the Framework. Knowing what you now know about AsTask, you can probably guess how these are implemented. The real implementation in the Framework is almost exactly like this: This means that these two lines both result in exactly the same behavior: Customizing await behavior As mentioned previously, TaskAwaiter and TaskAwaiter supply all of the members necessary to meet the compiler’s expectation of an awaiter: The most interesting member here is OnCompleted, as it’s the one responsible for invoking the continuation delegate when the awaited operation completes. OnCompleted provides special marshaling behavior to ensure that the continuation delegate is executed in the right place. By default, when the task’s awaiter’s OnCompleted is called, it notes the current SynchronizationContext, which is an abstract representation of the environment in which the code is executing. On the UI thread of a Metro style app, SynchronizationContext.Current returns an instance of the internal WinRTSynchronizationContext type. SynchronizationContext provides a virtual Post method that accepts a delegate and executes that delegate in an appropriate place for the context WinRTSynchronizationContext wraps a CoreDispatcher and uses its RunAsync to invoke the delegate back on the UI thread asynchronously (just as we manually did earlier in this post). When the awaited task completes, the delegate passed to OnCompleted is Post’ed for execution to the captured SynchronizationContext that was current when OnCompleted was invoked. This is what allows you to write code using await in your UI logic without worrying about marshaling back to the right thread: task’s awaiter is handling it for you. Of course, there may be situations in which you don’t want this default marshaling behavior. Such situations occur frequently in libraries: many kinds of libraries don’t care about manipulating UI controls or the particular threads on which they execute, and thus from a performance perspective, it’s helpful to be able to avoid the overhead associated with cross-thread marshaling. To accommodate code that wants to disable this default marshaling behavior, Task and Task provide ConfigureAwait methods. ConfigureAwait accepts a Boolean continueOnCapturedContext parameter: passing true means to use the default behavior, and passing false means that the system doesn’t need to forcefully marshal the delegate’s invocation back to the original context and can instead execute the delegate wherever the system sees fit. Given that, if you want to await a WinRT operation without forcing the rest of the execution back to the UI thread, instead of writing either: or: you can write: or just: When to use AsTask If all you want to do is invoke a WinRT asynchronous operation and wait for it to complete, directly awaiting the WinRT asynchronous operation is the simplest and cleanest approach: But as soon as you want more control, you’ll need to use AsTask. You’ve already seen a few such cases where this is useful: Supporting cancellation via CancellationToken Supporting progress reporting via IProgress Suppressing the default continuation marshaling behavior via ConfigureAwait There are also additional important situations where AsTask can be quite useful. One situation has to do with Task’s ability to support multiple continuations. The WinRT async operation types support only a single delegate registered with Completed (Completed is a property rather than an event), and it may be set only once. This is fine for the majority of cases where you simply want to await the operation once, e.g. instead of calling a synchronous method: you call and await an asynchronous counterpart: logically maintaining the same control flow as if you used the synchronous counterpart. But sometimes you want to be able to hook up multiple callbacks, or you want to be able to await the same instance multiple times. In contrast to the WinRT async interfaces, the Task type does support being awaited any number of times and/or having its ContinueWith method being used any number of times to support any number of callbacks. Thus, you can use AsTask to get a task for your WinRT async operation, and then hook up your multiple callbacks to the Task rather than to the WinRT async operation directly. Another example where AsTask can be useful is when dealing with methods that operate in terms of the Task or Task types. Combinator methods like Task.WhenAll or Task.WhenAny operate in terms of Task, not in terms of the WinRT async interfaces. So, if you wanted to be able to invoke multiple WinRT async operations and then await for all or any of them to complete, you could use AsTask to make this easy. For example, this await completes as soon as any of the three supplied operations complete, and returns the Task representing whichever it was: Conclusion It’s truly exciting how much functionality WinRT via asynchronous operations provide the volume of such APIs exposed speaks to just how important responsiveness is to the platform. This in turn places a significant demand on the programming model used to work with these operations: for C# and Visual Basic code, await and AsTask rise to the occasion. Hopefully this blog post has peeled back the curtain sufficiently to give you a good sense of exactly how these capabilities work and enable you to productively develop Metro style apps. For more info, I recommend these resources: [url=http://msdn.microsoft.com/en-us/async">Visual Studio Async Programming [url=http://blogs.msdn.com/b/pfxteam/archive/2012/04/12/10293335.aspx">Async/Await FAQ [url=http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-810T">Async made simple in Windows 8, with C# and Visual Basic Stephen Toub Visual Studio View the full article

Microsoft is tweaking SharePoint Online storage quotas and pricing for enterprise users of its hosted service. Source: All About Microsoft

Live Mesh, Microsoft’s PC-to-PC sync service, has been meandering down a long and winding road since 2008. Are its final days in sight? Source: All About Microsoft

The next public Windows 8 test build is due the first week of June., just in time for Computex 2012. Source: All About Microsoft

In one smooth move, Microsoft is pocketing $550 million by selling hundreds of patents it bought from AOL to Facebook. Source: All About Microsoft

Microsoft has announced the rumored paid storage tiers for SkyDrive, its cloud storage service, and has rolled out previews of new SkyDrive apps for Windows and Mac OS X Lion. Source: All About Microsoft

Over the last year we’ve been hard at work building SkyDrive alongside Windows 8, setting out a unique approach to designing personal cloud storage for billions of people by bringing together the best aspects of file, app, and device clouds. Meanwhile, we’ve made our file cloud more accessible with HTML5 and mobile apps, improved integration with Office and 3rd party apps, and built a device cloud for Windows and Windows Phone. Today, we’re excited to take another big step towards our vision by making SkyDrive far more powerful. There are new storage options, apps that connect your devices to SkyDrive, and a more powerful device cloud that lets you “fetch” any file from a Windows PC. Taken together with access from popular mobile phones and a browser, you can now take your SkyDrive with you anywhere, connect it to any app that works with files and folders, and get all the storage you need—making SkyDrive the most powerful personal cloud storage service available. Here’s what’s available for use, starting now: SkyDrive for the Windows desktop (preview available now). View and manage your personal SkyDrive directly from Windows Explorer on Windows 8, Windows 7, and Windows Vista with this new preview app available in 106 languages worldwide. Fetching files through SkyDrive.com. Easily access, browse, and stream files from a remote PC running the preview app to just about anywhere by simply fetching them via SkyDrive.com. SkyDrive storage updates. A new, more flexible approach to personal cloud storage that allows power users to get additional paid storage as their needs grow. SkyDrive for other devices. We’ve updated the SkyDrive apps on Windows Phone and iOS devices, bringing better management features and sharing options to those devices. We’re also releasing a new preview client for Mac OS X Lion, letting you manage your SkyDrive right from the Finder. You can download the new SkyDrive apps now, but you might want to take a look at this video first, which gives you a glimpse of all the things you can do with the new SkyDrive. Download this video to view it in your favorite media player: High quality MP4 | Lower quality MP4 SkyDrive for Windows In February, we announced a SkyDrive Metro style app for Windows 8, SkyDrive for the Windows desktop, and a feature called “fetch” that allows you to remotely access files or stream videos from a connected PC. When you combine all of these features, you can seamlessly access any file on your Windows 8 PC from anywhere. The SkyDrive Metro style app was first made available with the Windows 8 Consumer Preview, and today we’re releasing a preview of SkyDrive for the Windows desktop including ”fetch” support. But first, here’s a little background. Over the years, we’ve consistently heard from our most loyal customers that having SkyDrive accessible from Windows Explorer is important, and we’re happy to announce that, as of today, when you download the preview of SkyDrive for the Windows desktop, you’ll be able to access your SkyDrive from Windows Explorer on Windows 8, Windows 7, and Windows Vista. The benefits of SkyDrive integration with Windows are clear: you can now drag-and-drop to and from SkyDrive with files up to 2GB, access all of your files offline, and have the full power of Windows Explorer available to manage your SkyDrive files and folders. Files stored in your SkyDrive are in a plain folder on your PC, which means any app that works with local folders and files can now work with SkyDrive. As we set upon the path to bring SkyDrive closer to Windows, we had a few goals that drove our plan. First, we wanted you to be able to “get up and running” as quickly as possible, with very few steps. Secondly, we wanted to “be quiet” on the system and make sure that all processing was entirely in the background, with your needs and your apps as the first priority. And third, we really wanted it all to “just work” as you’d expect it to, staying up-to-date automatically, and humming along without confusing dialogs or pop-ups. Here’s a bit more about where we’re at for each of those. Downloading the preview of SkyDrive for Windows takes just a few seconds on most connections (the installer is under 5MB) and installs on most PCs in less than 10 seconds. There are just three simple setup screens and you’re finished. . Once it’s running, it’s out of the way in the system tray. A folder is created automatically for you in a default location or one you choose during setup, and your SkyDrive files immediately start to appear. . Once your SkyDrive is available on your PC, this special folder stays in sync with your SkyDrive. If you rename a file on your phone, it appears immediately in this folder on your PC. If you delete a file from SkyDrive.com, it is deleted immediately here as well. Or if you create a folder and move files from another PC, Mac, or iPad, those changes immediately sync, too. . Power users can have fun with the SkyDrive folder too In Windows Live Mesh, which some of you have come to rely on, we allowed arbitrary folders to be synchronized. Our experience has been that this introduced too many unresolvable complexities across different PCs, with the path on one PC synchronizing to entirely different paths on other PCs and the cloud. In order to maintain our goal of “it just works,” we designed SkyDrive to be the same everywhere, and to work well with libraries in Windows. If you’d like your SkyDrive folders to feel less like separate folders, you can add your SkyDrive Documents and Pictures folders to your Documents and Pictures Libraries in Windows 8 and Windows 7. Alternatively, you could change the target location for special folders like Documents or Pictures (or others) to folders in your SkyDrive, basically treating your SkyDrive as your primary drive (right-click the Documents folder, click Properties, and then Location). You can also customize the default root of the synchronized folder (to use a different drive, for example), and this option is available during setup of the SkyDrive app. So, as you can see, the simple and straightforward model of having a single folder for your SkyDrive still leaves lots of creative options for personalization. Fetching files through SkyDrive.com As we discussed and demonstrated back in February, with SkyDrive running on a Windows PC, you can also turn that PC into your own private cloud to browse your files and stream videos from anywhere through SkyDrive.com. This feature is great if you forgot something on your home PC and need to fetch it or just copy it quickly to SkyDrive. . Note that, in order to access a remote PC you will have to provide a second factor of authentication beyond your account password. You’ll need to enter a code that we send to your mobile phone or alternate email address even if you’re already signed in to your SkyDrive account (if you’re already on a trusted PC, you won’t have to do this every time, and it is easy to do this one-time setup). This means that anyone wanting access to your remote PC would have to have access not only to your account, but also to either an alternate email or your phone (which they would need to physically possess). New, more flexible approach to storage One of the challenges in building personal cloud storage for billions of people is scaling capacity and managing costs, while also meeting the needs of both enthusiasts and mainstream users. Different cloud providers take different approaches. Many promise unlimited storage or big referral incentives to attract enthusiasts – but then have lots of strings attached, which can make the service more confusing and less accessible to mainstream users. Do I really have to read multiple pages to understand my storage limits? Why do other people’s files count against my storage limit? Why does my upload speed slow down? Why do I get gobs of free storage but have to pay to sync my desktop files? Our model for SkyDrive is friendly and accessible to all, and just as importantly, provides a gimmick-free service that strikes the right balance of being free for the vast majority of customers, and low-priced for those who want more. Starting today, we are now offering: 7GB free for all new SkyDrive users. We chose 7GB as it provides enough space for over 99% of people to store their entire Office document library and share photos for several years, along with room for growth. To put things in perspective, 99.94% of SkyDrive customers today use 7GB or less – and 7GB is enough for over 20,000 Office documents or 7,000 photos. Since the current base of customers using SkyDrive tilts towards enthusiasts, we are confident that, as we expand the range of people using SkyDrive, this 7GB free limit will prove to be more than enough for even more people. . Ability to upload large files – up to 2GB – and folders using SkyDrive for the Windows desktop or SkyDrive for OS X Lion. Paid storage plans (+20GB, +50GB, +100GB) so that power users who need more storage can easily add more at competitive prices (US$10/year, US$25/year, US$50/year). Please note that paid-for storage requires the ability to pay by credit card (or via PayPal, in some markets) and a Windows Live ID that can be associated with that credit card or PayPal account. We know that many of you signed up for a service that offered 25GB, and some are already using more than 7GB of storage. So, starting today, for a limited time, any registered SkyDrive user *who has uploaded files to SkyDrive* as of April 22nd can opt in to keep 25GB of free storage while still getting all of the benefits of the new service. (For users who are already using more than 4GB as of April 1, we’ve automatically opted you in to 25GB of free storage to avoid any issues.) Just sign in here or view our FAQ. SkyDrive for Windows Phone and other devices SkyDrive has been available since 2007 from anywhere in the world through SkyDrive.com, but it wasn’t until the initial release of Windows Phone and our dedicated Windows Phone and iPhone apps in December 2011 that people had top-notch SkyDrive experiences from modern smartphones. These apps have been installed on over 2 million phones already by people taking SkyDrive with them wherever they go. As a Windows Phone or iPhone user, with today’s release, you can now delete, rename, and move files in your SkyDrive, and access a full set of sharing options for all files and folders. We’re also bringing SkyDrive to the iPad, with all the same capabilities you now have available through the iPhone, plus support for the new iPad retina display. . . . All of these apps also have dozens of small improvements, including the ability to see your remaining storage space, landscape support, and various performance enhancements and bug fixes. Almost 70% of Mac users also regularly use a Windows PC. Since we want every customer to be able to rely on SkyDrive to access files anywhere, it’s important for SkyDrive be wherever they are. Office for Mac 2011 already supports SkyDrive files, but starting today, you’ll also be able to manage your entire SkyDrive offline using Finder on the Mac. The integration with Finder means that any Mac app that opens from or saves to the file system will be able to take advantage of SkyDrive files as well. . Here’s where you go to try SkyDrive today: Get SkyDrive for Windows (preview) Get SkyDrive for Windows Phone Get SkyDrive for iPhone and iPad Get SkyDrive for OS X Lion (preview) If you currently use Mesh, we have a few tips for trying SkyDrive for Windows or Mac (preview) side-by-side with Mesh. We think you'll find SkyDrive to be increasingly useful over time. Source: Windows 8 Blog

The 1.0 version of Skype for Windows Phone is available in the Marketplace as of April 22. Source: All About Microsoft

What’s coming in the Exchange Server 15 component of Microsoft’s next wave of Office wares? Here’s some scuttlebutt from my sources. Source: All About Microsoft

Will Windows on ARM devices find an accepting home in the corporate world? Microsoft has some manageability plans to try to keep consumers and IT admins both happy. Source: All About Microsoft

One of the major trends in IT in recent years has been the drive towards consumerization of IT, which is a term describing how consumer technology, from phones to PCs, is bleeding into business organizations in all forms and fashions. And increasingly, the devices that are showing up are owned by and liable to the employee rather than the organization they work for. We see this most notably in the smartphone device category, but more recently also in tablets or other portable PC form factors that are increasingly showing up in the workplace. As organizations embrace consumerization, IT must consider how much control they can exert over a users personally-owned device, and how much management is good enough. These questions were top of mind for us as we began our journey to Windows 8, and particularly, as we built Windows for the ARM processor architecture. Our focus has been on how we can continue to deliver PCs and software that users need, like applications and data-access on any device, with enough IT control to assert that the device is trustworthy, while avoiding any compromise of the users privacy on their personal device. In Stevens earlier blog post about Line-of-Business applications and the WOA management client[/size] Demand for access to the business apps that users rely on - from email to licensed software from an independent software vendor to home-grown apps developed by IT - is one of the most important use cases for consumer devices in the enterprise. We know that developers are going to find it easy and convenient to build elegant Metro style apps that automatically work on any Windows 8 system including WOA, and developers of line-of-business (LOB) apps wont be any different. But many organizations want to directly control and manage access to their internal LOB apps, including the distribution of the app binaries for installation. For these organizations, publishing their LOB apps to the public Windows Store doesnt make sense, since there is no reason to broadcast these applications to others or to have their application deployment managed through the Windows Store process. And access to these resources and the data that they expose requires an assurance to IT that the systems accessing them meet an established bar for security and data protection. Organizations have been dealing with apps on x86/64 machines for a long time using a variety of tools and methods, including management products like System Center Configuration Manager and Windows Intune. Management of Metro style LOB apps on x86/64 will be able to leverage those same existing tools and methods and only requires that the client be configured to trust the apps that come from a source other than the Windows Store. For more information on the base capabilities of adding and removing Metro style apps on x86/64, see [url=http://technet.microsoft.com/en-us/library/hh852635.aspx" target="_blank">How to Add and Remove Apps. Developing WOA, however, provided us a unique opportunity to architect how LOB apps can be delivered to users in a way that meets the needs of IT while continuing to guarantee a consistent and reliable end-to-end experience over the life of the PC. For WOA, we have integrated a new management client that can communicate with a management infrastructure in the cloud to deliver LOB apps to users. Youll hear more about this management infrastructure at a later date from our friends on the [url=http://blogs.technet.com/b/systemcenter/" target="_blank">System Center blog, so this post will focus on the benefits and capabilities of the WOA management client itself. There are actually two parts to the WOA management client: the built-in system component, which well call the agent and a Metro-style app, which well call the self-service portal, or SSP, that the consumer uses to browse for and install LOB apps made available to them. Both parts of the WOA management client are well behaved Windows 8 apps in terms of user experience, power management/battery life, network awareness (for metered networks), and overall functionality. The agent does most of the heavy lifting on the client. It configures the client to communicate with the organizations management infrastructure periodically synchronizes with the management infrastructure to check for any updated LOB apps and apply the latest settings policies configured by IT for the device and handles the actual download and installation of any LOB apps that the user wants to install. Finally, if the user or the administrator chooses to remove the device from the management infrastructure, it clears the configuration of the agent itself and disables any LOB apps the user installed from the SSP. Connecting to the management infrastructure Lets explore some of these elements in more detail, starting with connecting the client to the management infrastructure. In truth, this step begins with the IT admin who specifies the group of Active Directory (AD) domain users who are authorized to connect devices into the service. The admin also has the option to specify the maximum number of devices allowed per user. For authorized users, the actual steps to connect a device are quite simple. Using a new Control Panel applet on their WOA device, the user supplies their company email address and password, just like they do to set up an Exchange email account. The agent then performs a service lookup to locate the organizations management infrastructure based on the users email address. [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/5633.Fig1_5F00_6F98511C.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/4150.Fig1_5F00_thumb_5F00_485E07E7.png Connecting to your management infrastructure is as easy as entering your company email address and password Once the agent has found the right address, it establishes a secure connection to the management infrastructure using [url=http://en.wikipedia.org/wiki/Secure_Socket_Layer" target="_blank">SSL Server Authentication and authenticates the user. If the user is successfully authenticated and has been authorized by the admin to connect devices, the service issues a user certificate to the user who initiated the connection. This certificate is sent back to the agent along with the organization root certificate and instructions for the agent, which it uses to configure its ongoing communications with the management infrastructure. All of this happens in a matter of seconds and typically requires no further interaction from the user. Once complete, the user is directed to install the SSP while the agent completes the connection in the background. [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6201.Fig2_5F00_4F11116A.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/8666.Fig2_5F00_thumb_5F00_27D6C835.png [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/0250.Fig3_5F00_52AF2C47.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/0334.Fig3_5F00_thumb_5F00_6E53B83D.png Completing the connection Next, the agent automatically initiates a session with the management infrastructure, using the user certificate to authenticate. This session and any subsequent sessions are performed using SSL Mutual Authentication to ensure the security of the connection. This initial session completes the registration of the device with the service by supplying some basic device information such as the make and model, the OS version, device capabilities, and other hardware information. This allows IT admins to monitor what types of devices are connecting to the organization, so they can improve the apps and services they deliver to users over time. Following the initial session, the agent initiates communication with the management infrastructure in two circumstances: First, as a maintenance task that runs daily at a time that the user can configure on the client. The activities performed during these maintenance sessions focus on reporting updated hardware information to the management infrastructure, applying changes to the settings policies for the device, reporting compliance back to the management infrastructure, and applying app updates to LOB apps, or retrying any previously failed LOB app installations initiated from the SSP. Secondly, the agent will communicate with the management infrastructure anytime the user initiates an app installation from the SSP. These user-initiated sessions are solely focused on app installation and do not perform the maintenance and management activities described in the first case. Regardless of whether a session is initiated automatically by a scheduled maintenance task or manually by the user, the WOA management client continues to behave well relative to the state of the battery on the device and its current network conditions. Settings policy management As already discussed, access to LOB apps typically requires systems to comply with basic security and data protection policies. From the management infrastructure, the IT admin is able to configure a set of policies that we believe are the most critical to give IT the assurances they need without seriously affecting the users experience with their device, including: Allow Convenience Logon Maximum Failed Password Attempts Maximum Inactivity Time Lock Minimum Device Password Complex Characters Minimum Password Length Password Enabled Password Expiration Password History Although our new WOA management client can only connect with a single management infrastructure at a time, we may decide to add other policy sources before we release Windows 8 and so weve architected the policy system to handle this. In the case where more than one policy exists for the same Windows 8 device, the policies will be merged and the most restrictive configuration will be selected for each. This resultant policy will apply to every administrative user on the Windows 8 device and every standard user with an Exchange account configured. Standard users who do not have an Exchange account will not be subject to the policy, but Windows 8 already restricts those users from accessing data in other users profiles and from privileged locations, thereby automatically protecting your corporate data. In addition to the configurable policies described above, the agent can also be used to automatically configure a VPN profile for the user, so that WOA devices easily connect to a corporate network without requiring any user action. Finally, the agent can also monitor and report on compliance of WOA devices for the following: Drive Encryption Status Auto Update Status Antivirus Status AntiSpyWare Status Leveraging this compliance information, IT admins can more effectively control access to corporate resources if a device is determined to be at risk. Yet once again, the users basic experience with the device is left intact and their personal privacy is maintained. Before we move on, lets consider a couple of the policies listed above and how they practically affect a Windows 8 system. First, well look at Allow Convenience Logon. Windows 8 offers users convenience login features, like biometric login or the [url=http://blogs.msdn.com/b/b8/archive/2011/12/16/signing-in-with-a-picture-password.aspx" target="_blank">picture password feature. These options maintain a high level of security for Windows 8 devices, while solving one of the biggest headaches for users and IT alike: forgetting your password. Yet some organizations may require additional time before they are ready to embrace these alternative logon methods, so the Allow Convenience Logon option lets IT manage when to allow convenience logins in their organization. Secondly, lets look at how drive encryption and Maximum Failed Password Attempts work together. You probably know people whove picked up their smartphone only to find that the device has wiped itself after their young child was playing with it and inadvertently entered the wrong password repeatedly. Nothing so severe will happen with your Windows 8 devices, fortunately. Windows 8 provides strong data protection already out of the box. So, when a user exceeds the password entry threshold, Windows will instead cryptographically lock all encrypted volumes and reboot the device into the Windows 8 recovery console. If your device has been lost or stolen, this effectively renders the device unreadable. But if youre simply the victim of your young son or daughter trying to get to Angry Birds while your device is locked, you can easily recover with the use of a recovery key that Windows 8 can automatically store on your behalf in your SkyDrive account. This way, you are able to get back up and running without enduring a lengthy wait to re-install all of your apps and copy down all of your data. LOB app management The features weve covered so far are obviously focused more on the mechanics of the management client and infrastructure along with the needs of the IT admin, but ultimately the entire solution exists to benefit the end user by enabling access to their LOB apps. Without such a benefit there's little reason a user would go through the trouble of using the enterprise management infrastructure. So lets dig deeper into LOB app delivery on the WOA platform. In our previous blog post about WOA, we told you that consumers obtain all software... through the Windows Store and Microsoft Update or Windows Update. Now, with the addition of the WOA management client, were adding a fourth trusted source of software for the WOA platform. As mentioned, the Metro style self-service portal app, or SSP, is the day-to-day interface for the corporate user to access their management infrastructure. Here they can browse to discover LOB apps that have been made available to them by the IT admin. There are actually four different types of apps that IT can publish for users in the SSP: Internally-developed Metro style apps that are not published in the Windows Store Apps produced by independent software vendors that are licensed to the organization for internal distribution Web links that launch websites and web-based apps directly in the browser Links to app listings in the Windows Store. This is a convenient way for IT to make users aware of useful business apps that are publicly available. Since the user specified his or her corporate credentials as part of the initial connection with the management infrastructure, the IT admin can then specify which apps are published to each user individually, based on the users AD domain user account, or as a member of AD user groups. As a result, the user only sees those apps that are applicable to them in the SSP. [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/0827.Fig4_5F00_192C1C50.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/5621.Fig4_5F00_thumb_5F00_1FDF25D3.png Browsing for LOB apps in the self-service portal (SSP) for a fictional company called Woodgrove NOTE: This screenshot shows an early prototype of the SSP and may not reflect the final product. Before any LOB apps can be delivered through the management infrastructure, there are two things that happen on the client. First, an activation key is issued by the management infrastructure and applied to the WOA device to allow the agent to install apps. Second, any certificates used to sign the LOB apps must be added to the certificate store on the device. In most cases, both the activation key and the root certificates are automatically applied during the first session after establishing the connection with the management infrastructure. Otherwise, they are automatically deployed during a subsequent session after the IT admin has turned on the feature in the management infrastructure. When the user chooses to install an app from the SSP, the request is sent to the management infrastructure and a download link is provided to the agent. The agent then downloads the app, verifies the validity of the content, checks the signature, and installs the app. All of this typically occurs within seconds and is generally invisible to the user. In the event that an error occurs during any part of this process (e.g. the location of the content is unavailable), the agent queues the app for a retry during its next regularly scheduled maintenance session. In either case, the agent reports the state of the installation back to the management infrastructure. [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/2072.Fig5_5F00_31BBB9A0.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/2480.Fig5_5F00_thumb_5F00_7185A025.png The details page of an app in the SSP, where the user can initiate installation NOTE: This screenshot shows an early prototype of the SSP, and may not reflect the final product. As part of its regular maintenance sessions, the agent will inventory which LOB apps are currently installed and report that information back to the management infrastructure so the IT admin can effectively manage their LOB apps. Only Metro-style apps that were installed via the SSP and the management client are included in this inventory from a WOA device. Apps installed from the Windows Store are never reported as part of the inventory. Anytime the IT admin publishes an update for an app that has been installed on a WOA device, the agent will automatically download and install the update during its next regular maintenance session. Disconnecting from the management infrastructure Finally, lets look at how to disconnect a device from the management infrastructure. Disconnecting may be initiated either locally by the user or remotely by the IT admin. User-initiated disconnection is performed much like the initial connection, and is initiated from the same location in the Control Panel. Users may choose to disconnect for any number of reasons, including leaving the company or getting a new device and no longer needing access to their LOB apps on the old device. When an admin initiates a disconnection, the agent performs the disconnection during its next regular maintenance session. Admins may choose to disconnect a users device after theyve left the company or because the device is regularly failing to comply with the organizations security settings policy. During disconnection, the agent does the following: Removes the activation key that allowed the agent to install LOB apps. Once removed, any Metro style apps that were installed via the SSP and management client are deactivated. Note, however, that the apps are not automatically removed from the device, but they can no longer be launched and the user is no longer able to install additional LOB apps. Removes any certificates that the agent has provisioned. Ceases enforcement of the settings policies that the management infrastructure has applied. Reports successful deactivation to the management infrastructure if the admin initiated the process. Removes the agent configuration, including the scheduled maintenance task. Once completed, the agent remains dormant unless the user reconnects it to the management infrastructure. Summary Given the trend towards consumerization of IT and our introduction of WOA with Windows 8, we wanted to rethink the way systems management is done. We worked to strike a balance between the sometimes competing needs of IT admins and the consumer who uses the device on a day-to-day basis. With the new WOA management client connecting to a management infrastructure in the cloud, we believe weve accomplished those goals, and we hope youll agree when you see it all in action. -- Jeffrey Sutherland Source: Windows 8 Blog

Microsoft has released a partial list of features in the coming Windows 8 Enterprise SKU for volume-license business users. Source: All About Microsoft

GesturePak is a new third-party toolkit for Kinect for Windows developers that requires little coding. Source: All About Microsoft

Microsoft is now disclosing publicly the new features it is adding to its Office 365 cloud for both small business and enterprise customers. Source: All About Microsoft

In Choosing delivery method for a notification [/size] Now that I know what I want the tiles to look like (see part 1 for a refresher) I need to figure out when to update them. There are 4 ways that an app can update its tile (see [url=http://msdn.microsoft.com/en-us/library/windows/apps/hh779721.aspx" target="_blank">Choosing a notification delivery method in the Dev Center). Apps can use local notifications to update their tile, which is useful if info changes while the app is running. Apps can schedule tile and toast updates to happen at precise times. Also, apps can use push or polling tile notifications to update their tiles from the cloud while they are not running. Polling is great for low-frequency broadcast content. Push is great for sending toast notifications, which need to arrive immediately, or tile updates that are targeted to individual users. In this post, I focus on polling updates and local updates. Polling for nearby food trucks Our app has two different kinds of info to update the tile with. The most important is the food trucks near the default lunch location of a user. Users set their default location for lunch inside the app when it runs. I use that default location info to update the tile and let the user know about food trucks near that location. The images here show the tiles for the app from part 1 of the post. Now let’s look at how to use polling to get these tiles to show up on our app’s tile. http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-51-31-metablogapi/5327.Wide_2D00_tile_2D00_update_5F00_1D58E5F6.png http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-51-31-metablogapi/6281.Square_2D00_tile_2D00_update_5F00_256EDE30.png Food trucks typically stay in one place for the entire day, or at least during the lunch hours. Because the locations of the food trucks don’t change often, I don’t need to update the tile in real time. Because of this, I can rule out push notifications, which are more useful for time-sensitive notifications. But I want this data to update at least once a day, so using periodic notifications that poll my web service for changes is my best option. Client implementation: polling for nearby food trucks The client-side implementation to set up periodic notifications takes just a few lines of code. We call [/b] each time a user launches the app or switches to it. This causes the URI passed to the API to be polled immediately and the tile to be updated at each app launch or switch. This is because the API call immediately reaches out to the cloud service URI and updates the tile. This behavior is very useful for debugging – we can test the polling of our cloud service without waiting for the next polling interval. The real question is what URI to provide to the startPeriodicUpdate API. In our case, I want to tell our cloud service to update the tile with info about a specific location. To protect the user’s location info, I don’t want to send out the exact location of the user to our service. Instead, I identify locations by the zip code that user provides within the app. To pass the zip code up to my web service, I attach a query string on the end of the polling URI to let our cloud service know which location to put on the tile: http://www.contoso.com/foodtrucks/tile.xml?zipcode=98052 In response to an HTTP GET of this URI, our web service returns the formatted tile notification XML for the zip code provided on the URI. Here’s the code to set up the polling, with the zip code hardcoded into the URI string. JavaScript: C#: Because a food truck can move during the day, I want to update the tile fairly frequently. In our case, I use an update interval of one hour to balance between load on our backend service and freshness of the info on the tile. After I call the startPeriodicUpdate API once, the tile continues to update once an hour, even if our app is not running. If I ever want to change the URI to poll, I just have to call the API again with a different URI. For example, if the user changes their default location to a different zip code, I update the URI with the correct zip code by calling startPeriodicUpdate again. If the user ever clears their default location, or wants to stop tile updates, the app can stop periodic updates by calling stopPeriodicUpdate API. For more info about how to use the startPeriodicUpdate API see [url=http://code.msdn.microsoft.com/windowsapps/Push-and-periodic-de225603" target="_blank">Push and periodic notifications client-side sample, and [url=http://msdn.microsoft.com/en-us/library/windows/apps/hh761476.aspx" target="_blank">How to set up periodic notifications for tiles in the Dev Center. Server implementation: polling for nearby food trucks We can implement the server side of our polled tile in nearly any service technology. Here I show some example PHP and ASP.NET code. When our web service is polled, it must respond to the HTTP GET request with XML that fits the tile XML schema. You can also use HTTPS so that the web service can protect the content as it’s sent over the wire. Cookies are not supported. All info that your service needs to respond to the request must be included as part of the URI. For that reason, our app uses query strings to pass the zip code. In the PHP code we look at next, I abstract away the access of our web service’s database. In real working code, the trucks variable returned by get_trucks_from_database() function would contain all of the info the web service needs to fill the tile template for a specified zip code. I simplified this service example code a bit, to focus on the XML the service will return. A real world web service deployment would consider performance, scalability, security, and a more maintainable architecture. PHP: The next code example is equivalent to the PHP code we just looked at. This ASP.NET Web Pages example shows a quick implementation of a tile service. For a full featured ASP.NET service, you would probably want to use the new ASP.NET Web API. ASP.NET Web API is built specifically for HTTP services like this. For more information about ASP.NET Web API, see [url=http://www.asp.net/web-api" target="_blank">http://www.asp.net/web-api. ASP.NET: Favorite food trucks Until now we looked at the content the app shows on the main tile. But sometimes a user would want to have a tile on their Start screen to track a specific food truck. In our app, I use the app bar to allow the user to pin a specific food truck to Start. These pinned tiles are called secondary tiles. After a user pins a secondary tile, we update that tile with info about that particular food truck by sending notifications to that tile. Pinning a food truck tile Pinning tiles allows our app to give a user direct access to specific content in our app from the Start screen. Secondary tiles can be used to launch our app directly into the part of the app that deals with the food truck that a user pinned. Pinned tiles can be created only from within an app. Users expect to be able to pin tiles by invoking the app bar. The app bar includes a standard a push-pin icon to indicate that users can pin the content in view. When the user taps the pin button, a flyout appears, showing a preview of the tile about to be pinned: http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-51-31-metablogapi/6735.Pinning_2D00_to_2D00_Start_5F00_58B1CF8F.png Now we need to: Add an app bar to the app, including the pin icon for the “Pin to Start” and “Unpin from Start” actions Implement an event handler to the click of the app bar pin/unpin button Add the app-specific logic to pin the new tile in response to the pin/unpin action We won’t look at the first two steps for creating the app bar so we can focus on pinning the tiles themselves. You can find the details of how to implement the app bar here: [url=http://msdn.microsoft.com/en-us/library/windows/apps/Hh761471.aspx" target="_blank">How to use the app bar to pin a secondary tile [url=http://msdn.microsoft.com/en-us/library/windows/apps/hh465309.aspx" target="_blank">Quickstart: adding an app bar with commands In step 3, our app creates the secondary tile by setting a few properties. JavaScript: C#: For more info on how to pin secondary tiles, see [url=http://msdn.microsoft.com/en-us/library/windows/apps/hh465398.aspx" target="_blank">Guidelines and checklist for secondary tiles and [url=http://code.msdn.microsoft.com/windowsapps/Secondary-Tiles-Sample-edf2a178" target="_blank">Secondary tiles Consumer Preview sample. Using local notifications to update the pinned tile The pinned tile is an additional tile for our app to update on Start. Updating this tile is no different than updating the app’s main tile. In this app I use the local notification APIs to update the secondary tiles while the app is running, instead of using one of the cloud update mechanisms. I show local notifications here so that I can demonstrate how it works. You can update from the cloud in a similar way. This app could have easily implemented polling scenario too. In the code in this section, I use the NotificationsExtensions library which is included with the [url=http://code.msdn.microsoft.com/windowsapps/App-tiles-and-badges-sample-5fc49148" target="_blank">Windows 8 SDK App tiles and badges sample. You can include this library in your app projects to make updating tiles locally easier. The library provides an object model on top of the Windows tile-update APIs which allows you to avoid manipulating XML from within your JavaScript, C#, and C++ apps. It also makes developing easier by providing IntelliSense. Using the local notification APIs, I can update the tile any time the app is running. For the pinned food truck tiles, I want to update the tile with any deals the particular food truck offers, every time a user launches the app. Enumerating secondary tiles Because a user can unpin secondary tiles from Start while our app is not running, the first thing the app needs to do at launch is look for its currently pinned secondary tiles. Each enumerated tile contains a tileId, which uniquely identifies it. Because the app sets the tileId when it is created, we can use the ID to know how to update each tile we find. Here’s how: JavaScript: C#: Local updates For each of the pinned food truck tiles, I update the tile with the current info about where that truck is for the day. If I was using local updates to update the main tile, we wouldn’t need to enumerate the secondary tiles first because the default action in the API is to update the calling app’s main tile. Just to remind you, here is what the tiles from the app we looked at in Part 1 look like. http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-51-31-metablogapi/3252.Wide_2D00_tile_2D00_update_2D00_with_2D00_image_5F00_thumb_5F00_2333898F.png http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-51-31-metablogapi/1780.Square_2D00_tile_2D00_update_2D00_with_2D00_image_5F00_thumb_5F00_7063831A.png Here is the function that we called in our enumeration, which actually sends the notification to the secondary tile. JavaScript: C#: Because I use the NotificationsExtensions library, I don’t have to manipulate XML in my local code. Instead, I use the object model that is provided by the NotificationsExtensions, which allows me to use IntelliSense to discover the different properties of each notification template. The XML for the tile update looks like this: If you use the NotificationsExtensions library, you can use IntelliSense to discover properties on the tile templates which makes developing local tile updates much faster. I hope you find the NotificationsExtensions helpful in your JavaScript, C#, and C++ projects. Conclusion When users see fun and interesting things on their tiles, they will be more likely to launch your app to learn more about it. I hope this post has helped to inspire you to think about how you can add a live tile and show off the best of your apps. If you are interested in learning more about notifications, see the [url=http://msdn.microsoft.com/en-us/library/windows/apps/hh779724.aspx">Tile and notification overview and [url=http://msdn.microsoft.com/en-us/library/windows/apps/hh779721.aspx">Choosing a notification delivery method in the Dev Center. -- Kevin Michael Woley, Program Manager, Windows This post was a group effort. Thanks go out to Tyler Donahue, Daniel Oliver, and [url=http://weblogs.asp.net/jgalloway" target="_blank">Jon Galloway for their contributions. View the full article

Microsoft is accepting tester applications for the next version of its Windows Intune service for managing and securing Windows PCs — and soon iOS and Android devices. Source: All About Microsoft

Previous blog posts have discussed the Metro style application model using Windows Runtime. An important attribute of this app model is that apps are suspended when they are no longer visible to the user. Suspending Metro style apps in the background is a good thing, as it conserves CPU for other apps and ensures that background apps dont cause activity that can consume resources, thereby improving the battery life and increasing responsiveness. This is outlined in detail in Sharif Farag and Ben Srours blog post, all[/i] the memory that suspended Metro style apps would otherwise hold onto. Windows 8 can reclaim this memory without having to terminate an app. Your browser doesn't support HTML5 video. Download this video to view it in your favorite media player: [url=http://ak.channel9.msdn.com/ch9/5c2b/1b9a4ea2-6cec-4869-a068-c5a49a3a5c2b/ReclaimingmemfromMetroApps_high.mp4">High quality MP4 | [url=http://ak.channel9.msdn.com/ch9/5c2b/1b9a4ea2-6cec-4869-a068-c5a49a3a5c2b/ReclaimingmemfromMetroApps.mp4">Lower quality MP4 Memory, responsiveness, and Metro style apps For any type of app (Metro style or desktop), Windows tries to regulate physical memory allocations on behalf of that app, regardless of the memory requests it has made. Windows has always behaved this way to keep memory available in anticipation of future app memory needs. Windows is careful to only allocate physical memory to an app when the app tries to touch it, even if the app had allocated it earlier. Windows will also page out or repurpose parts of memory from an app if the pages of memory havent been touched in a long time. It is important to understand the goal is not to deny memory to a requesting process, but to delay allocating physical memory as long as possible (until the user actually touches the app) because as with many resources, there is a tendency for software to over-budget. The OS is the place where all these requests come together and it has the information to see that meeting all the fully budgeted requests would ultimately starve every process. Not only would work not complete, but the system will essentially lock up. This happens even if the memory is virtualinstead of running out of RAM, your PC would simply swap pages in and out of disk. The physical memory given to a process at any point in time is referred to as the working set of the process. A private working set represents physical memory that is unique to a process. Processes also touch other pages of physical memory that are shared, which several processes can reference. When you look at the Processes view in Task Manager, the memory for a specific process is actually its current private working set. NOTE: For simplicity, when I refer to working set in this blog, I mean private working set. When the system starts to run low on available memory, the OS will look in all processes for pages of physical memory that it can repurpose to satisfy other needs in the system, even by paging out memory when necessary. For desktop apps, Windows will try to keep the most important (frequently accessed) pages of memory in the apps working set this is because desktop apps expect to be able to run code at any time, even when theyre in the background. Its a fine balance though: if too many pages of memory were to be removed from a desktop app, it could affect the apps responsiveness due to additional disk I/O (as the app tries to touch memory that has been paged to disk under the covers). For a deep dive on Windows memory management, see Mark Russinovichs Mysteries of Windows Memory Management Revealed talks: [url=http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL405" target="_blank">part 1 & [url=http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL406" target="_blank">part 2. Metro style apps, however, are different from desktop apps, in that they are usually suspended whenever they are no longer in the foreground. When theyre suspended, they arent touching ANY of their memory. To illustrate, Ive highlighted a few suspended Metro style apps with memory held in their working sets in the screenshot below. [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/0640.11_5F00_35FC5125.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6013.11_5F00_thumb_5F00_4ABE23D8.png Suspended apps holding on to memory NOTE: In the Consumer Preview build, the Suspended status does not show in the Processes view of Task Manager by default you have to choose to show it via an option on the View menu. If there isnt memory pressure in a system, its actually a good thing (most efficient) to just leave memory in the suspended apps working sets. But if there is some memory pressure, the fact that these Metro style apps are suspended presents an opportunity to get almost all the memory in these working sets back for other apps, without terminating them. Reclaiming memory from suspended Metro style apps In Windows 8 Consumer Preview, we can efficiently write the whole (private) working set of a suspended Metro style app to disk, in order to gain additional memory when the system detects pressure. This process is analogous to hibernating a specific app, and then resuming it when the user switches back to the app. Were taking advantage of the suspend/resume mechanism of Metro style apps to empty or re-populate an apps working set. The sequence of events is described below: The Process Lifetime Manager (PLM) detects memory pressure in the system and asks the Memory Manager (MM) to empty the working set of a specific process that houses a suspended Metro style app. [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/3683.Visio1_5F00_1781EA6F.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/7485.Visio1_5F00_thumb_5F00_2FA554CA.png MM moves the pages of memory from the working set of the app to the operating systems modified page list (which is a list of memory whose contents are to be written out to disk before being reused). [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/3288.Visio2_5F00_086B0B95.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/3782.Visio2_5F00_thumb_5F00_442AA448.png The working set pages on the modified page list are written out asynchronously, as dictated by the usual MM policies (written out opportunistically in the background, writes triggered when under memory pressure). [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/4762.Visio3_5F00_35EC2B58.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/4375.Visio3_5F00_thumb_5F00_63011826.png Even after the suspended apps working set is written to disk, the memory pages removed from a process are left intact on the operating systems standby list. This is a cache of useful pages of memory that can be repurposed for other apps, if necessary. If these pages are immediately needed again by their original process, they are quickly moved back. [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/4760.Visio4_5F00_6D523C86.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/3201.Visio4_5F00_thumb_5F00_7A4C1C97.png If a user switches back to the app while its working set pages are still in physical memory (on the modified page list or the standby list), its straightforward: the pages will be added back into the apps process immediately. If they are no longer available, Windows will read in the apps working set from disk in an optimized manner. Reclaiming memory in action To get a feel for how this works, lets walk through an example with real running code. The initial state is represented by the screenshot above. I had several Metro style apps running on a PC with 2GB of RAM. The Metro style apps were in the background, and therefore Windows suspended them. I then started opening more apps to drive up memory use on the system and trigger the new functionality. In the next screenshot, below, youll notice that I opened some apps in order to introduce additional memory pressure and induce the behavior described above. As you can see, Windows emptied the working sets of the suspended Metro style apps (highlighted). [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/2318.12_5F00_7973B6AD.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6428.12_5F00_thumb_5F00_573BAB27.png Working sets of Metro style apps emptied Lets compare the before and after working sets of the original Metro style apps (some of the after stats cannot be seen because Task Manager ran out of room to show all 27 launched apps): Metro style app Working set before (MB) Working set after (MB) Flixster 23.5 0.5 Flow 15.2 0.6 Kindle 23.1 0.5 LiveComm 3.8 0.3 Lyrics 65.3 0.9 Maps 28.1 0.8 Remote Desktop 21.0 0.5 SkyDrive 23.1 0.5 Store 26.9 0.6 Weather 42.0 0.8 Windows Reader 9.2 0.4 So in this example, we liberated over 250 MB of physical RAM for other apps to use without shutting down the suspended apps. Responsiveness when reading the working set back in A test for this new facility is how responsive a suspended app is after its working set contents are emptied and you decide to switch back to the app. While I was running this test, I used the Lyrics app as my indicator of responsiveness. The Lyrics app can display the lyrics of a song as well as play back a music video. When the Lyrics app goes to the background, it gets suspended, which stops the playback. After driving memory use to the point where working sets were emptied, I opened additional apps and used the system for a while to ensure that a swap back to the app was going to read the working set from disk. I then triggered the switch back to the Lyrics app (below). [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6763.13_5F00_6EF2E28D.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/1641.13_5F00_thumb_5F00_14102CFA.png Lyrics apps working set is repopulated The key indicator I was looking for was how long it would take from the time I triggered the switch back to the app to the point where I could hear sound again. On a low-end machine, with a high memory load, its hard to perceive a difference in responsiveness when switching back to the app whose working set was being read from disk compared to when its working set was still in memory. Your mileage will vary though: the larger the working set, the longer it will take to read-in from disk. Were also continuing to reduce the amount we have to write to disk for Metro style apps and further optimizing this feature. This functionality is something that everyone with the Consumer Preview release can try for themselves. Just open up a number of Metro style apps and desktop apps to generate some memory pressure, and then switch back to a suspended Metro style app that has had its working set emptied. NOTE: Windows will still close Metro style apps if memory gets into the critical range. However, this feature will enable a system to run more applications before getting to that point. Reading in a working set optimally To have a responsive experience when you switch back to a suspended app whose working set is on disk, weve optimized how we write the working set in the first place, so that reading it in is as efficient as possible. When we write out the working set of a suspended Metro style app, the working set pages are being written out to disk sequentially. This allows us to read the data back into a process using a small number of large sequential disk reads. The screenshot below is from our Windows Performance Analyzer (WPA) tool that comes as part of the [url=http://www.microsoft.com/download/en/details.aspx?id=28997" target="_blank">Assessment and Deployment Kit (ADK), showing a visual representation of disk reads during this process. Ive highlighted the working set read-in I/O. You can clearly see the sequential stream as we repopulate an apps working set. [url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/2727.Windows_2D00_Performance_2D00_Analyzer_5F00_437E9BC6.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6763.Windows_2D00_Performance_2D00_Analyzer_5F00_thumb_5F00_02701C62.png Sequential read I/Os to repopulate an apps working set (WPA Tool) Reading back sequential data from almost any storage device is really fast. Most rotational disks can achieve between 50-100MB per second. If a storage device is flash-based (like an SSD), you can get upwards of 200MB per second for these reads. We expect that many apps will take less than a second of I/O to get the working set of a suspended app back into memory. Conclusion By definition, all PCs of all form factors have limited physical memory. The challenges of managing memory do not change when you add more physical memory, so long as you are actually running more programs that request more memory. Several classes of modern software will continue to evolve to use more and more memory photo editing of giant RAW images, in-memory databases, very large spreadsheets, and so on. Whether these have WinRT-based implementations or desktop implementations, the OS needs to evolve to manage these ever-increasing memory requests. WinRT is an opportunity for programmers to use an API that allows access to all the memory they need while putting the user first in terms of responsiveness and getting work done. I hope youll try this out this feature in Windows 8 Consumer Preview. -- Bill Karagounis Source: Windows 8 Blog