In the wonderful world of Zune, all the Zune teamsters, Zune coders, Zune pushers, and Zune lovers are busy celebrating the launch of the Zune HD. That’s not to say there aren’t any snags with which to deal. Case in point: I came across this wonderful screen when I tried to sign into my account under Zune 4.0 for the first time:

“Great, there’s no terms to which I must agree. I’ll just go ahead and click Accept,” (the result of which you can see after the jump)

“Crap.”

I’ll chalk it up to quick thinking on behalf of Michael Gillet (@Gilly2468) for coming up with the bright idea of signing in online and accepting the terms there. If you’re one of the few people who, for whatever reason, aren’t able to sign into the Zune account for which you may have paid, try signing in via Zune.net and accepting the new terms there (you’ll see your account edit screen when you sign in, which is where you’ll do this). Once you’re done, you can sign back in via the Zune software and voila, life is good again.

Of course, I’m talking about Java.

I figured I would turn Java into an example of what not to do when designing something for Windows before uninstalling it. Since Sun Microsystems clearly has no idea how to develop for Windows Vista, I’m going to direct them to this wonderful page.

I highlighted the single switch present in the command which indicates the problem: “-auto”. UAC prompts should never be automatically launched without informing the user prior to launching one. It’s very plain and very simple, and when developers start writing applications which throw consent prompts without any obvious reason as to why, they’re clearly doing something wrong.

Worse yet, Java Automatic Update decides to tell me after I click Cancel that it wants to update.

This bubble should be thrown first, followed by launching the consent prompt should the user decide to update. Doing it the other way around is mindblowingly stupid. It’s not exactly an easy thing to screw up, either, so I’m chalking this one up either to developers not knowing what they’re doing or developers testing UAC out for the heck of it to see how many people obey random UAC prompts.

If you’re seeing this, I highly encourage you to click Cancel. Better yet, go ahead and uninstall Java. That’s what I did.

Now if you’ll excuse me, I’ll be going off to celebrate my birthday away from random UAC prompts.

This post was originally supposed to be about why blu is faster with WPF, hence the tweet in the image, but after some digging, an equally unusual happening supplanted my original purpose for this post. If you decide to download blu, feel free to follow me as well; blu is a fine application if you don’t mind the occasional random crashing.

When Vista was being developed, the ability to magnify WPF vector graphics was included as an accessibility feature: vectors scaled in the magnifier on a WPF app would be easier to see and read, thus making this feature highly beneficial for those with diminishing sight. However, down the road, the WPF guys decided to scratch this feature in SP1.

Now, before I start, it’s best to know what vector graphics are. Outside the usual jokes about vectors thrown around during the Longhorn days when Aero Diamond managed to be a very persistent rumor, not many people actually understand the benefits of vector graphics over raster images (or, for that matter, what a vector graphic even is).

• Raster images are built pixel-by-pixel stacked like brickwork to generate an image. Because of this, raster images aren’t any good once you start zooming in and seeing the individual pixels. Generally, raster images are great for photographs simply because there’s far too much detail to be captured through points and lines, which brings us to vectors.
• Vector graphics, on the other hand, are built using a series of points connected together by way of instructions for various types of lines. Along with fill, effect, and other instructions generally used to make things look pretty, that’s really all a vector graphic is. Because of this, vector graphics are great for web graphics and other computer-generated things which don’t require photographic precision (Corporate logos are a great example).  Thanks to the fact that vector graphics are rendered upon request, they’re infinitely scalable; all you’re doing when scaling a vector graphic is scaling the math behind the scenes.

Here’s the thing: this feature was supposedly nixed from Vista SP1, but before I found out about this, I tried scaling blu in the magnifier. The text scaled just fine, while the rest of the app did not (though this second bit could just be due to how blu was designed). I tested this out in Windows 7 and found that vector scaling in the magnifier was also kept out of Windows 7, as you can see by the fact that the text in blu is not magnified in Windows 7’s magnifier.

Well, if you take a look at the leading image at the top of this post, you’ll clearly see that vector scaling works in Vista SP1 at least with text (the unmagnified app is to the left).

Anyone have any ideas? I should note that I am on Vista SP1, and I do have .net 3.5 installed.

Yesterday, I took a look at the varying perspectives taken with regards to the Zune 30 debacle. Today, I’ll take a look at what exactly led the Zune 30s to freeze. If you’d like to see the code for the entire driver, click here.

Below the fold lies a sufficiently sized code sample with everything you’ll need to understand what happened with the Zune 30 bug.

Relevant code is non-gray code:

#define ORIGINYEAR 1980 
BOOL ConvertDays(UINT32 days, SYSTEMTIME* lpTime)
{
    int dayofweek, month, year;
    UINT8 *month_tab;

    //Calculate current day of the week
    dayofweek = GetDayOfWeek(days);

    year = ORIGINYEAR;

    while (days > 365)
    {
        if (IsLeapYear(year))
        {
            if (days > 366)
            {
                days -= 366;
                year += 1;
            }
        }
        else
        {
            days -= 365;
            year += 1;
        }
    }

    // Determine whether it is a leap year
    month_tab = (UINT8 *)((IsLeapYear(year))? monthtable_leap : monthtable);

    for (month=0; month<12; month++)
    {
        if (days <= month_tab[month])
            break;
        days -= month_tab[month];
    }

    month += 1;

    lpTime->wDay = days;
    lpTime->wDayOfWeek = dayofweek;
    lpTime->wMonth = month;
    lpTime->wYear = year;

    return TRUE;
}

So what’s the purpose of the while loop? To put it simply, it’s designed to get the number of years from the number of days since 1980 as well as a remainder of days out of the current year. Well, let’s look at how the code plays out in my confusingly simple While Loop in Plain English™. Keep in mind that you’re never supposed to retry the loop without committing some sort of action which will ultimately exit the loop:

1. year is set to ORIGINYEAR. Since ORIGINYEAR is 1980, any addition to year is added on top of 1980. This is fine because the hardware is passing the number of days since January 1, 1980.
2. Is the number of days greater than 365? If so, proceed. Otherwise, skip to number 6.
3. Is the current year a leap year? If so, proceed. Otherwise, subtract 365 from the number of days, add 1 to the number of years, and skip to number 5.
4. Is the number of days greater than 366? If so, subtract 366 from the number of days, add 1 to the number of years, and proceed.
5. retry number 2.
6. …
7. Profit?

The problem lies in the fact that there is one case which can never escape the loop. If it’s a leap year, the number 366 will stay within the loop forever because 366 will never be greater than 366, but 366 will also always be greater than 365. 366 days will pass through, in our Plain English While Loop, without having any action committed upon it.

There’s a very quick solution to this: Since 366 is a valid remainder of days in a leap year (December 31 is the 366th day in a leap year), 366 can technically exit the loop without any problems. All we need to do is add a way to exit the loop when the number of days is 366. Let’s see how things go with this new breakpoint:

1. year is set to ORIGINYEAR. Since ORIGINYEAR is 1980, any addition to year is added on top of 1980. This is fine because the hardware is passing the number of days since January 1, 1980.
2. Is the number of days greater than 365? If so, proceed. Otherwise, skip to number 6.
3. Is the current year a leap year? If so, proceed. Otherwise, subtract 365 from the number of days, add 1 to the number of years, and skip to number 5.
4. Is the number of days greater than 366? If so, subtract 366 from the number of days, add 1 to the number of years, and proceed. Otherwise, skip to number 6.
5. retry number 2.
6. …
7. Profit!

Thanks to the break (represented by “Otherwise, skip to number 6”), 366 days can escape the loop properly. This would lead to the end result for December 31, 2008 being years == 2008 and days == 366.

This is what the break would look in the while loop:

    while (days > 365)
    {
        if (IsLeapYear(year))
        {
            if (days > 366)
            {
                days -= 366;
                year += 1;
            }
            else
            {
                break;
            }
        }
        else
        {
            days -= 365;
            year += 1;
        }
    }

Clarifying one quick thing: A number of people on outlets such as Digg suggested that changing “if (days > 366)” to “if (days >= 366)”:

The problem with doing this is that the end result, upon hitting “if (days >= 366)” with the value 366, one would end up with the year going up by one and the operation “366 –= 366” playing out. End result: December 31 of the leap year is suddenly January 0 of the following year.

Extra credit: This loop can be fixed such that the loop’s condition is based on the year’s status as a leap year. The change needed is simple:

    while (days > (IsLeapYear(year) ? 366 : 365))
    //The above line basically says “Is it a leap year? Check days against 366.
    //Otherwise, check it against 365”
    {
        if (IsLeapYear(year))
        {
            days -= 366;
            year += 1;
            /*You’ll notice we no longer need a break. The loop condition now
             *checks the days properly. Because the loop properly checks
             *whether days is greater than 365 or 366, the second days > 366
             *check is no longer needed. */
        }
        else
        {
            days -= 365;
            year += 1;
        }
    }

