I'm no Microsoft advocate, but in this case I'd say that the problem isn't in the OS, but in the utilities. If something is technically supported, but used in the wrong manner, I wouldn't say that it doesn't really work. As PodMaster correctly points out, an application invoking the shell should quote its arguments to get them understood well; so, it's possible to use the feature without breaking anything.

This doesn't happen for ActiveState Perl, in which case the warning message should read "We have more interesting things to do other than fixing that spaces-in-paths issue in all stuff, so don't put spaces in your installation paths and you'll live happy".

I'm no MS advocate either, but I don't really buy the argument that this is not in the OS.

First off, spaces in paths have been available for years. I remember using them on DOS 5 and OS/2 2.1. Unix/Linux has always had the ability to put spaces in the path as well. So Windows isn't doing anything new here. What is new here is the advocacy to use spaces.

I look at this as I would any other design that will inherently cause users (in the case of an OS, this includes not just end-users, but developers on that OS) problems. Funny thing is, they could have avoided this by officially endorsing spaces, but using a directory such as C:\Programs instead of C:\Program Files as the directory for default installations. 99% of the problems with spaces would have gone away. Instead, they consciously chose to break everyone in order to enforce their idea that spaces should be allowed. What this means in practical use is that CMD.EXE is deprecated, as is any other non-GUI method of launching applications.

It's a design decision by MS that causes this pain. It means everyone else, especially those writing batch files, needs to change their code. It breaks backwards compatability, which I believe they did on purpose. And thus I'd say the problem is in the OS.

Unfortunately, it is what it is, and everyone who develops for Windows now (well, for the last 10 years now) must eat the cost of the switch. The market (generally) demands it.

I know that, at work, we were still eating the cost of conversion in 1998. And even today, there is a small overhead of having to constantly make sure we quote everything properly in our batch files. What a headache. Our build tools explicitly say "no spaces in their paths" for building. What we ship to end-users must support spaces, but it's too expensive for us to support the spaces internally. Yet another Microsoft-tax - this time on development.

Update: Some may wonder what a rant (yes, a rant ;->) on MS is doing here. It's not. It's a rant on design issues, and how they permeate to everyone that relies on your code and design. Care needs to always be taken that you break your users only when there is no other way to get them the behaviour desired, and I think that simply changing the default location for new software just a tiny bit would have reduced that break measurably. I have no issues with spaces in filenames per se (as I said, I've been doing this for years prior to Win95's arrival). Just the design of how to implement it.

(The funny thing is that I'm known among my colleagues for being Linux-biased and quite adverse to MS).

Sincerely, I'd not consider the fact that the default installation directory has a space a flaw in the OS. Maybe my point of view is biased by the fact that there are *lots* of flaws in that OS IMHO, and this forces me to consider this a non-flaw.

Moreover, I'm not a Win32 developer, but I don't see the difference between Win32 and Unix for this particular issue. In my understanding, you have to escape/quote stuff with spaces in both worlds.

I agree, the "Program Files" choice was particularly ill-minded, forcing you to take into account paths with spaces all the time (on the contrary, "/usr" or "/usr/local" are more developer-friendly). OTOH, I generally always take into consideration that there may be spaces in all shell variables I use in Linux, paths included, and I tax myself with extra quoting just to remain on the safe side. I'd do it in a batch file as well, without considering this an MS-related tax.

To conclude, in at least one field things work better here in Italy: our default installation directory is "C:\Programmi" :)

Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))')

Don't fool yourself.

Well, error messages that literally say "latest versions" irk me. I have no way to judge what that means. Is it Windows ME, which I don't have to worry about, or Windows 2000, which is old, or Windows XP, which I have now? It's the same annoyance I have with technical support web pages that don't have dates. How do I judge the information if I don't know how fresh it is?

But, just because I think the message is vague doesn't mean I don't understand the problem. Other people, however, may not.