X-Authentication-Warning: delorie.com: mailnull set sender to opendos-bounces using -f Message-ID: <01FD6EC775C6D4119CDF0090273F74A455A8E5@emwatent02.meters.com.au> From: "da Silva, Joe" To: "'opendos AT delorie DOT com'" Subject: RE: system calls Date: Fri, 4 Jan 2002 11:55:31 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Reply-To: opendos AT delorie DOT com The "swapvectors" stuff is recommended by Borland, because the TP run-time-library hooks or supplants some interrupt vectors during the execution of your program, hence an external program may require the original (normal) DOS interrupt vectors instead. Another subtlety is the use of the "$M" compiler directive. Normally, TP will allocate all free memory to your program, for heap space, I guess. This directive can override this behaviour, so your invoked external program will have some RAM left for it to run! Anyway, that's probably all the TP-specific stuff we should discuss on this list, lest this thread becomes too off-topic. Hopefully this is enough for you to "carry on" with, anyway. Aside from the inbuilt help in the TP compiler IDE, you can also get a useful guide to TP at "ftp://garbo.uwasa.fi/pc/turbopas/tptutr11.zip". If the external program produces a result code that will fit in a byte, you could just use it's exit code, to pass this result/value to your calling program. Otherwise, you would need to use file I/O (either by re-direction or by explicit file operations) instead. Another possibility might be to use a clipboard API, if it exists. I believe this is possible under Windoze (ie. a DOS box under Windoze), this would also be technically feasible under plain DOS, if someone has produced a TSR, that provides an equivalent API (don't know). Joe. > -----Original Message----- > From: DONALD PEDDER [SMTP:jims_son AT jedi DOT apana DOT org DOT au] > Sent: Thursday, January 03, 2002 9:12 PM > To: 'opendos AT delorie DOT com' > Subject: RE: system calls > > Joe, > > Except for the "swapvectors" stuff (which I could read up about) I > follow the example code you gave, bar one thing - what happens to the > output of the called command? Is there a way to put it straight into a > variable, or would you have to re-direct the output to a file and access > it from there? > > Thanks, > dp. >