Microsoft Surface Priced: 32GB For $499 Without Touch Cover, $599 With; 64GB For $699

Microsoft's Surface tablet pricing has been outed by the software giant.

Earlier today, Surface pricing was posted on the Microsoft Store online site. Not long after, the page was taken down, seemingly because the pricing information was put up on the site before it was supposed to go live.

Based on that screenshot, it appears Microsoft will sell its Surface with Windows RT for a starting price of $499 with 32GB of storage and a Touch Cover. Those who want a Touch Cover included in the order will need to set aside $599 for the device. Adding an additional 32GB of storage will push the Surface's price up to $699.

Microsoft unveiled its Surface tablet earlier this year. The RT version comes with a 10.6-inch screen and a 1,280 x 720 resolution. The device is expected to be Wi-Fi-only, and its Touch Cover add-on works as a screen protector, stand, and keyboard. Surface for Windows 8 Pro is expected to launch after the Windows RT version, and will come with a "full HD" 1080p screen resolution. That device will likely be more expensive than the Windows RT model.

Windows 8 is scheduled to launch on October 26. Windows RT, which will be running on the Surfaces leaked on the store site, will run on ARM processors. Microsoft will also sell Windows 8, Windows 8 Pro, and Windows 8 Enterprise versions. Those models are not compatible with ARM-based chips.

Microsoft promises faster startup for Windows 8, Boots in 8 seconds

Are you the sort of person who prefers to shut your PC down at the end of the day rather than hibernate it or put it to sleep, but do you still want to the system to start up fast? Windows 8 has a new feature that will be of great interest to you.

The feature is called ‘fast startup mode’ and it is a hybrid between a standard cold boot and restoring your PC from a hibernated state. How does it work? Gabe Aul, director of program management in Windows, explains over on the Building Windows 8 blog:

The key thing to remember though is that in a traditional shutdown, we close all of the user sessions, and in the kernel session we close services and devices to prepare for a complete shutdown.

Now here’s the key difference for Windows 8: as in Windows 7, we close the user sessions, but instead of closing the kernel session, we hibernate it. Compared to a full hibernate, which includes a lot of memory pages in use by apps, session 0 hibernation data is much smaller, which takes substantially less time to write to disk. If you’re not familiar with hibernation, we’re effectively saving the system state and memory contents to a file on disk (hiberfil.sys) and then reading that back in on resume and restoring contents back to memory. Using this technique with boot gives us a significant advantage for boot times, since reading the hiberfile in and reinitializing drivers is much faster on most systems (30-70% faster on most systems we’ve tested).

How much faster is this than a standard cold boot? Take a look at this:

Here’s how fast startup is different to a traditional cold boot:

The speed of the handoff between POST and Windows depends on whether the system has a traditional BIOS or the newer Unified Extensible Firmware Interface (UEFI) … so watch out for the sales pitch for new systems:

One thing you’ll notice in the video was how fast the POST handoff to Windows occurred. Systems that are built using Unified Extensible Firmware Interface (UEFI) are more likely to achieve very fast pre-boot times when compared to those with traditional BIOS. This isn’t because UEFI is inherently faster, but because UEFI writers starting from scratch are more able to optimize their implementation rather than building upon a BIOS implementation that may be many years old. The good news is that most system and motherboard manufacturers have begun to implement UEFI, so these kinds of fast startup times will be more prevalent for new systems.

And here it is in action:



The notebook used in that video is an EliteBook 8640p (Intel Core i7-2620M, 8GB, 160GB SSD).

Microsoft Improves Windows Explorer with Ribbon UI on Windows 8

Microsoft today gave another sneak peek of Windows 8 — showing a new approach to Windows Explorer, the place where users search for and interact with files in the operating system. The change will be familiar to many Microsoft customers, because it’s styled as a “ribbon” of commands very similar to the interface used in recent version of Microsoft Office 2007.

According to a Microsoft Windows team Alex Simons, they've evaluated several different UI command affordances including expanded versions of the Vista/Windows 7 command bar, Windows 95/Windows XP style toolbars and menus, several entirely new UI approaches, and the Office style ribbon and that the ribbon approach offered benefits in line with their goals.

