The behaviour you experience depends most likely on differences in the environment variable $PATH. The $PATH is essentially a colon-separated list of directories, which are searched in order for a particular executable when a program is invoked using anexec operating system call. The $PATH can contain relative path components, typically . or an empty string, which both refer to the current working directory. If the current directory is part of $PATH, files in the current working directory can be executed by just their name, e.g. a.out. If the current directory is not in $PATH, one must specify a relative or absolute path to the executable, e.g. ./a.out.
Having relative path components in $PATH has potential security implications as executables in directories earlier in $PATH overshadow executables in directories later in the list. Consider for example an attack on a system where the current working directory path . preceeds /bin in $PATH. If an attacker manages to place a malicious script sharing a name with a commonly used system utility, for instance ls, in the current directory (which typically is far easier that replacing binaries in root-owned /bin), the user will inadvertently invoke the malicious script when the intention is to invoke the system ls. Even if . is only appended at the end of $PATH, a user could be tricked to inadvertently invoke an executable in the current directory which shares a name with a common utility not found on that particular system. This is why it is common not to have relative path components as part of the default $PATH.
./in$PATHby default? Ewwwwww... – Shadur Aug 5 '13 at 7:01