The App Compat Guy

Finally a Great Weight Watchers Online Experience on Windows Phone and Windows RT!

2013-03-31T16:15:13Z

The flurry of “hurrah!” emails was my cue that the fix removing m.weightwatchers.com and mobile.weightwatchers.com from the Internet Explorer Compatibility View List went live this past week. Finally, users of Windows devices have a full fidelity experience using the Weight Watchers online tools! Enjoy, and terribly sorry for the delay in going live with this removal.

Update on the Weight Watchers Mobile Site on IE10

2013-01-23T16:18:29Z

Back in December, I blogged about the failure of Weight Watchers Mobile on IE10, which affects peoples’ fancy new Windows Phone 8 devices, not to mention their Windows RT devices like the Surface RT.

In the interim, I’ve disabled the compat view list on my Surface (there isn’t an option to do that on the phone), but wanted to update you on what I’ve been able to do so far as my surprising email volume about this issue indicates that I am far from alone in feeling the pain of not having a good site to track your PointsPlus.

First of all, I reached out via site support, trying to hit every email address I could find which might be related. So far, the silence has been deafening. (Something to keep in mind: if The App Compat Guy debugs your site for free and sends you the solution, READ THE EMAIL.) So, that didn’t get me very far.

Being fairly persistent, I also found out that Weight Watchers has a Premier Support contract, so I also tracked down their Technical Account Managers and sent them the details. Unfortunately, they haven’t made it any further. (Something to keep in mind: if you pay somebody to help you with technology, READ THEIR EMAIL.)

My persistence remaining, I also reached out to the IE Partner Outreach team. Initially it kind of went into the ether, but there are a couple of reasons behind that. First, it was the holidays, so everyone was stretched thin. Second, they wade through a LOT of email since it’s a very widely published email, and some dude asking for a random site to change who isn’t the site owner doesn’t automatically trigger a response. I found that having a Director of Product Marketing from the Internet Explorer Team CC’d on the email helped. (Something to keep in mind: build your network, don’t annoy them by over-using it, but when the time comes if the only favor you have to call in is “put up with one extra email” then call in that favor and get it done.)

So, m.weightwatchers.com and mobile.weightwatchers.com are scheduled to come off of the compatibility view list on or before February 28, 2013. So, sorry about making you sit tight for a month, but help is on the way even if I can’t get their devs to learn the beauty of x-ua-compatible for getting IE to bend to their will. Keep my honest and ping me if you don’t see it fixed. In the interim, happy tracking!

Windows Compatibility Center Supports Windows 7, Windows 8, and Windows RT

2013-01-09T01:16:16Z

