Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Executing external files 3

Status
Not open for further replies.

NMe84

Programmer
May 2, 2003
2
NL
I needed to make a menu program that runs in DOS mode that can be changed by editing a simple text file so I can easily run my DOS programs. I got everything working just fine, except for one little thing. When I execute programs in another folder, some of these programs don't work, since they try to find their external files in the same folder as where the menu resides. So I need to know how to change the active path to the folder of the file I want to execute, execute the file, and change the active path back to the menu's folder. Does anyone know if this is possible in Pascal, and if it is, can you tell me how?
I'd also like to know if it's possible to reduce memory usage by Pascal while the external file is being executed.

Thanks in advance! :)
 
I tend to do a rather more longwinded version. I use paramstr(0) to find the full file location of the exe file, and cut it down to a path. Then I append the names of any files the program would expect to find in its own directory to this path. That way it can reconstruct a full file name-and-path for everything it expects to find. This means the program is entirely independant of how it was called (for instance, it can be called by double-clicking on a target in the windows explorer, and it will open with the target identified in paramstr(1)).

The reason I don't actually change the current DOS default directory is that elsewhere in my program I might allow a user to browse the directory structure, and I'm not wanting to look for odd errors caused by the interaction of my program's desire to have a default directory, and the user wanting to set a different default directory....
i.e., the method I use is safe and guarunteed to work, whatever the nature of the program in which I embed it.

I don't think it is possible to do anything about the space taken by your parent Pascal program, because in the DOS environment its space has been allocated for good and is not available to any other program until the parent exits. The only things you can do is use compiler directives to compile it to occupy the bare minimum (smallest surviveable heap and stack spaces), or you could burst into TSR programming. But frankly it would take some fast talking to get me to do anything hairy like that.

Good luck!
 
I've done a program like this before.

1) As Lionel Hill said, use full paths from ParamStr(0). There's no need to ever be in the directory with your program.

2) If you need to be in a particular directory to run a program (generally evidence of bad design of the program) you can either modify your program to switch to the directory or instead of running the program you can run a batch file.

3) To change directories, ChDir(New directory). There's something for changing the current drive also but it's not coming to mind right now--I haven't had reason to use it in many years.

4) It *IS* possible to make this work without your program in memory. You can get the footprint down to 64 bytes IIRC.

Rather than running your program directly you run a batch file we will call menu.bat. Menu.Bat has two lines. The first one runs your program, the second runs Stage2.Bat. When the user picks something in your program a new stage2.bat is written. If they want to quit the file is blank. If they want to run something the first line runs the program and the second line runs menu.bat.

If the object you are running is a batch file you must add the word "call" before it so the system will return to your batch file when done.
 
Thanks for the quick reply. I was so totally lost in the glossary of terms in Pascal that I couldn't think of an obvious function like ChDir... Ah well, my program works perfectly now, and it seems that memory isn't a problem anymore either.

Again, thanks for helping me out, even though it was kind of a n00bish question :)
 
Hey, LorenPechtel, highly cunning with the .bat file. I hadn't thought of that. You've reminded me that years ago when a self-respecting person could still admit to knowing what gwbasic was, I did something similar with batch files (but not as nicely) to overcome the 64K barrier, before realising you could chain a basic program directly from another.
Nice. Thanks!

 
To free up more memory for a child program, you can also dump the memory used by the parent to EMS or disk, thus making all conventional memory (minus a few hundred bytes for the return code) free for the child.
More information can be found in the FAQ section on my website.

Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
 
lionelhill:
What's not self-respecting about knowing what gwbasic is? All that does is says you've been around a while--and what's not to respect about that? I've got QB3 on here and even drag it out every year or two--for simple one-shot number crunching that's no more than a screen of code or so it's still got it's merits.

Bertv100:
Anyone asking a question like this isn't going to be writing the assembly code needed for your approach.
 
I know, but I have a unit somewhere which does this. If I see there's an interest, I can dig it up, make it a bit more user friendly and put it online.

Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top