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?

  • 31
    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.
    – LPChip
    Apr 11, 2021 at 12:39
  • 2
    I agree with LPChip—this sounds like a bad path hard coded in the game itself. When you deviate from the developer’s expected installation path you are causing the videos to it be found. This is a bug within the program and not an issue with Windows specifically.
    – JG7
    Apr 11, 2021 at 12:54
  • Thank you @LPChip and JG7 BTW How do I accept your comments as answers? :P
    – Vikas
    Apr 11, 2021 at 13:23
  • 1
    You cannot. I posted it as an answer for you, so you can accept that. :)
    – LPChip
    Apr 11, 2021 at 13:25
  • 1
    Here's the help in case you want to see the details: superuser.com/editing-help#code
    – muru
    Apr 12, 2021 at 7:05

2 Answers 2


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 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.

  • 7
    Lots of Windows stuff fails in strange ways if your user name has a space in it. :( Apr 11, 2021 at 22:31
  • 17
    @Aganju not in windows, in 3rd party programs. Linux has the same exact "issue". Apr 12, 2021 at 0:03
  • 4
    @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.
    – Dev
    Apr 12, 2021 at 1:39
  • 9
    @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). Apr 12, 2021 at 7:11
  • 4
    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. Apr 12, 2021 at 10:11

The underlying issue is that under Windows the callee is responsible for parsing the command line. By convention, the called program expects and gets the entire command line as one single string from the command shell. (Programs written for the *nix family of operating systems, by contrast, expect a set of single arguments, corresponding to argv, a job the *nix shells perform by parsing the command line. Separating arguments is simply not an issue for the called program.)

DOS/Windows programs, by convention, expect the command line arguments as "words" separated by whitespace; consequently, if the caller wants to pass a single argument that contains whitespace, like a stupid path with whitespace, that argument must be quoted. The quotes are part of the command line seen by the called program! 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!1) of spaces in path names which precipitates errors like yours.

1 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 are not for extended discussion; this conversation has been moved to chat.
    – DavidPostill
    Apr 15, 2021 at 12:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .