Why does Counter Strike: Condition Zero not play intro videos in Windows if the installation path has spaces in it?

Question

I have Counter Strike: Condition Zero game. Whenever I install it in a folder like C:\FolderName and launch the game after intallation, the game starts with 2 intro videos (I found those videos inside game installation folder, both have .avi extensions).

But a pretty weird behavior I noticed. If I remove and install game again in C:\Folder Name the game works fine except that those 2 intro videos won't play at launch. Pretty weird.

To confirm if this is the exact reason, I tried at least 15 times installation of this game with different named folders. Few with folder name with spaces, and few without spaces. And it confirmed that those intro videos won't play if the folder name has any spaces.

Those video files have this path: C:\My Folder Name\czero\media OR C:\MyFolderName\czero\media

The game launch hl.exe file has path: C:\My Folder Name OR C:\MyFolderName

The game installs properly in both cases but videos play only in 2nd case i.e., MyFolderName.

Looks like either the game tries to avoid .avi files or some Windows feature forces the game to not play those files - whenever there are space(s) in folder name.

I would ask it on gaming SE network, but I strongly feel this weird behavior is just because of space in main folder name and related to those .avi files only.

Can there any particular reason for it? Is it because of some Firewall/Antivirus/UAC protection and rules?

Solution 1

Sounds like a bug in the game where the code opens video without quotes and as such part of the video path is assumed to be a parameter where it really isn't, resulting in an error, and thus the video never plays. Console will probably log an error too.

To explain this a bit... In Windows, when you work with paths, you either type it as such:

C:\My_Path_without_spaces

or

"C:\My Path With Spaces"

Note the quotes.

When you start an external program, for example a video player, the video player may have its argument list as follows (this is an example)

C:\Games\HalfLife\bin\videoplayer.exe /video C:\Games\HalfLife\intro.avi
                      ^ path to videoplayer
                                      ^parameter video
                                             ^video file

Now lets say you have Half Life as foldername:

C:\Games\Half Life\bin\videoplayer.exe /video C:\Games\Half Life\intro.avi
                       ^ path to videoplayer (the space may break here too)
                                       ^parameter video
                                              ^video file
                                                            ^invalid parameter
 

There's no video called Half without extension nor does it understaned the Life\intro.avi as parameter as the videoplayer does not recognize it.

Note that HalfLife 1 is a very old game. It was in the era where 8.3 length filenames were still very common.

Solution 2

The underlying issue is that under Windows the callee is responsible for parsing the command line. The callee gets the entire command line as one single string. (The *nix family of operating systems, by contrast, passes a set of single arguments to the callee, corresponding to argv. Separating arguments is simply not an issue.) Typical conventions separate command line arguments by spaces; consequently, single arguments that contain spaces must be quoted. The quotes are part of the command line passed to the callee! For a discussion, see this Microsoft article. As a side issue, there is no guarantee that the callee handles quotes at all! Don't quote parameters gratuitously.

In your case, quoting the path argument was forgotten: a bug in the game. Additionally, an entire equivalence group in the module tests was missed.

You may know such troubles from your favorite *nix shell: How do I again pass an argument that contains quotes? The user shell is the only program in the *nix world that needs to parse command lines. Programmatically calling one binary from another, by contrast, does not have that issue: The caller simply fills an array of arguments before the exec call, serving single arguments to the callee on a silver platter.

It is this ill-conceived combination of an ill-conceived, legacy DOS calling convention with an ill-conceived hippie idea (it's Apple's fault!¹) of spaces in path names which precipitates errors like yours.

---

¹ Yes I know, spaces (and other funny characters) in path names have been around before apple's adoption; but no sane *nix user would voluntarily name a folder "Program Files". Such nonsense has no right to exist on end user systems.

Comments

[Vikas]

If possible would you please also add a bit more explanation of how that "code error" would work? I have done coding in past so I'll probably understand.

[Vikas]

