gaisen

Custom WCF Authorization using ServiceAuthorizationManager

2008-12-09T19:37:00Z

I was recently tasked with implementing authentication and authorization in an existing WCF-based service using Windows Live ID. The service already had an extensive set of BVT tests that I didn't necessarily want to break. Integrating Live ID authentication in our service tests would require some additional code modifications and require another pass through those tests.

So, implement authentication and authorization and don't make modifications to existing test code. Seems relatively straight-forward! I grabbed my favorite group of triage to bounce design decisions around and our authorization scheme more or less ended up with two code paths: 1) If the Windows user account is present and in a Test security group OR 2) If the LiveID user is authenticated and authorized, return true.

That's alright; we're adding in some code to make things testable. And, of course, that code would require testing. And creating/maintaining a security group. But it could be better. In comes the ServiceAuthorizationManager class.

WCF allows you to create classes that derive off of ServiceAuthorizationManager. When you do this and override the CheckAccessCore method, you can implement an authorization scheme across all of your web service method calls. In my case, I created a LiveIdServiceAuthorizationManager class that attempts to cast the HttpContext.Current.User.Identity to a PassportIdentity. Some internal authorization checks are made based on that information.

Creating a custom ServiceAuthorizationManager is straightforward and looks like:

    public class LiveIdServiceAuthorizationManager : ServiceAuthorizationManager
    {
        protected override bool CheckAccessCore(OperationContext operationContext)
        {
            PassportIdentity currentUser = HttpContext.Current.User.Identity as PassportIdentity;
            bool isAuthorized = false;

            if (currentUser != null)
            {
                ...
            }

            return isAuthorized;
        }
    }

Enabling our custom authorization manager is a configuration change that looks something like this:

The <serviceAuthorization> node can be removed in BVT scenarios, allowing the service to successfully run through our BVT process without any code changes. However, when the node is present, callers must be authenticated through Live ID. This fulfills both of our requirements in a seemingly elegant way.

UI Automation in Silverlight - Part II (The Easy Way)

2008-07-17T19:19:00Z

So, I wrote a blog post a bit earlier on exposing custom controls for accessibility and automation in Silverlight. If you're only interested in the automation perspective and the Silverlight unit testing framework doesn't quite suit your needs, then there's an easier way than going out and implementing AutomationPeer types.

As of Silverlight Beta 2, you can utilize the AutomationProperties.AutomationId attribute in your XAML to make types you use unique and identifiable through automation:

   <TextBox AutomationProperties.AutomationId="SearchTextBox" x:Name="SearchText" KeyDown="CheckKey" />

AutomationProperties.AutomationId doesn't come up in Intellisense in Beta 2, and you'll get a false positive on the "The attachable property 'AutomationId' was not found in type 'AutomationProperties'." error message. Ignore it for now and spin up your Silverlight app :) Once this has been done, your element should look something like this when identified in UISpy (more):

   Identification
    ClassName:    ""
    ControlType:    "ControlType.Custom"
    Culture:    "(null)"
    AutomationId:    "SearchTextBox"
    LocalizedControlType:    "custom"
    Name:    ""
    ProcessId:    "2808 (iexplore)"
    RuntimeId:    "42 197822 3"
    IsPassword:    "False"
    IsControlElement:    "True"
    IsContentElement:    "True"
 
  Visibility
    BoundingRectangle:    "(240, 327, 300, 23)"
    ClickablePoint:    "390,338"
    IsOffscreen:    "False"

So, if we want to simulate a user at this point, we have three objectives:

1. Move the mouse cursor over to the ClickablePoint.

2. Click the mouse button.

3. Start typing.

To move the cursor to the clickable point, we need to set the Cursor.Position property. To do this, we must do a conversion between System.Windows.Point and System.Drawing.Point. I chose to handle this conversion through an extension method that looks something like:

    public static class ExtensionMethods
    {
        public static System.Drawing.Point ToDrawingPoint(this System.Windows.Point windowsPoint)
        {
            return new System.Drawing.Point 
                    {
                        X = Convert.ToInt32(windowsPoint.X),
                        Y = Convert.ToInt32(windowsPoint.Y) 
                    };
        }
    }

