UPDATE: showing code that actually works.

As a prelude to a series I’m hoping to do on file queries and file information, I just wanted to share a little snippet for making a file read-only. Although you can retrieve the current status through the StorageFile.Attributes property, it just returns an enumeration rather than a property set you can manipulate.

Changing attributes instead has to go through the StorageFile.properties property, which is a StorageItemContentProperties object. Its savePropertiesAsync method is the one you want. For this you need to create a Windows.Foundation.Collections.PropertySet object (see this previous post), populate it with the properties you need, then call savePropertiesAsync.

The specific property you need to set is “System.FileAttributes” with the value FILE_ATTRIBUTE_READONLY, which is just 1 as described for the Win32 SetFileAttributes function. The code looks like this, where I’m just working with a test.jpg in the pictures library to demonstrate:

JavaScript (you can add a completed handler if you need to take other action after savePropertiesAsync):

var key = "System.FileAttributes";
var file;
var pix = Windows.Storage.KnownFolders.picturesLibrary;
pix.getFileAsync("test.jpg").then(function (fileTemp) {
    file = fileTemp;
    return file.properties.retrievePropertiesAsync([key]);
}).done(function (props) {                
    if (props) {                    
        props[key] |= FILE_ATTRIBUTES_READONLY;
    } else {
        props = new Windows.Foundation.Collections.PropertySet();
        props.insert(key, FILE_ATTRIBUTES_READONLY);                    




String key = "System.FileAttributes";
var pix = Windows.Storage.KnownFolders.PicturesLibrary;

var file = await pix.GetFileAsync("test.jpg");                                
String [] retrieveList = new String [] { key };

var props = await file.Properties.RetrievePropertiesAsync(retrieveList);

if (props != null) {
    var temp = (UInt32)props[key] | FILE_ATTRIBUTES_READONLY;
    props[key] = temp;
} else {
    props = new Windows.Foundation.Collections.PropertySet();                
    props.Add(key, FILE_ATTRIBUTES_READONLY);                    

await file.Properties.SavePropertiesAsync(props);

My associate David Roussett has been running a blog for some time on HTML5, Windows 8, and Gaming. The particular series I wanted to point to is Using WinJS & WinRT to build a fun HTML5 Camera Application in which he covers some core scenarios of media capture and then gets to details of applying effects, using web workers, and using WinRT components to get to GPU shader capabilities.

A while back I was working with a partner who asked what it would take to convert their web app (in HTML5 & CSS) into a great Windows Store app. This wasn’t a question of a minimal approach to just get it to work, but of making a really good app while still minimizing the work. I put together the following list of priorities with some general estimates of the amount of dev work involved. I figured this might be a helpful list for other developers.

For further inspiration, also check out the Website to apps topic in the design inspiration section of the Windows Developer Center.


  • Has to meet Store policies, which is some of what drives this list. (1-3 days) Key considerations:
    • 3.5: touch interaction must have visual feedback (meaning proper animations)
    • 3.6: handling view states and process management
    • 3.9: disallowing remote script
    • 4.1/4.1.1: privacy statement
    • 4.1.2: opt in for use of personal information
    • 4.5 Network cost awareness (especially for any large transfers) (.5-2 days)
    • 5.1 and 6.2: content and age rating
  • Explore a horizontally-oriented design (though vertical can be done especially with the Windows 8.1 ListView). (1-3 day design; dev is variable depending on the design and where you’re starting from)
  • View states: handle portrait, snapped, filled along with landscape. (2-3 days for design, implementation, testing) [For Windows 8.1 this means handling variable sizing rather than view states]
  • Handles resolution scales well, both display sizes and pixel scaling. (1-2 days)
  • Must run within the app container security boundary, which excludes remote script and script injection. (1 day to check; possibly more if things need to be rewritten)
  • Works with mouse, keyboard, and touch input, the latter of which means that touch targets need to be the right size. (.5 day design; 1-2 days dev)
  • Move chrome/commands off-canvas, generally (2 days design; 3-5 days dev)
    • Search to Search charm
    • Sharing functions to share source, though you may retain what you have as it’s integral to the experience
    • Settings to Settings charm including logins and profile management
    • Other commands and navigation to app bars
  • Handling suspend/terminate/restart and suspend/resume. (1 day)
  • Migrate from page navigation based on <a href> to single host page with DOM replacement (using page controls) (1-4 days depending on how you’re doing it now)
  • Great splash screen and branding graphics (1 day design mostly; .25 days dev)

Nice to Do:

  • Handling network connectivity or lack thereof (caching strategy/offline story) (2-4 days dev)
  • Live tiles: what can you surface on the tile? (1 day design; 2 days dev)
  • Roaming experience—what settings transfer to the user’s other devices? (1 day dev)
  • Globalization (making a world-ready, language-neutral app) (2 days dev)
  • Localization (1 day testing with pseudo-language; each language is likely an hour or less but needs to include time spent )
  • Accessibility (2 days)
  • Good use of progress indicators when transitioning pages. (.5 days design, .5 days dev)
  • Honing performance especially if using collection controls. (2-4 days day dev depending on goals)


Figuring out which set of language resources to use in an app at runtime can be a tricky thing for the OS to do at runtime, especially if the app has multiple resource files for the same base language.

Fortunately, there’s a topic in the documentation that came out close to GA of Windows 8 last year that explains all this: Language matching. Totally recommended if you’re creating a multilingual app.


The URI scheme for maps application has been around for a while, but because it's buried off with other XML schema, it can easily escape notice. So I wanted to raise awareness of it, as it's very useful for apps that have specific mapping requirements but don't necessarily need to build maps directly into the app. By activating protocols with the bingmaps: scheme, you'll launch the Maps app or any other that wants to implement the scheme itself.

Speaking of Bing Maps, check out the preview SDK on www.bing.com/dev that has added three new capabilities:

  • Optical character recognition (OCR) control, which has exciting possibilities for document reading when combined with the Text to Speech API.
  • Maps 2D Control (this is an update to the existing control that doesn't work with Windows 8.1 Preview apps)
  • Translator Control, with support for 40 languages.

From what I can see, the OCR control is only supported in XAML apps at present; the other two are more general, but I haven't verified that.

This is a good question to ask. If an app is in the Windows Store and the developer’s account with the Store expires after some time (like in a year), will the app disappear or what?

At present, apps will no longer be visible once a developer account expires. However, customers who already own the app will still be able to reacquire it later on, as when setting up a new device, but others cannot see the app. In-app purchases are also disabled for obvious reasons: the developer account is how revenue transfers from purchases to the developer, so if that account has expired there’s no longer a legitimate channel for the revenue stream.

You will get an email notification if your account is near expiry, so be sure to keep a current email listed there.

Also note that if your account expires, all reserved app names will be released.

In Windows 8.1, there’s a new WinRT-level HTTP API, specifically Windows.Web.Http.HttpClient that is intended to gradually supercede other APIs. More about this in my earlier post, Cool New APIs in Windows 8.1 #2: Windows.Web.Http.HttpClient.

One feature of this API is that it lets you manage cookies directly, something that APIs like the JavaScript XMLHttpRequest (and WinJS.xhr) lack.

In this context, some have asked whether cookies involved in one HttpClient request will persist to subseqeuent calls. The answer here is yes, in the same way that a desktop browser handles them. This means that cookies used with apps are subject to the typical app isolation policies for websites: cookies for app A are not visible to app B and vice-versa. The cookie will persist across calls, certainly, and also across app sessions, as they are stored in the WinINet cache like other HTTP request data. This assumes that the cookies are marked as persistent, and they are still subject to normal per-app limits and so on.

Calling HttpClient.Dispose(), mind you, will clear this stuff out.

The same policies apply to everything else in the WinINet cache, by the way–stuff that app A downloads is cached for it (subject to usual limitations), but is not accessible to app B. If the two apps request the same resource, that resource is cached separately for both apps and will be downloaded separately for each.

The question occasionally arises about using a C++ DLL within a Windows Store app. There are a few thing to know about this.

First, Visual Studio will let you import the DLL into a project, no problem, and the project will likely compile with whatever calls you make to that DLL. However, it won’t actually run unless you add a Reference in Visual Studio to that DLL.

Second, if you’re importing DLLs that are already built, there is a requirement that the DLL is built with Visual Studio 2012, otherwise it has a dependency on a different version of the C runtime library (CRT). Windows Store apps can only take a dependency on the VS2012 CRT (see this blog post).

Third, if you’re working in a language like C++ or C# via P/Invoke that can call DLL exports directly, then you can just use the DLL. For other languages like JavaScript, or to have a better C#/VB experience, you can wrap the DLL inside a WinRT component (written in C++) that then plugs into the language projection layers. This will add minimal overhead to the calls and then make the DLL accessible in whatever app language. This is clearly a good solution for SDKs or libraries, with the caveat that you’ll need to rebuild the DLL in VS2012.

The last requirement for a DLL is that it must use only whitelisted Win32 APIs; other APIs are blocked for Windows Store apps and will fail at runtime.