dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/08/88)
>My second idea: use LoadSeg/CreatProc/WBStartup/UnLoadSeg etc. ok, it seems >that C-A forgot that a process might return a return value to WorkBench. >Change the startup/exit protocol by adding this to the message? NO that >would break WorkBench. OK no return value from WB. What else??? > >My third idea: this works but is dirty, uses inside info on Dos etc. > >Your idea? Any official / compatible solution? If you find my shell source (*not* the drew version), it has two modules that handle loading and running a program and getting the return value. It's a mess. Most of the mess is to allow for running BCPL program. -Matt
rap@ardent.UUCP (Rob Peck) (04/09/88)
In article <1779@sugar.UUCP>, schaub@sugar.UUCP (Markus Schaub) writes: > > My first idea: use Dos.Execute. This works except that I cannot get the > return value of the compiler. If the compilation fails, Execute writes > a nice message "m2c aborted with error 20" or similar. Execute however > returns that the execution was successful. > What am I doing wrong? What is Execute doing wrong? Execute only works if > the program was started from CLI? (Just another problem, or is it a BUG?) I had discussed this problem with Tim King just before 1.1 came out - it seems that: success = Execute("programname",0,0); returns the status of "was I able to spawn another process or not". I had requested that Execute be made to respond to the return status of the program itself, but as I recall, Execute operates in an async mode, so when it calculates the success value, it is disconnected from what is happening to the program that it spawned. I think the result is just like saying RUN programname from the CLI... like there is no place for the return result to go and the async nature of the beast makes this impossible. There are make programs for both Lattice and Manx C, on FISH disks - I have not checked how they handle this, but I suspect it is not via the Execute() function. Rob Peck ...ihnp4!hplabs!ardent!rap