Xbox 360 Support Sucks

They may have retooled enough to become efficient at repairing red ringed Xbox 360 consoles, but boy do they suck at general support. A week or two ago my 360 stopped being able to play NetFlix video over HDMI, stating that a “secure HDCP link could not be found.” Contacting NetFlix has been resourceful in the past, so I did this with no luck. After explaining I was in a preview program for the new dashboard, they redirected me to Microsoft. So that is where I went! I didn’t feel like calling them and waiting on hold for hours and hours and thus emailed them. Here is the response I just received.

Hello John,

Thank you for contacting Microsoft online support for XBOX. I am XXXXXXXXX and I will be helping you today with this issue.

As I understand it, when you use an HDMI cable to connect your Xbox 360 to your HDTV or monitor, you experience one of the following display issues:
. A green or purple tint to the video
. Extensive flickering for more than several seconds when you play video, use the Xbox Guide, or switch from the Dashboard to a movie
. Image “ghosting”

I know how disappointing it is that the cable you’re using is not working properly. Please be assured that I will do my best to help you resolve the issue.

Wow. So problems with this response? Well it doesn’t actually restate my problem but attempts to and fails miserably. I also love how they immediately blame the cable, as if that was the problem here. The email then goes on to suggest connecting to live to obtain automatic updates, unplugging my HDMI and plugging it back in as well as adjusting my HDTV settings to obtain “optimal resolution.”

Fortunately NetFlix did something internally because a day or two later the problem resolved itself. It turns out that some videos aren’t allowed to be streamed to the Xbox 360 and I just happened to be trying to play some of them. Movies that had stopped working that were working started working again like magic. And they thought it was my cable…. ha! Cables don’t just break, hardware that is known to go bad does.

Difference Between System.* and Microsoft.*

Scott Hanselman has been on a roll lately with his posts and twits. Today he writes “Question to .NET Programmers: what is the difference between the System.* and Microsoft.* namespaces?”

This is an important question and one that I can’t say I truly know the answer too. I had always assumed it was based on either the idea that System.* was part of the core framework where as Microsoft.* was for Microsoft specific functionality. For instance, it would be expected that much or all of the System.* functionality would be replicated on many other platforms where as Microsoft.* would not.

Certainly this is true for the very basic feature set such as the common types but it is not true for System.Windows.Forms. Which begs the question that I always wondered: why is Windows.Forms where it is? I always expected it to be in Microsoft.Windows.Forms as it is a Windows specific implementation based on many of the Win32 controls.

Weighing In On EIPL

EIPL, or English as the International Programmer Language, seems to have been brought up again around the blogosphere. It seems to have started on Scott Hanselman’s blog with a comment stating “If you don’t know English, you’re not a programmer!” Of course it does not end there: Bjoern writes about it in a blog post saying “In regard to translated documentation: I wouldn’t use it. Maybe it is because I learned programming during the dark ages when everything development related was English – it is even possible to claim I learned English through such documentation – or maybe the early days of localizations spoiled my conception of its quality.” And finally it appears here with generally the same attitude: that English is quickly becoming or should become the official language of programmers.

I believe that English should not be the official language. It is nice to know that variable names will generally be in a language I can understand, however I believe that this can be fixed in the future with language independent coding taking the place of what we do not. Visual Studio is already an incredibly powerful tool and it wouldn’t surprise me if within a decade or two it would begin to support the dynamic localization of variable names. It would be ignorant of me to demand or expect all source code to be in English.

However, the one caveat here is that non-English speaking programmers or wannabes should most likely learn English simply because features like the one mentioned above will take many years to come about and perfect. Furthermore, it can be said that English is somewhat of an international language. In Western cultures it is very easy to find someone who speaks English and it is quickly spreading throughout the tiny corners of the world. For evidence of this, look no further than the Olympics which was conducted in (I believe) three languages. If memory serves me correctly it was English, French and Chinese. This was due to the host country (China) and the IOC (Official Languages: English, French).

While on the subject of languages there is another potential problem. While languages based on Latin or in similar style (left to right) can be well understood by an immense amount of people in the community, vertical and right to left languages that feature non-alphanumeric characters can cause more problems than just being able to understand the meaning. I can’t imagine what source code written in Chinese or Japanese would look like.

The Difference Between New and Override

This is a fundamental topic in C# and if you plan to do any development at all with the language you need to know this. Override is used for changing the behavior of the original type’s method or property. The new keyword, in this case, is used for scratching the existing behavior but only in the current type. To better explain this, consider the following code.

public class Foo{
     public virtual void Print(){
          Console.WriteLine("I am a Foo!");
     }
}

public class Bar : Foo{
     public override void Print(){
          Console.WriteLine("I am a Bar!");
     }
}

If we declare a Bar and cast it to a Foo in the above code, we will still get “I am a Bar!” when we invoke the Print method. However, if we change the code to the following things will get messed up a bit.

public class Foo{
     public void Print(){
          Console.WriteLine("I am a Foo!");
     }
}

public class Bar : Foo{
     public new void Print(){
          Console.WriteLine("I am a Bar!");
     }
}

If we instantiate a Bar, we will get the new functionality. However, if we cast that Bar object into a Foo, we will get the implementation provided by the Foo. So be sure of what you are using and why!