from within my native application I have to start another application (toolB.exe) on another computer on the local network. to do this I use psexec and a call to _wsystem. for now, I am trying to start toolB on the same computer instead of on the remote computer. so in my code I have this:
const std::wstring command = L"\"" + psexecfull + L"\" " + psexecargs + L" -c -f -d -s -n 10 \"" + toolpathfull + L"\" " + toolargs;
int exitcode = _wsystem(nullptr);
wchar_t buffer[1024];
_wgetcwd(buffer, _countof(buffer));
exitcode = _wsystem(command.c_str());
this tells me that the command interpreter is found (first call to _wsystem with nullptr returns 1), and that the current working directory is C:\project\bin\tools\toolA, and that the command (C:\project\externals\psexec\tools\psexec.exe \\127.0.0.1 -c -f -d -s -n 10 C:\project\bin\tools\toolB\toolB.exe -arg) fails (second call to _wsystem with command returns 1 and the text The filename, directory name, or volume label syntax is incorrect appears in my applications console window). maybe I should also mention this piece of native code is in a DLL that contains both C++ (native) and C++/CLI (managed) code and is dynamically loaded and executed by a .NET application (in the same AppDomain I think) called toolA.
the weird thing is though, when I execute the exact same command line from the exact same working directory manually psexec runs fine and toolB.exe is started as expected. so why is this not working programmatically with a call to _wsystem?? how do I fix this??
I am running Windows 7 x64, if it matters.
ok so the manual attempt on the command line turned out not to be the exact same command line text, I was not using the enclosing "" for the psexec and toolB executables. leaving the enclosing "" out for the psexec executable worked, so apparently _wsystem does not tolerate enclosing the first parameter with "". which is weird because then if psexec is located in a path with spaces the call to _wsystem will fail while trying to resolve the psexec path. I'm not yet sure how to overcome this.
apart from all this, the call to _wsystem also returned the process id of toolB.exe whereas I was expecting 0, but that's another issue.