While Microsoft isn’t the final arbiter on whether an application is “compatible” with any given version of Windows (see: http://blogs.msdn.com/b/cjacks/archive/2010/01/12/what-does-it-mean-to-be-compatible-with-windows-7.aspx) a few years ago we launched an initiative to help reduce a bit of the burden of looking up every app you care about by aggregating some of that data into a single website, which you can find here:

http://windows.com/compatibility

For Windows 8, we ended up branching it, because there are all kinds of people who are still furiously working to finish up Windows 7 migrations before April 8, 2014, so we didn’t want to take that down, and at the same time we also wanted to talk about Windows RT, so in case you haven’t noticed this (I’ve talked to a few people who hadn’t) we have a dropdown now which lets you choose the platform you are targeting:

Hopefully this will be helpful as device and operating system heterogeneity becomes more commonplace!

Debugging the new WeightWatchers Mobile Site on IE10 for Windows Phone 8

2012-12-18T20:24:46Z

It’s been a while since I’ve done a debugging post, and I thought it was about time I came back and did one again.

As some of you may have figured out, I travel now and then. (I am at just over 195,000 BIS – butt in seat - miles so far in 2012.) And, if you travel as well, you know how damaging this can be to your waistline. So, I decided to nip this little gain in the bud and join WeightWatchers. Now, shortly after I joined, they updated their mobile website, and warned that “Windows Mobile” (apparently they didn’t get the re-branding memo) might not work.

That’s a challenge if I ever heard one.

So, I went to the site, and sure enough, it really didn’t work. I just saw this:

So, they were right. But – there really is no reason why we shouldn’t run an HTML app with our latest and greatest IE10 browser unless they took a hard dependency on some unstable spec which we hadn’t implemented yet.

So, first stop – the developer tools. This one turned out to be pretty easy, as the console went ahead and spat this out:

HTML1200: weightwatchers.com is on the Internet Explorer Compatibility View List ('C:\Users\cjacks\AppData\Local\Microsoft\Internet Explorer\IECompatData\iecompatdata.xml').
m.weightwatchers.com

Aha! Another example of developers not wrapping their heads around the confusing world of Internet Explorer’s compatibility infrastructure and our rabid desire to keep all of your sites working. Only this time, it appears we actually broke the site with the compatibility view list!

To find out, I switched out the document mode using the F12 developer tools, and voila:

So, what can they do to get around this, rather than having to tell all of their Windows Phone customers to just use the junky old site (and then pay to continue maintaining it)?

First, they could immediately fix their site by adding X-UA-Compatible to the headers, and overrule our compat view setting for this part of the site.

Second, they could make sure that everything works, and then get themselves removed from the compat view list by sending mail to iepo at microsoft.com.

But this illustrates the conundrum we face in app compat. By keeping old sites working, we inadvertently broke a new site, and unaware of the compatibility infrastructure that was hindering rather than helping them, they just threw up their arms and decided to keep the old site around. Compatibility adds complexity and confusion, but when it works it makes customers very happy.

Changes to Shim Global Exclude in Windows 8

2012-12-13T16:49:56Z

Lex III: Actioni contrariam semper et æqualem esse reactionem: sive corporum duorum actiones in se mutuo semper esse æquales et in partes contrarias dirigi.

I remember a time when all bugs were bad, and it was my job to find and destroy them all. That, of course, was when I was a developer. My perspective is quite different now that I am an app compat guy. You see, fixing a bug eliminates that bug, but technology is sufficiently complicated these days that fixing a bug often has unintended consequences. In other words, it creates new bugs, which may actually be worse than the one you fixed.

That’s the challenge we face in all of app compat – fixing something breaks other things. It happens all the time. It’s the reason why we introduced Switchback in Windows 7.

The single biggest impact of a bug fix I’m aware of is the DOCTYPE bugfix we put in for IE7.

And we fixed another bug in Windows 8 which may impact you if you are currently holding your busted apps together with some shim duct tape on Windows 7, and choose to update to Windows 8 (or if you are hoping to transition your skills to that).

What is the bug fix?

The shim infrastructure supports includes and excludes for particular modules at multiple levels. We can include and exclude modules at the individual shim level. We can do so at the application level. And the platform also supports doing so at the global level.

Except … there was a bug in the global exclude. We never applied it. (Well, except the System32 directory exclude.)

How might that affect you?

Well, we applied the global exclude to managed code. You see, there is no way for the shim infrastructure to differentiate between the framework and your app when running managed code. And shimming the framework can have many unintended consequences which leads to mysterious, difficult to troubleshoot failures. So, rather than create an even worse situation, we excluded it and you would have to consider alternatives (or work a little harder to override that with an include).

But since we never applied it, you could very easily shim managed code. (Except, as many have noticed when first experimenting with shims, version lies.)

And if you migrate that shim database forward to Windows 8, then some apps will no longer be shimmed without an include. For example, for anyone demonstrating shims, Stock Viewer needs includes to fix most of the issues (unless the shim itself has an include, like ForceAdminAccess does).

So far, the biggest audience I’ve seen impacted in practice are those using Stock Viewer, but I wanted to point out the bug fix – the solution being to simply add includes when you need to shim managed code, or to consider other alternatives. Happy shimming!

App Compat with Windows 8 Chat - December 7, 2012

2012-12-06T22:29:18Z

Just in time for the holidays, on December 7, 2012 (tomorrow as I write this), 1:00pm Central, I’ll be chatting with my friends from ChangeBase / Quest / Dell about the app compat landscape for Windows 8. You can join in the conversation here:

http://www.quest.com/webcast/webcast-key-application-compatibility-considerations-for-migrating-to-818803.aspx

Hope to chat with some of you tomorrow!

Aaron Margosis Updates LUA Buglight for Windows 8

2012-11-29T19:22:52Z

Another new operating system means another new LUA Buglight!

My friend Aaron recently released an update to LUA Buglight to support Windows 8. So, for any customers who are still using Windows XP but migrating directly to Windows 8, or those who are using Windows Vista or Windows 7 but chose to disable UAC (so clearly I wasn’t available to come and talk you out of doing that), now you have the chance to help test applications which are failing as a standard user on Windows 8!

For those of you who are unfamiliar with LUA Buglight, it is the best tool out there for diagnosing standard user issues (“LUA Bugs” – hence the name). Why is it the best? Because the approach it uses is to let Windows itself tell you what’s wrong. First, it tries with a standard user token, and if that fails, it tries again with the admin token. If that works, then you have a LUA Bug. (Whether or not it is breaking and therefore needs to be fixed is another story, as discussed elsewhere.) That’s much more precise than trying to be predictive or re-create the logic in Windows, particularly in cases where there is more subtlety than just Users and Administrators.

Oh, and during the dev cycle for the update, I helped Aaron sort out a bug that would affect you over slow links to the corporate network, so this should work even better in situations where you are on a slow WAN connection (or, as I was, on a Cellular modem connected via DirectAccess). It’s a pretty good deal, you see – I gripe about something, and Aaron has to write to code to fix it. A perfect division of labor!

Go and grab it now here:

LUA Buglight 2.2 with support for Windows 8

Thanks Aaron!

Defining Red, Amber, and Green (RAG) Statuses

2012-11-28T21:10:42Z

A few years ago, AppDNA and ChangeBase (listed alphabetically, so please don’t infer anything from the ordering, though they are also sorted by the capacity of their original CTOs to consume gin and tonics – I won’t say if that is ascending or descending) came along and fundamentally redefined the language of app compat with the introduction of one simple concept: the RAG (Red, Amber, Green) report.

The RAG report is a very elegant idea – you get some indication of whether things work or not in a simple, highly visual report that lends itself well to pie charts and executive reports.

And this idea, like all great ideas, took off like wildfire when applied to app compat. I know of no customer who doesn’t phrase their app compat work in the context of a RAG status these days.

But eventually, a bit of a problem emerged – that there was no consistent operational definition of the Red, Amber, and Green statuses. (Well, in addition to the problem that Americans call yellow lights “yellow lights” rather than “amber lights”, but in addition to forcing Americans to learn just one British colloquialism, RAG also just sounds better than RYG reports.)

Here are just some of the definitions I have seen:

Red	Amber	Green
Broken, but can’t be auto-fixed	Broken, but can be auto-fixed	Works
Broken	Works, but with issues	Works
Broken, needs code remediation	Broken, can be shimmed or repackaged	Works

With all of these potential definitions, it’s hard to say what it means to be a Red, Amber, or Green application. And, as most customers continue to use this taxonomy throughout the app compat project, I have also noticed that many customers end up changing the operational definition within the scope of a single project.

That makes it very difficult to make this data actionable!

The problem is that we have conflated whether an app works or not with how hard it’s going to be to fix it. So, lately I have been working with the customers I work with to disambiguate the statuses and agree on a single definition, and then track the fix difficulty separately.

Here is the definition that I use:

Red	Amber	Green
Known issues	I don’t know	No known issues

This may seem obvious, but it actually matters quite a lot to have the project agree on the terminology.

Given this, the app compat project can now be much more clearly visualized by these different statuses. Here’s an example:

At the beginning – you don’t know anything. Everything starts out as yellow!

In this example, the customer chose to start with static analysis. (Lately, I’ve been noticing a trend of folks starting with Install/Launch Testing – ILT - and then leveraging static analysis to diagnose failures.) At the end of static analysis, they still didn’t know compatibility status for all of their apps, but they know a lot more.

At the end of ILT, however, note that we don’t have any more amber. We have either seen it work, or we have seen it fail and sent it over for remediation. An app exits ILT when it has been remediated and turned to green.

The next phase is UAT, where the user validates that the application works correctly. Remember, though we had some red apps in ILT, they didn’t exit until they were remediated and validated green in ILT. But we find still more red apps that only the user can find! (That is, after all, why we have UAT.) Once we’ve fixed all of those, we hit our finish line.

So, app compat is the gradual progression from Everything Amber to Everything Green, with some apps turning Red along the way (perhaps multiple times, if we find and fix bugs discovered at different stages of the process), but always eventually being transformed to Green somehow.

With this definition in place, I’ve had a lot more success not only using this terminology with customers who are using static analysis tools, but also taking it and extending it throughout the project and through other tools and services, not to mention even using it for products that don’t have tools which produce such reports.

(It also means that, if a tool generates output with a different definition, I always go in and tune the output to match my definition, so the data and statistics become more meaningful and actionable.)

Troubleshooting my Battery Life Issues on the Nokia Lumia 920

2012-11-27T17:12:44Z

Right before the Thanksgiving holiday, I picked up a new Nokia Lumia 920 and had the week free to play around with it. Right off the bat, the battery life seemed pretty good, but a few days later I came across a bit of a problem with battery life (meaning I was getting maybe 7 hours – not even a whole day). Without benefit of Mark’s Sysinternals Tools, it was time for a bit of debugging without a debugger.

My job was made somewhat easier by the occasional “ping!” noise from my pocket. After a while, I finally pieced together what that was – my pocket was going “ping!” every time it was speeding. (Which obviously was always the result of an unexpected gust of gale-force tail wind, since I would clearly never intentionally violate the law.) It was then that I discovered a new feature in Windows Phone 8: Background Location Tracking.

You see, I had started up the Nokia Drive (Beta) app, and then just pressed the Home key to get back. Normally, even if the process wouldn’t end, it would still be suspended – which was good enough. It’s no longer being scheduled by the CPU and memory will be freed when needed. But developers imagined scenarios where background execution could be interesting – perhaps providing feedback via a Live Tile, or (as demonstrated at Build 2012) tracking a run.

But I wasn’t trying to track my journey, and didn’t need feedback at all. Yet, here I was, sacrificing my battery to track a location that I didn’t knowingly choose to have tracked. And boy, was it burning fast!

This is today’s conundrum for application developers. We can envision scenarios where having true multitasking support is useful. But – how often do we actually need them? While it’s easier to conceptualize a world in which your app is running all the time, does the user really want to donate his battery to that cause? And can app developers be honest and admit that their application is not The Most Important Application in the History of the World? The scenario of “I would like my battery to last at least all day” is something I hit daily – the scenario of “I would like to track my location on an app I am not looking at” is something I hit … never. Makes me wish someone had brought some data into the decision rather than just their imagination before choosing a default.

Of course, had I closed the app with the “back” key rather than the “start” key, I wouldn’t have faced that problem. But I like the idea of just suspending an app – assuming it complies with my expectation that it’s then not still being scheduled for CPU time.

Of course, I then found a couple of additional things via web searches. I uninstalled and then reinstalled both Facebook and Skype, and then I let my battery run down to zero before recharging (which was pretty easy to do with battery life as it was). After doing these things, battery life now exceeds my expectations – hitting over 2 days with my typical (moderate) use!

New Windows 8 Springboard App Compat Content

2012-11-14T17:09:42Z

My blog sure has been quiet lately, but that doesn’t mean I haven’t been writing anything! A lot of my focus has been on laying the groundwork for a refreshed set of app compat content for Windows 8, to put up on the Springboard site. Well, it’s finally live, so here is the writing that hasn’t gone up here on my blog:

Understanding Application Compatibility

Getting Started with Application Compatibility in a Windows Deployment

Five Steps to Windows 8 Application Readiness

Managing Shims in an Enterprise

Five Things Every IT Professional Should Know About Application Compatibility

And now that I’ve slogged through that (and managed to do my day job) I should have more time to hang out here…