Чтобы запустить с помощью CreateProcess выполнимый файл, не указывая полный путь к нему, но о котором известно, что он находится в одном из каталогов, перечисленных в переменной окружения PATH, необходимо (как утверждается в MSDN'е) первым параметром передать NULL, а имя приложения передавать вторым параметром (т.е. как часть командной строки).
В этом случае CreateProcess будет искать указанный файл в некоторых заранее предопределенных местах, а именно (в той последовательности, что указана ниже):
1. В каталоге, из которого был загружено приложение.
2. Текущий каталог родительского процесса.
3. В каталоге, "возвращаемом" GetSystemDirectory.
4. В каталоге, "возвращаемом" GetWindowsDirectory.
5. В каталогах, перечисленных в переменной окружения PATH.
// #import <windows.bas> class IWindows9x:protected DOS { private: virtual HANDLE EnumClouds()=0; };
Здравствуйте, KA, Вы писали:
KA>Чтобы запустить с помощью CreateProcess выполнимый файл, не указывая полный путь к нему, но о котором известно, что он находится в одном из каталогов, перечисленных в переменной окружения PATH, необходимо (как утверждается в MSDN'е) первым параметром передать NULL, а имя приложения передавать вторым параметром (т.е. как часть командной строки). KA>В этом случае CreateProcess будет искать указанный файл в некоторых заранее предопределенных местах, а именно (в той последовательности, что указана ниже): KA>1. В каталоге, из которого был загружено приложение. KA>2. Текущий каталог родительского процесса. KA>3. В каталоге, "возвращаемом" GetSystemDirectory. KA>4. В каталоге, "возвращаемом" GetWindowsDirectory. KA>5. В каталогах, перечисленных в переменной окружения PATH.
да, и при этом поле lpCurrentDirectory должно быть валидным (если полный путь не входит в имя процесса)!
еще, если полный путь к файлу не указан и сам файл — часть командной строки, ОС может немного модифицировать эту строку — в этом причина того, что тип LPTSTR lpCommandLine (а не LPCTSTR как казалось бы есс-но) — может быть причиной взрыва если константное выражение (строка с именем) в сегменте только для чтения окажется
... << RSDN@Home 1.0 beta 7a >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
