Re: System Calls

[mfb@mbunix.mitre.org (Michael F Brenner)]

Gilles > ...want to call another executable

T.E.D. Responds:
  Invoking another executable is not a standard function in Ada 
  like it is in a typical scripting language. 
  Thus you have to use OS calls, which means the
  answer depends on the OS you are using.

Gilles > ... developing on unix

T.E.D. Respons:
  ...how do you want the executable to behave? 
  Should it run simultaniously with your already running Ada program? 
  Should your Ada program wait for the other executable to complete? 
  Should the Ada program terminate entirely in deference to the new executable?
  Does any information need to be communicated between them, or 
    is this a "fire and forget" situation?


When we first started doing Ada, many of us assumed that tasking 
had answered those questions for us. In some tasking runtimes, tasking
is actually the answer to those questions. On systems with multitasking
kernels like NT or unix, it seems that it is easier to permit tasking
to do the system calls for this than not. 

On bare machines, like DOS or cross compilers, a multitasking extender
or kernel would have to be supplied like DESQVIEW or PHARLAP or any of
the others.

Since DOS and UNIX and VAXen are so similar in their ideas of what a 
subdirectory is and what happens when executables are spawned, it
seems that the basic commands like change directory, rename directory,
move directory, copy directory, get current directory, concatenate
directory to filename, run an executable in parallel, run an executable
in series, put message into shared memory, wait for program, 
terminate, minimize, get mouse coordinates, get interrupt on
key down or key up or mouse button down or up, light up filled
rectangle on the screen, read the color of a pixel, rename a file,
wait for executable, peek/poke, get/put/seek to ordinary
operating system files, parse filename, etc., could be standardized 
without pain in a little operating system-independent package.

little operating system