Q:

ifstream issue when executing from the Windows taskbar

I have written a very simple program in Visual Studio C++ 2012 on a 64-bit Windows 7 machine; all it does is open a file using std::ifstream and prints its contents.
int main() {

    std::ifstream fileStream("Test.txt");

    if (!fileStream.is_open()) {
        cerr<<"Error: "<<strerror(errno)<<endl;
    } else {
        std::string testString;
        getline(fileStream, testString);
        cout<<testString<<endl;
    }
}

Simple enough, and it works perfectly fine. While this code is running, an icon appears on the taskbar for the executable generated from this code. If you were to right-click that icon and run another instance of the resulting executable, ifstream will fail, stating that the file does not exist. Except of course it does, it already executes correctly under normal execution.
And if the above were not weird enough, then I tried to pin the executable to the taskbar and repeated the experiment. And it worked. No matter how many more instances you create from the taskbar it works if it is pinned.
Using a full path rather than a relative one also works, but I am developing a larger project that stores resources relative to the executable; I don't want to determine the path of the executable when the files are already right there.
I did call GetModuleFileName to find the execution path, and it appears to be the same in all executions.
So my question is, what the heck am I missing? Why can I not find those files that are literally right next to my executable if it is run this way?

A:

How your application is re-launched from the taskbar is probably an implementation detail and not documented. A pinned application is actually a shortcut stored in your profile. If this breaks your application then it will also break if a user manually starts your application with a path like .\yourapp\app.exe!
Relative paths are relative to the working directory, not the directory the executable is in.
The working directory for a new process can be set in many ways:

It can be inherited from the parent process
The parent process can set a specific directory when calling CreateProcess/ShellExecute
A shortcut (.LNK) can specify a working directory

If you want to open a file in the same directory as your .EXE then you should build a full path based on the result of GetModuleFileName(0) (PathRemoveFileSpec and PathAppend can be helpful).
If you are never going to accept filenames from the command line then you could manually change the working directory before you open the file instead.

