Comment On The Core Launcher

systemdrive:

hardcodes root drives as "C:" into their programs

"But it works on my computer!"

Other people don't have your computer.

Evan:

Ralph:

This whole story just reeks of layer upon layer of WTF.

For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

I_know._I_hate_spaces,_which_is_why_I_never_use_them._Interesting_that_you_do,_though._Clearly_you_haven't_seen_the_light_in_its_full_glory_yet.

OK, less sarcastically, I don't get that position. Pretty much at all. Yes, spaces makes some things less convenient, but it makes lots of other things more convenient, especially in the GUI world, where there's essentially zero problems because of spaces. Even in the command line and scripting world, it's usually only a somewhat mild inconvenience because now you have to type a few more quotes or escapes.

But computers are here for humans to use. We use spaces, very reasonably. Why should I have to call a file "01_In_The_Flesh"? It's called "In The Flesh"! Computers should be programmed to match our thinking as best as possible, not the other way around. "You shouldn't be able to use spaces in file names" is, IMO, almost the quintessential example of the exact wrong way to think.

Also, you have some chronology messed up. But whatever. And none of this is really intended to justify the Windows behavior of just trying different breaks between commands and arguments, though I do suspect their hand may have been forced a little because of backwards compatibility problems.

You have a point, but you take it too far. Computers aren't capable of thinking like humans. At least not yet. Therefore, as a human using a computer, sometimes you have to think like it would.

Sure, spaces make sense in filenames because you might use them. What about unicode chatacters? What about slashes? Dashes? Periods? Sure, they make sense in some cases... but where do you draw the line? Eventually the computer will need a deterministic way of parsing a path.

Shinobu:

Simple. Since MacOS traditionally used : as a path separator, but the new Unix like kernel that underlies OS X uses /, path names have to be translated. Swapping : and / is a simple solution that makes sure : gets correctly interpreted as a path separator, while still allowing / in names like in the old days.

That's what was my initial thought as well, but it doesn't make sense — it would mean any filename with a slash in it would break the path if you try to access it from an OS 9 application, wouldn't it? (Which would have been common ten years ago when OS X was new and not too stable yet.)

Gurth:

(Which would have been common ten years ago when OS X was new and not too stable yet.)

Wait a minute? I thought Mac machines were always the paragon of stability and thats why people used them, not because people thought themselves to elite for Winboxes?
This has to be troll food.

Flash:

Thanks for spelling "poring" correctly.

But it's "allow its communications," not "allow it’s communications."

Yep. Out of all of the stuff in this WTF, what annoyed me the most was the author saying "...would allow it’s communications to pass through the firewall"

It SO breaks up the flow of reading the text to come across a typo like this.

¯\(°_o)/¯ I DUNNO LOL:

Gurth:

I have a bit of a hard time thinking of a situation in which you would want to install to "/Volumes/Macintosh HD/whatever" instead of to /whatever, since "/Volumes/Macintosh HD" is a symlink to / — though that probably doesn't mean nobody ever used it in a program …

Did you know that people with Macs actually use external hard drives (gasp!)

They do? No! That finally explains what those two boxes on my desk are, that sit there being connected to this iMac's FireWire ports …

¯\(°_o)/¯ I DUNNO LOL:

so it's not uncommon to mount a bootable volume... which is likely to have a space in the volume name.

Which would nicely be taken care of by the OS. The original post referred to install scripts, which — if they have hardcoded paths — probably wouldn't try to use /Volumes/Macintosh HD/ but /.

KattMan:

Wait a minute? I thought Mac machines were always the paragon of stability and thats why people used them, not because people thought themselves to elite for Winboxes?

I can't speak for anyone else, but I bought mine because I got tired of all the maintenance work (read: upgrading libs) I had to do on my Linux box in order to be able to install just about any new software on it. OS X 10.0 and 10.1 had several problems that meant that apparently hardly anybody used them all the time, switching to the OS 9 that came with it when they needed to. 10.2 is usually called the first one that you could actually use all the time.

