Gregarius » BetaNews.Com » décembre 2, 2009

BetaNews.Com (5 non lus)

Mark Russinovich on MinWin, the new core of Windows

Publié: décembre 2, 2009, 11:27pm CET par Scott M. Fulton, III

By Scott M. Fulton, III, Betanews

Since the first public news of Windows 7's development back on October 2007, we've heard about a component of the operating system called MinWin -- a tantalizingly titled element that sounds like some kind of portable Windows kernel. Now Windows 7 is actually residing on paying consumers' desktops, and inside of it -- and inside of Windows Server 2008 R2 -- is the MinWin kernel architecture...and yet few have been made clear as to what it actually is.
A few weeks ago in Los Angeles, Microsoft technical fellow Mark Russinovich -- absolutely the world's leading authority on Windows performance and architecture -- took time to explain to developers attending PDC 2009 in Los Angeles exactly what this is. In summary, it's a way to graft onto Windows some semblance of the architectural layering it should have had, if its architects in the 1980s had any foresight into how Windows would be used thirty years later. It enables current and future Microsoft developers to evolve new configurations of the operating system, without having to rewrite core services or worry about breaking dependencies between those services and upper-level APIs.
"If you look back at the evolution of Windows, it's evolved very organically, where components are added to the system and features are added to the system without, in the past, any real focus on architecture or layering," Russinovich explained. "And that's led us to do some hacks with Windows, when we want to make small footprint versions of Windows like Server Core, or Embedded Windows, or Windows PE -- the pre-installation environment. What we do [instead] is take full Windows, and start pulling pieces off of it. The problem with that is, the pieces that are left sometimes have dependencies out to the pieces that we've removed. And we don't really understand those dependencies."
Perhaps "Windows" is a poorly fitting name for what the operating system should be at its core. The breakthrough with Server Core, introduced back in Windows Server 2008, is that it minimized the number of running services to just those that enabled the operating system to be self-sustaining, and perform its roles as a server to the outside world. But even those services contain dependencies to libraries that involve graphical functionality, even if none of those services use that functionality. Conceivably, a breakthrough above and beyond Server Core itself would be a completely minimalistic kernel, upon which those roles could be added modularly, without having to involve libraries that presume the computer operator needs graphics, a mouse, and sound.
MinWin is the first critical step in that direction. "We want to get more rigorous about this," said Russinovich, "because every time we evolve Windows, we end up breaking those versions that we've sliced-and-diced. We'd like to have a Server Core that we understand, that totally depends on itself and not things outside of itself, so that we can evolve things outside it while we evolve Server Core, and not be worried about breaking Server Core, or having to redefine it with every release."
The basic MinWin in Windows 7 is comprised of about 161 files, whose total footprint on disk is about 28 MB. Before you go thinking you could carry that around in the cheapest thumb drive you've got, realize that MinWin doesn't even issue a command prompt. It runs the kernel, basic system services, and the TCP/IP stack, and that's it.
Operating system functions are implemented through APIs; and since Windows 3.1, those APIs form the collective library of libraries known as Win32. The principal division of labor in Win32 has historically been vertical, not horizontal, dividing core system kernel functions from "user" input and interactive functions, from graphics and display functions. Even though Windows architecture has evolved to the point where the whole graphics part is essentially deprecated for modern apps, GDI32.DLL is presumed to be present.
For Microsoft's engineers to implement a more horizontal layering, they needed to create a scheme whereby API functions operate as though the typical division of labor still existed, even when it doesn't. Here is where that most blessed word "virtual" enters the picture. Under the new MinWin architecture, the handful of core functions in the new KERNELCORE.DLL KERNELBASE.DLL handle essential system services. Any other calls to APIs outside that realm are "forwarded," like unresolved DNS addresses in the Internet naming scheme, to libraries outside the core.
But whereas APIs used to "resolve" to the same core sets of libraries that existed since the '80s, under the new MinWin architecture, all that's changed. Revealing the gulf between the mindsets of what constituted efficiency 25 years ago and efficiency today, Russinovich explained something incredible: In the old days of Windows, APIs were bunched together in groups that may not have had any logical bearing with one another, simply to reduce the length of the boot path. Bigger API collections meant fewer references to their filenames.
"We want to get away from that, and really make the definition of the logical DLLs, these files on disk, separate from the API sets that they implement, so that we can compose them dynamically," said Russinovich. "In other words, we want people to call virtual DLLs that implement APIs, and then what happens on the system is that those virtual DLLs are mapped to logical DLLs that actually implement this functionality. So it doesn't matter from a programmer's perspective if a virtual DLL's implementation is in this logical DLL or that one, it's up to us behind the scenes to figure out how to best combine virtual DLL implementations into logical DLLs."
There are performance costs to the implementation of logical DLLs, one of which being the creation of "artifacts" in the dependency trails that tools such as Russinovich's own Dependency Walker can trace. Also, processes now have to be endowed with a map that associates virtual DLLs with logical DLLs. And the files for the virtual DLLs have to physically exist on disk, even though their instructions are comprised completely of no-ops.
But the benefits outweigh the costs, including expediting API requests through virtual, dynamic placement. And now Microsoft's own developers, mindful of what Russinovich calls the three-year "cadence" between major product release cycles, are freer to innovate different form factors and implementations of Windows for new classes of hardware and new configurations.
MinWin can boot as a separate operating system process unto itself, but it doesn't actually have any console of its own. In this PDC 2009 demonstration, an outside process actually has to test the waters to see that MinWin has a heartbeat.
One potential payoff down the road for MinWin may yet come from an improved Server Core. As Russinovich demonstrated, even the command prompt up until Vista relied upon a high-level process associated (for no important reason) with graphical functions, the Client/Server Runtime Subsystem (CSRSS). The new MinWin architecture now enables each running process to have access to a command subsystem called CONHOST that is closer to the core, without messing around with libraries they won't even use. A future Windows release ("Server 2011?") could substitute the existing Server Core with a horizontally-layered architecture based on a MinWin foundation.
And another possible permutation for the client edition -- one which Russinovich did not mention, but which is foreseeable nonetheless -- involves a foundation layer built on MinWin whose basic purpose is to manage the hardware and run system services, topped by a virtual layer also built on MinWin that runs applications and provides the user environment. Such a scheme would be worlds more secure than the system we use today.
Copyright Betanews, Inc. 2009
Google begrudgingly adjusts news crawling for paid publishers

