The Scribbler

In this last installment, I’ll describe TicketDesk’s custom database initializers, which allow TicketDesk 3 to automatically choose which migration should run on startup. I’ll also confess to a major development blunder!

In my last post, I talked about creating the initial migration for new TicketDesk databases. I used the MigrateDatabaseToLatestVersion<T> initializer in global.asax.cs. This initializer works well for normal EF migration usage patterns, but TicketDesk needs initializers with a bit more spunk.

EF also ships with a feature called “automatic migrations”. I will NOT be talking about this feature here. Automatic migrations are, in my opinion, an abortion-in-progress for anything but the most trivial of applications. I advise you to read up on this feature, and then do your best to avoid it. What I will be talking about here is automatically executing a “code-based migration”.

Great primer on Automatic migrations here, and for Code-base migrations here.

Initializers:

A common technique for customizing database initialization is to write a custom initializer that inherits one of the standard initializers. Sadly, the MigrateDatabaseToLatestVersion initializer is ill-suited for inheritance. There are no overridable methods or extension points to plug into. Instead, I’ll roll my own initializers, implementing IDatabaseInitializer<T>, and take direct control over the migrations process. Fortunately, the EF APIs makes this pretty simple.

Initially, I built one big do-it-all initializer, but later switched to separate initializers that operate independently — in keeping with the SRP.

On Application_Start, TicketDesk will run both initializers. Here is how the process should go:

1) Legacy Initializer Runs
    1a) Check if there is a database
    1b) If a database exists, check the version number (stored in the dbo.settings table)
    1c) If version 2.0.2, run the legacy initial migration (else, do nothing)
2) Regular Initializer Runs
    2a) Run all standard migrations

While the initializers don’t need a mediator, or other coordinating object, the order in which they are invoked is relevant to achieve the desired behavior.

The trick to step 2 is that, if the DB was upgraded in step 1c, then the regular migration will think its own initial migration has already run (remember, both use the same ID and hash value). The regular initializer will still run all additional migrations added later, even if the legacy initializer did the initial migration.

The initializers themselves are rather simple. They instantiate EF’s DbMigrator, which is the code equivalent to using the Package Manager Console’s Update-Database command.

The regular initializer:

public class TicketDeskDatabaseInitializer : IDatabaseInitializer<TicketDeskContext>
{
    private string ConnectionName { get; set; }
    public TicketDeskDatabaseInitializer(string connectionName)
    {
        ConnectionName = connectionName;
    }

    public void InitializeDatabase(TicketDeskContext context)
    {
        var config = new Configuration();
        config.TargetDatabase = new DbConnectionInfo(ConnectionName);
        var migrator = new DbMigrator(config);
        migrator.Update(); //run all migrations 
    }
}

The legacy initializer:

public class LegacyDatabaseInitializer : IDatabaseInitializer<TicketDeskLegacyContext>
{

    private string ConnectionName { get; set; }

    public LegacyDatabaseInitializer(string connectionName)
    {
        ConnectionName = connectionName;
    }

    public void InitializeDatabase(TicketDeskLegacyContext context)
    {
        //if existsing TD 2.x database, run upgrade; creates migration history table 
        if (context.Database.Exists() && IsLegacyDatabase(context))
        {
            var upgradeConfig = new Configuration();
            upgradeConfig.TargetDatabase = new DbConnectionInfo(ConnectionName);

            //this will do nothing but add the migration history table 
            //  with the same migration ID as the standard migrator.
            var migrator = new DbMigrator(upgradeConfig);
            migrator.Update("Initial"); //run just the initial migration
        }
    }

    public static bool IsLegacyDatabase(TicketDeskLegacyContext context)
    {
        // TicketDeskLegacyContext has no DbSets, directly execute select query
        var oldVersion = context.Database.SqlQuery<string>(
                  "select SettingValue from Settings where SettingName = 'Version'");
        return 
        (
            oldVersion != null && 
            oldVersion.Count() > 0 && 
            oldVersion.First().Equals("2.0.2")
        );
    }
}

The Accidental Integration Test:

You will note that the constructor for both initializers requires an explicit connection name, which is used to set the target database for the migrator. This is the result of another oversight in how EF migrations were implemented internally –I consider it an oversight anyway.

The initialize method takes an instantiated DbContext as a parameter, but there is no way to pass that context to a DbMigrator. Instead, DbMigrator always creates a new instance of the DbContext, and it always uses the DbContext’s default constructor. So, in cases where you want to use non-default connections, you must explicitly pass that information into the DbMigrator, otherwise it will use whatever connection your DbContext’s default constructor uses.

I discovered this issue when trying unit test the legacy initializer. My unit test used a custom connection string when it instantiated the DbContext (pointing to a localdb file database in the unit test project). I would run the test, but the DB in the test project refused to change.

Eventually, I discovered that the migrator was making a new DbContext from the default constructor, which in this case was hard-coded to a default connection named “TicketDesk”. This connection string was present in my app.config file, but I had, unwisely, left it pointed at my production database server…  the real TicketDesk 2 database that my company’s IT staff uses!

Yikes!

The test was, indeed, migrating the crap out of my production database!

As a testament to the migrator’s effectiveness, and the similarity between the TD3 and TD2 schemas, TicketDesk 2 didn’t skip a beat. The users never knew their DB had been upgraded, and everything kept working. Later, I manually un-migrated the production database using the PM console commands, which also worked without a hitch.

Lesson learned! Again…

Planting Seeds

Another interesting facet to the design of EF Migrations is how it handles seed data. For migrations, seeding is done through an override method in the migration configuration class. The odd thing about this seed method is that it runs every time migrations are run, even if there are no pending migrations to apply to the database. In TicketDesk’s case, both seed methods will run (from legacy and regular configuration classes).

In my opinion, there are two kinds of “seed” data –there is “default data” which is data that should be pre-set when the DB is created, then there is “test data”, which is used for testing or just pre-loading some example data. EF uses “seed data” in the sense of “test data”.

As a practical example of the difference, TicketDesk has a bunch of default settings that are stored in its settings table. These values are required, or the application fails, but admins can change the default settings later if they choose. This is not, in the sense EF uses the term, “seed data”. It is “default data”, for which EF has no explicit support.

For default data, the best solution seems to be inserting the data during the migration itself –by adding insert operations to the migration class’s up and down methods. Unfortunately, there aren’t any convenient helper methods for doing inserts, so you have to issue raw SQL insert commands as strings.

For “test data”, you can rely on the seed method in configuration, as long as you are comfortable with your data being reset every time the application starts. At least you can use Linq helper methods and your strong-typed entities there.

At this point, I have working database initialization and full migrations support in TicketDesk 3, at least for the core model entities. Security, and security database support, may prove more challenging.

Ten years ago, I was about a year into my first full-time programming gig. Prior to that, I’d just been a hobbyist developer. I had a reasonable understanding of C#, VB 6, VBScript, JScript.NET, ASP 3.0, and even dabbled a little in PHP. I was also pretty wiz-bang with Perl 5 regular expressions, though not so much Perl itself. I spent most of my spare time on the new .Net framework, but my skills were strongest with JavaScript.

My JavaScript background landed me my first full-time programming job, where I wrote complex drag-n-drop form designers, fancy-pants grid controls, and lots of out-of-band XML stuff (later known as AJAX). Basically, I wrote the kinds of stuff you’d just buy from a 3rd party component vendor now days. The application itself was a colossal enterprise EAM product, and the server side was all Java… lots and lots of all Java.

Given that my paycheck came from a Java shop, learning Java would have probably been the smart move. But the more I looked at it, the less enthusiasm I could muster. I had no problem with the language itself. Java and C# were comparable at the time, and I was comfortable with static typing, case sensitivity, and the C-style syntax in general. But, a variety of issues kept putting me off Java.