What I'm thinking is: var path_name = sdfdf/sdfdf/FolderName works while var path_name = sdfdf/sdfdf/Folder Name; will give error because there's unwanted space?

[LPChip]

Done. Hope this helps.

[hanshenrik]

@Vikas to see the problem for yourself, run this in cmd as administrator: mkdir "C:\foo" \n mkdir "C:\foo bar" \n copy "%windir%\system32\timeout.exe" "C:\foo" /y \n copy "%windir%\system32\timeout.exe" "C:\foo bar" /y \n C:\foo\timeout.exe 5 \n C:\foo bar\timeout.exe 8 \n (just replace the \n with enter)

[David Schwartz]

Lots of Windows stuff fails in strange ways if your user name has a space in it. :(

[Aganju]

In other words, lots of Windows is still buggy, after 30 years of improvement. Hardly a surprise, though.

[Todd Sewell]

@Aganju not in windows, in 3rd party programs. Linux has the same exact "issue".

[Dev]

@ToddSewell it's more prevalent in old Windows programs that use composition via routing arbitrary strings through COMMAND.COM or CMD.EXE. Even in the olden days of Linux, people knew to use quotation marks in their shell scripts, and programs that executed subprocesses often passed argv as an array of strings anyway, so they didn't have to deal with escaping arguments for a shell.

[Sebastiaan van den Broek]

@Dev that still doesn’t mean it’s Windows being buggy though. Although it is quite possible that more developers for the Windows platform would make a mistake like this, simply because they’re not as used to working with the command line. Not because they’re not as good (I wouldn’t call game developers poor programmers) but because they don’t need that knowledge as often.

[phuclv]

@Aganju not quoting paths with spaces properly is a bug of the program and has nothing to do with Windows. Any apps that don't work with spaces in file names are shitty these days

[Kamil Maciorowski]

(1) Why HalfLife and HalfLive? (Occam's razor: entities should not be multiplied without necessity). (2) There is a space in C:\Games\Half Life\bin\videoplayer.exe. The answer suggests the string is somehow interpreted as one entity despite the lack of quoting; at the same time C:\Games\Half Live\intro.avi is two entities because of lack of quoting. (3) videoplayer.exe may not support quotes at all (compare this).

[Dev]

@SebastiaanvandenBroek Nowhere did I say this was a Windows problem, thank you. It's just a general trend with old Windows programs, not the fault of the OS, unless encouraging bad coding practices counts. :)

[Sebastiaan van den Broek]

@Dev context is important. See what you replied to and what they replied to.

[LPChip]

@KamilMaciorowski The Half Live is a typo on my end... well spotted. Fixed. :) When calling programs without quotes, windows often still works, but it may also break, so that's a valid point.

[Peter - Reinstate Monica]

@Aganju Actually, whoever had the idea to allow spaces in paths should be flogged and quartered. That was probably a costlier mistake than the nullpointer.

[Peter - Reinstate Monica]

@Dev Passing all arguments in a single string is not a bug but a design flaw, creating generations of headaches for developers: "CommandLineToArgvW treats whitespace outside of quotation marks as argument delimiters." Uh-hm. Vs. "On *nix, the parameters are parsed off by whatever program creates the new process." No formatting or parsing headaches whatsoever (except for a user shell).

[Kamil Maciorowski]

Feedback: I like the other answer because it touches what your answer misses: a hypothetical command videoplayer.exe /video C:\Games\Half Life\intro.avi "fixed" by quoting like this: videoplayer.exe /video "C:\Games\Half Life\intro.avi" may or may not succeed; it depends on whether or not videoplayer.exe supports quoting. There is a bug in the game but it's not necessarily because "the code opens video without quotes". Maybe videoplayer.exe is crippled in the first place.

[Dev]

@SebastiaanvandenBroek The comment I replied to stated that Linux also had the same faulty third-party programs. That's what I was addressing.

[DavidPostill]

Comments are not for extended discussion; this conversation has been moved to chat.