Once we've moved the mouse, we also need to simulate a click. We're a DllImport away from making that happen. We can create a nice wrapper class to simplify our calling code:

    public static class Mouse
    {
        private const UInt32 MouseEventLeftDown = 0x0002;
        private const UInt32 MouseEventLeftUp = 0x0004;

        [DllImport("user32.dll")]
        private static extern void mouse_event(UInt32 dwFlags, UInt32 dx, UInt32 dy, UInt32 dwData, IntPtr dwExtraInfo);
 
        public static void Click()
        {
            mouse_event(MouseEventLeftDown, 0, 0, 0, IntPtr.Zero);
            mouse_event(MouseEventLeftUp, 0, 0, 0, IntPtr.Zero);
        }
    }

So, we set automation IDs on our elements in XAML, we can identify elements with unique automation IDs, we can move the mouse with an element's ClickablePoint property, and we can simulate a mouse click. How does this all come together?

        [TestMethod]
        public void TestMethod1()
        {
              // Assumes an existing Internet Explorer process is running and pointed at your Silverlight app
            Process process = System.Diagnostics.Process.GetProcessesByName("iexplore").First();
            AutomationElement browserInstance = System.Windows.Automation.AutomationElement.FromHandle(process.MainWindowHandle);
            Thread.Sleep(1000);
 
            TreeWalker tw = new TreeWalker(new PropertyCondition(AutomationElement.AutomationIdProperty, "SearchTextBox"));
            AutomationElement searchBox = tw.GetFirstChild(browserInstance);
            Thread.Sleep(1000);
 
            System.Windows.Point uiaPoint;
 
            if (searchBox.TryGetClickablePoint(out uiaPoint))
            {
                Cursor.Position = uiaPoint.ToDrawingPoint();
                Mouse.Click();
                SendKeys.SendWait("Hello, world!");
            }
            else
            {
                Assert.Fail();
            }
        }

But what if you're dynamically building out your controls in code? You can still set the AutomationId property of generated controls using the static methods in AutomationProperties, which would look something like this:

    ListBoxItem myDynamicListBoxItem = new ListBoxItem { Content = "Hello, world!" };
    AutomationProperties.SetAutomationId(myDynamicListBoxItem, "myDynamicListBoxAutomationId");

SendKeys has some new behaviors that were introduced in the .NET Framework 3.0. If that sort of thing interests you, you can read more about it here. If you find that those results give you some inconsistent behaviors, you can make the following addition to your app.config in your Test project:

    <appSettings>
        <add key="SendKeys" value="SendInput"/>
    </appSettings>

Hope this helps :)

UI Automation in Silverlight - Simulating User Interactions

2008-07-12T06:07:27Z

I was recently tasked with automating Silverlight Rich Internet Applications (RIAs) in our immediate group. Some tools out there provide limited assistance in this regard; for example, you can write unit tests against your Silverlight controls for in-proc testing. You can read more about that approach here: http://www.jeff.wilcox.name/2008/03/31/silverlight2-unit-testing/

Unfortunately, my requirement is to enable scenario automation. We must simulate a user that goes through several user flows both within and outside of our RIA; move the mouse somewhere, click on a thing, go to a 3rd party authentication provider, start typing some keys, and so on. The Silverlight unit testing framework doesn't quite address this requirement.

UI automation in Silverlight has been a hotly followed topic around here. With the release of Silverlight Beta 2, we started seeing some accessibility stubs come into play. More correctly, we started seeing the WPF way of doing UI automation start to trickle in. If you want to follow along, you're going to want to grab UISpy (http://blogs.msdn.com/windowssdk/archive/2008/02/18/where-is-uispy-exe.aspx).

The Microsoft UI Automation (UIA) assemblies were released with the .NET Framework 3.0. Traditionally, we've had various COM wrappers to work with Microsoft Active Accessibility (MSAA), which isn't going to get you very far with your Silverlight application. If you've done any sort of UI automation in WPF, then you're going to feel right at home. So, without dwelling on that further, let's start working with UIA!

First, let's start a new Test project in Visual Studio 2008. The UIA namespaces that you'll need to start automating applications in Silverlight are System.Windows.Automation and System.Windows.Automation.Providers. You'll need to add references to these assemblies that ship with .NET 3.0+ to get the relevant parts:

- UIAutomationProvider.dll

- UIAutomationClient.dll

- UIAutomationClientsideProviders.dll

- UIAutomationTypes.dll

Let's say that we need to automate a Silverlight control that we own. We'll need to override the OnCreateAutomationPeer method (from the Control class) to return our own Peer type that handles the accessibility functions of the control. This is important, because the accessibility functions will be key in letting us automate our application.

Assume a hypothetical Search control that consists of a text box and a search button:

    public partial class SearchBar : Control
    {
       ...
 
        public SearchBar()
        {
            this.GotFocus += (sender, args)
                =>
                {
                    this.SearchText.Focus();
                };
 
            InitializeComponent();
        }
 
       protected override AutomationPeer OnCreateAutomationPeer()
       {
           return new SearchBarAutomationPeer(this);
       }
    }

We've overridden the OnCreateAutomationPeer, which will get called by anything that's inspecting your control tree for accessibility functions (and consequently, your automation functions). The Peer object will be responsible for returning your combination of controls in a manner that is coherent to anything that needs accessibility.

In the process of doing so, we've also wired up the GotFocus handler to set up our controls' default .Focus() behavior.

Let's take a look at what we need to implement the SearchBarAutomationPeer class:

    public class SearchBarAutomationPeer : FrameworkElementAutomationPeer, IValueProvider
    {
        public SearchBarAutomationPeer(SearchBar searchBar) : base(searchBar)
        {
        }

Our Peer class needs to derive from FrameworkElementautomationPeer to provide all the methods that we're going to need to work with. IValueProvider maps out to interacting with the TextBox component of our custom control. You can learn more about the Provider interface mapping to individual components here: http://msdn.microsoft.com/en-us/library/system.windows.automation.provider.aspx

We need to give our control a class name and an accessibility identifier to find it in the control tree. To do this, we must override GetAutomationIdCore() and GetClassNameCore() from FrameworkElementAutomationPeer.

        protected override string GetAutomationIdCore()
        {
            return "SearchBar"; // You're going to want to make this unique. ;)
        }
 
        protected override string GetClassNameCore()
        {
            return "SearchBar";
        }
 
        protected override bool IsKeyboardFocusableCore()
        {
            return true;
        }

IsKeyboardFocusableCore is an important override to add in, as well; without it, our calls to SetFocus() on the control will fail. We should also think about implementing our Provider interface. The SearchBar that we passed into our constructor maps out to the base.Owner property. Casting base.Owner to SearchBar is going to get tedius, so we'll add a property to make working with that easier as well.

        public SearchBar SearchBar
        {
            get
            {
                return (SearchBar)base.Owner;
            }
        }
 
        #region IValueProvider Members
 
        public bool IsReadOnly
        {
            get 
            {
                return this.SearchBar.SearchText.IsReadOnly;
            }
        }
 
        public void SetValue(string value)
        {
            this.SearchBar.SearchText.Text = value;
        }
 
        public string Value
        {
            get 
            {
                return this.SearchBar.SearchText.Text;
            }
        }
 
        #endregion

If we take a look at our control in UISpy, it should now look something like this:

  Identification
    ClassName:    "SearchBar"
    ControlType:    "ControlType.Custom"
    Culture:    "(null)"
    AutomationId:    "SearchBar"
    LocalizedControlType:    "custom"
    Name:    "SearchBar"
    ProcessId:    "2276 (iexplore)"
    RuntimeId:    "42 197110 6"
    IsPassword:    "False"
    IsControlElement:    "True"
    IsContentElement:    "True"
 
  Visibility
    BoundingRectangle:    "(356, 286, 949, 36)"
    ClickablePoint:    "830,304"
    IsOffscreen:    "False"
 
ControlPatterns
  Value
    Value:    ""
    IsReadOnly:    "False"

The "Value" property under ControlPatterns automagically comes from the IValueProvider interface, mapping out to the value of our underlying TextBox. Slick, huh?

So we've done some plumbing to enable our Silverlight control. Let's take a look at our test method looks like:

        [TestMethod]
        public void TestMethod1()
        {
            Process process = System.Diagnostics.Process.GetProcessesByName("iexplore").First();
 
            AutomationElement browserInstance = System.Windows.Automation.AutomationElement.FromHandle(process.MainWindowHandle);
            TreeWalker tw = new TreeWalker(new PropertyCondition(AutomationElement.ClassNameProperty, "SearchBar"));
            AutomationElement searchBar = tw.GetFirstChild(browserInstance);
 
            myElement.SetFocus(); 
            Thread.Sleep(1000);
            searchBar.SetFocus();
            Thread.Sleep(1000);
 
            SendKeys.SendWait("Hello, world!");
        }

You might be asking yourself a couple of questions at this point: "Why did I implement IValueProvider?" for example. Well, the snippet above simulates user input. If that isn't your thing, in comes the ValuePattern. As an aside, I found interacting with the ValuePattern/TryGetCurrentPattern/etc and found the whole experience to be a bit clunky. You can see what I mean below:

        [TestMethod]
        public void TestMethod1()
        {
            Process process = System.Diagnostics.Process.GetProcessesByName("iexplore").First();
 
            AutomationElement myElement = System.Windows.Automation.AutomationElement.FromHandle(process.MainWindowHandle);
            TreeWalker tw = new TreeWalker(new PropertyCondition(AutomationElement.ClassNameProperty, "SearchBar"));
            AutomationElement searchBar = tw.GetFirstChild(myElement);
 
            object valuePattern;
            searchBar.TryGetCurrentPattern(ValuePattern.Pattern, out valuePattern);
            ((ValuePattern)valuePattern).SetValue("Hello, world!");
        }

This is by no means a comprehensive guideline, but it should be enough to get those of you out there interested in UI automation going.

One caveat: applications with Windowless enabled show up as one huge control if you're looking in UISpy. Hopefully, support for accessibility (and subsequently, automation) will be in RTW builds of Silverlight. If you want to perform UI automation on your Silverlight application today, you'll have to do it without Windowless.

LINQ to SQL: Optimizing DataContext construction with the factory pattern

2008-05-20T02:10:00Z

In the context of building out a web application, the corresponding DataContext is meant to be built out several times. The application's DataContext is constructed, some sort of data retrieval or manipulation is done, and then the DataContext goes out of scope. This operation will most likely be done several, several times throughout common user flows.

However, constructing a DataContext object is a relatively expensive operation. 99.9% of this performance hit is spent building out the MappingSource object that gets used by your DataContext. Consider that, in a stock scenario, your application goes out and builds out the MappingSource object every single time that the DataContext object is created. Typically, this is something that will happen very frequently.

These calls can be significantly optimized by caching the expensive part of the operation, which is the construction of the MappingSource object. If we wrap our DataContext construction around a factory method, we have a nice, centralized point for making this happen.

Consider the following code example:

public static class MyDataContextFactory

{

private static MappingSource _myMappingSource;

public static MyDataContext Get()

{

MyDataContext ctx;

if (_myMappingSource == null)

{

ctx = new MyDataContext();

_myMappingSource = ctx.Mapping.MappingSource;

}

else

{

ctx = new MyDataContext(_myMappingSource);

}

return ctx;

}

This example caches the MappingSource object by storing it in a static variable. We have another source file containing a partial class of MyDataContext. This partial class adds a new constructor that takes in a MappingSource object.

This partial class is used to ensure that calling code doesn't have to worry about where the connection string comes from when passing a MappingSource into the constructor of a DataContext object. Our partial class now looks something like this:

public partial class MyDataContext
{
    public MyDataContext(MappingSource mappingSource)
        : this(Settings.Default.MyConnectionString, mappingSource)
    {
    }
}

Now, our DataContext construction is exceptionally cheap after the first call. All subsequent calls will gain the performance advantage of the cached MappingSource object. In some informal performance testing, we found this approach to be a significant reduction in the amount of time it takes to construct a DataContext.

LINQ to SQL: Performance and Security

2008-02-20T19:41:00Z

Like many people around the office, I've spent the last several weeks being completely enamored with LINQ. It started out innocently enough with a link to Joseph Albahari's LINQPad and it just took off from there. I'm pleased to say that it has pretty much replaced SQL Management Studio for my purposes. And as an added bonus, it serves as an awesome C# scratchpad. :)

I recall the "good ol' days" when people weren't entirely sure what LINQ had to offer; after all, we already had a decent query language that accomplished the same task! People were already quite proficient with SQL. Why would you need to learn a second query language? What was the point? There is absolutely no excuse to stay in this mindset; if you're not sure what LINQ has to offer, I strongly recommend downloading LINQPad. See it for yourself; there is a lot that LINQ has to offer.

It isn't so much the syntax of the language as much as it is the implementation of all the tools. The instant you connect to a database with LINQPad or generate your LINQ to SQL classes, you'll have a collection of intuitive and easy-to-interact with objects that have well-defined associations to other objects. For instance, an object with a 1:N relation to another table immediately has a collection of strongly-typed items from that other table. A 1:1 relation becomes a typed object; for example, an "AddedByUserId" column becomes an "AddedByUser" object, mapping out based on relationship on the User table. That related object has all of its associations set; suddenly, traversing from one corner of the database to the other becomes much easier.

By intuitively working with the generated LINQ to SQL classes, a lot of work gets done for you. Before I knew it, I had complex queries that were infinitely more maintainable than their SQL equivalents. And they took a fraction of the time to write. In fact, I was able to rewire some of our more complex middle tiers within hours to start taking advantage of LINQ-based queries.

However, despite the colossal benefits I've seen in such a short time, I've encountered a lot of resistance to LINQ. This resistance usually stems from these two reasons:

Myth 1: "LINQ is slow. Dynamically generating SQL queries is a costly maneuver; far moreso than just executing a stored procedure equivalent." This is one of the pitfalls of premature optimization; I've spoken with several people internally who immediately discounted LINQ, saying that it wasn't ready for production code. Not surprisingly, these were people who had no interest in doing their research and had a relationship with SQL that could be best described as unhealthy ;) Rico Mariani has a great 5 part blog post about performance in LINQ (summary here); in a worst case scenario, you're looking at roughly a 7% reduction in performance. Within our group, this is an acceptable tradeoff between performance and productivity.

Myth 2: "LINQ is insecure. Dynamically generating SQL queries means that my attack vector for SQL injection is much greater." This is another one of those healthy knee-jerk reactions; if I'm dynamically generating SQL, then it would make sense that my SQL injection vector is higher. If LINQ is dynamically generating SQL, then this should hold true. But it doesn't. Under the covers, LINQ is breaking down queries into parameterized SQL. Security was a huge concern that was revisited several times in LINQ's development; even through unusual vectors that couldn't be parameterized, LINQ remained a secure way to build out your SQL queries.

I highly recommend taking some time out of the day to learn LINQ; the return on investment is tremendous. Even for something as small as the adhoc queries you make day-to-day, you'll find yourself saving a great chunk of time.

WIX v3 and XmlConfig / XmlFile troubleshooting

2007-10-09T23:18:00Z

I've recently been tasked with implementing deployment automation for each component of a relatively large project. Armed with a colleague who had done similar work before, I dove into WiX with a great resource at hand :)

Let me preface this whole thing by saying that, despite the snags I've ran into, WiX is absolutely worth the effort. For as easy as WiX is to implement, it's criminal to *not* implement it in your project. Currently, the entire deployment process we have takes around 10-15% of the team's time. Dev and Test come up with a release plan, review with the program manager and release manager, refine, revise, rinse and repeat. Then, when the time to deploy actually comes, a hole in the document everyone signed off on becomes apparent. WiX helps solve that dilemma.

My goal was to add an entry to the machine.config file's appSettings node. I needed to output: <add key="MSCOM/Environment" value="[MyVariable]" />

I wasn't able to find a lot of great documentation on this, so I'm hoping to save someone else some time :) That said, let's move ahead to the XmlConfig/XmlFile issues I ran into:

XmlConfig, despite my best efforts, didn't seem to actually *do* anything. Taking known-good examples yielded absolutely no edits to my target file. The root cause? At the time of this post, the latest build of WiX available on the Sourceforge download page 3.0.2925; however, the actual latest build is 3.0.3405 (http://wix.sourceforge.net/releases/). In build 2925, XmlConfig seems totally broken, but in build 3405, it functions as expected.
Before realizing that a newer build was available, I resigned and tried to utilize an XmlFile to perform the same task. This proved difficult for a variety of reasons; XmlConfig lets you pass an ID to a new element, where XmlFile makes you do an XPath query each time. This results in a hacky solution where you create a temporary value, do queries based on that temporary value, and then null the value of the newly created node when done. Once this has been done, uninstalling doesn't remove the nodes. For manipulating Xml documents, XmlConfig is the way to go.
Once I updated builds and XmlConfig was "working", the XmlConfig node wasn't actually creating a new element. The second XmlConfig node that added an attribute couldn't find the XmlElement created previously. I had to scope down from all attributes to a specific set of attributes to get something to create.
Once I had my <add> node being written to the file, my attributes wouldn't get written. To successfully write attributes to a newly created node, I had to scope down my XmlConfig node to a few select attributes. Specifically, I believe having "Action" and "Node" values trips up the Util assembly.
Once I had my attributes writing to the correct node, my uninstall process wouldn't remove the node it added. I added an XmlConfig node with On="uninstall" that *seemed* right. However, the parameters you expect to pass to XmlConfig vary by operation; it takes using the same attributes differently to actually do something on an uninstall. Specifically, ElementPath points to the *parent* node of the node you want to delete, and the VerifyPath is an XPath query to the node you want to delete, relative to the ElementPath.
Documentation on XmlConfig is not good enough; the way you utilize parameters vary based on operation. The documentation doesn't make this apparent, leaving you to trial and error and a dozen searches that don't yield a solution.

The actual XML snippet I ended up using to get a successful uninstall/reinstall process was:

                <util:XmlConfig
                    Id="MachineConfigAdd"
                    File="[DOTNETCONFIGPATH]\machine.config"
                    Action="create"
                    ElementPath="//configuration/appSettings"
                    Name="add"
                    Node="element"
                    Sequence="1"
                    On="install" />

                <util:XmlConfig
                    Id="MachineConfigKey"
                    File="[DOTNETCONFIGPATH]\machine.config"
                    ElementPath="MachineConfigAdd"
                    Name="key"
                    Value="MSCOM/ConfigEnvironment"
                    Sequence="2" />

                <util:XmlConfig
                    Id="MachineConfigValue"
                    File="[DOTNETCONFIGPATH]\machine.config"
                    ElementPath="MachineConfigAdd"
                    Name="value"
                    Value="[ENVIRONMENT]"
                    Sequence="3" />

                <util:XmlConfig
                    Id="MachineConfigRemoveNode"
                    File="[DOTNETCONFIGPATH]\machine.config"
                    Action="delete"
                    Node="element"
                    VerifyPath="add[\[]@key='MSCOM/ConfigEnvironment'[\]]"
                    ElementPath="//configuration/appSettings"
                    On="uninstall"
                    Sequence="1" />

I can only hope that this saves someone, somewhere a headache :)

Hooray!

2007-01-18T03:07:00Z

Power was out for 9 days, from December 14th to December 23rd. Being stuck in freezing weather really helped take the edge off of Christmas :D Also, I'm pretty much useless without some sort of electronic gadget.

The MSHTML COM object I was having problems with before isn't so much a *problem*. What I was running into was something that was done by design, and with good reasons. However, in this scenario, it didn't make much sense.

I was writing a program to scrape relevant values off of a series of HTML pages. When you're using Passport (Windows Live ID) as an authentication mechanism, the login page always resides on login.live.com. The actual login page you visit is a page that hosts an iframeset. The contents you see outside of the login page are framed in from other sources/other domains.

This scenario has an iframeset originating from login.live.com with content in iframes originating from www.microsoft.com. I was interested in programmatically fetching the data from the content in those iframes. No problem! I wrote an application that used the .NET 2.0 WebBrowser object to navigate to the login page. I then went through the Window.Frames collection to get the underlying HTML documents. This is when I hit a System.UnauthorizedAccessException. What? Why should that happen?

My understanding is that JavaScript works by manipulating the MSHTML COM object, and that limiting access to the content in the iframes is a by-design XSS countermeasure to prevent one domain from accessing sensitive information in another domain. Which makes total sense in terms of client-side script. But in this scenario, there simply wasn't a "clean" way to pull all of the information that didn't originate from login.live.com.

