System Calls

System Calls

[Matt Raikes]

I am attempting to call a Unix(gzip) executable with in my Ada code,
must I go through a pragma or there an easier way of doing that..
Thanks in advance.

Re: System Calls

[Dale Stanbrough]

Matt Raikes wrote:

> I am attempting to call a Unix(gzip) executable with in my Ada code,
> must I go through a pragma or there an easier way of doing that..
> Thanks in advance.

You (obviously) need to call the operating system to do this.
Unix requires a C -calling convention- (not for you to call
from a C program), and this can be done from Ada by using
the appropriate pragrams.

Prebuilt solutions include the Posix interface Florist, and 
a couple of others that are about.

If you know Ada it's not a very hard job to create such a binding.

Dale

Re: System Calls

[mabrouk BELHOUT]

mabrouk BELHOUT wrote:

> Hi,
>
> i am looking for a C librarie to bind to Ada for calling system
> subroutines or programs.
> if this exist anywhere please help.
>
> --mouly

i answer myself : you can  use gnat lib., you can find here a
description :

http://www.ida.liu.se/education/ugrad/progkon/Ada/ada-sw/gnat/gnatAdaLib/gnatadalib.html

-- mouly

System Calls

[mabrouk BELHOUT]

Hi,

i am looking for a C librarie to bind to Ada for calling system
subroutines or programs.
if this exist anywhere please help.



--mouly

Re: System Calls

[dennison]

In article <3677F2B6.FDC20000@gla.ecoledoc.lip6.fr>,
  mabrouk BELHOUT <belhout@gla.ecoledoc.lip6.fr> wrote:
> i am looking for a C librarie to bind to Ada for calling system
> subroutines or programs.
> if this exist anywhere please help.

There are tons of them. I'm sorry I can't give a better answer, but I have no
clue what "system" you are talking about. Is it Windows NT 4? Is it Linux? Is
it a Commodore 64? Is it a Newton? I tried asking my Magic 8-Ball, but it
just said "Ask again later". :-)

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Calls

[Gilles Sarnikowski]

> There are tons of them. I'm sorry I can't give a better answer, but I have no
> clue what "system" you are talking about. Is it Windows NT 4? Is it Linux? Is
> it a Commodore 64? Is it a Newton? I tried asking my Magic 8-Ball, but it
> just said "Ask again later". :-)

i was talking about every systems: i just want to call another executable.
i'am developping on unix.
can this help you to help me ?
--mouly

Re: System Calls

[dennison]

In article <36793CF7.6795AA80@gla.ecoledoc.lip6.fr>,
  Gilles Sarnikowski <sarnikowski@gla.ecoledoc.lip6.fr> wrote:
> > There are tons of them. I'm sorry I can't give a better answer, but I have
no
> > clue what "system" you are talking about. Is it Windows NT 4? Is it Linux?
Is
> > it a Commodore 64? Is it a Newton? I tried asking my Magic 8-Ball, but it
> > just said "Ask again later". :-)
>
> i was talking about every systems: i just want to call another executable.
> i'am developping on unix.

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.

We're getting there. But 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?

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Calls

[mabrouk BELHOUT]

> 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.
>
> We're getting there. But 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?

ok, i know all this.  I just want to run an exe and wait for him, no direct
communication no different process or task...
only launch and wait until the termination. I think i need to interface with 'C',
isn't it ?
--mouly

Re: System Calls

[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         

Re: System Calls

[dennison]

In article <75tmgp$bjf@top.mitre.org>,
  mfb@mbunix.mitre.org (Michael F Brenner) wrote:

> 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

The problem is in the little differences. Dos uses '\', where Unix and VMS
use '/'. In Unix that '\' is quite liable to be used in the file name to
escape special characters. In DOS, devices are at the front of the path with
a ':'. In Unix devices are simply the first path or two in the filename. In
Unix and VMS '::' can be used to indicate the machine owning the device in
some circumstances. In Unix disks must be mounted before use. In DOS and
Windows, they are generally automaticly detected.

Of course the scripting languages have to deal with these very issues, and
have each come up with their own partial solutions.

> 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.

I notice your list is quite long. That genrally means it is not
comprehensive. :-) Any package that contained all this stuff would be far
from little. Plus large parts of it are unrelated. Yuk. You are talking about
at least 8 different packages here. Some of it is doable, but I doubt a
graphics package that just provided the graphics function you mention would
be useful to anyone. Start adding many more functions, and you might as well
just implement a TCL binding.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Calls

