I'm crowdsourcing "action shots" of Surface OR iPad for a ZDNet piece

What I'm looking for here is people using their tablets in normal, everyday settings.

Such as this one from Microsoft evangelist Martin Beeby using his Surface on a train:

Please send your pictures to mbrit@mbrit.com

You will retain copyright of the images, but by sending them to me you grant me permission to use them on ZDNet and associated properties.

How to tell if a Windows Store app is XAML or HTML/JavaScript

tl;dr - look in the Registry.

Packages are registered in HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\Repository\Packages. You'll find the installation folder in there - look through to see if you have .xaml or .js files. HTML apps also have an ~/Applications/<Package> key with a DefaultStartPage value. This will tell you definitively whether it's an HTML app as only these have "start pages". 

If the app has neither XAML or JS files, they're likely to be C++/CX apps.

To help, I wrote a small utility which is available on GitHub at https://github.com/mbrit/XamlOrHtml. This will go through the installed packages and dump out what it thinks it is.

Some spoilers...

It's most likely to be XAML. My reckoning is that 80% of Windows Store apps are XAML. Interestingly, most of the built-in Microsoft apps are HTML. My view on this is that these are proof-of-concept apps, to prove that you can build Windows Store apps in HTML. At this point, however, if you're building Windows Store apps in HTML... it very much looks like you're doing it wrong. 

Upgrading Win8 RP to RTM on OS X with VMware Fusion

Quick pro-tip.

Say you have Win8 RP in a VHD. You want to create a replacement VM for RTM. Once you delete the VHD with RP (or more likely move it).

If you do this, allocate all of the space in the new VHD. OS X seems to struggle with expanding out that file into reclaimed space. Also, once expanded, OS X seems to struggle with using the space that may not be contiguous on the disk. (Even with an SSD.) If you expand all the space out, you should be better off. Word of warning though, may take a couple of hours to create a ~100GB disk.

That "don't call your product Metro" thing... Obvious, right?

You should be glad they fixed it really. The problem isn't Metro, the problem is that there was no trademark defence clauses in the Windows Store agreement at all. Here's the agreement, which for this post is version 3.0 dated 2012-07-09.

You think MS was ever going to allow devs to post apps called "Hurr Hurr iPhone SUCKS LOL!" No. 

The wording in the guidance document that calls out "Metro" specifically will eventually be supported by vNext of that document which will be clearer about Microsoft's position of protecting partner trademarks. I suspect really what they want to do now is not end up with 33% of the apps in the Windows 8 store being called "Metro <Blah>", because that was happening.

A corollary point - I'm sure that if you happen to trade under the name Metro you'll be fine. Can you imagine MS turning round to Metro AG and telling them that they can't use that name in the store? 

Update: Tom Warren just noticed that the wording in the guidance document has changed to remove the reference to "Metro". I still stand by what I say - expect explicit clarification of trademark rules in the next rev of those rules.

A "snark-free" post on the Metro naming debacle* (Caution: May contain snark)

In a parallel universe I'm writing a much less kind version of this post, but with GA of Windows 8 being measured in a short number of months, I'm going to try and be helpful. Am I happy about the naming change? No. Was I happy about the "Metro-style" moniker before? Also no. Could something good come of this change? Well, anything's possible.

"Metro" is the name of the design language invented by Microsoft as the basis for the user experience offered by Windows Phone. Microsoft needed to reboot their smartphone platform and (actually pretty boldly) did this by creating an entirely new look. But it wasn't just about the look - it was about the *experience*.

"Metro-style", or as MSDN calls it "Metro style (no hyphen) for reasons I now happily don't have to understand, is the set of APIs that come together to drive the user experience for new post-PC applications. Now, Microsoft aren't mad keen on the term post-PC - but I am, I love it. Post-PC is about a world where Windows continues to dominate the desktop, but the desktop stops being important. Go out to 2022, Windows will sit on servers or project their desktop forwards to all manner of devices over VDI. But Windows will also run on tablets, and there it *could* be dominant. It *could* be bigger than iOS.