KattMan:

This has to be troll food.

Are you sure your post isn't? ;)

Gurth:

any filename with a slash in it would break the path if you try to access it from an OS 9 application, wouldn't it?

No it won't. A file name with a / in it will be stored with a : instead, as I explained. Since no application manipulates the file system directly, if it wants the file name it has to ask the system, which performs the swap, making sure that the application sees the / like intended.

Gurth:

KattMan:

This has to be troll food.

Are you sure your post isn't? ;)

When I said "This", how do you know I wasn't self referencing?

Paul:

deckard:

I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP...

You're clearly a "glass half full" kind of person, for which I commend you.

I can very well believe that a released version of Windows had brain-dead behavior as a default.

But this isn't brain dead behaviour. This behaviour would have to intentionally be written in this terrible method. I also do not believe that it existed ever.

Shinobu:

Gurth:

any filename with a slash in it would break the path if you try to access it from an OS 9 application, wouldn't it?

No it won't. A file name with a / in it will be stored with a : instead, as I explained. Since no application manipulates the file system directly, if it wants the file name it has to ask the system, which performs the swap, making sure that the application sees the / like intended.

Actually, it's the other way around. At least when storing to HFS+ disks, the native path separator even for Mac OS X is the colon. If you access files through most of the high-level APIs, particularly Carbon (the Mac OS 9 compatible API), then forward-slash is allowed in files, colon is disallowed, and colon is the path separator.

However, if you access files through the BSD APIs, forward-slash is the path separator. So, there is an automatic translation from forward-slash to colon and vice versa. Thus, creating a file "a:b" through a BSD API will result in a file "a/b" on disk. An existing file "c/d" on disk will appear through a BSD API (e.g., ls) as "c:d". So then forward-slash is a disallowed character in filenames but colon is allowed. So in the end you have compatibility with both Mac OS 9 and with BSD.

HFS+ technically permits any characters in filenames, colon is just barred by the OS. Any other characters will work, depending on the API. Some weird characters are unlikely to work unless you're particularly careful. For example, Mac OS X stores some internal data in a directory whose name starts with four null characters, virtually guaranteeing that it is a pain to access. (In order to render it in a C string, they use a UTF-8 encoding for a null that is technically invalid but conveniently contains no nulls.)

Ralph:

Evan:

If ", \, |, and / characters were anywhere near as common as spaces, then yes, I'd say that a system that prevented you from using those is dumb.

So now we're determining our design principles based on a popularity vote?

Um, yes. Personally, I take that as pretty axiomatic... if you have two possibilities for a choice and they are roughly equal, and choice A satisfies 10 people and choice B satisfies 90, then choice B is almost certainly the correct one.

Evan:

(And I'd actually even say I'd prefer to see Windows allow at least " and | in names. \ and / are probably no good because of their use in directory separators

and spaces are used as keyword separators in the CLI, which every major OS including Windows has had for a very very long time, in most cases before the GUI. And before that, spaces were used as word separators for umm let me see know what maybe 10 thousand years? So you'll concede a directory delimiter -- very much an outgrowth of technology -- but not a word delimiter -- invented by those precious untrained humans to which all software design must bow?

No, I would say you're explaining it wrong.

I would say there are three separate separators. The first separates path components. The second separates arguments in a CLI. The third separates "words" within an argument. The first two, not just the first one, are basically new to technology. (The closest analogy to the second which I can think of off the top of my head is the separation of function arguments in math, which is traditionally done with the comma.)

All three of those separators "must" exist regardless of what file system choices you make, unless you want echo "Hello world" to not work. Thus if you decide that the character 0x20 should act as a separator for both arguments and words within an argument (the latter is definitely reasonable, unless you want something like echo "Hello_world" to actually output Hello world), we already need and have a means for distinguishing the two.

And because we already invented escaping, there's no fundamentally new problem that is introduced by having spaces in file names. The biggest problem now is that tools have to realize that spaces can't be used to separate file names. But the fact that they don't always do is just a matter of lazy coding IMO rather than "this is a hard problem to solve."

AN AWESOME CODER:

You have a point, but you take it too far. Computers aren't capable of thinking like humans. At least not yet. Therefore, as a human using a computer, sometimes you have to think like it would.

Absolutely, which is why I qualified my statement with "as best as possible." And dealing with odd characters in file names is not something that is hard. (Or rather, it's something that, when it is hard, is sort of "artificially" hard because other people made bad decisions.)

Sure, spaces make sense in filenames because you might use them. What about unicode chatacters? What about slashes? Dashes? Periods? Sure, they make sense in some cases... but where do you draw the line? Eventually the computer will need a deterministic way of parsing a path.

Yes, I agree it needs a deterministic way of parsing a path. But the only thing you need for that is one single path separator, plus perhaps an end-of-string terminator. POSIX gets away just fine saying that any character is allowed in a file name except for / and NUL. And you don't even need to exclude those if you use an different representation, e.g. ["a", "b", "c"] instead of "a/b/c".

That does push the problem up the stack a little bit, but it's just a matter of escaping. And fortunately, we know how to do that.

I mean, flip things around. Spaces aren't the only character that causes problems; as pointed out earlier, hyphens can too. Should we exclude those as well?

Gurth:

I got tired of all the maintenance work (read: upgrading libs) I had to do on my Linux box in order to be able to install just about any new software on it.

Troll, astroturfer, or drooling old-timer. I haven't had to bother with upgrading a single library since I switched to Debian Linux back in 2006. The packaging system handles it all automatically. Not just for the OS (like Windows Updates) but for all your installed apps as well. And yes there are tens of thousands to choose from, and I've installed a lot of them, all without ever fighting version dependencies or recompiling my kernel (did you forget to trot out that old one?)

Even before that, Red Hat Linux was doing a halfway decent job of package management, but only halfway.

GROMMP:

He may as well have written PORMMG or something. I picked up on that too, although everyone did know what he really meant :)

After some French TV show pronounced MMORPG as "meuporg", a meme has been born. http://www.youtube.com/watch?v=MwiCLnlJeco

Evan:

Ralph:

Evan:

If ", \, |, and / characters were anywhere near as common as spaces, then yes, I'd say that a system that prevented you from using those is dumb.

So now we're determining our design principles based on a popularity vote?

Um, yes. Personally, I take that as pretty axiomatic... if you have two possibilities for a choice and they are roughly equal, and choice A satisfies 10 people and choice B satisfies 90, then choice B is almost certainly the correct one.

OK, I was vague, and you took advantage of my vagueness to change the argument. At first you said (paraphrasing) "we should support the top X% of common characters and not the rest". Which means you would design a language syntax based on what characters were most popular, not on what made for an unambiguously parsable statement. Which leaves us debating where to set "X". 85%? 90%? This design mentality is heading down the path toward a system that usually works for most people most of the time, but can never be fully reliable for everyone always. A perfect synopsis of how most MS products work, no?

But then you turned it to (paraphrasing) "we should support the top X% of people". Different design criteria. But let's suppose that is "axiomatic" as you claim. Most people, when they have some data to capture and organize, create a spreadsheet. Never mind that a bunch of computer scientists came up with formal rules for optimal data accuracy decades ago, have been improving on it ever since, and there are carefully crafted databases (engines and schemas) implementing this designed-for-reliability-and-performance architecture. You'd toss it all, because it doesn't win the popular vote?

There are well thought out good ways to design and build good systems. There are also sloppy hackarounds. The masses are not qualified to tell the difference. You should be, if you're in this business. Stop using popularity to determine what is right.

Ralph:

OK, I was vague, and you took advantage of my vagueness to change the argument. At first you said (paraphrasing) "we should support the top X% of common characters and not the rest". Which means you would design a language syntax based on what characters were most popular, not on what made for an unambiguously parsable statement.

Look, I'm not saying you should forgo deterministic parsability or anything like that. There are some times when one design choice is just wrong, e.g. if it leads to too great of a security risk. But there's nothing about spaces in file names that leads to that. Let me try again.

There are two places where characters need to be interpreted; in Unix, different decisions are made at each place, and neither one restricts the choice of spaces.

At the level of the kernel (you can substitute other APIs here as well), the choice was made to (1) not allow escapes and (2) always use / as a directory separator. As a consequence, it is not possible to use / in file names. However, spaces at this level cause absolutely zero problems; the only special character is / (and NUL for the terminator).

Two more points about this level. First, theoretically it would have been possible to use spaces as a directory separator. But that's not your argument, nor is it a good idea (at least I'd argue). A large part of that has to do with the frequency of characters. You could use A as a directory separator. Why's this a terrible idea? Because A is a common character that you'd actually want to be able to use in file names! Sure, you could always write _ for A, but that'd become a PITA. IMO, spaces in file names are similar, though obviously less extreme. Character frequency shouldn't be the only design factor (you also want something that is evocative of a separator), but it certainly should be one. (And to tie this into my last comment, this is because choosing a frequent character, like A, will annoy too many of your users.)

Second, the Unix way is not the only way. You could modify either of its assumptions and either provide some way for / to be escaped or a different API entirely (["a", "b", "c"]). Such an API would enable the use of / in file names. If you change to counted strings (I'll call them "God's strings" because this thread doesn't have enough dispute in it yet :-)) then you could also allow NUL and thus any character in your file names.

(I think any of these choices is somewhat reasonable; if I were to make an OS, I'd probably go with the ["a", "b", "c"] API. Perhaps with a wrapper that uses / but allows escapes.)

The second level that has to interpret characters is the shell. CLIs are the main locus of problems; GUIs are almost problem-free in comparison. But shells also have no fundamental problem with spaces, because you can escape any character in the shell.

The only real problems with spaces are because of what I consider poor decisions (granted from the standpoint of spaces should be allowed) and lazy coding. But there are almost no actually hard problems to solve, it just requires conscious thought and a recognition that there are "obnoxious" file names. (E.g. -print0 can't have been hard to add to find, nor -0 to xargs. Though how I really feel about that is in part a whole other discussion -- basically I think the Unix utilities are pretty fundamentally flawed and don't work nearly as well together in pipelines as Unix proponents like to think they do.)

But it's not even a question in my mind that it's worth paying attention to such file names, even if you were to design a system from scratch. The usability benefits of allowing spaces and other funky characters far outweigh the inconveniences they allow.

[quote user="deckard"][quote user="Andrew"][quote user="deckard"]
CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes.
[/quote]

Then why does cmd.exe empirically not work this way?[/quote]
Because CMD validates the user input first. It only assumes the user wants to launch a new process if the user enters a valid string. CreateProcess doesn't return the error message that CMD does on entering an invalid path, for example.

Windows XP, Vista, 7, and 8 all do this. Just look at your startup items in the registry and startmenu->programs->startup. Many programs have the stupid mistake of setting their startup entries to not have quotes on the path. So you have C:\Program Files\McJaffa Scan Naow\Scanner.exe, but sometime later the user installs McJaffa Suite which installs in C:\Program Files\McJaffa\Suite\av.exe Suddenly the startup entry that was launching the Scan Naow app is opening the C:\Program Files\McJaffa folder at every start!

I always wondered why/how this line in an AutoHotKey script actually worked:

Run, C:\Games\DCS A-10C\bin\dcs.exe --net-mode gui, C:\Games\DCS A-10C

Yes, the "--net-mode gui" part is a parameter to dcs.exe.

I guess now I know! Lots of the program's instructions are basically just wrappers around Windows API calls.

Anon:

L.:

And besides, defending IE6 or corporate policies on tdwtf. nice troll.

One of my favorite troll tactics is the "call the other guy a troll" one. Bravo.

Thank you, sir.

Ralph:

uns:

I thought the Windows-vs-Linux flamewars died out like 10 years ago.

The war against MS will die the day MS dies.

For you backwards compatibility apologists "yeah we have to support turds today because we implemented a turd 25 years ago" perhaps the mistake was the original turd? Maybe? I'm not arguing against backwards compatibility. I'm suggesting a company that can't see a turd in its own hands doesn't deserve to be in this business.

"Oh yeah it had problems long ago but the most recent version fixed all that." -- MS fanboi, 1983, 1984, 1985... 2012...

"Other people do it too (wahhh)" yeah maybe, but it is still a turd.

"If we didn't sell turds someone else would" OK then I'd be opposed to the "someone else" wouldn't I? It's still a turd.

All turds indeed, but I'm not sure Redmond is hell bent on making crap, I believe the substantial improvements with XP and 7 are proof that some things can push them towards better solutions - even if it remains microsoft-y.

That way I believe the linux vs Windows war may end, when Redmond will create a linux based windows compatible monster at some point - or when they make a windows that's globally as fine as a linux, including GUI.

What's way more interesting nowadays is flaming osX anyway, it's so much worse than windows and linux both - fail security, no fucking maximize button on windows and other retarded crap... I think microsoft have found a competitor.

systemdrive:

every software development company that hardcodes root drives as "C:" into their programs should be shut down immediately and the responsible programmers should be burnt on a heap of "coding for beginners" books.

we don't have C: drives in our machines, and especially not in our terminal servers, and constantly experience e.g. drviver installers crash on that.
it's unbelievable how many companies don't seem to know about environment variables, even in 2012!!!

Well that'll teach you to use a user OS for server purposes.

Seriously, if you're going to use windows, you could also respect its windowsness instead of trying to play it leet without c drive -- while using the noobest OS of all .

blueg3:

Actually, it's the other way around.

No actually. Carbon is implemented in terms of the BSD like API. Carbon swaps : and / in all paths that are exchanged between Carbon applications and the kernel.
If the file system used is HFS+ then file system driver will cut the path up at the /s and the individual parts are stored as a 16 bits length value followed by that many 16 bits values indicating the Unicode code points.
HFS+ doesn't use a path separator and any Unicode code point can occur in a file name, although if you use a disk editor to insert some of them you may run into operating system and application issues.

Fred:

Gurth:

I got tired of all the maintenance work (read: upgrading libs) I had to do on my Linux box in order to be able to install just about any new software on it.

Troll, astroturfer, or drooling old-timer.

Probably option No. 3 :) I used to use SuSE 7 and 8 …

Draxom:

I took a stab in the dark and guessed the game was EverQuest. Of the MMOs around in the 90s it was either EverQuest or Final Fantasy XI, and EverQuest was far more popular. I ran a quick google search and came up with a slew of results.

http://forums.techguy.org/games/477150-solved-everquest-taking-over-my.html

so myth confirmed....

Final Fantasy XI didn't launch until the 2000s, for what it's worth. It couldn't have, for Final Fantasy X wasn't out until 2001 itself. :)

VictorSierraGolf:

deckard:

And it will try to execute “C:\Program” as a file, passing it “Files\id Software\Doom\Doom.exe -nomusic” as argument to that executable. Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument. It would continue this way until a program existed and started, or until the path was depleted and no program was to be found.

Was there ever really a version of Windows that worked this way? I know for a fact that XP doesn't. If you give it a path without quotes it will take everything up to the first space as the command, and everything afterwards as arguments. If that command doesn't exist, it gives up and spits an error. I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP...

Agreed. I've never complained about a story here, but this ones reeks of bullsh-!

Also, I tried this and, whoa, nothing wrong happened!
And now I'm feeling stupid for even consdering that MS could be THAT stupid...

This doesn't make the story bull. It doesn't matter whether Windows was going to give up after the first try, or try again with the first space as part of the command, because just the first try (C:\Program "Files\etc") would cause the error described.

K:

This doesn't make the story bull. It doesn't matter whether Windows was going to give up after the first try, or try again with the first space as part of the command, because just the first try (C:\Program "Files\etc") would cause the error described.

Except that the story specifically states that the behaviour applied to shortcuts, which it can't since shortcuts store the path and the arguments separately. Read my comment on page 3 and it's obvious most of the article must be fiction.

And it will try to execute “C:\Program” as a file, passing it “Files\id Software\Doom\Doom.exe -nomusic” as argument to that executable. Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument. It would continue this way until a program existed and started, or until the path was depleted and no program was to be found.

Windows actually does that? That's a WTF right there...

FF Guy:

Final Fantasy XI didn't launch until the 2000s, for what it's worth. It couldn't have, for Final Fantasy X wasn't out until 2001 itself. :)

Well, Star Wars Episode V is from 1980 but Episode 2 didn't come out until 2002, so it'd be possible for XI to precede X.

IT WORKS even in Windows 7. When you try to REMOVE quotes when editing a shortcut, Windows 7 adds them BACK (if the executable exists, I presume). So using normal "properties" dialog you cannot remove quotes from around the path.

BUT when you paste the command directly to CMD.exe, in my case
C:\Program Files (x86)\LuaEdit 2010\LuaEdit.ext

It LAUNCHES C:\Program.exe.

Linux allows them, however Linux distributions don't come pre-configured with key system paths that have spaces littered in them.

failed:

But when you paste the command directly to cmd.exe, in my case
C:\Program Files (x86)\LuaEdit 2010\LuaEdit.ext
It launches C:\Program.exe.

But if C:\Program.exe doesn't exist you get the following message:
‘C:\Program isn't recognised as an internal or external command, program or batch file.’
And it's been that way since Windows 95 although back then the message displayed was ‘Bad command or file name’.

Anon:

When I read this story I thought it's bullshit. But not because of Windows behavior, but because of antivirus's. Could you imagine any antivirus putting a quarantined file IN ROOT FOLDER? Only a deliberately insane person does that.

I wish, with all my heart, that I could forget enough of my past to find it hard to believe that an antivirus would be this stupid.

(Sadly, I can still remember the year when system-wrecking side-effects of installing or uninstalling Norton accounted for over 30% of all failures I was asked to troubleshoot. Yes, seriously.)

Im pretty sure this is about eve online and NOD32, see thread:

https://forums.eveonline.com/default.aspx?g=posts&t=80365

vansante:

I'm pretty sure this is about Eve Online and NOD32, see thread:

The claim has been made before in this thread, but if you're right then the article is mostly bullshit.

/ and \ are file separators, not path separators.

: and ; are path separators.

That is all.

It's that piece of krap AVG of course.

AN AWESOME CODER:

Sure, spaces make sense in filenames because you might use them. What about unicode chatacters? What about slashes? Dashes? Periods? Sure, they make sense in some cases... but where do you draw the line? Eventually the computer will need a deterministic way of parsing a path.

The idea that paths are strings has IMHO been braindead since it was first thought of. Paths are ordered lists of path elements. How you interface the data structure to the human is a separate matter. You don't need to elevate printable characters to a special status, you know. It's not like in the old days it was hard to produce control bytes on a terminal...

Kuba:

The idea that paths are strings has IMHO been braindead since it was first thought of.

I wholeheartedly agree, and so do many file system designers, which is one of the reasons file systems commonly don't store delimiters.
The idea of path delimiters stems from the console shell world, where paths needed to be (expressable as) strings. And from there it subsequently infected GUI land which evolved from and built on previous console technology.

