run a program from within another

[meynaf]

Hi,

The problem here is to simply launch some program, wait for it to return (or not), and (eventually) continue with the original code. Say, calling some external program like a routine would be.

I could run a program with SystemTagList() or Execute() but I can not detect if the target program exists or not : if it does not, this stupidly writes some "command not found" message to the console...
In addition it seems SystemTagList() is unable to run a program with PROGDIR: in the path for the executable...
It also seems there's no way to grab the return code of the command.

So did I miss something important or is dos.library real stupid ?

Note : used language is asm. But it shouldn't matter.

[SavageMonkey]

Could you use execute() and redirect the command's output to NIL: ..?

[meynaf]

I do *not* want to redirect the command's output to NIL: because the program I run may well output something useful.
Besides, this would just fail silently if it's not found.

[SavageMonkey]

Why can't you detect the program's existence first?

[meynaf]

The fact a file exists doesn't make it a valid executable.

[ross]

LoadSeg?

[SavageMonkey]

I know, you said you couldn't tell if the target program exists or not, I wondered why.

[meynaf]

Originally Posted by ross

LoadSeg?

That will just load the program in memory, not create a new process, allocate stack, give args, etc.

Originally Posted by SavageMonkey

I know, you said you couldn't tell if the target program exists or not, I wondered why.

Well the program may exist but still fail in a number of ways... It's general failure i wish to catch.

[ross]

Originally Posted by meynaf

That will just load the program in memory, not create a new process, allocate stack, give args, etc.

You can manually do it
I realize that it is a little inconvenient..

[meynaf]

Originally Posted by ross

I realize that it is a little inconvenient..

Apparently, yes. I just wanted some "cheap" way. Seems Atari ST has better PEXEC function

[SavageMonkey]

It's a shame that Execute() doesn't return the command's return code.

I'm not sure of your use case but wonder if you could write a script that runs your command and checks its return code and execute the script instead, though I appreciate that's a bit clunky.

[meynaf]

My use case is to write a wrapper function and then reuse it in every program that will need to call another. Therefore it must be clean of "clunky" things

Now wondering if i can do that (or not) with LoadSeg and CreateNewProc/RunCommand.
Of course i'd like to have both synchronous and asynchronous modes

[alkis]

Autodocs on execute say the result is bool on if it found and executed the prorgam or not.

http://amigadev.elowar.com/read/ADCD.../node015E.html

That does not apply?

[SavageMonkey]

lol... would SystemTagList do the job if it wasn't for the PROGDIR: issue..?

[Don_Adan]

Originally Posted by meynaf

The fact a file exists doesn't make it a valid executable.

You can check, if existed file is executable, this is easy enough. Check for $000003f3 at begin and $000003f2 at end of file. And for kick 2.0+ you must check also for R and E bits.

[meynaf]

Originally Posted by alkis

Autodocs on execute say the result is bool on if it found and executed the prorgam or not.

http://amigadev.elowar.com/read/ADCD.../node015E.html

That does not apply?

I don't know what return code it gives, but when i saw the error message in the cli i knew it did not work as i wanted...

Originally Posted by SavageMonkey

lol... would SystemTagList do the job if it wasn't for the PROGDIR: issue..?

Nope - it also shows bogus error message in cli.

Originally Posted by Don_Adan

You can check, if existed file is executable, this is easy enough. Check for $000003f3 at begin and $000003f2 at end of file. And for kick 2.0+ you must check also for R and E bits.

That's quite a weak check, and will catch libraries, devices, handlers, etc, as well as malformed executables.


Oh, yes, just to add to the horror of it... It seems LoadSeg() will probably not apply to internal (rom) commands. Neither would checking if file exists, of course

[Don_Adan]

Originally Posted by meynaf

I don't know what return code it gives, but when i saw the error message in the cli i knew it did not work as i wanted...



Nope - it also shows bogus error message in cli.



That's quite a weak check, and will catch libraries, devices, handlers, etc, as well as malformed executables.


Oh, yes, just to add to the horror of it... It seems LoadSeg() will probably not apply to internal (rom) commands. Neither would checking if file exists, of course

No, this is good/enough test. All good written libraries, devices, handlers will be not crashed after running, because has moveq #x,D0, rts at begining. And remember dont exist 100% test for crash protection. Someone can put trash data inside code, or one bit can be changed in code when file was copying (it occured often for weak HD or DD or damaged RAM). Od course you can add more tests for object files, more hunks to check or check if first called data is valid 68k command.

But of course if you want to be perfect, you can add CRC check for every file and ignore files within wrong CRC.

[Don_Adan]

And of course, all valid Amiga exe files packed with absolute addressing mode or which used direct access to VBR = 0, will be crash Amiga too. Then only solution is checking CRC or something similar.

[meynaf]

The problem isn't a potential crash. The problem is bogus error message appearing on cli when the command can't be loaded. Libraries, etc, have moveq #-1,d0+rts at start and this *will* trigger the message even though the exe is perfectly valid.

[Don_Adan]

Originally Posted by meynaf

The problem isn't a potential crash. The problem is bogus error message appearing on cli when the command can't be loaded. Libraries, etc, have moveq #-1,d0+rts at start and this *will* trigger the message even though the exe is perfectly valid.

Then check if first longword of running code is moveq #-1,d0, rts, and prevent this file from be called.