из моего собственного приложения я должен запустить другое приложение (toolB.exe) на другом компьютере в локальной сети. Для этого я использую psexec и вызов _wsystem. сейчас я пытаюсь запустить toolB на том же компьютере, а не на удаленном компьютере. поэтому в моем коде у меня есть это:
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());
это говорит мне, что интерпретатор команды найден (первый вызов _wsystem с nullptr возвращает 1), и что текущий рабочий каталог C:\project\bin\tools\toolA
и то, что команда (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
) не удается (второй вызов _wsystem с командой возвращает 1 и текст The filename, directory name, or volume label syntax is incorrect
появляется в моем окне консоли приложений). возможно, я должен также упомянуть, что этот фрагмент нативного кода находится в DLL, которая содержит как C ++ (нативный), так и C ++ / CLI (управляемый) код и динамически загружается и выполняется приложением .NET (в том же AppDomain, который я думаю) под названием toolA ,
странная вещь, хотя, когда я выполняю ту же самую командную строку из точно того же рабочего каталога вручную, psexec работает нормально, и toolB.exe запускается, как и ожидалось. так почему это не работает программно с вызовом _wsystem ?? Как это исправить??
Итак, попытка вручную в командной строке оказалась не тем же текстом командной строки, я не использовал «» для исполняемых файлов psexec и toolB. оставив включенный «» вне для работающего исполняемого файла psexec, очевидно, что _wsystem не допускает включение первого параметра с «». что странно, потому что тогда, если psexec находится в пути с пробелами, вызов _wsystem завершится неудачно при попытке разрешить путь psexec. Я еще не уверен, как это преодолеть.
Помимо всего этого, вызов _wsystem также вернул идентификатор процесса toolB.exe, тогда как я ожидал 0, но это другая проблема.