[Larry Kilgallen]

In article <75tv4m$vmm$1@nnrp1.dejanews.com>, dennison@telepath.com writes:
> In article <75tmgp$bjf@top.mitre.org>,
>   mfb@mbunix.mitre.org (Michael F Brenner) wrote:
> 
>> 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
> 
> The problem is in the little differences. Dos uses '\', where Unix and VMS
> use '/'. In Unix that '\' is quite liable to be used in the file name to
> escape special characters.

Actually, VMS uses "[","]","<",">","." and the ever popular ";".
";" is used in particular for file versions, and a VMS user faced
with a program that did not handle file versions properly would
judge it as a very poor program indeed.

So the problem is just as you said, only worse.

Larry Kilgallen

Re: System Calls

[dewarr]

In article <1998Dec24.140342.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> Actually, VMS uses "[","]","<",">","." and the ever
> popular ";".
> ";" is used in particular for file versions, and a VMS
> user faced
> with a program that did not handle file versions properly
> would
> judge it as a very poor program indeed.
>
> So the problem is just as you said, only worse.


Yes but the original questioner excluded VMS, and that
is perfectly reasonable, a package that covers Unix and
NT (and OS/2 and Win95 without extra effort) is still very
useful to most people. The VMS user community is a small
sliver, and while it is nice to include VMS where possible
(as is done for example in GNAT.OS_Lib) it would be a
mistake to let the idiosyncrasies of VMS impede progress
here!

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Calls

[Tarjei Tj�stheim Jensen]

dewarr@my-dejanews.com wrote >
>Yes but the original questioner excluded VMS, and that
>is perfectly reasonable, a package that covers Unix and
>NT (and OS/2 and Win95 without extra effort) is still very
>useful to most people. The VMS user community is a small
>sliver, and while it is nice to include VMS where possible
>(as is done for example in GNAT.OS_Lib) it would be a
>mistake to let the idiosyncrasies of VMS impede progress
>here!


I don't think there is a particular need to exclude anybody. Most OSes has
similar semantics with regards to drives, directories and file names. The
problem is that syntax is different. It is easy to create an intermediate
description of these things so that a program might reason about its
environment in a sensible manner. All that is needed is a translator to and
from that representation.

A sensible representation of the intermediate description would be something
like <length><tag><content> used recursively (at least if it is transmitted or
stored somewhere). Tagging items allows programs to disregard what they don't
know or care about. These items may be version number or some other file info
such as dates, last backup, protection, file type, etc.

Greetings,

Re: System Calls

