Tag Archives: winrt

Death of the Start Screen Exagerated

It seems like the online media is foaming at the mouth about Windows 8.1 Update 1 supposedly making the move to boot by default to the desktop. The first article I came across was by Steven J. Vaughan-Nichols over at Computerworld followed by an article at Mary Jo Foley over at ZDNet (who gives the topic a much more balanced treatment).

Where Mary Jo Foley stops at reporting the news, Steven’s opinion piece is vitriolic which is typical of his previous articles. I mentioned to one of my co-workers the other day that I was disappointed in the state of tech journalism these days. Alas, there is only so much news to go around which means that content ends up being rehashed – so the only way to stand out is to write an opinion piece, the more bitter the better.

With that out-of-the-way, I have to acknowledge that where there is smoke, there is fire. So what about the rumour that Windows 8.1 Update 1 will boot straight to the desktop. If the rumour is true it is worth stepping back and thinking practically how this might work.

When Microsoft introduced Windows 8.x, the Start Screen didn’t replace the desktop. Rather the Start Screen replaced the Start Menu. The Desktop was always there in the background, it was just as if immediately after login that the Start button had been pressed and a full screen start menu was being displayed.

I suspect that Microsoft might ideally want to just boot to the desktop by default for devices that don’t have a touch first experience (desktop PCs and laptops) leaving touch first devices to boot to the Windows 8-style Start Screen. This would give users balance the best possible experience on their particular devices form-factor.

Some of the press has pointed out that if you boot to the desktop, then how will users know to launch metro-style apps? Well, remember that the Start Screen did not replace the Desktop, it replaced the Start Menu. So when a user presses the start button on the desktop (or on their keyboard) the Start Screen would still be displayed. If this continues to be the case then metro apps would still be discoverable in a desktop environment.

As Mary Jo Foley pointed out, leaked screenshots of the Windows 8.1 Update 1 UX reveal that users will be able pin metro-apps to the start menu. This means that users could quickly switch between legacy desktop apps and modern apps. I suspect that Microsoft has more plans for blending the metro and desktop environments.

I speculate that in a future release (not necessarily Windows 8.1 Update 1) we’ll see metro apps being able to run in floating windows on the desktop along with API support to make apps intelligently respond to this environmental change. Windows Runtime (or WinRT) is the underlying platform for modern metro applications, but that doesn’t mean that you can’t produce a UI in it that is more optimal for a mouse/keyboard user.

The second change we MIGHT see is a Start Menu / Start Screen hybrid. So far the best concept of how this might work I have seen is this start menu/screen transition video which was posted recently (and received great reviews).

What this video hints at is that the theme for phone, tablet and PC operating systems moving forward is convergence. Microsoft has pretty much confirmed this to be the case for Windows and Windows Phone, but I suspect this will also happen with OSX/iOS. Google is an interesting case because they have two quite different approaches to apps in Android and Chrome OS.

For Windows the key ingredient to convergence is Windows Runtime. Not only does Windows Runtime expose the UI building capabilities, but it also surfaces other OS features, file system, networking, sensors etc. WinRT modernizes key aspects of the existing Windows API (in Win32) in a way that is suitable for desktop, tablet and phone.

In summary, I don’t think that booting to the desktop on desktop-style devices spells the end for either metro, or the Windows 8-style start screen. Rather I think it’s just a continued fine-tuning of the user experience to support as broader range as users as possible. Indeed this kind of UX spread is a necessary feature of a single operating system running on a multitude of devices.

Presenting on VS2013 and Windows 8.1 in Brisbane.

I’m up in Brisbane for a week at the moment and on Monday the 28th I am giving two presentations back to back on What’s new in VS2013, and a separate session on improvements in Windows 8.1 for Enterprise Applications. We’ve got quite a few registrations at the moment and I’m not sure what the cut-off is but if you would like to come along and check out the latest improvements in VS2013, and get a handle on how you might using Windows 8.1 in your business then register here.

I’ll be around for a little while after the event so if you want to discuss some app ideas or whiteboard anything then I’ll be available.

DNS Limitations in Windows Runtime

Lately I’ve been looking at line-of-business applications for Windows 8.x and how you would go about deploying such applications in the real world. When you build a line-of-business application in-house you can often get away with doing things like hard coding service URLs, but if you are building software that is going to redistributed to multiple customers or even on the Windows Store you need to figure out how your application is going to “discover” where the services are located.

The simple and obvious approach is for the application, upon starting to ask the user for a server name to connect to, but in enterprise environments this information is often opaque to the end-user. Further, once this information “gets out” it can be notoriously hard to retrain users to enter some other value if the network topology changes.

DNS Support in Windows Runtime

Discovering service endpoints is a common challenge. For example, when you set-up e-mail in many mobile devices an automated discovery process is undertaken which involves querying DNS for addresses such as “autodiscover.mycompany.com” when you tell the mail client that your e-mail is “someone@mycompany.com”.

The Domain Name System actually has a mechanism to support discovery of services associated with a domain name via the use of SRV records. An SRV record is a DNS record which combines a service name, protocol, domain and target address to tell a program (via a DNS resolver) which endpoint it should connect to. Many technologies and/or products such as Active Directory and Lync rely on this mechanism.

Getting back to Windows 8.x, I was investigating the best way to enable an service address discovery mechanism which followed this basic process:

  1. On initial start-up of application, ask user for their e-mail address.
  2. Use the domain part of the e-mail address to initiate an SRV record lookup (DNS)
  3. Use the target address from the SRV to connect to service address.

Unfortunately, Windows Runtime doesn’t expose a good mechanism to do this, and the .NET API subset exposed to Windows Runtime doesn’t contain the classes that you might have used to do this in a traditional desktop application. There is some suggestion that you can use the DatagramSocket class to do SRV record lookups for UDP endpoints, but my scenario is for TCP connections.

Workaround

Without the ability to execute sophisticated DNS queries from modern applications in Windows 8.x the only thing that you can do from a discovery point of view is abandon using SRV records and use an “autodiscover” mechanism similar to the way that Microsoft Outlook uses to find the mail server based on the e-mail address.

This process would look something like the following:

  1. On initial start-up of application, ask user for their e-mail address.
  2. Use the domain part of the e-mail address and prefix with a unique string (e..g myappdiscover.mycompany.com).
  3. Send a request to this endpoint to download configuration data which can be used to locate service endpoints.
  4. If this fails fallback to ask for detailed configuration information.

As it happens I believe that Microsoft has already encountered this problem. If you’ve used Lync, you’ll know that there are two different Lync clients for Windows. The standard desktop Lync client, and the modern version of the Lync client. The modern Lync client relies on a mechanism similar to the above (lyncdiscover.mycompany.com), whereas the desktop client can make use of the SRV records to discover the location of the server.

The “autodiscover” or “lyncdiscover” approach for Exchange or Lync respectively rely on a CNAME record being present in the DNS and a server available at that address to respond to the discovery requests. This would be largely unnecessary if the platform supported querying SRV records.

You might be tempted to look at implementing your own DNS client using the sockets API in Windows Runtime. Of course this would take some time to implement correctly, but more than that, you need to be able to discover the address of your assigned DNS server, which from what I can tell is not exposed to modern applications via Windows Runtime.

Touted Demise of Windows RT and Marketing Lessons for Microsoft

I read an article this morning on The Motley Fool about a consumer electronics trade show in  Taipei. The headline “Does This Mean Microsoft Windows RT is Dead?”.

I won’t comment on whether devices running the “RT Edition” of Windows 8 are going disappear based on the presence of new devices at a trade show. But the headline did stand out for me because it is an example of the confusion caused when you “borrow” a technical term and slap it onto the end of a product name.

In this specific case Windows RT actually means two things. First, to me as a developer Windows RT means Windows Runtime, an API layer inside introduced in Windows 8 and Windows Phone 8 and is the basis for modern applications.

On the other hand, if you aren’t a developer and you are more focused on “products” and “devices”, the term Windows RT might identify a lower power device running a special build of Windows 8 which introduces some limitations for these lower powered machines.

The problem is when the journalists go around saying “Windows RT” is dead, IT managers who might not know about the lower level details of the Windows 8 platform might start to disregard the proposition that they might like to build a Windows 8 application that targets the Windows Runtime (Windows RT).

Confused? Yep, so are most folks and this is why MIcrosoft needs to be very careful about tacking the RT suffix on products like the Microsoft Surface RT and Office RT. They might accidentally build the impression that the underlying runtime itself is going away if indeed the industry is moving back towards an Intel centric architecture. I think Microsoft should drop the RT moniker all together on their OS, Office and devices (including partner devices) and come up with some other suffix. Leave WinRT to the developers.

Some might say it is unlikely that ARM processors running Windows will disappear, but the X86 and X64 architectures have proven incredibly resilient in the face of other architectures (ia64, ARM etc). One exception might be in the Windows Phone space where you really do have some heavy power conservation requirements and the expectations are considerably lower than that of a PC or a tablet device.

My gut feel is that Windows RT (the runtime, or the device class) aren’t going away any time soon, and it is certainly too premature to say that based on what you are seeing at this years trade shows. What is far more relevant is what we see announced at BUILD 2013 this year in terms of Windows and Windows Phone platform convergence.

The big question I have is will the rumoured “phablet” devices run a Windows Phone-like build of Windows RT, or a Windows-like build of Windows RT. Based on some of the projects I am seeing at the moment I am hoping that a phablet is running something derived from the current Windows 8 generation of platforms. The Windows Phone UX is great for small surface areas but I don’t think it will scale well up to a phablet size.