Ars Technica NewsOne Microsoft Way
Windows 8 for software developers: the Longhorn dreamreborn?
Early this month, Microsoft dropped somethingof a bombshell on Windows developers: the new Windows 8touch-friendly immersive style would use a developer platform not basedon .NET, which Microsoft has been championing for the past decade.Instead, it would use HTML5 and JavaScript. Since then, the company hasrefrained from making any further comment on the issue. In particular,the question that has many Windows developers particularlyconcerned—how can I make use of my existing skills and experience whendeveloping these new applications?—remains unanswered; the companyplans to reveal nothing until its BUILD conference in September.
But the situation probably won't be as grim as many developers fear.Early milestone builds of Windows 8 have leaked onto the Internet, andconsiderableeffort has been put into figuring out how they work. Thoughofficially tight-lipped,snippetsof information have escaped Redmond's walls. So far, it appearsthat Windows 8 development doesn't just looknot bad—thereare signs that it will actually resolve many long-standing annoyanceswith writing Windows software. If Microsoft can pull off everythingit's hoping to achieve with the platform, Windows 8 will be asimportant and radical a release as Windows Longhorn was going to be.
A little bit of history
Before we look at what Microsoft will be doing with Windows 8, alittle context is necessary. To understand the vision and why it's sucha break from the past, one first has to understand the current reality.
Prior to the introduction of .NET in 2002, Windows applications werewritten in two main ways. "Big" applications—think Office, orPhotoshop, or Netscape Navigator—tended to be written using the Win32API and C++. Win32 is a large API that covers a lot of ground. There'slots of "obvious" stuff, like graphics and user interface creation,network communication, and file system access, and there are also manymore esoteric things, like backup creation, network configuration, andsecurity.
It's big, and it does a lot, but there are important things that itdoesn't do very well, and some things it doesn't really do at all. Forexample, although it includes an API fordatabaseaccess—several,infact—it's rather fiddly to use plain Win32 for writing applicationsthat use databases a lot. More problematically, even though it has allthe basic tools you need for putting together a GUI, it sure doesn'tmake it easy. For example, it doesn't give you any assistance when laying out a userinterface. Each button, text box, and toolbar must be positioned bythe developer. If you want the positions to change when you enlarge thewindow, well, you have to do that all yourself. Many libraries weredeveloped to act as a layer between the developer and the operatingsystem to try to make this task easier, including Microsoft's ownMFC,but all too often you have to delve into Win32 to get things to workjust the way you want.
The other major way of writing Windows applications was VisualBasic. Visual Basic made some tasks really easy—in particular, talkingto databases and creating user interfaces—and it became a staple of thebusiness world. An awful lot of business applications out there dolittle more than pull information out of a database, show it to a user,and give the user a form so they can add data. At these tasks, VisualBasic excelled. What it wasn't so hot at was anything else. It hadlittle good support for calling Win32 functions directly, especiallythose that used certainconstructs that Win32 depends on.
Visual Basic also lacked support for the rather popular objectorientation paradigm, being merely "object-based."
.NET came along and changed all that. .NET gave developers much ofthe ease of use of Visual Basic, but did so without the compromisesthat Visual Basic imposed. Similar to Visual Basic, it had good toolsfor buildinguserinterfaces andtalkingto databases, so it was eminently suitable for writing businessapplications. But, unlike Visual Basic, it also made access to Win32 aneasy, ifslightly awkward, option.The platform rapidly gained traction with business developers, and somenew commercial projects also used it.
The Longhorn dream
Windows XP, released the year before .NET, unsurprisingly didn't usethe technology. But as Microsoft announced at PDC in October 2003, thatwas due to changewiththe release of Windows Longhorn. Longhorn would integrate .NET intothe core Windows platform. .NET FX, as it was known in the company(with "FX" standing for "framework") would give way to WinFX, a WindowsFramework based on the same technology. Among other things, this wouldinclude a brand new way for writing user interfaces, codenamed Avalon,that would be thoroughly modern, vector-based, andhardware-accelerated. Windows itself would be written to use WinFX forits user-visible programs—Explorer, calculator, and so on—and, goingforward, .NET would bethe way to write Windows applications.Win32 would still exist for backwards compatibility, but it would befrozen and left static.
Longhorn would have been the end of the old ways of writing Windowsprograms, and the dawn of a new era of modern Windows development, onethat was not hamstrung by design decisions made ten or fifteen yearsprior.
As we all know now, Longhorn never shipped as such. The project grewenormous, unmanageable, and broken. Around the same time, Windows XP,on which Longhorn was based, was being ravaged by hackers. Microsoftpoured its resources into making Windows XP and Windows Server 2003tolerably secure—an effort that culminated in Windows XP Service Pack 2and Windows Server 2003 Service Pack 1—then, for the most part, starteddevelopment of its next operating system, the one eventually to ship asWindows Vista, all over again.
One of the biggest losers in this developmental reboot was .NET.Windows Vista, though radical in some ways, abandoned the entire"WinFX" concept. Avalon did ship—it's now known as Windows PresentationFoundation (WPF)—but as an add-on to the operating system, not a corepart. The only significant piece of .NET code in Windows Vista andWindows 7 is Media Center (and that doesn't even use WPF). Everythingelse is plain old Win32. More significantly, the Win32 API itself wasupdated and extended. Numerouslow-levelfeatureswere added, and support for GUI changes, like Windows Vista's taskbarthumbnails and the Aero Glass theme, were added to Win32. None of theseGUI changes worked especially well with WPF.
There were a few factors that led to this decision. Part of it wassimply expediency; there wasn't time to rewrite everything to use .NET.But perhaps the bigger factor was internal divisions within Microsoft.Windows is from the Windows division (WinDiv); .NET is from theDeveloper Division (DevDiv), which in turn is part of the Server andTools business. Although one might think that these groups were alignedin their objectives, this was not the case. Not necessarily out of anymalice—just that the groups had different priorities.
Fractured development
Some of these priorities made sense at the time. WPF, for example,can only be used by .NET programs, and it only works well with oneswritten in C# and Visual Basic.NET at that. The entire API, from top tobottom, is off-limits to native C++ programs, making it a significanteffort to migrate existing programs to use WPF. This made sense whenall future development was meant to use .NET, but when that planchanged and native code regained its position as the preferreddevelopment environment, it was a big problem. Microsoft couldn't usethe clean, vector-based, resolution-independent, hardware-accelerated,WPF library to build any of the core operating system applications.
Others priorities were simply a result of the different purpose ofthe groups. So, for example, DevDiv's priorities were to make .NET acredible platform developers; this meant addingnewcore functionality and developing libraries and tools such asSilverlight. WinDiv's priorities were the aforementioned C++compatibility, robustness, and fixing certaintechnicalissues. All the objectives were sensible, but because DevDiv didn'tanswer to WinDiv, not as much weight was given to the things WinDivwanted. The result was that WinDiv management wasn't happy with .NETand was happy to ignore it.
Subsequent releases of .NET have improved the situation, with allbut the C++ issue now resolved. The damage had already been done,though; WinDiv, dissatisfied with DevDiv, ignored its work, and Windows7, just as its predecessor, uses .NET only for Media Center. Windows7's new APIs are all native C++ APIs, with no ready access from .NETprograms, and native C++ programs still have no access to aresolution-independent, vector-based, hardware accelerated frameworkfor building user interfaces.
Windows 8 will put an end to that.
A brave new world
Windows 8 will ship with a pair of runtimes; a new .NET runtime(currently version stamped 4.5), and a native code C++ runtime(technically,COM,ora derivative thereof), named WinRT. There will be a new native userinterface library, DirectUI, that builds on top of the native Direct2Dand DirectWrite APIs that were introduced with Windows 7. A new versionof Silverlight, apparently codenamed Jupiter, will run on top ofDirectUI. WinRT and DirectUI will both be directly accessible from .NETthrough built-in wrappers.
WinRT provides a clean and modern API for many of the things thatWin32 does presently. It will be, in many ways, a new, modern Win32.The API is designed to be easy to use from "modern" C++ (in contrast tothe 25 year old, heavily C-biased design of Win32); it will also mapcleanly onto .NET concepts. In Windows 8, it's unlikely that WinRT willcovereverything Win32 can do—Win32 is just so expansive thatmodernizing it is an enormous undertaking—but I'm told that this is theultimate, long-term objective. And WinRT is becoming more and moreextensive with each new build that leaks from Redmond.
WinRT isn't just providing a slightly nicer version of the existingWin32 API, either. Microsoft is taking the opportunity to improve theAPI's functionality, too. The clipboard API, for example, has been madeeasier to use and more flexible. There will also be pervasive supportfor asynchronous operations, providing a clean and consistent way to dolong-running tasks in the background.
DirectUI is built around a core subset of current WPF/Silverlighttechnology. It includes support for XAML, the XML language for layingout user interfaces, and offers the rich support for layouts that Win32has never had. This core will give C++ programs their modern userinterface toolkit and, at its heart, it will be the same toolkit that.NET developers use too. (DirectUI is a name Microsoft has used before,internally, for a graphics library used by Windows Live Messenger. Thenew DirectUI appears to be unrelated.)
Jupiter is essentially Silverlight 6; a fully-featured, flexibletoolkit for building applications. The exact relationship betweenDirectUI and Jupiter isn't entirely clear at the moment. It's possiblethat they're one and the same—and that DirectUI will grow infunctionality until it's able to do everything that Silverlight can do.It's also possible that DirectUI will retain only core functionality,with a more complete framework built on top of its features. Anotheroption is that Jupiter refers specifically to immersive, full-screen,touch-first applications.
XAML and the WPF-like, Silverlight-like way of developing GUIs aregoing to be absolutely central to Windows development in the future.Testament to their new importance is a reorganization that occurred atthe start of this week. Instead of operating under DevDiv's roof, theXAML team has been broken into three parts. The group working on XAMLand related technology for use in Windows has moved to WinDiv, and thegroup working on it for Windows Phone, Xbox, and the browser plugin hasmoved to Windows Phone. Only the group that works on the developertools—including Visual Studio and Expression Blend—is staying behind inDevDiv. The internal Microsoft e-mail announcing the change notes thatthe XAML team has been working with the Windows team for the durationof Windows 8's development; this move simply makes them a formal partof the UI team.
A single, modern, unified Windows API at last
The point of all this? It gives parity to native C++ and managed.NET code. Instead of being separate, each with its own differentcapabilities and strengths, they will be peers. If Microsoft adds newAPIs to core Windows, the WinRT system will ensure that they'reseamlessly available to managed code, meaning that .NET developers willno longer be at a disadvantage relative to native ones. Conversely,existing native applications can be updated to use the new UI withouthaving to be substantially rewritten to use .NET. This same flexibilityapplies to Microsoft: putting native and .NET code on an equal footingopens the door to actually seeing .NET applications shipping with theoperating system.
With this facility, we might even see Office 15, for what wouldsurely be the first time in a decade or more, adopt a standard Windowsuser interface, instead of the many various custom front-ends that it'sbeen sporting for years.
Less immediately clear is what will happen to WPF. WPF andSilverlight are owned by the same teams within Microsoft, butSilverlight has met with more market success than full-blown WPF.WPFdoes do things that Silverlight doesn't,however, and it would be a shame if these richer features didn't maketheir way into the brave new Windows 8 world. WPF and Silverlight havebeen developed on a broadly convergent path, and it's possible thatJupiter may eliminate the remaining differences between the two.
Downplaying WPF and expanding Silverlight's role would make sensegiven the broader Microsoft ecosystem. A version of Silverlight is usedfor third-party Windows Phone development, and there'scompellingevidencethat indicates that a version of Silverlight for Xbox is also in theworks. Having Silverlight across Windows, Windows Phone, and Xbox wouldgo a long way towards promoting Microsoft's "three screens [computer,TV, phone] and a cloud" ambition, which would see software and userexperiences seamlessly interoperating between all three environments.
Just how closely aligned these three screens will be is one of themany questions still unanswered. Windows Phone developers havelong-standing concerns that Windows tablets, unlike their iOS andAndroid counterparts, won't directly support the use of Windows Phoneapplications. Both Windows and Windows Phone use Silverlight, but thephone adds a raft of phone-specific functionality that presently has nocounterpart in desktop Silverlight.
The future is nothing to fear
The bigconcernthat arose as a result of the initial Windows 8 presentation severalweeks ago was that the new-style immersive applications would beavailable only to HTML5 and JavaScript developers. The language usedduring this presentation said that the new development framework was"based on" HTML5 and JavaScript, and this sent ripples throughout theentire Silverlight community.Individualthreadsabout the issue on the official Silverlight forums received hundreds ofreplies and tens of millions of hits—those threads saw more activitythan the rest of the forum would get all month. Windows developers wantto be able to build immersive applications, and they don't want to haveto use HTML5 and JavaScript to do it.
They won't have to. Want to write an immersive application in nativeC++? That's cool. Want to use C# and Silverlight? That's cool too. Bothwill be supported. Far from being left behind on the legacydesktop—which was the impression that many took from thepresentation—native C++ and managed C# will both be first-class,supported ways of developing immersive, touch-first, tablet-friendlyWindows 8-style applications.
What of HTML5 and JavaScript? They'll be an option too. Microsofthas ventured down the HTML application path before, with itsHTAtechnology. HTAs—HTML Applications—are packages of HTML, JavaScript,CSS, and other resources that run in a special trusted mode. The normalconstraints that regular HTML webpages are governed by—for instance, aninability to access local resources—don't apply to HTAs: HTAs can writeto the file system, access arbitrary network resources, and more. Inother words, they're webpages stripped of some of the limitations thatmake webpages unsuitable replacements for desktop applications.
New-style HTML5 immersive applications won't be distributed as HTAs,but many of the same principles are likely to apply. Like HTAs beforethem, they'll gain greater access to operating system functionalitythan regular webpages—so they'll be able to call Windows APIs and havea user interface that feels less like a webpage, more like a nativeapplication. Feature-wise, they should be at the same level as .NET andnative programs. It's just that they'll use an HTML5 programming modeland JavaScript. The net result should be something that's familiar toWeb developers, but without the functional deficits that Webapplications normally suffer.
Far from being a developer disaster, Windows 8 should be a huge leapforward: a release that threatens to make development a pleasure fornative, managed, and Web developers alike. The unification of the .NETand native worlds; the full hardware acceleration; the clean, modernAPIs; Avalon as the primary solution for creating Windows UIs—this iswhat Longhorn's WinFX promised all those years ago, and this timearound it looks like it might actually happen.
Mystifying silence
Which all makes the continued radio silence from Microsoft evenharder to understand. The company is aware of the way that its HTML5and JavaScript comment was received in the community, but its stance isthat there's no real problem; the shock horror reaction is an overblownblogger thing. The decision to not say anything more than "wait forBUILD in September" has been discussed and re-discussed within thecompany, at a high level, but at present the decision remains: saynothing, and leave developers with uncertainty.
I thought this policy stank a week and a half ago, and I think itstill stinks today. The tens of millions of page views that theSilverlight forum received aren't an overblown blogger thing. WindowsPhone developerstoday saying that they're going to ditch theplatform because of uncertainty over its future isn't an overblownblogger thing. When a former Microsoft Project Manager, one who workedon both WPF and Silverlight, says that he's going toswitchto Adobe's comparable Flex/Flash stack—because at least Adobe iscommitted to that—that isn't just an overblown blogger thing.
It's understandable that Microsoft doesn't want to spill everythingright now. Windows 8 is still a long way from completion, and plentycould change between now and BUILD. But developers aren't asking toheareverything now; they want to know a few salient details.Answering two questions would probably do the trick. Will it bepossible to write immersive applications using C++ or .NET? Will it bepossible to write immersive applications using XAML?
Unless the direction shifts radically after BUILD—this ispre-release software, so that's not impossible, even if unlikely—thenthe answer to both of those questions is "yes," and the Windows 8developer experience will see the greatest leap forward since theintroduction of the 32-bit Windows API in 1993. That's an excitingprospect—but Microsoft gains nothing from leaving doubts hanging in theair.
扫一扫
4075
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