However, if this change is made, IsLeapYear() is now being called twice. This is inefficient, especially on small devices (like the devices which would be using this driver). In order to reduce the number of times IsLeapYear() is being called, it would be best to store the value of IsLeapYear() in a variable.

    int leap = IsLeapYear(year);
    //leap is determined before the loop begins.
    //In this case, it would be true (1980 is a leap year)
    while (days > (leap ? 366 : 365))
    {
        if (leap)
        {
            days -= 366;
            year += 1;
        }
        else
        {
            days -= 365;
            year += 1;
        }
        leap = IsLeapYear(year);
        //leap is determined again now that the year has changed.
    }

This can actually be reduced even further. If you look at how the if/else statement is operating, you can see that it’s basically saying “If it’s a leap year, subtract 366. Otherwise, subtract 365,” which is similar to the while loop’s condition!

    int leap = IsLeapYear(year);
    while (days > (leap ? 366 : 365))
    {
        days -= (leap ? 366 : 365);
        //days is equal to days - 366 if it's a leap year,
        //                 days - 365 if it isn't.
        year += 1;
        leap = IsLeapYear(year);
    }

If you wanted to reduce the number of times (leap ? 366 : 365) is checked, you could do this instead:

    int daysThisYear = (IsLeapYear(year) ? 366 : 365);
    //The number of days in the current year is now calculated instead. 
    while (days > daysThisYear)
    {
        days -= daysThisYear;
        year += 1;
        daysThisYear = (IsLeapYear(year) ? 366 : 365);
    }

It’s questionable whether or not this code is any better than the original solution with the break, but this would be the “proper” way to do it (instead of using an arbitrary break in your code). It’s also easier to understand if you know C.

The irony in all of this is that this specific driver is used in multiple Windows CE devices, not just the Zune. This is why quality assurance is so necessary.

There are three morals here:

1. Test every condition which could happen in every single loop in your code (though, as Matt Boehm points out in the comments, this might be a tad bit hard).
2. Don’t visit Digg for programming advice. What you’ll hear is questionable at best
3. Make your code easy to read for other developers.

This is a shout-out to all Zune 30 owners who remained patient.

This is to you, the faithful owner of a Zune 30, who didn’t buckle under stress and kept a keen eye on Microsoft, waiting for a solution.

This is to you, the discount shopper who picked up a Zune 30 and didn’t want to lose faith in your hardware.

Low and behold, Microsoft dug deep to find out the problem and, within minutes of finding out exactly what it was, pushed out an answer and a solution that didn’t void your warranty (thanks, Gizmodo). There’s a reason for why I’m bringing all of this up. July of 2008 saw cataclysmic server failure when a vast majority of all newly-purchased iPhone 3G units tried activating at nearly the same time, leaving both new iPhone 3Gs and some iPhone Gen 1 units dead in the water until the activation servers came back online. Poor planning led to the creation of a load-intolerant system on AT&T’s side (though the blame hardly belongs to them, given that Apple mandated this system in the first place). However, people weren’t infuriated by Apple’s ineptitude here. They were complacent and merely went with whatever explanation was fed to them. Meanwhile, a sizable majority of people who stuck with their own platforms of choice decided not to point and jeer.

Fast forward to December 31, 2008, and every Zune 30 device freezes due to a bug in a driver from Freescale Semiconductor in this while loop (between lines 259 and 274):

    while (days > 365)
    {
        if (IsLeapYear(year))
        {
            if (days > 366)
            {
                days -= 366;
                year += 1;
            }
        }
        else
        {
            days -= 365;
            year += 1;
        }
    }

(protip: day 366 triggers an infinite loop. To see the context of the code, check out the pastie link above, or just click here. You can see a breakdown of how this could’ve been handled here) 

What happened? Every Apple-loyal iPhone, iPod, and Mac owner threw a fit even though none of them actually owned a Zune 30 (You can’t run a Zune 30… or any Zune, for that matter, on a Mac). Thanks in part to the additional sensationalism promoted by gadget bloggers and, subsequently, news outlets the world over, a problem with a Zune model sold only in North America suddenly became a "Worldwide Zune Outage."

This is the difference between the Social and the Kingdom of Apple. Those with Zunes held out patiently and were rewarded with verbose output by Microsoft, whereas Apple simply vaguely alluded to some other company being the source of their problems (or were otherwise mute for a long period of time) whenever something on Apple’s side went wrong.

Thank you, Zune 30 owners, for living up to the hype of the Social. I’m now quite proud to be an owner of a Zune myself.