After several posts discussing what Windows 8 is in a more general sense, this one is going to try to focus on what it means to ComputerTalk specifically. This means that if you’re not a customer, potential customer, or admirer of ComputerTalk and our products, this might only be interesting from the point of view of a case study: here’s how one person is looking at applying what he learned at build to a product suite.

For the current products that ComputerTalk offers, anything we support on Windows 7 will be supported on Windows 8 in at least its current form, just like we did when Windows 7 released. We’re already working with Microsoft to make sure that both our web and windows clients are compatible with their changes, and so far we’ve already helped them identify some bugs in the current Windows 8 build. The goal is to be Windows 8 compatible at RTM, at least when running our software in desktop mode.

Now that the build conference is situated firmly in the past, there are things that we now know, things that we know we don’t know, and things that we don’t know we don’t know. For example, we don’t know the release date of the OS. In the keynote, they committed to a beta and a release candidate, but no hints on timing for either. We can, however, guess when it might be based on what we already know. After spending some time hands on with the OS, I can say that it’s definitely not finished. The claim that “everything that works in 7 works in 8” is not true yet, as I’ve found some of our applications that use features that don’t work in this build. I’ve also had to go into the task manager to kill errant metro apps a few times, and run into UI strangeness like apps disappearing from the back stack when they are killed (which is sure to confuse users). Add to this the fact that everyone is going to need a lot of time to get the hang of developing metro apps, and I’d guess that RTM by next fall is possible, but even optimistic. A year from now we’ll definitely have a new build, and likely even the RC, but having an OS that’s ready to hit the shelves in October 2012 is probably not going to happen. Honestly, that’s fine with me-I’d rather the OS be complete than rushed, and should they be able to prove me wrong with a complete product before then, I’d be happy to take it.

There were a lot of sessions at build, and many more sessions than there were timeslots. Once the schedule was finally made available (after Tuesday’s keynote), my first step was to start figuring out what to see, and what conflicts there were. I think the fewest number of simultaneous sessions that I wanted to see was four, and it went as high as eight for one block. Needless to say, the fact that all the sessions are posted online is quite handy, since it means being able to catch up post-conference on what I wasn’t able to see in Anaheim. If you’re looking for something to watch over lunch, here are some suggestions (note, some of these are only interesting if you’re a developer):

• Building real-time web apps with WebSockets using IIS, ASP.NET and WCF-websockets is a great emerging technology that will allow an http (request/response) connection to be upgraded to a TCP socket (full duplex). Essential for real-time web apps.
  
  
• 8 traits of great Metro style apps-A good overview of what makes a metro application “metro”
  
  
• Fundamentals of Metro style apps: how and when your app will run-Summarizes the new application lifecycle, and how metro apps are suspended, resumed, and killed.
  
  
• Future directions for C# and Visual Basic-a quick overview of what’s new in .net 4.5, and language features coming in a future release by the creator of the C# language.
  
  
• Using tiles and notifications-A deep dive on how applications can and should use and update tiles.
  
  
• Writing modern C++ code: how C++ has evolved over the years-This session explains some of the new C++ 11X standards, and helps to justify the C++ renaissance that’s starting to happen. Never write delete again!
  
  
• Real time communication: keep your Metro style app connected whether it is running or suspended-not only a long session title, but a great overview of how to write lock screen apps in metro. Essential for creating VoIP or IM apps.

In Windows, applications have always been able to communicate with each other, but it hasn’t always been easy. First, there’s the question of protocol-applications could choose from setting up sockets, named pipes, http interfaces, COM, .net remoting, command lines, or any number of other choices that both sides of a transaction would need to agree on. Then there was the matter of the messages that would flow on that channel, which were usually published by one side or the other, and required custom development from the opposite side to implement. There were places where things were better, such as registering for a protocol handler or a file association. Double clicking a .docx file in explorer opens word, and clicking a sip: or tel: URI in a browser (or anywhere else that renders hyperlinks) will open a softphone (iceBAR, Lync, eyebeam etc). For the most part though, inter-application communications were a largely proprietary effort that required work on the part of someone to get working. One of the visions Microsoft has for Windows 8 though, is a “Web of Apps” (their words), and they’ve exposed a series of contracts to enable this.

Developing for Windows 8 is going to fall into two camps: the Metro apps and the desktop apps. The chart below breaks things down quite nicely.

Looking at any of the screenshots of the Metro UI, one thing stands out on the main page: