Just use the default view and type what you're looking for into the search box. Isn't that much easier than scanning the classic-view list?

Libraries don't help you segment your data, they help you bring it together from disparate sources. The whole idea is to *remove* the segmentation of your data by providing rich, metadata-based views backed by a fast database where you can search or pivot easily across any properties (including location) without regard for the physical location of the data.

I'm also confused what you mean about "OS-locked-in-way." The OS provides rich APIs for working with Libraries, but the definitions themselves are simple and (soon to be) well-documented XML format. What about that do you believe creates unnecessary "lock in?" What would you propose to make it better?

(Note that I'm a developer on the shell team, and am genuinely interested in how you think we could improve the interoperability story regarding Libraries)

You're making it sound like copying a file is as simple as reading from one place and writing to another. In reality, file operations are an incredibly complex problem.

A few points:

1) The shell doesn't just deal with files. It has a very sophisticated set of abstractions to support all manner of data sources. Whether it's WebDAV, SMB, HTTP, FTP, a portable media device, a third-party namespace extension, or a standard filesystem location - the shell has to support transferring data between each. Each can have its own set of requirements around naming, around alternate streams, around metadata support, conflict resolution, ACL / permissions information, error handling and resume support, and so on.

2) Read the link I gave in my earlier post. Windows XP used buffered I/O and also dismissed the copy dialogs before the operation completed. Vista changed this so that the dialog stayed until the operation completed and also disabled the use of buffered I/O. This offered some advantages, but in SP1 we moved back to buffered I/O because of customer feedback (and a lot of work to optimize its usage).

3) Vista does a much better job handling ACLs and maintaining permissions structures across copies and moves. But there's some small overhead introduced in order to accomplish this.

4) Vista introduced a lot of features around the "discovery" process before a copy or move operation begins. This process adds some additional overhead, but enables a better experience in other ways. For example, beginning in Vista the shell can now ask you upfront about conflicts that will occur. This prevents you from starting a large operation, walking away, and returning to find that as soon as you left the room the system asked you a question about one file at the front of the list, leaving all the other non-conflicting files waiting for your response.

In Vista, the shell will check every file for conflicts before it begins copying. And once it does begin copying, most errors it encounters (like a permissions or file-in-use error) will be deferred until every successful item is copied. Then it will prompt you at the END of the process for those which it was unable to handle without your help.

Now, there were some issues with this logic in Vista which caused it to be run unnecessarily (like on same-drive moves) or take more time than it should. SP1 made significant improvements to this, and as I said Windows 7 makes substantial improvements on top of that.

There are other complications I didn't cover here, like the fact that I/O is scheduled to ensure that media playback isn't interrupted and that the system remains responsive during these operations.

If you haven't built such a system, it's easy to oversimplify the problem and make it sound trivial. But that doesn't paint an accurate picture of what's going on. There are very few "simple" problems when dealing with software as complicated as an operating system, especially one with the scale and broad requirements of Windows.

Protected Media Path is NOT DRM. And it was included in Windows XP under a different name.

It is a platform service which enables application developers to meet the requirements imposed by certain content protection standards. It is in of itself completely unaware of any DRM schemes or media types.

It is also completely inactive and irrelevant until somebody's code calls the necessary APIs. Enabling PMP features doesn't impact performance, and the PMP code is ONLY run while an application is actively making use of it.

Windows Explorer makes no use of these features. Hell, its features (securing the audio / visual outputs and running decoders in a protected process) are completely inapplicable to the file browser. The only applications included in Windows which make use of it are Media Player and Media Center. And as I already said, even if you are running one of those applications (with media like BluRay which enables these features), there is no perceivable performance impact on your system.

If you really don't like the Protected Media Path services, nothing stops you from using a media player which doesn't make use of the PMP APIs. And the assertion that the presence of this platform service somehow affects file copy performance is proposterous.

Vista never had any DRM of any kind built-in, other than the DRM support in WMP that was in XP.