My workaround? A somewhat convoluted system in which after the initial request, three other hidden web browser objects (one for each iframe) are utilized to directly make requests to the URL value of each iframe. On the DocumentCompleted event, I'm able to use the existing object model and scrape all of the relevant information. It's not ideal, but it works and I'm not recreating a ton of existing functionality.

Still no power...

2006-12-20T23:31:00Z

My area of Washington is still without power after last Thursday's windstorm. Power went out on Thursday night, and as of this posting, there's still no power. I'm feeling pretty useless without electronics :D

To do: Write a whiny post about the WebBrowser COM interface.

Good news, everyone! (Wii impressions)

2006-12-07T07:20:00Z

The 360 made it back, safe and sound, after three weeks of being out for repair. More correctly, a replacement unit made it back... And the unit that showed up is defective. It crashes frequently, the DVD drive is inoperable while the unit stands upright, and the DVD drive also makes terrible thunking sounds preceding hardware crashes. After a particularly scathing email to the support team, which I have no doubts will be met with an automated response, I feel a bit better. Alas, it looks like I'm still out of "The Game".

I took advantage of the crippling snowstorm a while back and called some nearby stores hoping to find a Wii in stock... Sure enough, they were in stock, but nobody could actually get to them on account of the snow. So off I went, facing the treacherous two to four inches of snow, all for a Wii! My grizzled Alaskan mountain man self was able to successfully navigate the snow... so by the time I arrived at the store, there were still plenty of Wii units on the shelf. The Factoria Target received roughly 50 units on the day I arrived, and the Redmond Target received somewhere in the range of 120. Accessories are almost more difficult to find at this point, but the good news is I made off with a Wii console while demand was still high :)

If you read my earlier post on the Wii AILive SDK demo, you can see that I had reservations going in on the Wii. My primary concerns were that the control set would be completely gimmicky, feeling tacked on in games that they had no right to, and being used in a way that doesn't add anything to the gameplay (mapping gestures to buttons). The good news is that Wii Sports puts these fears to rest! Motions with the controller map very well to what is happening in the game. Bowling has become one of my favorite past times; being able to hold the wiimote in one hand and a beer in the other makes it an excellent party system :) I feel confident that gamers and non-gamers alike will play Wii Sports and leave, pleased with the experience they just had.

The bad news is that, of the 20-something launch titles, most of them are multiplatform titles. Let me emphasize: Games that are not designed from the ground up for the Wii will not have control sets that make sense on the Wii. Wii Sports is an excellent use of the controller; golf swings, bat swings, throwing a bowling ball, and even boxing feel completely intuitive and can be picked up and played by anyone. However, Wii Sports is one of a sea of launch titles. Because it is a first party game, it is designed with the Wiimote control scheme and it completely makes sense. It feels intuitive to the non-gamer, and has the finesse to add lasting appeal. Other games? Not so much.

Even Zelda: Twilight Princess has the tacked on control set feeling, and I'd be much happier with the game if I could play from the couch using a wireless gamepad. Flailing the nunchuk madly, trying to execute the "Special Move" that could just as easily be done by pressing the X button on the Gamecube "port" is not an ideal experience. Nunchuk flailing was added for the sake of utilizing an accelerometer, not because it made sense in the context of gameplay.

This creates an interesting dilemma. The Wii has a reasonable launch library, far better than the 360 at launch. However, if given the choice between a game available on multiple platforms, I would never make the purchase for the Wii if the same option were available for the 360. Unless the game is designed from the ground up for use on the Wii, it will be guaranteed to not "feel right" when played on the Wii. Additionally, opportunities for network play become extremely limited, visuals get kicked down several notches, etc.

The Wii and the 360 don't come close to occupying the same space. I believe the Wii will be the party game system with a handful of excellent first party titles. The library today is large, but first-party games that are designed to use the Wiimote will become the only "worthy" purchases. The number of worthy purchases will be a miniscule fraction of the total number of games available. The 360 still offers a different and unique experience, with big budget flashy titles and the best online implementation of The Three.