• My interest was web development, but JSP was slow, clunky, and annoying.
• The run-anywhere promise had a certain appeal, but the price of portability was poor performance and lowest common denominator functionality  With web apps, you wound up coupled a particular application server anyway, so portability was a low value proposition.
• I disliked how SUN conducted business. They’d refused to turn the language over to an independent standards body, and were quick to file lawsuits. Their licensing and prices had grown increasingly draconian as well.
• I wasn’t impressed with the direction many Java libraries were taking, and enterprise JavaBeans was a total mess.
• The tooling was terrible too. I prefer IDEs to command line compilers and plain text editors. Eclipse was the best Java IDE around, but it was not fun. On my high-end workstation, it often took five minutes to launch; and once open it was still slow, buggy, and feature poor.

In the end, I decided to skip making a deeper dive into Java. I rode out my JavaScript job for another year, and then jumped into a full-time ASP.NET position as soon I could. I have never regretted that decision.

Ten years later, I’m going back to college to grab that long overdue CS degree. Naturally, my curriculum centers around Java. I still have no love for the language, but I am looking forward to learning my way around it more… it never hurts to branch out.

The last ten years have radically changed C#. A C# developer from 2003 would probably not recognize most code written today. So, when I took another look at Java, I’d expected to see a similar progression. I was wrong.

Using Java today feels eerily like being back in 2003  – cranking out blocky-ass code, casting everything six ways from Sunday, and with precious little of the expressiveness and elegant fluidity I’ve grown accustomed to. The only surprising thing about Java is how stubbornly it has resisted change.

Java’s  most significant advance was the addition of generics. After digging deeper though, I find Java’s generics a bit half-baked. They don’t support primitive types, which is super annoying. You can use the reference wrappers, and rely on auto-boxing/unboxing, but it feels clumsy. The syntax for generics is also a bit odd in places. The wildcards are especially interesting, but I’m reserving judgment for now. While confusing, wildcards seem like a good way to handle covariance and contravariance. C# also struggled with those, and its solution wasn’t very intuitive either.

When generics were first introduced in .Net, it gained a significant performance boost across the entire framework. However, Java implemented generics purely as a compiler trick using type erasure, which is an… er… interesting choice. This means Java can’t really optimize around generics like .Net can.

Additionally, Java’s implementation prevents runtime reflectivity over generic types. In C#, I have used generic reflection heavily in a few cases, and was able to produce elegant solutions to some really thorny problems. I’m not even sure how to approach those kinds of problems in Java without generic reflectivity.

Java did pick up some smaller improvements over the years, but they don’t seem to add up to very much:

• Foreach loop. A simple feature, and a solid win.
• Annotations. Weak-sauce compared to C# attributes, but just as essential for tooling, code generation, and reflection.
• Automatic boxing/unboxing. Especially useful given that generics don’t support primitives, and Java has no type lifting (nullable value types to us C# guys). At least auto-boxing/unboxing cuts down the casting cruft. The implementation on the unboxing side gives me the heebeegeebees, but I’ve had no trouble from it in actual practice.
• Enumerations. One of the few things Java does, arguably, better than C#. Java enums are full reference types, and can implement methods and such. Nice!
• Varargs (params to us C# folks). A minor improvement, but a handy simplification to a common code pattern.
• Static imports. Yeah, sure… ok. I don’t often use aliases in C# either.
• Strings in switch statement. How was that not there all along? More to the point, why does Java’s switch statement still allow fall-through? Why doesn’t it work with all types? Overall, the switch statement in Java still seems horribly broken, but at least it works with strings now… so that’s progress I guess.
• Automatic resource management via the Try statement. The same as a “using” statement in C#. A useful little feature to have around.
• Binary integer literals. Anyone who uses binary constants probably loves this, so I imagine there are at least two happy developers out there somewhere.
• Underscores in numeric literals. Sure, why not!
• Type inference. Limited to generic types. A more comprehensive type inference mechanism would have been nice, but some is better than none. Complex usages of generics can produce some gnarly expressions, so if you were going to half-ass tackle type inference, generics would be the place to start.

Java is seriously conservative in adopting changes. There are good things to say about stability and predictability, but there are a few other things from C# that I REALLY miss when working in Java.

First-class Properties:

This drives me insane, and there is no excuse for Java not having added native property syntax by now. Properties are easier on the developer, and they make the intent behind your code much more apparent. Java’s convention driven naming pattern of manually written getter/setter methods is a piss-poor substitute.

Extension Methods:

I didn’t really appreciate these when they first appeared in C#, but after getting used to them I find them indispensable for framework development. Extension methods let me quickly add functionality to existing types, even 3rd party components, without any need to modify the original source, write wrapper classes, or create some intermediate abstraction layer.

Lambdas/Closures:

I completely get why these aren’t in Java yet, but at the same time their usefulness is also unavoidably obvious. The sheer number of amazing capabilities C# picked up after adding lambdas is staggering. This feature is slated for the next release of Java, and I sincerely hope they don’t kick the can down the road any further.

Most of the arguments within the java community over this feature are plain silly, and those arguing against lambdas are just plain idiots. I respect Java’s inner and anonymous class implementations. They are slick, and come close to providing full featured closures already. Enhance what’s already there, and full closure support might be a done deal… but if that’s all that’s done, it would fall far short of the full potential. Lambdas are not just about the functionality; the real benefit is providing an elegant and expressive syntax for using the functionality.

I dearly miss lambdas when working in Java, and I’m 100% sure that Java developers will love this feature as much as C# developers do. I just hope the final implementation isn’t as half-baked as generics were.

Ten years ago C# was just a shiny new clone of Java. Since then though, C# has grown and changed rapidly. It has picked up many of the most useful features of functional and dynamic programming, and balanced them successfully against its own static-typed roots.

Java’s lack of progress should  make learning my way around it a lot easier. I’ll have to acclimate to the “Java way” of course. Tackling the design patterns and core libraries of any language takes time and patience, but at least the language itself is simple, predictable, and familiar. I just wish java felt more… alive.

After having used C#, Ruby, and modern JavaScript for so many years, Java just seems old and stagnant. Hopefully, a bit more time working with it will improve my opinion.

Windows 8 Release Preview dropped to the public last week. This release gives us a concrete look at the final form of the new OS. Between now and final release, there will only be a few bug fixes and tweaks.

Before I begin, I want to qualify that I’ve been using Windows 8 as my primary OS since February. I am not running this in a VM, and I spend 60+ hours a week using this system. I run everything on this machine; development tools, database servers, web servers, admin tools, utilities,  games,  videos, music, social networking, etc. My opinions are my own, but they are based on months of extensive use.

What I learned from the release preview is that Microsoft’s Windows 8 team is convinced that all the negative reaction to Windows 8 is simply change resistance. They appear convinced that once people get used to the new user interface, everyone will love it. For traditional laptop and destop users, I completely disagree, but the ship has sailed. What we see now is what we’re going to get.

I’ve already written at length about Windows 8 on a tablet, and the release preview doesn’t change any of my expectations there. So, here, I’ll concentrate on Windows 8 for x86 based desktops, laptops, and hybrid devices.

The metro UI is still horrible with a mouse and keyboard, and metro apps even more so. There have been minor improvements since the beta versions, but the fundamental nature of metro is still a highly touch-first design, and that isn’t going to change. The horizontal scrolling in metro is obnoxious, and even after months of use I still hate it. If you are using large screen monitors, or a multi-monitor systems, the full-screen windowless nature of metro apps is outright silly and wasteful. The inability to run multiple metro apps on multiple monitors is insulting  for a multi-tasking OS.

The stock Metro apps have been improved to show off what metro apps can do. Of course, that also shows off how limited these apps are compared to their traditional desktop cousins. Metro apps waste space like crazy, and common commands are still hidden away most of the time. Getting to the swipe out command bars always seems to take twice as many clicks as it should. I’m always wishing for a way to tell the apps to just leave the command bar open so I don’t have work so hard to get at them. I also hate the absence of a system-wide task or  status bar in metro. I’d like to see what’s going on with my other apps, see a clock, and most importantly status indicators that show my remaining battery time and network connection statuses.

And of course, metro apps are still sandboxed to hell and back, and are still unable to cooperate with desktop apps. Your metro apps don’t show on the desktop taskbar, which is REALLY annoying. The hot-corner switch list will show all the running metro apps, but not your individual desktop apps; it only gives you one item for the entire desktop and all apps running there. Switching between metro app and desktop app is still disorienting and jarring, though the transition is better animated in the release preview.

The only thing positive I can say about metro apps is that they can be quite pretty. Not pretty in any useful way, but visually appealing in a shallow and vain way.

The good news is that, other than the start screen, you can mostly just ignore metro apps and the entire metro UI. I have not seen anything that a metro app does that traditional desktop apps can’t do just as well or better, so ignoring metro is quite easy. The desktop, and the desktop applications, work just fine and work way they always have in the past.

In my opinion, Microsoft  had finally gotten the start menu right in Windows 7, but the new metro start screen is a sad regression that you are stuck with unless you obtain a hack that puts the start menu back (I have not done this, forcing myself to get used to the start screen instead). You can get used to the start screen and be productive with it. It has all the features necessary to do the job. I suspect that some users might come to like it more than the start menu, since it is actually bit easier for non-professional users to manage and organize. Of course, most desktop applications written before windows 8 dump a truck-load of useless and ugly icons all over the start screen, so you have an incentive to learn how to organize and customize it.

As for running traditional desktop applications, Windows 8 is quite nice. It is a good bit faster than windows 7, and there are a few minor touches that qualify as improvements here and there. The traditional file explorer has a ribbon interface that makes setting viewing options a bit easier. The control panel is still a total fucking usability disaster, but some of the utilities in the control panel have been slightly improved.

One thing striking about the the release preview is in how well it renders on screen. I’m using the same video card and driver that I was using in the last beta, but something about the release preview made even traditional desktop apps much prettier than they’ve ever appeared. It’s a subtle, but very distinct improvement.

I am still annoyed by the new, and over-hyped, File History feature. File history is obviously inspired by Apple’s time machine for real-time continuous backup and file versioning. File history also works well with the new system reset feature that can put your OS back to stock without requiring a format and re-install. Obviously, Microsoft is pushing this feature as a replacement for traditional disk and image backups, and it is a fine feature I suppose. But they’ve done their best to hide the full windows image backup tools. If you can find it in the control panel, it’s called Windows 7 File Recovery. But if want a full system backup that lets you restore your whole system after a complete disk crash, then this is still the better tool by far.

Hyper-V is another nice feature, and it finally lets you run 64bit virtual OSes. I’m glad to see Hyper-V on Windows 8, but this is pretty much the entire Hyper-V service you see on Windows Server. That means it has all the power you could want, but it also means that it is nearly impossible for anyone that isn’t an IT professional to use. I was hoping to see a more friendly front-end admin tool for it, something similar to Virtual PC/XP Mode on Windows 7 but with the full power of Hyper-V behind it. Setting up virtual networks and drives via the full server admin tools is not trivial, especially on a laptop that sometimes uses WiFi, sometimes is docked to a hard-line, and other times uses a built-in mobile broadband card. Fortunately, VMs are a feature that few non-professionals really need, so I don’t think this will hurt sales or customer approval in any way.

Overall, I don’t predict success for Windows 8 on traditional laptops and desktops, especially not in the enterprise. Metro running side-by-side with the desktop will be confusing for the average home consumer. For businesses, it will a training and support nightmare that most shops will simply avoid.

A lot of people are talking up touch-screen monitors for desktop and laptops, but I am not sure that’ll fly either. Holding your hands out like a zombie to use a touch screen is physically exhausting, ergonomically unhealthy, and very inconvenient. I personally have no interesting in smearing up my screen with my grubby paws, and cleaning a laptop or desktop screen is much more inconvenient than rubbing a tablet across your shirt every now and again. And all that’s ignoring the fact that touch screens much more expensive, and wont be widely available on most end-user PCs for while yet.

The only possible bright spot I really see for Windows 8 is in hybrid, or so-called convergence, devices. There are already a lot of very interesting devices with new and experimental designs being shown off. It will be neat to see how the hybrid device market shakes out over the next year or two. The real issue will be finding an actual customer demand for hybrid devices. I suspect that there may be some opportunities for a successful hybrid devices, but only time will tell. The sad part is, if this market doesn’t materialize, then I don’t see Windows 8 amounting to anything less than a complete disaster.

I predict that Windows 8′ will be a huge sales boost for Apple’s MacBook line, but no help to Microsoft’s own market share. I further predict that Steve Ballmer will be forced out as CEO next year. I will personally continue using Windows 8, while ignoring the annoying metro end of things. For experimentation, I will likely buy a hybrid windows 8 device of some sort in the near future.

At this time I could not recommend Windows 8 to any of my non-professional friends and associates.

I’m not a big fan of Windows 8, but I’m not going to waste time on what I do and don’t like about it as a desktop OS; that ground has been covered to death elsewhere on the net.

What I do want to talk about are my many doubts about its future as a tablet operating system… I don’t see this schizophrenic bastardization doing well, even on pure tablet devices.

What Window 8 is up against:

Microsoft got caught off-guard by the explosion in mobile and tablet devices, which is a fine testament to the poor state of their management. Tablets are a critical market that will decimate the established consumer PC space during the next several years. Microsoft knows this, even if they appear clueless as to how to proceed with that knowledge.

Most people don’t need a full-featured, general-purpose computer at home. They just need something that can show movies, browse the web, play music, check messages, display books, and play games. They’ll gladly give up the complexity of today’s general purpose PCs and laptops in favor of highly portable, user friendly, and easy to manage tablets. The consumer power-user of the future is just someone with a dock and keyboard for their tablet.

Microsoft is also, probably, smart enough to recognize that a large chunk of the business market will turn to tablets. Most corporate users are information consumers, not content and data producers. Tablets are a better fit for those users for most of the same reasons –they are cheaper, more portable, and orders of magnitude easier to support and maintain.

So Windows 8 is aimed at giving Microsoft a competitive tablet before the PC market collapses on itself.

The tablet market today:

Apple and Google have had years to establish and define the tablet. Both companies have decided on, fundamentally, the same approach. They up-ported phone OSes that run sand-boxed apps purchased from centralized app stores. Those apps are full-screen affairs with a heavily touch-centric UI. Alternate inputs (stylus, keyboard, mouse, etc.) are marked off as unimportant and poorly supported legacy options.

More importantly, Apple and Google have grown large and rapidly maturing software ecosystems for their tablets. They have also established a positive mind-share among the general public. Apple in particular has a substantially mature product with a vast array of capable apps. Android is struggling a bit still, but is coming along at a breath-taking pace, with major new releases appearing every few months.

Windows 8 on ARM:

On ARM devices, Windows 8 will be running hardware that is fairly comparable to that used by Apple and Google tablets. While less powerful than traditional PCs, ARM hardware promises to run cooler, have longer battery life, and be powerful enough to smoothly run a single full-screen foreground app with a few background tasks.

The key thing about ARM hardware is that these are the devices cell phone carriers will be selling. Make no mistake; those carriers are the single most important factor for competing in the tablet market.

Carriers provide ubiquitous connectivity. WiFi may be good enough for the take-it-out, set-it-up, and use-it-hard laptop world, but it falls short with use-it-anywhere tablets. Having constant connectivity is a necessity for the rapid user adoption of tablets.

Carriers also heavily discount the up-front costs of the hardware in exchange for lucrative multi-year data contracts. This makes purchasing a tablet much more appealing for most users, and it will be the deciding factor that drives many people’s decision to give tablets a try.

Microsoft doesn’t have a particularly good relationship with cell carriers these days. Based on what we’ve seen from Windows Phone 7, Verizon doesn’t even return Microsoft’s calls. AT&T will sell just about anything, but they haven’t really been promoting Microsoft’s products. And, sadly, Sprint and T-Mobile just aren’t big enough to put a dent in the overall tablet market.

As for Windows 8 itself, on ARM it is limited to running only metro apps. The metro UI is actually quite good, especially for a version 1 OS. The WinRT platform that powers metro apps is fantastic, and the developer tools are light-years ahead of the competition. And, naturally, the core Windows kernel is still an impressive feat of engineering, especially after the internal refactoring that’s been done over the last 10 years or so (yes, I hear the Linux guys grinding their axes).

Metro is, in my opinion, where the heart of Windows 8′s pending tablet failure resides.

Metro is, fundamentally, the same approach to tablets that everyone else has taken. Sandboxed full-screen apps, obtained from a centralized app store, with a heavily touch biased UI. ARM devices can’t run traditional PC apps and has no traditional desktop. Basically, apps on Windows 8 ARM devices behave just like apps on every other tablet.

Since you can’t run any of your old Windows PC software on ARM hardware, you’ll have to buy all new apps and learn how to use them. You can’t even re-use your existing Windows skills, since Metro is completely new and quite different from the traditional Windows experience of the past. A Windows 8 tablet will be just as unfamiliar to Windows users as an iPad or Android tablet.

Add to that the fact that Microsoft has a horrible public image. Lots of people love Google and Apple, but public approval of Microsoft rivals only that of the U.S. congress; and even there it’s a neck and neck race to the bottom.

To sum it up… Windows 8 on ARM will be a new and untested OS that is completely alien in how it works. It is made by a company you haven’t enjoyed doing business with in the past. It will be running on a new and untried hardware platform. It will have a small number of quality apps, and you’ll have to buy your software all over again. You’ll have to learn how to use the new apps from scratch. You’ll have to buy them from a tightly controlled app market that you’ve never done business with before. And your cell provider is probably going to do their damnedest to talk you into getting an iPad instead.

Does that sound like a recipe for success to you?

Windows 8 on x86:

Windows on x86 tablet hardware is quite different from the ARM devices. It is on x86 where the schizophrenic nature of the operating system is most apparent.

Hardware for x86 tablets is, generally, the same stuff used in laptops today. The x86 hardware will tend to run hotter, be a bit bulkier, and have much less battery life. On the plus side, x86 hardware is much more powerful, especially for running multiple desktop applications, or for heavily multi-threaded apps.

To achieve even modest battery life in the small form-factor of a tablet, most x86 tablets will have to stick with low-end components compared to traditional laptops. Metro apps will do fine, even on this lower-end hardware, but traditional desktop applications that were smooth and fast on your old laptop, will be sluggish on a tablet.

Other than expensive developer machines, I don’t expect to see a lot of high-end x86 tablets, the hardware costs too much, takes up too much space, run too hot, and requires more battery than a reasonably sized tablet has room for.

A major problem with x86 tablets is that cell carriers are not interested in selling them. They have to support the devices they choose to sell, and since these are still full-featured, general-purpose OSes, they still have all the same problems that have plagued PCs in the past; viruses, conflicting and buggy software, bum drivers, security vulnerabilities, etc. Cell carriers learned their lesson during the brief days of netbook computers, and I don’t see them lining up for another customer support ass-kicking.

The primary sales channels for x86 tablets will be the same as for traditional laptop PCs. Without cell carriers to discount the hardware costs, these will have higher up-front costs.

Getting mobile broadband working on these tablets will be just as complicated, expensive, and confusing as it is for laptop users today. You will either have to select a tablet that has the right built-in broadband card for your preferred carrier, or you’ll have to go down to the phone shop and buy a mobile hotspot. Either option adds significant up-front costs, requires specialized knowledge to setup, and still locks you into an expensive 2 year data contract (with no hardware discount to show for it).

As for Windows 8 itself, on x86 it can run both traditional desktop software, as well as the new touch friendly metro apps. While this may seem like a selling point, it presents a whole mess of new problems. Windows 8 doesn’t do much to make traditional applications touch-friendly. The on-screen keyboard also doesn’t go very far. Hopefully most of these tablets will support a stylus, which will make a decent mouse substitute for desktop applications, but the OS doesn’t  do near enough to make the stylus a compelling alternative. You can always use an external mouse and keyboard, but at the cost of the portability that makes tablets appealing in the first place.

Metro apps work fine on x86 tablets, so most of what was said about them in the Windows 8 on ARM section applies here. But metro apps have a totally different look and feel. Switching from desktop applications to metro apps is a jarring and uncomfortable experience. Furthermore, metro apps can’t interact with to their non-metro counterparts in any meaningful way, which leads to near endless user frustration. The whole experience around mixed metro and traditional applications on the same device is disorienting and counter-intuitive, and that’s the polite description.

To sum it up, Windows 8 on x86 tablets will give you an over-powered tablet for metro apps, but under-powered for desktop apps. They’ll be more expensive, bulkier, and have crap for battery life. It will be made by a company you haven’t enjoyed doing business with in the past. It will run desktop software and metro style apps at the same time, but the dual nature of the interface will probably drive you insane. Desktop applications will be difficult to use on a touch-screen, and metro apps are plain obnoxious when using a mouse and keyboard. You’ll have to buy metro apps from a tightly controlled app market that you’ve never done business with before. You will have to buy the tablets from traditional PC distributors at full price, and getting them online with mobile broadband will be difficult and significantly more expensive.

Where’s my cheese grater?

What Windows 8 could have been:

The depressing thing about Windows 8 is that it could have been great, had Microsoft just taken a different approach.

What I, and many others, really wanted from Windows 8 was an OS that brought real general purpose computing to tablets. We wanted a tablet that let us get real work done with real “applications”, not another device that just runs little finger-paint apps…

What we wanted was a tablet built for adults.

Even more depressing is the fact that Microsoft was well on their way to producing that kind of tablet on two separate occasions during the last 10 years.

First was the old Tablet PC OS, a variant of Windows XP. It was a good start that failed mostly due to internal apathy and politics within Microsoft itself; though some blame falls to the hardware, which wasn’t quite up to the job of making cost-effective tablets 10 years ago.

Later there was the courier project, a dual screen book-like tablet with a completely fresh and unique approach to the UI. It would have combined touch, stylus, and on-screen keyboard with a task-driven, workflow oriented application design. Courier had massive support and interest from the public before Microsoft killed it in early 2010.

The key thing about Microsoft’s past attempts was that they did NOT concentrate exclusively on finger-based input. Instead, a stylus was used for detailed work, while fingers were used when accuracy wasn’t an issue. Handwriting recognition via the stylus competed with an on-screen keyboard for data entry. And of course, external keyboard and mouse was a fully supported option.

Had windows 8 continued in this tradition, instead of just copying what Apple and Google were doing, it could have brought touch, stylus, keyboard, and mouse together with full-featured desktop applications. And it could have done so by extending a familiar Windows user interface, rather than chucking out 25+ years of graphical user interface evolution.

Microsoft could still have introduced WinRT, and the other technologies that are aimed at creating touch-first apps, yet let those apps run side-by-side, comfortably, and cooperatively on the same desktop with traditional applications. They could have still had an app market, without needing to force it on everyone. And they could have still forked a version of the OS to port over to ARM hardware without needing to support the older desktop software.

I mourn the OS that could have been, and I suspect that after Windows 8 falls on its face, Microsoft may never again be in a position to produce a compelling tablet OS.