Publié: décembre 2, 2009, 6:27pm CET par Scott M. Fulton, III

By Scott M. Fulton, III, Betanews

With a group of blog posts this morning, one of which literally said paid content was probably not a good idea anyway, Google announced it was making an adjustment to its First Click Free aggregation scheme for news publishers. The adjustment to the service, first rolled out in 2007, will now enable readers to sample more content before subscribing through the publisher's own portal.
"While we're happy to see that a number of publishers are already using First Click Free, we've found that some who might try it are worried about people abusing the spirit of First Click Free to access almost all of their content," reads this morning's post to Google's Webmaster Central blog. "As most users are generally happy to be able to access just a few pages from these premium content providers, we've decided to allow publishers to limit the number of accesses under the First Click Free policy to five free accesses per user each day."
Google charges nothing for its search, as everyone knows; and the whole point of search is to let users sample content throughout the Web. Some of that content is for publishers' paid subscribers. But if all of that content were put behind a pay wall, as publishers are free to do, then Google can't index it, and users can't find it. So in 2007, the search provider established First Click Free as a way to enable publishers to let readers see a sample in Google's index, and click through to read the page associated with that sample, for free. Should the reader click elsewhere in the site, he's directed to that site's signup page.
That sounded nice on paper, at least at first. The problem was that readers found a simple way around being directed to the sign-up page: simply hitting the Back button, returning to Google, and finding another First Click Free page from the same index. Publishers got around that problem by instituting a method that Google calls cloaking. Since a site "knows" when it's being crawled by Google or another index, it has the power of treating the crawler like a pre-paid subscriber, giving it free reign to index everything. When the user clicks on an indexed page, the reader goes directly to the subscriber sign-up sheet.
That sounded nice on paper as well. The problem there, as Google put it this morning, was a security issue: If a Web site can make nice with Google while directing the user somewhere else, that other location could be a malicious misdirection.
The changes to First Click Free today don't actually solve that problem, although this morning, Senior Business Product Manager Josh Cohen cited the need to avoid deceiving the reader as the principal reason for today's adjustments. He did not cite rumors of News Corp. Chairman Rupert Murdoch making an exclusive indexing deal with Microsoft's Bing, although Murdoch's appearance yesterday at an FTC workshop certainly brought the issue to a head.
"If you're a Google user, this [adjustment] means that you may start to see a registration page after you've clicked through to more than five articles on the website of a publisher using First Click Free in a day. We think this approach still protects the typical user from cloaking, while allowing publishers to focus on potential subscribers who are accessing a lot of their content on a regular basis."
Google will also be instituting a system, Cohen said, capable of crawling the first few paragraphs of a story rather than the entire page, as long as the publisher makes those few paragraphs available in a preview page to regular users as well. This doesn't actually differentiate itself very much from what Google already does for non-cloaking publishers that produce preview pages, according to Cohen's description, except that now, preview page content will be labeled in Google's indexes.
"Because the preview page is identical for both users and the crawlers, it's not cloaking," Cohen wrote. "We will then label such stories as 'subscription' in Google News."
But Cohen then closed with a parting kick in the teeth for any publisher that insists on charging for content, and bothering to use the First Click Free program: "Paid content may not do as well as free options, but that is not a decision we make based on whether or not it's free. It's simply based on the popularity of the content with users and other sites that link to it."
Copyright Betanews, Inc. 2009
Microsoft's 'Black Screen of Death' denial solves the blame not the problem

Publié: décembre 2, 2009, 6:26am CET par Joe Wilcox

By Joe Wilcox, Betanews

Microsoft's response to the so-called "Black Screen of Death" problem is a throwback to an older and equally ineffective strategy -- what I have called "security by PR." Rather than managing the problem, Microsoft is managing the reaction. That simply is the wrong approach to quality customer service or instilling users with confidence about using Windows. With Windows 7 only in market for about six weeks and the holiday sales season just started, the company's priority should be fixing the problem rather than denying culpability.
Recap: Some Windows users are complaining of a Black Screen of Death (KSoD), where the operating system essentially fails to fully load at startup. KSoDs aren't new, but there have been recent reports suggesting an increasing number starting in mid November. Last week, British security firm Prevx claimed that November 10 Microsoft security updates caused recent KSoDs. However, in a late-day blog post yesterday, Prevx backed away from its assertion:
"Having narrowed down a specific trigger for this condition we've done quite a bit of testing and re-testing on the recent Windows patches including KB976098 and KB915597 as referred to in our previous blog. Since more specifically narrowing down the cause we have been able to exonerate these patches from being a contributory factor."
The post followed Microsoft's denial by many hours. But Prevx's update doesn't exonerate Microsoft from having mishandled the situation, because Windows security may yet be an issue. Prevx still identifies a registry problem, just one it now asserts could be caused by malicious software:
The issue appears to be related to a characteristic of the Windows Registry related to the storage of string data. In parsing the Shell value in the registry, Windows requires a null terminated "REG_SZ" string. However, if malware or indeed any other program modifies the shell entry to not include null terminating characters, the shell will no longer load properly, resulting in the infamous Black Screen with the PC showing only the My Computer folder.
The malware modifying the registry caught my attention, and Microsoft mentions it in yesterday's blog post denying culpability as deflection of responsibility:
We've conducted a comprehensive review of the November Security Updates, the Windows Malicious Software Removal Tool, and the non-security updates we released through Windows Update in November. That investigation has shown that none of these updates make any changes to the permissions in the registry. Thus, we don't believe the updates are related to the 'black screen' behavior described in these reports.
We've also checked with our worldwide Customer Service and Support organization, and they've told us they're not seeing 'black screen' behavior as a broad customer issue. Because these reports were not brought to us directly, it's impossible to know conclusively what might be causing a 'black screen' in those limited instances where customers have seen it. However, we do know that 'black screen' behavior is associated with some malware families such as Daonol.
But neither Microsoft's denial nor Prevx's retraction resolve the issue or answer why some Windows users report experiencing new KSoDs after installing Microsoft security updates. What if, say, the security updates corrected changes made by malware that results in black screens? I certainly have seen Windows PCs rendered partially unusable after removing malware. Example: Networking features disabled after some spyware is excised.
The point: Prevx only just made its assertions about Microsoft security updates and KSoDs last week, offering up a fix, too. How can either company definitively say that Microsoft security updates aren't involved? In the scenario I arbitrarily suggest, Microsoft could still claim its security updates weren't the cause, since the updates would fix changes made by malware. That's great security by PR.
Even if the security updates aren't the cause, Microsoft should show customers that it's aggressively looking for what might be causing the KSoDs -- particularly if malware might be mucking with the Windows registry. I expect more from Microsoft. Security by PR shifts the blame. Real security seeks a solution for the benefit of customers that might have comprised systems and, more importantly, to protect other users who might be assaulted by others' infected Windows PCs. Afflicted customers don't want to hear what's not causing their KSoDs. They want to know the cause and how to fix the problem. Microsoft's denial fixes nothing but blame.
The holidays have historically been a time of increased malware attacks. That's all the more reason for Microsoft to show customers -- and even malware writers planning holiday attacks -- that it's prepared for most anything. But is Microsoft really on the job, or are too many security professionals without a job because of the company's 5,000-plus layoffs? I'm not feeling confident because of Microsoft's response to Prevx? Are you?
Copyright Betanews, Inc. 2009
Security firm: Windows patches not responsible for 'Black Screen of Death'

Publié: décembre 2, 2009, 3:49am CET par Scott M. Fulton, III

By Scott M. Fulton, III, Betanews

When Betanews reported last June about occurrences of the infamous "Black Screen of Death" (KSoD) in Windows Vista, a reader wrote to suggest to us that we might have only considered the matter so important this late in the game because suddenly it happened to us. A similar opinion may be appropriate for British security firm Prevx, which now says it has "exonerated" last month's set of Patch Tuesday updates from Microsoft as the cause of what it called last night a "crop" of KSoD incidents.
Early Tuesday evening, Prevx director of malware research Jacques Erasmus reported on his company's blog that he and his team have made "significant progress in determining specific triggers of the black screen event." Specifically, it determined that a side-effect accidentally discovered over three years ago by none other than SysInternals' Mark Russinovich (now with Microsoft), led to instances where Windows' product activation inadvertently triggered the black screen. When a System Registry entry of String type is supposed to be terminated by a null character (0) but isn't, the result is that the entry itself may disappear from REGEDIT, Windows' well-known Registry Editor. Such an entry may also trigger KSoD conditions.
But that much has been public knowledge for as long as Russinovich has been distributing his "cool" registry key hider tool. Nevertheless, Prevx now has come around to believing that non-terminated Registry entries to be the cause of KSoD problems, not some strange and allegedly unpublicized change in the "rules" for Access Control Lists that a patch may not have followed.
Erasmus may have had some help in reaching this conclusion from Microsoft. In a statement to Betanews late this afternoon, security response communications lead Christopher Budd told us, "Our comprehensive investigation has shown that none of the recently released updates are related to the behavior described in the reports. While we were not contacted by the organization who originally made these reports, we have proactively contacted them with our findings."
So if Prevx wasn't really sure that ACLs were at the root of the KSoD problem, exactly what does its free fix tool, released yesterday, do? This evening, Erasmus suggested that at the very least, it does nothing bad. "We apologize to Microsoft for any inconvenience our blog may have caused," he wrote. "This has been a challenging issue to identify. Users who have the black screen issue referred to can still safely use our free fix tool to restore their desktop icons and task bar."
Prevx's earlier story led to the BBC reporting a rash of KSoD incidents afflicting specifically Windows 7. The evidence of such a rash may have just disappeared, which doesn't exactly mean the problem has gone away. It does mean we can reset the panic button now.
Copyright Betanews, Inc. 2009
My Windows 7 confession (and why you should confess, too)

Publié: décembre 2, 2009, 12:56am CET par Joe Wilcox

By Joe Wilcox, Betanews

They say that confession is good for the soul -- or the mind. I'll make mine but insist that you read no further unless you're willing to make yours in comments. Deal?
My confession is the real reason for running Windows 7. In September, I wrote "Why I chose Windows 7 over Snow Leopard (and why you should, too)." In that post, I explained about Windows 7 being my primary operating system since January on two different Sony VAIO notebooks (I see from comments how many Betanews readers remember the Sony rootkit and just love the company for it). As I explained in that post, two primary reasons led to my picking the newer version of Windows over Mac OS X: Windows 7's fresh, new user interface and VAIO Z720 hardware features -- mainly higher-resolution display -- compared to 13-inch MacBook Pro. But neither of these reasons is why I stuck with Windows 7, even for the productivity gains realized from using the operating system over Mac OS X Snow Leopard.
As much as I like Windows 7, there is still no iLife equivalent for Windows. The need -- the want -- for iLife has left an empty longing for Mac OS X. After all, people buy computers for applications not operating systems. I blame Microsoft's severely back-asswards content strategy for my terrible Mac OS X longing.
The company controls the last-generation application stack: Office-Windows-Windows Server. Office productivity suites defined PC computing during the 1980s, 1990s and early 2000s. There is enormous infrastructure and huge revenues tied up with this aging, and quickly becoming ancient, application stack. Microsoft seeks to preserve this aging stack through productivity suite ties to SharePoint Server and with new versions like Office 2010, which is beta testing now and due for release in June next year.
The application stack of the present and future is in the cloud. Most people generate content on a non-PC device, manipulate or edit on a PC and share via the Internet -- perhaps by email or more likely Facebook or other online community or service. Granted, text is often created on a PC, but who really uses Word, other than a few stuck-in-the-past businesses -- and, of course, Microsoft? (If you use Word, it's OK to confess.)
Wordprocessing is a commodity. The basic formatting features most people need are available in most any product using text -- blogging service, email client, instant messenger or online community, among many others. None of these products require a separate, dedicated wordprocessor, with Microsoft's Outlook being one of very few exceptions (and there is a longstanding bug -- hopefully not a feature -- that sends attachments to non-Outlook clients as unusable DAT files).
The majority of content people produce today is either textual, using features already part of the aforementioned products, or audiovisual. For example, the PowerPoint of the 2000s is the Web-hosted photo slideshow. Photos and videos easily top the list of content that most people regularly produce and want to share with others. Music is another, although for most of it there are sticky copyright considerations.
Apple understands and has taken a commanding lead in both consumer and professional markets for digital audio, photo and video content creation. Apple controls an applications stack, too: Final Cut Studio-Mac OS X-Mac OS X Server, and it's hugely popular among people that professionally produce content. There's a smaller application stack, with iLife at the front end.
Microsoft needs to understand how important iLife is to the Mac, and how much more important an iLife-equivalent would be to Windows. The company's recently renamed Windows & Windows Live division is supposed to deliver something during MIX10, which last I checked is scheduled for mid-March. By the way, any Microsoft employee thinking that Windows Live Essentials and iLife are comparable is seriously delusional.
So, I've been pining for Mac OS X because of iLife, which would be hugely useful for my work as a journalist. But something has held me back from giving up Windows 7, and it also is part of the new cloud and content stack Microsoft has failed to adequately embrace: Google Chrome. I confess. I'm a Chrome junkie. The browser is fast, elegant and (seemingly) safe, all without those nagging warnings that make Internet Explorer 7 or 8 a spiteful nuisance (C`mon, you know it's true. Confess!). There's something about the Web and cloud content that is simply better on Chrome, but that's topic for another post.
As the official Chrome for Mac beta approaches -- albeit minus many features -- I find myself considering putting away the VAIO Z720 for the 13-inch MacBook Pro. Yes, I'd give up the simply gorgeous 1600 x 900 LED display, but I could always run Windows 7 and Mac OS on the Apple laptop.
The new application stack is the cloud, and Google gets it perhaps even better than Apple. I've got to wonder, will I be running Chrome OS in 2011? Will you? OK, so it's time for your confession. For what applications do you run either Windows 7 or Snow Leopard?
Copyright Betanews, Inc. 2009