Path problem running a child DOS process under NT
I have a problem when using CreateProcess to start a 16 bit DOS program in my MFC app. I want to run the child file viewer app when the user views one of my data files.
I am calling CreateProcess with lpCommandLine set to the full path of the DOS application plus just the name of the data file, and have tried both passing the data file's directory in as the lpCurrentDirectory parameter, and alternatively, using ::SetCurrentDirectory to set the working dir. Neither method seems to work, with the standard error value returning "file not found".
Note that I want the application to run on both Win9x and NT. Passing the current directory into CreateProcess seems to work well on Win95, but neither method works on NT.
I also want to include spaces in my path if possible :)
I am calling CreateProcess with lpCommandLine set to the full path of the DOS application plus just the name of the data file, and have tried both passing the data file's directory in as the lpCurrentDirectory parameter, and alternatively, using ::SetCurrentDirectory to set the working dir. Neither method seems to work, with the standard error value returning "file not found".
Note that I want the application to run on both Win9x and NT. Passing the current directory into CreateProcess seems to work well on Win95, but neither method works on NT.
I also want to include spaces in my path if possible :)
I think Madshi is right, though i'm stunned to rear that NT doesn't do the conversion itself when calling 'CreateProcess()'...
Hi Jürgen,
win95 doesn't do the conversion. I didn't test it with winNT, but I guess it's the same... :-(
Regards... Madshi.
win95 doesn't do the conversion. I didn't test it with winNT, but I guess it's the same... :-(
Regards... Madshi.
ASKER
The problem seems to be related to the length of the path in which the data file is stored. It is about 5 directories deeps, which makes the path quite long.
So far I have found the best method is to get the 'short' version of the data file, and just pass it and thein via the lpCommandLine, ie the lpCommand eventually equals
c:\nms\bin\replay.exe c:\nms\projec~1.prj\melbou
This works well, until the length of this command exceeds 142 chars!? The CreateProcess then fails returning "The parameter is incorrect". I recall reading something about using fully qualified paths (ie "\\servername\sharename\pa
So far I have found the best method is to get the 'short' version of the data file, and just pass it and thein via the lpCommandLine, ie the lpCommand eventually equals
c:\nms\bin\replay.exe c:\nms\projec~1.prj\melbou
This works well, until the length of this command exceeds 142 chars!? The CreateProcess then fails returning "The parameter is incorrect". I recall reading something about using fully qualified paths (ie "\\servername\sharename\pa
This text is from the CreateFile documentation. I don't know, but I guess, you can use the same syntax with CreateProcess. Of course you then have to use CreateProcessW instead of CreateProcessA.
"Windows NT: You can use paths longer than MAX_PATH characters by calling the wide (W) version of CreateFile and prepending "\\?\" to the path. The "\\?\" tells the function to turn off path parsing. This lets you use paths that are nearly 32,000 Unicode characters long. You must use fully-qualified paths with this technique. This also works with UNC names. The "\\?\" is ignored as part of the path. For example, "\\?\C:\myworld\private" is seen as "C:\myworld\private", and "\\?\UNC\tom_1\hotstuff\co
Regards, Madshi.
"Windows NT: You can use paths longer than MAX_PATH characters by calling the wide (W) version of CreateFile and prepending "\\?\" to the path. The "\\?\" tells the function to turn off path parsing. This lets you use paths that are nearly 32,000 Unicode characters long. You must use fully-qualified paths with this technique. This also works with UNC names. The "\\?\" is ignored as part of the path. For example, "\\?\C:\myworld\private" is seen as "C:\myworld\private", and "\\?\UNC\tom_1\hotstuff\co
Regards, Madshi.
16 bit programs are limited to 127 characters in the command line.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Try using GetShortPathName to convert the data file path to short name convention.
Regards, Madshi.