subst command not working through createProcess()

This is a discussion on subst command not working through createProcess() within the Windows Programming forums, part of the Platform Specific Boards category; Helo all,
I try to do subst command to map a folder to a drive letter.
I achieved it through ...

The DebugLogMessage1(cmd); prints the value of cmd as subst R: C:\PROGRA~1\Syntegra

Please give me the things went wrong in the above program or in the windows settings.

Regards,
Naga

Is there any specific reason for using the above method to map a drive as opposed to using something like WNetAddConnection2 ? This is assuming you're trying to map a folder on a remote workstation. But yet the DebugLogMessage implies that you're somehow trying to map a drive to a folder on the local workstation. I'm not sure I understand what exactly you're trying to accomplish. Can you provide some additional detail?

No, subst makes a directory translation so that an application thinks that R: is C:\program files\Syntegra (or whatever you put after the first drive: combination). It used to be that you'd swap floppy drives around to make naff applications run on B: or C: when it hard-coded A: as the "home-drive".

No, subst makes a directory translation so that an application thinks that R: is C:\program files\Syntegra (or whatever you put after the first drive: combination). It used to be that you'd swap floppy drives around to make naff applications run on B: or C: when it hard-coded A: as the "home-drive".

I could be way off here (and most likely am) but: The effects of subst go away after the process ends, right? It's not permanent. So just because the shell that gets created knows what R: means, doesn't mean anybody else does.

I could be way off here (and most likely am) but: The effects of subst go away after the process ends, right? It's not permanent. So just because the shell that gets created knows what R: means, doesn't mean anybody else does.

Not true - I use subst at work to get reasonable paths for different projects that I've got concurrently on my machine - and I just tried it on my Win2K system too.

We use this because code is already several levels deep, e.g. x:/group/module/component/source/partsource/xx.cpp - if you then have to do something like "y:/mywork/projectx/current/" on top of that, it gets pretty hard to read the path - even with the subst drive I have some compnents that have so deep directory structure that an 80 character command-line is filled out so that I can't even do "cd" without going over the edge to the next line - not a bit problem, but gets a bit messy at times. Adding another two, three or four directory levels wouldn't help much!

Not true - I use subst at work to get reasonable paths for different projects that I've got concurrently on my machine - and I just tried it on my Win2K system too.

We use this because code is already several levels deep, e.g. x:/group/module/component/source/partsource/xx.cpp - if you then have to do something like "y:/mywork/projectx/current/" on top of that, it gets pretty hard to read the path - even with the subst drive I have some compnents that have so deep directory structure that an 80 character command-line is filled out so that I can't even do "cd" without going over the edge to the next line - not a bit problem, but gets a bit messy at times. Adding another two, three or four directory levels wouldn't help much!

--
Mats

No, you're right. I'm not sure what I was thinking (probably confusing system startup with shell startup). Just call me "Emily Littella".

If the above changes do not solve your problem then you might try setting up the Comspec environment for the first parm to CreateProcess. And if that doesn't work, then you might try waiting until the child process finishes before exiting the function.

But I am not seeing any R: drive in my “MyComputer” or start->run>r: also states no drive found.

I also tried using the below code.

Code:

STARTUPINFO si = { 0 };
PROCESS_INFORMATION pi = { 0 };

Now my only question is how I am getting err 183, even though I am not able to see the drive R: in “MyComputer”. Interestingly I can use “subst” directly in command prompt and I am successful in viewing the dive R: in “MyComputer”.

Now my only question is how I am getting err 183, even though I am not able to see the drive R: in “MyComputer”.

You can use the reciprical function QueryDosDevice to see what Windows thinks its mapped to. Also if your app is a service that isn't running under the LocalSystem/SYSTEM acount, then any mappings will be local to the service's user account and not global. That is, the service may succeed in creating the mapping but as an interactive user you may not see it in My Computer. There's more info, and the scoping rules for various Windows versions here