• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 386
  • Last Modified:

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 :)
1 Solution
I guess, that dos program is loaded but it can't find the file, cause the filename is passed in long file name convention.
Try using GetShortPathName to convert the data file path to short name convention.

Regards, Madshi.
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.
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

jjozAuthor Commented:
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~1.prj\testmt~1.MT1\981201.dta\15'36'33.log

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\path") with NT to overcome path limitations, but I can't seems to relocate it now.

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\coolapps" is seen as "\\tom_1\hotstuff\coolapps"."

Regards, Madshi.
Tommy HuiEngineerCommented:
16 bit programs are limited to 127 characters in the command line.
Tommy HuiEngineerCommented:
If you need to get around this, then you will need to do what some compilers do. Create a temporary file in a short directory. The contents of the file contains anything you want. Pass the name of this temporary file to the 16 bit application, but with a special character preceding the name. Then in the 16-bit application check the command line argument to see if it contains this special character. If it does, then get the real parameter from the file. Otherwise, process the command line argument normally.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now