He said the motive of redesigning Explorer is based on opt-in data from hundreds of Windows users showing that, despite having over 200 commands, only ten of those represent 81.8% of Explorer's total usage and only two of the top 10 commands are featured prominently in Vista and Windows 7's command bar.

The new Windows Explorer on Windows 8 looks like this:

Goals of the new Windows Explorer
We set out to accomplish three main goals with this new version of Explorer.

1. Optimize Explorer for file management tasks. Return Explorer to its roots as an efficient file manager and expose some hidden gems, those file management commands already in Explorer that many customers might not even know exist.


2. Create a streamlined command experience. Put the most used commands in the most prominent parts of the UI so they are easy to find, in places that make sense and are reliable. Organize the commands in predictable places and logical groupings according to context, and present relevant information right where you need it.


3. Respect Explorer’s heritage. Maintain the power and richness of Explorer and bring back the most relevant and requested features from the Windows XP era when the current architecture and security model of Windows permits.

The new approach is drawing a mixed reaction from Windows users in the comments on Simons’ post.

On the surface, the ribbon looks inconsistent with the tile-based, Windows Phone-style design and fonts that Microsoft has adopted for the default Start screen in Windows 8. Microsoft will be giving more details on Windows 8 next month, and it will be interesting to see how the company bridges the new and old elements of the overall Windows interface.

Check out the video below where Alex illustrates few of the changes in the next Windows Explorer:


The new operating system is set to roll out next year, i'll love to hear your opinions on this, especially the Ribbon UI design.

Why Microsoft Has Made Developers Horrified of Coding for Windows 8

By Peter Bright, Ars Technica

When Microsoft gave the first public demonstration of Windows 8 a week ago, the reaction from most circles was positive. The new Windows 8 user interface looks clean, attractive and thoughtful. And, in a first for a Microsoft desktop operating system, it’s finger-friendly. But one aspect of the demonstration has the legions of Windows developers deeply concerned, and with good reason: They were told that all their experience, all their knowledge and every program they have written in the past would be useless on Windows 8.

Key to the new Windows 8 look and feel, and instrumental to Microsoft’s bid to make Windows a viable tablet operating system, are new-style full-screen “immersive” applications. Windows 8 will include new APIs for developing these applications, and here is where the problem lies. Having new APIs isn’t itself a concern — there’s simply never been anything like this on Windows before, so obviously the existing Windows APIs won’t do the job — but what troubles many developers is the way that Microsoft has said these APIs will be used. Three minutes and 45 seconds into a demo video, Microsoft Vice President Julie Larson-Green, in charge of the Windows Experience, briefly describes a new immersive weather application and says, specifically, that the application uses “our new developer platform, which is, uhh, it’s based on HTML5 and JavaScript.”

Cue much wailing and gnashing of teeth.

Windows developers have invested a lot of time, effort and money into the platform. Over the years, they’ve learned Win32, COM, MFC, ATL, Visual Basic 6, .NET, WinForms, Silverlight and WPF. All of these technologies were, at one time or another, instrumental in creating desktop applications on Windows. With the exception of Visual Basic 6, all of them are still more or less supported on Windows today, and none of them can do it all; all except Visual Basic 6 and WinForms have a role to play in modern Windows development.

Hearing that Windows 8 would use HTML5 and JavaScript for its new immersive applications was, therefore, more than a little disturbing to Windows developers. Such a switch means discarding two decades of knowledge and expertise in Windows development and countless hours spent learning Microsoft’s latest-and-greatest technology. Perhaps just as importantly, it means discarding rich, capable frameworks and the powerful, enormously popular Visual Studio development environment, in favor of a far more primitive, rudimentary system with substantially inferior tools.

A Justified Reaction

The idea of Microsoft discarding all of that expertise seems crazy, and one might think that the developer response is an overreaction — but it’s seen as confirmation of the direction Microsoft already appears to be heading down: moving HTML5 to the foreground, in spite of its inferiority to other technology. The Windows 8 comment made by Larson-Green was shocking, yes, but seemed to be confirmation of what developers already suspected. Developers aren’t willing to assume that the company is going to do right by them, because the messages from the company have given them every reason to believe that the Larson-Green really meant what she said: If you want to use the new development platform, you’re going to have to use HTML5 and JavaScript.

