brake@ari-hq1.ARPA (04/18/85)
I am working on an application using dBASE III and Framework (what did I do to deserve this?). What I would like to do is pass information between the two programs via the environment variables. I can get at these variables from both programs, but it looks like MS-DOS uses a stack to hold the variables and after I set them and return to a command file they return to their old values. Has anyone done this? The documentation is very sparse and when it exist it is usually wrong. Any help would be appreciated. As a personal opinion, neither of these programs are worth the media they come on. Framework tries to do everything in memory and on this system with 640k I get the nasty message that we are out of memory. What would they have done on a PDP 8? If they would remove all of the bells and whistles it would be much nicer. The copy protection scheme used by dBase III requires the master disk to be in drive A whenever the program is started. If you forget, it tells you that you have an illegal copy and aborts. I usually have to start it up twice. When you do get it running, it fills the screen with an obnoxious copyright notice informing you that you don't own the software only the right to use it. Dennis [BRAKE@ARI-HQ1] ------
jchapman@watcgl.UUCP (john chapman) (04/21/85)
> I am working on an application using dBASE III and Framework (what did > I do to deserve this?). What I would like to do is pass information > between the two programs via the environment variables. I can get at > these variables from both programs, but it looks like MS-DOS uses a > stack to hold the variables and after I set them and return to a command > file they return to their old values. Has anyone done this? The documentation > is very sparse and when it exist it is usually wrong. Any help would be > appreciated. . . . > Dennis [BRAKE@ARI-HQ1] The manuals I got with my release of Ms-Dos (from Seattle Computer) say essentialy the same thing as you have conjectured. An alternative might be to install your own device driver which does nothing but allow reading/writing to a small buffer so the programs can trade info back and forth easily. I don't know what your doc. is like but the Seattle Computer stuff is quite clear and making your own driver would be easy. John ...!watmath!watcgl!jchapman
shor@sphinx.UChicago.UUCP (Melinda Shore) (04/22/85)
Path: sphinx!gargoyle!ihnp4!cbosgd!clyde!watmath!watcgl!jchapman Date-Received: Sun, 21-Apr-85 19:53:12 CST > An alternative > might be to install your own device driver which does nothing but > allow reading/writing to a small buffer so the programs can trade > info back and forth easily. Actually, this is how environment variables are handled. The address of the buffer is located in a program's program segment header. -- Melinda Shore University of Chicago Computation Center uucp: ..!ihnp4!gargoyle!sphinx!shor Mailnet: staff.melinda@uchicago.mailnet Bitnet: shor%sphinx@uchicago.bitnet ARPA: staff.melinda%uchicago.mailnet@mit-multics.arpa
bc@cyb-eng.UUCP (Bill Crews) (04/23/85)
The deal is that you are working with the child process's environment, which was set up as a copy of the parent's environment when the child was forked. There are probably several ways to solve your problem; what comes to mind is that two undocumented DOS function calls (things you get at with int 21h) not only get the segment address of the current psp (program segment prefix) but can also *set* (think on this!) a psp as being the current psp . . . like, multitasking, huh? These are functions 51h and 50h respectively. You could get the current psp and save it, set your parent's psp as current (communicating your parent's psp to the child is comething you must take care of some way or another) and then access the environment. You will be accessing the parent environment. Be aware, however, that you have actually set the parent to be the current process, so any files you might open will belong to the parent, *not* the child! So be careful to set the psp back to the child before continuing. There may be an easier way, but I can't think of it offhand. By the way, I don't warrant the use of functions 50h and 51h -- I just use them and they seem to work. Good luck. -- / \ Bill Crews ( bc ) Cyb Systems, Inc \__/ Austin, Texas [ gatech | ihnp4 | nbires | seismo | ucb-vax ] ! ut-sally ! cyb-eng ! bc