Certainly nothing at all that affects copy operations in the shell. That notion is absurd (I'm a shell developer, I would know).

It's just a ridiculous myth that gets repeated on Slashdot and nowhere else.

http://blogs.technet.com/markrussinovich/archive/2008/02/04/2826167.aspx

XP hid the dialog before the copy was really finished. Vista changed this so you wouldn't pull out a USB key before the operation had finished.

Vista RTM had some copy performance issues but SP1 fixed those, and during Win7 there was a significant focus on improving copy / move / delete performance.

You seem to be missing the point. It's not just hard to "take full advantage" of the PS3, it's hard to make the damn thing work at all.

You mentioned HDR, something that Xbox developers take for granted since they have 3 different ways of doing it, all which are easy and which given them different performance / quality trade-offs.

Not only is it *harder* to do HDR on the PS3, but the PS3 simply doesn't have the memory bandwidth to accommodate HDR without sacrificing in several other areas (resolution, FSAA, texture size and filtering, etc). Whereas the 360 allows you to balance out the resolution, level of HDR, level of FSAA, texture size, etc - the PS3 lets you pick one. Because if you want 1080p there's no way in hell you're getting any HDR, FSAA, or anything else that requires memory bandwidth.

That's why games look and run better on the 360. Even in the rare cases where one aspect (like, say, HDR) looks a little better on the PS3, it always sacrifices in other areas, resulting in a better experience on the 360. Even if you could eek out some minuscule visual advantage from the PS3 (good luck), no one is going to care. That's not why people buy games.

If your driver supports a Stereo Mix source, then you can enable it in the Recording mixer. You do have to right-click on the background and uncheck the "hide disabled devices" box though, which can be tricky to find (there's probably another way but that's the one I'm familiar with).

Or, you can just download the free and open source loopback device example posted by one of the Windows audio devs:
http://blogs.msdn.com/matthew_van_eerde/archive/2008/12/16/sample-wasapi-loopback-capture-record-what-you-hear.aspx

EVERYTHING. Absolutely EVERYTHING in this article is incorrect.

* What kind of idiot blames the OS for "disabling a program based on a modified DLL." The OS has no such support, this is the APP either crashing or doing its own integrity check.

* Lots of apps ask you if you want to add the appropriate firewall rules during their installers. This has nothing to do with Adobe being a "large software vendor" - Stardock's apps do this too. Go read the API documentation on MSDN if you want to know more.

* The "sound degredation" thing is just unsubstantiated FUD.

* Microsoft in bed with the RIAA? Since when?

* Anyone can browse into their own Local Settings folder. Either this is further idiocy, or ::gasp:: someone hit a bug in a beta OS.

* "Stereo Mix" is a feature of some sound drivers.

And Slashdot proves again that it doesn't matter if something is true, so long as it makes Microsoft look bad.

You haven't "found" any DRM in Win7 because there isn't any (other than the same support for DRM'd WMA and WMV files that has existed in Vista and XP).

"He makes the point that the OSX dock is for applications and that Windows is for each window, though Microsoft is heavily encouraging grouping that makes it seem as much like the dock as possible. True, in Windows this can be turned off, but that doesn't do anything to disprove the intent is to acheive the model the Dock presents."

This isn't the case, though. The dock does not aggressively group windows. It doesn't even display windows! Except when it does (ie. they're minimized), and in that awkward case it doesn't group them.

Windows 7 groups them because the idea is that there is "one button to rule them all" and it is on the taskbar. If you want to switch to an IE window, you tell Windows this by pointing at its taskbar entry, then it asks you "which one?" and gives you a very clear mechanism for choosing the right window (or tab, which is the same thing).

On the Mac, you tell OS X you want to switch to Safari, and it just picks a random Safari window to come to the front (okay, it probably isn't random, I think it's the last one you used). Then if you want to switch to a different one, you have to fend for yourself, or use Expose - a feature completely independent of the dock.

What's interesting is that in the past, the Windows taskbar was mainly meant to accomplish the same task as Expose - switching windows. The quick launch area was the equivalent of the Dock.

Now those functions have been combined. So while the taskbar always had (via QL) the same app-launching capabilities as the Dock, and window switching capabilities with the same goal as Expose - it now combines them into one, clearer metaphor, with a prominent feature being the use of "muscle memory" since things never move around and always stay where you put them.

In my opinion, the comparison of Taskbar vs Dock isn't very interesting, as the Taskbar's app launching capabilities haven't changed all that much and the Dock was already a confusing mess of form-before-function.

The main improvement to app launching is the Jump List, which lets you bypass the application UI for common tasks or recently used / frequently used documents to get straight to your destination.

However, the taskbar has now taken on Expose by offering even more robust window switching capabilities, including the ability to handle window switching within MDI and TDI (tabbed) applications, something Expose does not yet support.

In Vista the disk rating measured only read and write throughput. However, the Windows performance team found that many hard drives with good throughput exhibited terrible latency with faced with random I/O. So the Windows 7 test will cap the result at 2.9 for drives with very poor latency, and 1.9 for drives that are especially bad. Basically if you hit those caps, your drive is likely causing noticeable hangs or reduced responsiveness.

Not really sure what you were getting at with the comment about installing versus copying a folder. I was just trying to explain that the code for copying items in the Explorer shell is actually very complicated (and needs to be, to support all the scenarios it's meant to). That doesn't mean it shouldn't be very fast and trouble free, but it does mean that sometimes there are bugs, especially in a beta!

Anyway, thanks for trying the beta and sharing your feedback :)

Copying is an incredibly complex system, actually. We aren't talking about a simple command-line file copy from one disk to another. We're talking about a copy engine in a shell that can handle arbitrary data sources all with varying capability levels, access restrictions, latencies, optimized move capabilities, and so on. Before copying can begin, you have to know if there's enough space at the destination, if the destination supports the kinds of files, levels of hierarchy, and file names that are provided by the source. You have to do access checks against both locations. In some cases an optimized copy or move isn't possible and data needs to be brought local to the machine and then pushed back out over the network. Sometimes temporary files need to be created. Merge conflicts need to be identified up front so that the user can be prompted before the operation begins, so that they don't walk away and have the operation stop in the middle because of a conflict. Many errors need to be queued up til the end so that the rest of the operation can proceed.

And that's just part of the complexity. The problem you hit may not have even been at all related to the copy engine. It could be a driver or configuration problem that made I/O perform slowly. There could have been a hang in Explorer, in a filter driver, in the file system, in the security manager (since we're dealing with ACLs), etc.

That's why it's a beta. When you get into this state and it says "Preparing to copy" for a long time, click the Send Feedback button! That's the best way to help us.

That said, Windows 7 has made many excellent improvements to copying, and more will come before it's done.

Windows Vista has NOT had an extremely short life, and most people haven't skipped it. It's already been out for more than two years. The gap between Vista and 7 is greater than the gap between Windows 2000 and XP OR between Windows Me and XP. Windows Me was replaced after one year!

In every other way it is not at all comparable to Windows Me. Windows Me was a dead end, the last of an era - it was in development for a fairly short time and tossed out early because XP was coming along much faster than expected. It was barely different than 98 SE (in fact, Windows Me's alternate name was 98 Third Edition).

Windows Vista on the other hand was a massive undertaking, a very long project (just like Windows 2000) with architectural changes that will be around for years and years to come.

Oh, and Wikipedia is wrong. Cairo wasn't NT 4, Cairo was going to be NT 5.

Hi, welcome to Slashdot. Your comments have been made and addressed many times over.

Windows 7 and Vista SP2 are absolutely, positively nothing alike. SP2 is a sustained engineering project, not even run or engineered by the Windows development team. It's a collection of bug fixes and security updates - service packs don't add new features. The Win7 Beta is the culmination of 2 years of development from well over a thousand engineers, many of whom are the best in the business. It includes some major changes that were *incredibly* difficult to architect and develop, and has seen several significant chunks overhauled or rewritten entirely. I should know, I'm one of the developers.

Windows 7, just like Vista, and just like Windows XP, has no DRM code that runs unless you put DRM'd media on the box and play it in a player that supports DRM.

This is Windows XP to Vista's Windows 2000, end of story.

Windows 2000 was more secure, more reliable, and was architecturally a major milestone for Windows. But it had some really troubled beta releases, and suffered many delays and resets (it had been codenamed Cairo and was supposed to include the Object Oriented File System, but most of that plan was scrapped about halfway through). It also broke a lot of compatibility, had heftier machine requirements, had major issues with games, had major issues with drivers thanks to the whole new driver model. Many of these cleared up over time (by service packs, maturing of the ecosystem, etc), but tons of people said they'd never upgrade from Windows 98, which was lighter and faster and better for games. But when XP came along, they upgraded.

Windows Vista was more secure, more reliable, and was architecturally a major milestone for Windows. But it had some really troubled beta releases, and suffered many delays and resets (it had been codenamed Longhorn and was supposed to include WinFS (Windows Future Storage), but most of that plan was scrapped about halfway through). It also broke a lot of compatibility, had heftier machine requirements, had major issues with games, had major issues with drivers thanks to the whole new driver model. Many of these cleared up over time (by service packs, maturing of the ecosystem, etc), but tons of people said they'd never upgrade from Windows 98, which was lighter and faster and better for games. But when Windows 7 comes along, they'll upgrade.