No BS. The behaviour described still works in Windows Server 2008R2 64-bit...

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\richard.breese>d:

D:\>dir "a bc"
Volume in drive D is Code
Volume Serial Number is AC48-6518

Directory of D:\a bc

24/04/2012 11:58 <DIR> .
24/04/2012 11:58 <DIR> ..
24/04/2012 11:58 16 C.exe
1 File(s) 16 bytes
2 Dir(s) 503,563,747,328 bytes free

D:\>a bc\c.exe
This version of D:\A.exe is not compatible with the version of Windows you're ru
nning. Check your computer's system information to see whether you need a x86 (3
2-bit) or x64 (64-bit) version of the program, and then contact the software pub
lisher.

D:\>
D:\>"a bc\c.exe"
This version of D:\a bc\C.exe is not compatible with the version of Windows you'
re running. Check your computer's system information to see whether you need a x
86 (32-bit) or x64 (64-bit) version of the program, and then contact the softwar
e publisher.

D:\>

anon:

D:\>a bc\c.exe

It has been noted several times already that when a.exe is missing the system won't try to run c.exe, but instead will complain that a.exe is missing.
At least read the comments before posting.

Shinobu:

Kuba:

The idea that paths are strings has IMHO been braindead since it was first thought of.

I wholeheartedly agree, and so do many file system designers, which is one of the reasons file systems commonly don't store delimiters.
The idea of path delimiters stems from the console shell world, where paths needed to be (expressable as) strings. And from there it subsequently infected GUI land which evolved from and built on previous console technology.

The first sentence is correct; the second is not.

Path delimiters stem from the kernel API, which (only) accepts paths as strings. There's no way using the POSIX API to create a file with / in the name (or NUL), because the kernel splits up paths on / and there's no way to escape it.

This goes well beyond just the shell. In fact, it's the shell that has escaping and can deal with special characters: it's the kernel that doesn't.

Evan:

Shinobu:

The idea of path delimiters stems from the console shell world, where paths needed to be (expressable as) strings. And from there it subsequently infected GUI land which evolved from and built on previous console technology.

Path delimiters stem from the kernel API, which (only) accepts paths as strings. There's no way using the POSIX API to create a file with / in the name (or NUL), because the kernel splits up paths on / and there's no way to escape it.
This goes well beyond just the shell. In fact, it's the shell that has escaping and can deal with special characters: it's the kernel that doesn't.

It should have been clear that I was talking from a historical perspective. When the Windows NT kernel was designed, console interfaces had been around for a long long time.
The developers were probably inspired by the paths in Unix, DOS and early Windows, which itself used paths because DOS did.
The kernel folk could have designed their API without delimiters, but they didn't because their mindset was influenced by earlier systems that used string paths.

Shinobu:

It should have been clear that I was talking from a historical perspective. When the Windows NT kernel was designed, console interfaces had been around for a long long time.
The developers were probably inspired by the paths in Unix, DOS and early Windows, which itself used paths because DOS did.
The kernel folk could have designed their API without delimiters, but they didn't because their mindset was influenced by earlier systems that used string paths.

I am also talking about the historical perspective. Do you think that the NT designers didn't know how the kernel APIs in other systems like Unix work?

It's the open call and things like it that are most closely related to the NT API, not the shell. (The VMS $OPEN system call also specifies file name by string.) And for that reason, in the absence of evidence to the contrary, I still say you're probably wrong: NT's design comes from the fact that the string-taking API is nearly universal among OS kernels, not from the shell.

Evan:

I am also talking about the historical perspective.

That's disingenuous. You weren't and you aren't and you know it. Case in point: VMS originally didn't have a GUI.
Kernels tend to use strings for paths because in the past there was a closer relation between kernel and shell than there is now, since early kernels were implemented with the shell in mind, and at the time command line interfaces were universal.

Are you sure MS have a "trial" phase?

The real WTF is why anyone would play Doom without music. The Doom music was awesome!