CreateProcess lpApplicationName param
-
Hi I have a program in subdirectory folder as such c:\dira\dirb\program.exe When I do GetCurrentDirectory API I get c:\dira When Use "program.exe" as the first parm I get returned code 0 followed by file not found from GetLastError
-
Hi I have a program in subdirectory folder as such c:\dira\dirb\program.exe When I do GetCurrentDirectory API I get c:\dira When Use "program.exe" as the first parm I get returned code 0 followed by file not found from GetLastError
Just use the full path for the
lpApplicationName
parameter. Avoid using partial names. When using them you have to ensure that the current working directory is set to the parent of the partial name resulting in a path containg that file. The only exception is when you know that the application is stored in one of the directories specified in thePATH
environment variable. Then you can use the plain file name. -
Return code 0 means the command completed successfully, so calling GetLastError is not necessary, and will give you a meaningless response. My mistake.
The CreateProcessA function | Microsoft Docs[^] returns a
BOOL
where zero indicates failure. -
The CreateProcessA function | Microsoft Docs[^] returns a
BOOL
where zero indicates failure. -
Just use the full path for the
lpApplicationName
parameter. Avoid using partial names. When using them you have to ensure that the current working directory is set to the parent of the partial name resulting in a path containg that file. The only exception is when you know that the application is stored in one of the directories specified in thePATH
environment variable. Then you can use the plain file name. -
The problem with using the full path name if my .exe is stored in c:\dira\dirb GetCurrentDirectory only returns c:\dira my module is stored in the current directory Thanks
You have to know (and usually will know) where the file is stored. Where is the problem using the full path?
GetCurrentDirectory()
returns the actual working directory of the session. It is not related in any way to the application calling that function (besides the application has set the working directory explicitly). Again: Use full pathes. If necessary create them dynamically during runtime. But never expect the current working directory to be a specific one if you have not set it. But when setting it, you can also create full pathes instead. If you need to know where the application actually executed is stored, access the first command line parameterargv[0]
in yourmain()
function. That contains the full path of the executable. Or use the GetModuleFileName function (Windows)[^] with the first parameter set toNULL
. With both methods you can extract the path which can be for example used to access other files known to exist in the same directory or a sub directory. -
You have to know (and usually will know) where the file is stored. Where is the problem using the full path?
GetCurrentDirectory()
returns the actual working directory of the session. It is not related in any way to the application calling that function (besides the application has set the working directory explicitly). Again: Use full pathes. If necessary create them dynamically during runtime. But never expect the current working directory to be a specific one if you have not set it. But when setting it, you can also create full pathes instead. If you need to know where the application actually executed is stored, access the first command line parameterargv[0]
in yourmain()
function. That contains the full path of the executable. Or use the GetModuleFileName function (Windows)[^] with the first parameter set toNULL
. With both methods you can extract the path which can be for example used to access other files known to exist in the same directory or a sub directory.