If you have a say in the matter, go Wii60 :)

Setting up a Windows Vista + XP Dual Boot

2006-11-28T09:45:00Z

With my 360 out for repairs for the Thanksgiving weekend, I was looking for other ways to entertain myself during the long weekend. I've been running Vista as my primary OS since RC1 and swore I'd stick with it, but inevitably, I don't think Vista is something that can completely replace XP for gamers today.

This weekend, I decided I'd try to play Knights of the Old Republic 2 on the PC. I went to the options screen to turn the pretty effects up, but clicking on the "Advanced Options" button yielded a crash to desktop. Okay, no problem! I just won't go to the options. That's fine. I'll just play, and all will be well. But hey, what's with these framerates? In an engine that looks roughly equivalent to Quake 2, I was lucky to get ~20FPS on an AMD64 4800+ X2 on a 7900GTX 512MB machine with 2 gigs of RAM as soon as transparent particles came into the picture. And what's this? Another crash to desktop, just going from level to level? The crashes eventually made the game unplayable, so moving right along...

Well, maybe I'll try playing Dark Messiah of Might and Magic. Which worked to some extent (after disabling a CPU core to bypass some driver issues!), but with intermittent and random crashes to the desktop. Keep in mind, these have been filed as bugs, but didn't make it into the business RTM. The second level was basically a death knell; if it didn't crash to the desktop upon loading, it would crash before the end of the level or run at 2FPS until I terminated the process.

At this point, who's to blame? I'd wager 99.9% of the problems I'm running into at this point are all driver related. The actual operating system itself is sturdy, and it's a pleasure to work on. However, I don't believe it's ready for widespread adoption among gamers until the release in January. Support for games today is somewhat reasonable; there were more titles that worked for me than titles that didn't. And to be fair, the games above have had extremely problematic releases and support. However, I noticed that: 1) The new Vista video drivers are in their infancy. Running games in Vista will incur a large performance hit. 2) Not all games will run right out of the box. I bought Dark Messiah over a month ago and wasn't able to play it until setting up a Vista/XP dual boot. What if this had been Portal that didn't work? I, as well as nerds everywhere, would be crushed :)

At the time I came to this realization, I still had a long weekend ahead of me... I thought, hey! Let's just install XP. We'll set up a dual boot and be done with this nonsense! I did some cursory Live searches to see what others had discovered, and it sounded like a snap. So in goes the Windows XP CD.. I boot up, install on the same drive under the WINXP folder, setup restarts... and the machine won't start. The bootloader got totally hosed by the Windows XP install process, rendering the machine inoperable until running a Vista startup repair. At this point, the Windows XP install was incomplete, so I couldn't really do anything but do a clean format or stick with Vista.

So I decide that my previous approach of trying to set up XP from Vista might be a bit backwards. I tackle the problem with newfound resolve and format my C drive, installing XP as a base to install Windows Vista in a dual boot fashion. Some time goes by, I install Windows XP, boot up the Vista DVD, and start the install process.. But wait! I can't install Vista side by side with Windows XP? The "Custom" installation is allowing me to pick a partition, and it even nicely offers to move my old OS to Windows.old, but I don't see an option to have the two living side-by-side in perfect harmony.

At that point, I had to reformat my drive again and create two different partitions from the Vista installer. I then installed Windows XP on the C partition, and after a successful install, I started up the installer for Windows Vista. I picked the new partition, and lo! Everything worked just as I had wanted it to. The final tally was around 6 hours, 3 installs of Windows XP and two unplanned reformats.

Unfortunately, as I use my home machine for gaming more than anything else, I'm finding that the increased performance and broader support in Windows XP is hard to leave. Even with a dual boot setup, I've spent more time in Windows XP than in Vista. At this stage, I couldn't see a gamer running Vista exclusively. I'm sure that will change as we get closer to the "For Everybody" release, but that doesn't do much good for the early adopters. :)

In other news, the Xbox box showed up on Wednesday. It was picked up by UPS today, right before everything got snowed in. That puts me at 8 business days before receiving a new console. Hooray! I'm about a thousand points behind first place in the building 6 leaderboards. King K-0wn'g..ed? I guess? :D