Пути и CreateProcess

Question

У меня есть вопрос, касающийся симптома моего неправильного использования CreateProcess. Я использую параметр lpcommandline, чтобы указать путь к моему исполняемому файлу и параметрам. Я неправильно использую то, что я не окружил путь к exe кавычками.

Мой вопрос: почему CreateProcess прекрасно работает на большинстве компьютеров, а не на других? Я знаю, что путь будет занимать большую часть времени, но на 90% машин XP он работает. Я, конечно, обнаружил свою проблему на тех 10%, где это не так. Но мне интересно, что отличается на машинах, где это не работает? Есть ли какая-то обстановка или политика, о которой знает каждый из вас? И да, я собираюсь исправить проблему с цитатой. Просто любопытно, почему что-то подобное не сорвалось бы с места.

Таким образом, код будет выглядеть примерно так, как показано ниже, а параметр szCommandLine будет выглядеть примерно так: Обратите внимание, что нет кавычек вокруг пути к exe.

"C: \ Program Files \ Моя компания \ doit.exe параметр1 параметр2"

CreateProcess(
    NULL,           
    szCommandLine,  
    NULL,           
    NULL,           
    FALSE,          
    NULL, 
    NULL,  
    NULL,           
    &si,            
    &pi )       

Answer 1

Поскольку документ Мартин Йорк ссылается на подсказку, CreateProcess () имеет некоторое поведение для обратного сравнения с программами с пре-длинными именами.

"c: \ program files \ sub dir \ имя программы arg1 arg2" будет искать:

"c:\program.exe" files\sub dir\program name arg1 arg2
"c:\program files\sub.exe" dir\program name arg1 arg2
"c:\program files\sub dir\program.exe" name arg1 arg2
"c:\program files\sub dir\program name.exe" arg1 arg2

Так что, если какой-либо из этих файлов существует, Windows будет вызывать их, а не вашу программу. Кроме того, я бы предположил, что если у вас нет доступа на чтение ни к одной из папок, в которых находятся эти возможные совпадения, CreateProcess () может сразу же завершиться ошибкой, вместо проверки того, что вы прочитали более поздние возможные совпадения. (Windows по умолчанию проверяет доступ на чтение только в последней папке.)

Answer 2

Вы должны прочитать эту страницу:
http://msdn.microsoft.com/en-us/library/ms682425.aspx

• Если имя приложения NULL (первый параметр).
  
• В качестве имени приложения используется первое слово, разделенное пробелом в командной строке (второй параметр).
  
• Если имя приложения содержит пробел, оно должно быть заключено в кавычки.

Опять код стоит миллион слов:
Это выглядит так:

char commandline[] = "C:\Program Files\My Company\doit.exe parameter1 parameter2";
CreateProcess(NULL,commandline, .... );

Или вы генерируете путь куда-нибудь?
Помните, что на общие вопросы вы получите только общие ответы.
Вы должны быть конкретны, прежде чем получите конкретный ответ о том, почему в противном случае слишком много спекуляций.

Answer 3

Я просто долго боролся с той же проблемой. Поэтому, даже если этот вопрос был поднят очень давно, просто для справки, вот в чем проблема в моем случае:

Если командная строка не заключена в кавычки и содержит пробелы, CreateProcess попытается устранить неоднозначность, как описано в ответе Саймона. Если какая-либо из протестированных частей, вплоть до символа пробела, также преобразуется в существующий файл без расширения или с расширением .exe, этот файл будет использоваться вместо намеченного полного пути.

Пример:

char cmdline[] = "C:\Program Files\App One\bin\app.exe param1 param2";
CreateProcess(NULL, cmdline, ...);

К сожалению, на самом деле в моем случае существовал файл с именем "C: \ Program Files \ App" (без расширения). CreateProcess нашел этот файл, предположил, что это исполняемый файл без расширения .exe, и попытался его запустить. Результат: ошибка 193 «% 1 не является допустимым приложением Win32».

Итог: используйте кавычки или, что еще лучше, первый аргумент CreateProcess или ищите любой другой файл, который может совпадать с частью ошибочного пути.

Answer 4

Хороший способ диагностировать что-то подобное - встроить в ваше приложение ошибку и механизм отчетности. Это помогает для многих целей - в основном для ошибок, которые вы, возможно, никогда не увидите сами, а некоторые пользователи могут просто игнорировать и не сообщать вам. Таким образом вы сможете диагностировать эти параметры при вызове команды и возникновении сбоя.

Кроме того, вы можете попробовать изучить сайт MSDN и дополнительные функции, связанные с этим методом. Вы оставили большинство из них NULL. Изучив эти расширенные функции, вы узнаете и, возможно, сможете сами выяснить, почему может существовать такая несоответствие.

Еще один общий ответ, но я надеюсь, что это поможет вам оценить вашу конкретную ситуацию.