[robert_dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

In article <76ai9b$ion5@news.kvaerner.com>,
  "Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no>
wrote:
>
> dewarr@my-dejanews.com wrote >
> I don't think there is a particular need to exclude
> anybody. Most OSes has similar semantics with regards to
> drives, directories and file names. The problem is that
> syntax is different. It is easy to create an intermediate
> description of these things so that a program might
> reason about its environment in a sensible manner. All
> that is needed is a translator to and from that
> representation.

That's misleading. In the case of VMS, the file versions
add a completely new dimension, and require different
thinking. For example, an editor is expected to create a
new version of the file being edited, and leave the
original input file completely unchanged. This is quite
a different fundamental semantics from a normal unix style
editor. Version numbers on files are pervasive and need to
be thought through carefully. For example, if you change
the name of a file, does the version change? If you copy
a file, is the version number preserved? All such questions
have reasonable answers, but the questions themselves just
do not arise in the context of a unix style file system
without version numbers.

I am not saying that it is impossible to take this into
account in a general design, but saying that the issue is
purely syntactic misses the boat!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Calls

[Larry Kilgallen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

In article <76ai9b$ion5@news.kvaerner.com>, "Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no> writes:
> 
> dewarr@my-dejanews.com wrote >
>>Yes but the original questioner excluded VMS, and that
>>is perfectly reasonable, a package that covers Unix and
>>NT (and OS/2 and Win95 without extra effort) is still very
>>useful to most people. The VMS user community is a small
>>sliver, and while it is nice to include VMS where possible
>>(as is done for example in GNAT.OS_Lib) it would be a
>>mistake to let the idiosyncrasies of VMS impede progress
>>here!
> 
> 
> I don't think there is a particular need to exclude anybody. Most OSes has
> similar semantics with regards to drives, directories and file names. The
> problem is that syntax is different.

No, the VMS semantics for file versions do not particularly match
any other file system, and they are crucial to the VMS experience.

For that matter, the semantics for secondary appearances ofa
single file seem to vary from OS to OS (alias, soft links,
and hard links are some of the names I have heard).

Or consider that Macintosh files have a second fork, called a
"resource fork" which is crucial to proper programming.  Who
else has that ?  Why Windows NT, which can have _many_ additional
forks using the NTFS file system.

Let us not have the hallmark of an Ada program be that it is
"least common denominator" when it comes to OS features. Ada
may be a lovely language, but it cannot take all the work out
of programming.

Larry Kilgallen

Re: System Calls

[dennison]

In article <1998Dec29.144631.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:

> No, the VMS semantics for file versions do not particularly match
> any other file system, and they are crucial to the VMS experience.

I think RMS's original idea for the GNU Hurd filesystem was going to include
file versions. I don't know whatever became of that.

> For that matter, the semantics for secondary appearances ofa
> single file seem to vary from OS to OS (alias, soft links,
> and hard links are some of the names I have heard).

Yeah. Some Unix applications require copies of things everywhere on the theory
that this feature makes it painless. Then they get ported to NT. Ouch!

> Let us not have the hallmark of an Ada program be that it is
> "least common denominator" when it comes to OS features. Ada
> may be a lovely language, but it cannot take all the work out
> of programming.

Amen to that!

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Calls

[Robert A Duff]

dennison@telepath.com writes:

> The problem is in the little differences. Dos uses '\', where Unix and VMS
> use '/'. In Unix that '\' is quite liable to be used in the file name to
> escape special characters. In DOS, devices are at the front of the path with
> a ':'. In Unix devices are simply the first path or two in the filename. In
> Unix and VMS '::' can be used to indicate the machine owning the device in
> some circumstances. In Unix disks must be mounted before use. In DOS and
> Windows, they are generally automaticly detected.

The Symbolics Lisp machine had a pretty decent solution to these kinds
of problems.  They invented an abstraction that included pretty-much a
superset of all the bells and whistles on the various systems.  At least
part of the problem is pretty trivial -- I mean, "list of directory
names" is an abstraction that need not care about "/" vs "\".  Not all
of it's easy, but the Lisp Machine solution seemed pretty well thought
out to me at the time.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: System Calls

[dennison]

In article <wccg19y8zti.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:

> part of the problem is pretty trivial -- I mean, "list of directory
> names" is an abstraction that need not care about "/" vs "\".  Not all

Perhaps we should compromise and use "|".  :-)

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Calls

[Chris Morgan]

dennison@telepath.com writes:

> > part of the problem is pretty trivial -- I mean, "list of directory
> > names" is an abstraction that need not care about "/" vs "\".  Not all
> 
> Perhaps we should compromise and use "|".  :-)

No wait, don't say that, if I even begin to think about unifying
the directory separator and the pipe operator my head hurts.

-- 
Chris Morgan <mihalis at ix.netcom.com>		http://www.mihalis.net
	         "At least my mother isn't on the 
                  cover of Crack Whore magazine"

Re: System Calls

[dewar]

In article <75tmgp$bjf@top.mitre.org>,
  mfb@mbunix.mitre.org (Michael F Brenner) wrote:

> ...
> 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.


Some of these functions can be found in POSIX (e.g. look
at the florist package for GNAT). If you are using GNAT,
also look at the GNAT.xxx library routines (e.g. there is
one for reading directories, and GNAT.OS_Lib has a Spawn
routine for calling executables that works on all targets,
as well as other useful stuff).

Robert Dewar
Ada Core Technologies

P.S. The pixel stuff seems entirely at the wrong level to
assume that a universal package is possible, it is more
appropriate to standardize on the use of a higher level
graphics package than try to mess with pixels, which is
simply not possible in some environments.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Calls

[dewar]

In article <75tmgp$bjf@top.mitre.org>,
  mfb@mbunix.mitre.org (Michael F Brenner) wrote:

> ...
> 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.

By the way, peek and poke are in the language, see
System.Storage_Elements.

Robert Dewar
Ada Core Technologies


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own