Weird Windows / WinBoard behavior.

[hgm]

I have two engines fmax.exe, one in the WinBoard folder, the other in the WinBoard\Fairy-Max sub-folder. I ask WinBoard to run the one in the Fairy-Max folder (/fd=Fairy-Max). But from the version number it prints, I can see it runs the one in the WinBoard folder instead.

Now I rename the one in the Fairy-Max folder to gmax.exe, and that in the WinBoard folder to hmax.exe. Now starting gmax.exe with directory Fairy-Max runs the one in directory Fairy-Max, as expected. But running hmax.exe with directory Fairy-Max runs the one in the WinBoard folder.

How is it possible that in one case it ignores the directory specification, while in the other case it obeys it? Is this new Windows behavior, (I am running 8.1), that when it cannot find an engine where you say it is, it just picks a binary with the same name elsewhere to execute? Even if it is, why would it prefer to run the binary in another place than where I am asking for, if that name exists in two places?

I cannot recal having made WinBoard to look in two places. If it would look in its own folder first, rather than in the specified one, that would be completely wrong behavior, so even if I would have been temporarily insane and cannot remember that now I should not have done such a thing...

[Joost Buijs]

I know you don't like Windows but I have never seen Windows behave in such a way, can it have something to do with the software you used to create the windows executable?
The first thing I would do is to examine the code of Winboard very carefully because it is very likely that the problem resides there.

[Dirt]

Are either of these in your path?

[hgm]

Neither of the names is in the PATH as a full path name. I suppose the current directory is always searched for commands, although I don't see it explicitly in the PATH (when doing "echo %PATH%").

But I thought the PATH would be an issue handled by command interpreters. WinBoard is using the API call CreateProcess, after using SetCurrentDirectory to change directory to the engine directory.

Code: Select all

  GetCurrentDirectory(MSG_SIZ, buf);
  SetCurrentDirectory(installDir);
  SetCurrentDirectory(dir);

  /* Now create the child process. */

  siStartInfo.cb = sizeof(STARTUPINFO);
  siStartInfo.lpReserved = NULL;
  siStartInfo.lpDesktop = NULL;
  siStartInfo.lpTitle = NULL;
  siStartInfo.dwFlags = STARTF_USESTDHANDLES;
  siStartInfo.cbReserved2 = 0;
  siStartInfo.lpReserved2 = NULL;
  siStartInfo.hStdInput = hChildStdinRd;
  siStartInfo.hStdOutput = hChildStdoutWr;
  siStartInfo.hStdError = hChildStdoutWr;

  fSuccess = CreateProcess(NULL,
			   cmdLine,	   /* command line */
			   NULL,	   /* process security attributes */
			   NULL,	   /* primary thread security attrs */
			   TRUE,	   /* handles are inherited */
			   DETACHED_PROCESS|CREATE_NEW_PROCESS_GROUP,
			   NULL,	   /* use parent's environment */
			   NULL,
			   &siStartInfo, /* STARTUPINFO pointer */
			   &piProcInfo); /* receives PROCESS_INFORMATION */

  err = GetLastError();
  SetCurrentDirectory(buf); /* return to prev directory */

In this case cmdLine should just be "fmax", and dir should be "Fairy-Max". installDir should be "C:\cygwin\home\fboard\xboard-9ddb27d\winboard".

This command turns out to be able to start both fmax.exe in <installDir> and <installDir>\Fairy-Max, and prefers the former if both exists.

[kbhearn]

From the MSDN page for CreateProcess()
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

If the file name does not contain a directory path, the system searches for the executable file in the following sequence:
The directory from which the application loaded.
The current directory for the parent process.
The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this function does not search the per-application path specified by the App Paths registry key. To include this per-application path in the search sequence, use the ShellExecute function.

Since the first option before current directory is the directory you loaded from, if you don't specify a path, it'll load that one first. The correct answer is to specify the path in the commandline probably.

[hgm]

Indeed, that explains it. Amazing that this never caused anyone any trouble before. I can try to solve it by prefixing simple filenames by ".\", as in XBoard.

Thanks.