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...
Weird Windows / WinBoard behavior.
Moderators: hgm, Rebel, chrisw
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
- Posts: 1563
- Joined: Thu Jul 16, 2009 10:47 am
- Location: Almere, The Netherlands
Re: Weird Windows / WinBoard behavior.
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.
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.
-
- Posts: 2851
- Joined: Wed Mar 08, 2006 10:01 pm
- Location: Irvine, CA, USA
Re: Weird Windows / WinBoard behavior.
Are either of these in your path?
Deasil is the right way to go.
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Weird Windows / WinBoard behavior.
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.
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.
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 */
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.
-
- Posts: 411
- Joined: Thu Dec 30, 2010 4:48 am
Re: Weird Windows / WinBoard behavior.
From the MSDN page for CreateProcess()
https://msdn.microsoft.com/en-us/librar ... s.85).aspx
https://msdn.microsoft.com/en-us/librar ... s.85).aspx
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.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.
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Weird Windows / WinBoard behavior.
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.
Thanks.