The company has never exactly been good at picking a direction for its development strategy and sticking with it. There’s been too much infighting, too many leaps aboard new technology bandwagons, and too much software that fails to adopt new paradigms. But until about a year and a half ago, it looked like things were beginning to settle down, with the combination of .NET, Windows Presentation Foundation (WPF), and WPF’s Flash-like sibling, Silverlight. WPF and .NET provide a flexible, high-level and structured approach for writing GUI applications, and Silverlight is a cut-down version of WPF that can be used as a browser plugin on both Windows and Mac OS X.

Neither of these technologies was perfect — WPF has never been as fast as it should be, and Silverlight is not as cross-platform as it ought to be — but the set of products did at least represent some kind of a coherent vision for software development. WPF and .NET for big applications, Silverlight for portable ones.

Hopes Dashed

But then Internet Explorer 9 happened. Microsoft jumped on the HTML5 bandwagon, and that’s when things all got rather muddy. Prior to Internet Explorer 9, Silverlight had been the company’s preferred solution for developing rich cross-platform applications. The lack of broad platform support meant that Silverlight could never quite rival Flash on this front, but it was there, and it worked well on those platforms that were supported. With Internet Explorer 9, however, Silverlight took a back seat. HTML5 became the way forward. If Silverlight was to be used at all, it should only be used for those things that HTML5 couldn’t do very well, such as streaming video. For anything else, the message was that developers should use HTML5.

Microsoft did have a point. If you’re really wanting to target people on any platform, HTML5 is the way to go. For Web-facing applications that don’t have any special needs such as DRM video, HTML5 is the long-term bet. But third-party developers were deeply unhappy when this repositioning was made explicit, and they had a point too. For a developer writing an internal-use line-of-business application, one for whom depending on a browser plug-in is not a problem, Silverlight had, and still has, a lot of points in its favor.

HTML5 remains true to its text mark-up heritage. Its structure and semantics are still geared towards creating structured text documents, not application user interfaces. Where Silverlight programs can deal with buttons, icons, list boxes, tree views and other interface controls, HTML5 applications must generally deal with boxes of text, with no higher-level concepts to work with. There are JavaScript libraries that attempt to bridge this gap, but they lack the capabilities and control that Silverlight offers. Ultimately, if one were to design a framework for creating user interfaces, it would look a lot more like Silverlight than it does HTML5.

Another weak area for HTML5 is tooling. Design and development tools that work with HTML5 are not as developed or as robust as those that exist for Silverlight, making HTML5 development more complicated, especially as application complexity increases. Thus far, though the company has continued to promote it as the first choice for browser-deployed applications, Microsoft has done little to address these issues with HTML5.

Redmond has, however, done something with HTML5 that it has never bothered to do for either Silverlight or WPF, and that’s make it fast. Internet Explorer 9 builds on top of an API called Direct2D. This is a 2-D graphics library that uses Direct3D 10 for acceleration. The Direct2D API is even lower-level than HTML5; while HTML5 pages are basically built up of text boxes, these boxes do have some “intelligence” of their own; they have layout rules, borders, backgrounds, and more. Direct2D in contrast can handle little more than curved lines — or groups of curved lines — with every aspect of layout left to the developer. And unlike the inefficient way in which WPF uses Direct3D, Internet Explorer 9 and Direct2D have been optimized and are far more efficient.

With Internet Explorer 9, Microsoft was therefore telling its developer community two things: HTML5 is the preferred technology, regardless of its suitability or desirability. If you want high performance you can either use the low-level Direct2D from C++ directly — an unpalatable option — or the mid-level HTML5. If you want a high-level, purpose-built API with high performance — a version of WPF built on top of Direct2D, for example — it isn’t going to happen.

The Windows 8 comment thus seems to be the culmination of Microsoft’s policy of the last few years. HTML5 was already the blessed development platform in spite of its many failings, and with Windows 8 developers are going to be faced with little alternative but to embrace these inadequate technologies if they want to produce new-style immersive applications. As crazy and destructive as this policy appears, it has the feeling of consistency. Internet Explorer 9 and the downplaying of Silverlight were the first step down this path; immersive applications requiring use of HTML5 are the next.