Aargh. ^W != delete word. Arse.

>>>>You only need to look at the utter mess that is their date and time handling, filesystem semantics, and (process) scheduling policies to realise this.<<

Not to disagree, but could I get you to elaborate a little on each of these with some of your specific complaints?
<<

No problem.

Date and time: Date and time handling is a complex and difficult thing to do, and many people have spent a lot of effort in trying to do it properly. Sadly, it appears none of them work for Microsoft. They have several problems.

Good practice dictates that dates and times should be manipulated and stored in a representation based on a datum. The world has chosen UTC to be that datum, so you'll find most systems which need to handle dates and times will convert user input into UTC, store and manipulate it in UTC, and convert it back to the local timezone when a user needs to see it. This solves a lot of problems.

Firstly, the system clock. They use a local timezone in the system clock -- with no way of enforcing UTC, which is why Linux gives you the option -- and that causes them issues. The classic example was one of the Windows 95 releases would, if left on overnight during the autumn DST change, triumphantly say it'd set the clock back, then an hour later would set the clock back, and an hour later would...

Secondly, Outlook and Exchange cannot handle timezones properly. Scheduling meetings in one timezone to be handled in another, then setting the system clock to that timezone when actually out there, mangles all the meeting times. This isn't an easy thing to get right, but they get it fantastically wrong. The text portion of the Outlook meeting emails even says 'GMT; London ...' year-round here, when it's summertime and should be BST (UTC+1).


Filesystem semantics: I've already mentioned filesystem semantics here before, fairly recently, but here's a brief recap of some of the issues.

Firstly, it's impossible to do an atomic replacement of a file. There's always a window of time where the object doesn't exist in the filesystem. Most of the time this isn't a problem, but when serving a busy website (such as http://www.bbc.co.uk/ which I worked on for rather a while), you'd be surprised at how little time there has to be before you're serving a 404 to someone. That looks poor.

Secondly, I'm lead to believe that you need to open a file to delete it, and the file isn't actually removed from the filesystem until the last handle on it is closed. That also leads to some interesting problems to be worked around at the application layer. If you have a large file that you're serving to someone at the wrong end of a modem, AIUI it's not possible to move it out of the way and replace it with a more modern version without some help at the application layer. This just complicates matters more than it should for a properly-functioning OS.

Thirdly, streams. Streams are actually quite a good idea. The principle is sound: each file in the filesystem has a primary stream, and a collection of metadata streams referenced by name (IIRC 'filename#streamname', but don't quote me on that). The problem here is that (until recently?) it's been impossible to enumerate the streams associated with an object, and this provides an ideal place for malware to hide itself. You can happily specify a path in the registry (and I'm not going to start on *that* pile of shit) which references it, but as nothing else knows about it, nothing knows to scan it. It's all quite marvellously broken.

The filesystem layout, with its multitude of spaces is a subtly different problem, but it's still broken. The shell has to decide, for an unquoted path, whether you meant 'c:\program.exe files\path\somewhere' or '"c:\program files\path\somewhere"', and it'll speculatively run the first one first. Most versions of Windows have suffered some reasonably amusing security holes in the default installation by allowing users to write to the root directory, add a 'program.exe' that's then called on boot in a variety of system (LocalSystem and Administrator) contexts, for example.


Lastly, scheduling policies: Microsoft's schedular is pretty broken. When you minimise a process to the task bar, the process is largely swapped out on the specious understanding that you don't need it any longer. If it sits there doing something backgroundy (as a lot do), it'll be paged straight back in again. This consumes resources needlessly, and as users have a tendency to minimise and maximise frequently (as a consequence of the UI forcing the window with the focus to the top), this is counterproductive. My understanding is that Vista has changed this behaviour, but as the only exposure to that has been going 'ugh' at laptops in my local branch of Curry's, I can't really comment.

The other classic example is from Vista: the networking slows to a crawl when the system plays any sound (including Windows' highly irritating bongs and beeps) for some bizarre reason I forget. Quality server OS, that...


In summary, Windows' architectural flaws, coupled with its huge array of bugs (often as a result of the braindead programming practices used when creating it; I mean, really, who in their right mind uses 'void *' to pass around different objects to and from the system? Hello? Type checking? Gods...) lead me to label it fundamentally broken, and impossible to salvage. I'm actually quite impressed that Microsoft have managed to get it as far as they have, and I suspect the only reason they didn't throw in the towl a la Apple and rebase it on a rock-solid kernel is their NIH bloodymindedness. The whole edifice reminds me of the Syrius Cybernetics Corporation, complete with their helpful customer services department.

Hrm. Rather a longer rant than I intended.

Hope this helps.