The reimagined Windows 8 works really well on a tablet. Metro-style applications (there's that name) eschew "mouse first" and present touch as an equal citizen. And it's trusted end-to-end, from the vendor having to be vetted, to static and dynamic analysis of the apps in the store, to a kill switch, to more proactive rev'ing of the OS and patches. Metro-style is intimidation free and works beautifully. It makes Android tablets look like amateur, half-baked tat.

Except for that we can't call it that anymore. Which is fine, it's just a name.

"Metro - the design language" is the biggest casualty of this, oddly, because there is no other name that describes the design principles that range across the *ENTIRE* Microsoft portfolio. That new Outlook.com? That's "Metro", well it was. Now it doesn't have a name. And the Xbox dashboard - Metro. How about downloads.microsoft.com? Metro. And the proposed name - well, the assumed name - of "Windows 8 UI Style", how exactly does that fit when describing the Xbox dashboard? It doesn't. So my first point is that people are forgetting how big "Metro" is.

If it were Apple, Microsoft could get away with this because Apple could just send down a dictat that developers weren't allowed to ape the style, that it was a Cupertino Co only thing. But Microsoft want people to ape the Metro design language. To see evidence of this, look in the Windows Phone and Windows 8 store and find anything that's not based on the Metro design language. Found any? Thought not.

What I have been struggling with for the past six months though is that no one knows what "Metro-style" is. I've lost track of the number of people I've spoken to about "Metro-style" who've gone, "Oh, you're a designer?" Um. No. Not a designer.

Where this gets very untidy is that Metro-style isn't just WinRT. Metro-style, at least for me, describes the APIs that drive the experience of a "Metro-style" application on Windows 8. So it's the XAML libraries that let you build something that looks Metro design-ish, but it's also the file APIs that limit you to the sandbox, the asynchrony throughout that keeps the UI responsive, the limits on thread manipulation to stop you from killing the battery. You can't just remove "Metro" and not replace it with anything. "Metro-style" apps are not "WinRT" apps. Especially not when you think about what's likely to happen with Windows Phone 8 and its convergence with the WinRT model. 

(And thoughout this you can read WinRT as "Windows Runtime" - it's the same thing.) 

WinRT is also *bigger* than Metro-style. Personally, I love the idea of an ARM-based cut down Windows Server RT that ran IIS RT and some WinRT-based ASP.NET-like thing. (Not that such a thing exists outside of my own head.) But that's the idea - Windows Runtime is not about driving user experience on tablets and devices. It's a classic Microsoft move of building a big, powerful, well-supported API.

So back to what I struggle with - it needs a name. When .NET was out it was easy, you could say to someone "do you want some .NET training?" And they would say "yes", or "no". They would not say "what's .NET?" Which is what happens with Metro-style. All. The. Time. 

What isn't going to be beautiful here is calling them "Windows 8 UI Style" apps. Funnily, "Windows 8 UX Style" apps would work a little better because - as I've said - Metro-style is about *experience* not about look. But what happens with Windows 9? Let alone how you explain that Metro-style apps actually run on Windows Server 2012. "Windows 8/Windows Server 2012 UX Style" apps? Just, please, don't do this.

Normally, in a snarky post, I'd be looking to finish off with a few paragraphs that leave my victim writhing about in the throes of death, but let's try and be productive... 

"Windows Apps". Done.

I'm guessing here that when *normal* people download and run an .msi they are not thinking about "installing an app". They don't think of Firefox on Windows as an "app". Or Office. But oddly "applications" is what software has been called since the days of the mainframes. I find it frankly boggling that Apple managed to own the moniker "app". It's like Dyson ending up owning the word "hoover" when Hoover had been making vacuum cleaners for a hundred years. In the Windows space, "apps" doesn't mean anything - but it could do.

"Hey I'm thinking of buying a Surface? What apps does it have?" 

"Well, it doesn't have as many apps as the iPad, but it's got the ones you need. Here, let me show you."

For the consumer, that seems to work. It's simple. It retains the brand. It survives revving the OS to Windows, Windows X, whatever. It's just an "app". There's old style software that you "install" and there are "apps" that you "download". 

For the developer, "Windows apps" it sorta works. If you can find the docs on MSDN, at the moment they read "Learn to build Metro style apps". (OK, and a little snark - why does it still say "Metro style"? Suggests a lack of planning, hmmm?) That could say "Learn to build Windows apps", or "Learn to build apps for Windows 8 and Windows RT". Developer naming can survive revving because we're used to being confused - or rather, getting unconfused has some sort of payoff. 

Either way, for me, that works. It's better than "Learn to build Windows 8 UI style apps". Also, Windows RT isn't Windows 8. And then there's the problem of Windows Server. You can't ram the rev number into the name. It has to be generic because, and the dumb thing is we all know this, Windows is bigger than one OS.

The only problem is Google. It'd be hard to find content for "Windows apps", but then most of the time we're searching for WinRT anyway. (Also, you all know you can just do "-winter" in the query to remove the autocorrect from "WinRT" to "winter", right?)

The victim then remains Metro design style. The design style that has no name. Voldemort-y.

Do I have any ideas about the Metro design style name? No, but then I don't care because I'm not a designer. You can call that what you want, all I care about is that developers build apps and that consumers buy Windows 8/Windows RT tablets because enough good developers had the wherewithal to write enough good apps.

So my vote for the new name: "Windows apps".

Mailing lists for deeper discussion of Metro-style app issues and opportunties - a community experiment

Back when .NET v1 was coming out I was lucky enough to be on the pre-release programme. One of the things that we had during that process was really good mailing lists. Smart people discussing deep issues really helped me understand .NET and how to use it.

So why mailing lists?

- Stack Overflow is under-represented on WinRT at the moment. A lot of edge-case questions are being asked there, but it's very hit-and-miss. Plus, Stack Overflow's weakness on long discussions is that the "right" answer breaks the temporal nature of the discussion. It's about the destination, not the journey.

- MSDN Forums are operating like technical support with virtually every question being answered by an Microsoft employee. Which is great, and is probably why Stack Overflow isn't working for WinRT currently.

An so I'm proposing Metro-style Friends, which will be a set of mailing lists that will work in the old-school LISTSERV/Mainman manner. Ultimately (and hopefully quickly) they'll be moderated and properly managed.

I have only set-up one at the moment. Email listserv@metrostylefriends.com with the text subscribe msfriends-general in the *body* and you'll be good to go. Let's try having some discussions!

There is now a (part-baked) website to allow signups. Go to http://metrostylefriends.com/ and start from there.

Porting NLog to Metro-style/WinRT... or why starting again is a good idea

I've tried porting NLog to Metro-style/WinRT a couple of times, and I've surrendered both times within hours of starting. The problem with NLog is that it's amazing, rich surface area extends all the way over the Metro-style surface area. Whereas in .NET Full you have Console, Debug, and Trace, in .NET Core you only have Debug. Talking cross-process is out. There's no event log support (which is a mistake in my book). The file API is synchronous. Queuing is hard, etc. In short, although NLog will run on anything and is fantastic, it's too big a solution for Metro-style very focused capabilities.

What I see as the total surface area of logging on Metro-style is being able to send information to Debug.WriteLine, and also to dump out crash reports to disk, or maybe HTTP. Don't forget that Debug.WriteLine ends up in OutputDebugString and hence in the regular Windows debug stream. You can use DbgView to surface information outside of the process, which is helpful if your Metro-style process won't start. Likewise, dumping a file to disk on ERROR or FATAL is also helpful - providing you can write it before you're scrubbed out of memory.

To that extent, I've put together MetroLog. This is a first pass over a very basic logging framework that's optimised for Metro-style/WinRT development. It's not intended to become huge like NLog.

I think splitting it is actually quite workable. For the most part you're actually just using a tiny amount of NLog functionality in your actually running code. 99% of calls to the NLog library are Log.Info(...), etc, and these are easily shimmed out. I would go far to say that clipping NLog so that it fits into Metro-style is rather over-thinking the problem.

I've tried to keep the construction compatible, whilst lightweight. So you still have LogEventInfo, and Logger. It could be that these two libraries converge again in the future, or it could be as @davkean suggested that actually it make sense to restructure the lot around Portable Class Libraries.

FileOpenPicker/FileSavePicker doesn't allow *.* wildcard file associations

On Twitter, Matthias Jauernig commented that the FileOpenPicker and FileSavePicker doesn't allow *.* wildcard file associations. I was relaxed about this and wrote back that it was related to sandboxing implying it was a "good thing", however as Matthias commented back, perhaps it's not.

In Metro-style the sandboxing works that if something gives you a file (e.g. the picker, or a share operation), you can access it regardless of where on the system. If you find the file yourself, you have to declare the type.

The reason why I think it's related to sandboxing is because if you work with files programmatically you have to be explicit about the file types. This is to stop malware that you think is only interested in - say .PDF files, scanning and uploading any .EML files that it can find on the machine. It follows then on the pickers that restriction would continue. It allow's the retail store team to validate that an app is likely to behave itself. If it's an app that works with images, locking down the picker so that it can only access image file types makes sense.

However Matthias mentioned that he has an app that should allow files of any arbitrary file. That fits more into the "if the user selects it, it must be OK" camp than the "programmatic scanning" camp. So now I'm left wondering why the picker doesn't allow any type to be selected.

I think then maybe the decision comes down to simplicity. A lot of the decisions in Metro-style design relate to ideas about "zero intimidation". Allow the user to select any file is too much like Old Windows, and not enough like Reimagined Windows. What happens in Matthias's app if the user selects Explorer.exe as the file he or she wants to work with? I guess it's fine if you expect your user to know what they're doing (Old Windows), but not so fine if you're expecting a three year old to work with it (Reimagined Windows).

Detecting right-click on XAML GridView control item

Leaving aside why you would ever want to do this in a touch-centric world, here's how you tell if the right-mouse button has been clicked on a GridView in XAML/WinRT/Metro-style. You have to retrieve a point relative to the UI element you're in, and then query its properties.
        void itemGridView_PointerPressed(object sender, PointerRoutedEventArgs e)
        {
            if (e.GetCurrentPoint(this).Properties.IsRightButtonPressed)
            {
                this.BottomAppBar.IsOpen = true;
            }
        }
(The reason why you might want to do this can be explained by looking at any of the built-in Win8 apps. You can right-click any of the items on any list to bring up a context-sensitive AppBar.)

Virtualising Windows 8 on OS X with VMware Fusion above the 8GB limit

tl;dr - don't.

VMware Fusion has an 8GB limit, so on my 16GB MacBook Pro (which is an old one with a 16GB memory upgrade), I wanted to use more than 8GB. 

You can fudge it my editing the .vmx file and changing the memsize value to whatever you want.

However it turns out that if you do this the performance on the whole machine turns into a pig. It beachballs all over the place, both in VMware and without. Constant hanging of VMware, fan running hot the whole time, etc.

This is just an apocryphal view, but having spent a week and a half with it unusable and me thinking I was going to have to go back to Win7, turn it down back to using 8GB exactly seems to be working much more stably.