Console App ChDir function - cause folder to be changed after program terminates

I have just moved a Delphi 6 environment from XP to Vista 64 bit and an old console app "GO"  I wrote 10+ years ago won't run under Vista 64.  All it is supposed to do is accept a param line argument, looks it up in a list of shortcuts then changes the directory to that folder if it is found (so "GO Z" will change to whatever folder "Z" looks up to).  The ChDir function correctly changes to the desired folder, but ONLY for the duration of that execution.  When I get back to the cmd.exe prompt I am still where I was before.  Is there a different function or technique that will accomplish what I want to do?

I have no real feeling for the EE points system - H :-}
hnrsoftwareSenior Software EngineerAsked:
Who is Participating?
Emmanuel PASQUIERFreelance Project ManagerCommented:
excellent question.
I tried to create a normal application that will terminate itself after using ChDir. But exactly as the console application it does not reflect once returned to cmd prompt. I suppose that MS added one unwanted piece of protection that is going to be difficult (if even possible) to workaround directly with an application.

So I guess you have only one option left :
instead of calling your application, you call a batch that will look that way:

GotoLink.bat :
call GOFolder.bat

and your GO.exe will fill the GOFolder.bat with :
cd D:\MyLinkStartFolder
D:      <== add this to change also the current drive

to do that, you console app will look like :
 GotoDir:=...;  // find the dir
 GoBatch.Add('cd '+AnsiQuotedStr(GotoDir,'"'));

Open in new window

hnrsoftwareSenior Software EngineerAuthor Commented:
Hi - I will wait a day or so to see if any Delphi-only ideas show up, but your approach ought to work with the addition of a %1 param in the Gotolink  batch file to pass to the temp batch file creation program.  I can see how to structure things so I can type ">go xxx" and get where I intend.

I guess anyone who still spends time at the DOS prompt deserves kludges, but it is still annoying.  I suppose I should just be thankful that Delphi 6 still works under Vista.  I'm supposed to continue on with the free "upgrade" to Windows 7, but I really dislike it on my wife's machine so I will wait until I am forced to change.  Thanks for your solution.
Emmanuel PASQUIERFreelance Project ManagerCommented:
> with the addition of a %1 param in the Gotolink  batch file to pass to the temp batch file creation program.
exactly , I forgot it :o)

I know what you mean, about these "modern" OS. Progress often means abandoning things that used to work for ages. That's too bad, but that is also necessary, most of the time. Maybe not with that extra protection of the current directory in cmd...
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

Hi there,

Give this API a try - it should work in theory. From your discussion above, I take it the link is enough to give you ideas to carry out.
hnrsoftwareSenior Software EngineerAuthor Commented:
Hi cyberkiwi - I going to accept epasquier's solution because I can see how to make it work.  There may be some significant point you are making with your link, but I sure can't see it.  It appears to be about doing screen output in a Windows 2000 environment.  Thank you for your effort.
Emmanuel PASQUIERFreelance Project ManagerCommented:
Hum. Do you mean he could use that to send keys to the cmd prompt to do a cd command AFTER the program terminate ? I'm not sure that would be possible because the input would be instantly relayed to the currently running application within the console. This API is generally used from applications that run other process in console they created, not the other way around.

In theory, the Go application could launch another win32 process with the folder to go to in parameter and it's own process handle, then terminate. The new application would then wait for the Go application to terminate, find out the console handle it was launched (maybe it would be easier for the Go application to know in which console handle it was run), then use WriteConsoleInput to simulate the typing and running of the cd command, and terminate.
That would be fun to do.
hnrsoftwareSenior Software EngineerAuthor Commented:
I hate to do the kludge aspects of the solution, but at least it should work and get me back on track with my real work.
hnrsoftwareSenior Software EngineerAuthor Commented:
Hi epasquier - it is already pretty easy (and useful) to use the Shell API functions to launch new processes and start them in a desired folder.  All I really wanted to do with this situation was provide an editable list of shortcuts for the "CD" command.  I think my "GO" program goes back to a Turbo Pascal utility I wrote back in the 90s - source code long gone.  My current urgency is that the cmd.exe environment in Vista 64 seems to have degraded one more notch from XP and appearantly can no longer run (some?) 32-bit exe files.  Go,exe was last compiled in 1998.  I don't particularly care why it no longer executes, only that it means that I will probably find some other things not working as well......  Oh well.....   if it was easy, it probably wouldn't be so much fun....   Howard
This would have worked:

Start new process with parameters.
New process is not visible and delays 200ms.
Quit console app.
Invisible process uses SendKeys to change dir (visibly) and quits.
The console app can find the host command prompt session PID and pass to new process.
hnrsoftwareSenior Software EngineerAuthor Commented:
cyberwiki - OK - now I see where you were headed.  I think this would be as awkward as the batch creation method.  I think the "go" process would also have to send an "exit" string to the cmd.exe that executed it in the first place as well.  I may try this just for fun, but it won't be any cleaner.  Thank you for the clarification.  Howard
Emmanuel PASQUIERFreelance Project ManagerCommented:
@cyberkiwi : I believe it would have worked , with SOME restriction : it cannot be used within a batch. And using a delay is sketchy. All I say is that this solution, involving another executable, is not very reliable, and not less dirty than writing a batch file.

@hnr : I too made such a thing in Turbo Pascal ages ago, along with some kind of graphic shell, I believe it was around 90-92... At that time the whole system was already based on batch files dynamically generated called within a loop in a main batch. That might be the only 'dirty' trick I know still running 20 years after, from DOS 3.0 to Windows Seven. I think it's so basic that it should work even in 50 years - or M$ really went crazy enough to remove .BAT files support from their OS
hnrsoftwareSenior Software EngineerAuthor Commented:
Hi epasquier - In a 40 year professional computer programming career, I usually had to learn a new machine, a new operating system, text editor, compiler language... about every 3 years.  It got very old, very fast.  When I found Turbo Pascal, there was no looking back - smart compiler, smart linker, "units", separating interface and implementation, and then "objects" -- WOW!  I started making code libraries and find comments dated in the early 90s on some code I still use today.  (The downside to re-using code is that if you go down the wrong path, you tend to stay down the wrong path for longer...)  Thanks for your thoughts.  Howard
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.

All Courses

From novice to tech pro — start learning today.