Antonio Torrecillas wrote:The current directory is inherited from the parent process explorer.exe.
In the process of drag and drop of a file into a program's icon. argv[0] is the full path of the executable (as usual
)
and argv[1] is the fullpath of the dragged file. The current directory is the drag directory, so the directory from which you start the action.
OK, this inded is confirmed. Because WinBoard is a GUI app I seem to have no direct access to argc, argv, and the iitial entry point looks like:
Code: Select all
int APIENTRY
WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
One of the first things it does is call InitInstance, in which I put the code:
Code: Select all
BOOL
InitInstance(HINSTANCE hInstance, int nCmdShow, LPSTR lpCmdLine)
{
HWND hwnd; /* Main window handle. */
int ibs;
WINDOWPLACEMENT wp;
char *filepart, curDir[MSG_SIZ];
hInst = hInstance; /* Store instance handle in our global variable */
programName = szAppName;
if (SearchPath(NULL, "WinBoard.exe", NULL, MSG_SIZ, installDir, &filepart)) {
*filepart = NULLCHAR;
GetCurrentDirectory(MSG_SIZ, curDir);
SetCurrentDirectory(installDir); // just added
} else {
GetCurrentDirectory(MSG_SIZ, installDir);
}
gameInfo.boardWidth = gameInfo.boardHeight = 8; // [HGM] won't have open window otherwise
screenWidth = screenHeight = 1000; // [HGM] placement: kludge to allow calling EnsureOnScreen from InitAppData
InitAppData(lpCmdLine); /* Get run-time parameters */
/* xboard, and older WinBoards, controlled the move sound with the
appData.ringBellAfterMoves option. In the current WinBoard, we
always turn the option on (so that the backend will call us),
then let the user turn the sound off by setting it to silence if
desired. To accommodate old winboard.ini files saved by old
versions of WinBoard, we also turn off the sound if the option
was initially set to false. [HGM] taken out of InitAppData */
if (!appData.ringBellAfterMoves) {
sounds[(int)SoundMove].name = strdup("");
appData.ringBellAfterMoves = TRUE;
}
if (appData.debugMode) {
debugFP = fopen(appData.nameOfDebugFile, "w");
setbuf(debugFP, NULL);
fprintf(debugFP, "Install: %s Initial: %s Command %s\n", installDir, curDir, lpCmdLine);
}
Thea last line causes printing of:
Install: C:\WinBoard-4.7.0\WinBoard\ Initial: C:\cygwin\home\shogi Command C:\cygwin\home\shogi\Pulsar.xop
It seems that lpCmdLine only contains argv[1] and later, not argv[0]. But the initial directory is indeed the one I clicked the Pulsar.xop in, and it is different from the WinBoard folder. So the SetCurrentDirectory that I just added is essential to end up in the WinBoard folder.
That does still beg the question how SearchPath did know it should have returned C:\WinBoard-4.7.0\WinBoard\winboard.exe, and not, for instance, C:\WinBoard-Chu\winboard.exe. It certainly could not have seen that from the current directory. Some other hidden information must have been passed from explorer.exe to the WinBoard process...
Strange thing is that I now cannot reproduce the problem I had after browsing, which should have led to printing of another initial path name.
Another piece of info: when I make a copy of winboard.exe and rename it blupko.exe, I
can make it appear in the 'Open With' dialog, and associate files to it. And when it appears in that dialog, it does appear as 'WinBoard 32-bit GUI for Chess. there, so it was not fooled by the name change. But there seems to be a ban on associating files with something named winboard.exe...
