|
Summary: Windows doesn't fix all bugs on each release. We'll look at some of the reasons Windows might not fix something you consider to be an important bug.
This is a common question. Not specifically about file size display notation, but rather the more general question "why didn't Microsoft fix this" where "this" is a person's personal pet peeve or perhaps a system bug. Asking "why?" is in many cases simply an exercise in frustration. Rarely will you get a clear answer. But I can absolutely theorize many very legitimate reasons for not addressing something like this. And no, "lazy" or "second rate" aren't on the list. • Most people fail to understand just how incredibly complex an operating system like Windows has become. Consider how much it has to do, on a vastly differing variety of hardware and hardware combinations, how customizable the operating system itself is, how many different languages (and behaviors) that it must accommodate, and how little control Microsoft actually has on the various drivers and applications that run on it. Some days it seems that it's amazing that it works at all. (And yeah, yeah, this is where the anti-Windows crowd screams in unison: "It Doesn't!"). So, making any change to it, no matter how small, can have dramatic repercussions that aren't at all obvious to most of us. So, using the file size display format in Windows Explorer simply as an example, here are some reasons I can theorize why it hasn't been changed per the original question (Important I'm using that only as an example. These same reasons may well apply to any random feature/bug that you think should have been fixed or changed but hasn't been): "With each release, with each update an even with each
patch, Microsoft is making a combination of technical, user and business
related decisions."
Remember that I'm just guessing here, but for this specific feature, the fact that the functionality is actually available in the tool tip makes me believe that there's probably a compatibility issue preventing it from being implemented in the size column. Much of the implementation work and testing matrix may well have been addressed by the tooltip. The compatibility issue need not be a huge one, since as I mentioned above, the fact that the data's available in the tool tip would lower, somewhat, the priority of making it available in the actual size column. That is all total guesswork on my part based on being a software engineer who happened to have worked there for many years. I could be totally wrong. Now, the logical next question to ask is "OK, if they didn't fix my issue, why did they fix, change and break all the things they did? Surely that was more work and broke more things than my little issue would have?" And that is a very valid question. Unfortunately the answer is going to be about as vague and speculative as the reasons for not fixing or implementing something. A lot of research and effort goes into deciding what features "make the cut" when a new version of Windows is produced. And arguing, don't forget lots of arguing as well. Most of the "big" new features and changes are part of a larger theme. Vista's UI revamp is a good example. Microsoft spends a lot of time and effort designing and evaluating UI changes to make sure that they work for people. You might feel that they fail in that regard, or you might simply not agree with the theme, but that's generally what's happening: a few major themes are selected and hundreds if not thousands of changes result. Smaller items are likely more haphazard. Product support representatives, designers, test engineers and software engineers all have a say in what goes in, and they all have differing opinions - just as you do - about what is and is not important to the next version. And of course as deadlines loom and the product needs to ship, some of those previously agreed upon features and fixes get tossed anyway. Often cuts are made with the consideration that "we'll get to it next version", but the pragmatic reality is often simply that when the next version comes around one argument is that "if it's wasn't important enough for that version, then perhaps we don't need to address it all and focus on more important things." • I'm totally convinced that for people who are passionate about one feature or another, or for the folks that are anti-Windows and anti-Microsoft, what I've presented is a totally insufficient answer. I don't think there is a clear, complete or sufficient answer. With each release, with each update and even with each patch, Microsoft is making a combination of technical, user and business related decisions. How those all combine into specific features and product changes is much like making sausage: you probably don't really want to know. One thing I can assure you of is that "lazy" has nothing to do with it. Related:
Article 12337 | Posted April 9, 2008 |
Stay Informed Archives Advertisers |
|
•
As to why Explorer doesn't show folder size, I quote Raymond Chen of The Old New Thing:
"[Explorer doesn't recursively show folder size as an optional column for] the same reason \\ does not autocomplete to all the computers on the network (see http://blogs.msdn.com/oldnewthing/archive/2005/01/11/350628.aspx): Because it would destroy corporate networks.
Showing folder sizes "all the time" means that when you open, say, the root of a large server, Explorer would start running around recursively enumerating every single directory on the server in order to compute the folder sizes. One person doing this to a server is bad enough. Imagine if hundreds of people did it simultaneously: The server would be hammered continously.
Even worse: imagine doing this across a limited-bandwidth link like a VPN or an overseas link. The link would be saturated with file enumerations and wouldn't have any bandwidth remaining for "real work". Even the change-notifications that Explorer registers are cause for much hair-pulling on corporate networks. (See http://support.microsoft.com/?kbid=330929 -- and these are change-notifications, which are passive.)
Even on a home computer, computing folder sizes automatically is is still not a good idea. How would you like it if opening a folder caused Explorer to start churning your disk computing all the folder sizes recursively? (Then again, maybe you don't mind, in which case, go nuts: http://blogs.msdn.com/noahc/archive/2007/02/26/folder-size-for-windows-explorer.aspx)
Of course, the question sidesteps the question the linked article -- http://blogs.msdn.com/oldnewthing/archive/2004/12/28/336219.aspx#345978 -- tries to address, namely, "What do you mean by the size of a directory anyway?" "
Source: http://blogs.msdn.com/oldnewthing/archive/2007/10/29/5750353.aspx
Posted by: Simon at April 10, 2008 09:22 AMThen there are people like me who want the exact opposite of what you give as an example. I want to know the exact byte size of a file, and "127KB" isn't accurate enough, and "2.3GB" even less so. (For example, someone uses ftp to copy a file between Windows and Unix, and I need them to verify that they used binary mode and the file size didn't change.) Yes, I can have them right-click and select "properties", or drop to a command prompt, but "why should I have to?"
On a side note, explorer isn't consistent in displaying file sizes. For example, I have a document that is 30,807 bytes in size. Explorer shows "31KB" in the listing, "30KB" if you hover over the filename, and "30.0K" if you select "properties".
Posted by: Ken B at April 10, 2008 12:01 PMI am a compulsive feedback giver - I don't feel I can grumble unless I have given people the opportunity to rectify matters. I have never managed to give Microsoft any feedback. Only people who pay for additional support appear able to speak to them.
Posted by: Natalie Kehr at April 12, 2008 12:19 AMWhat's the big deal? If you hover over a folder Vista gives you the approximate size, if you right click/ properties the folder you get it to the last byte.
Posted by: Peter M at April 15, 2008 03:50 PM