* System Calls @ 1998-12-16 0:00 mabrouk BELHOUT 1998-12-16 0:00 ` dennison 0 siblings, 1 reply; 21+ messages in thread From: mabrouk BELHOUT @ 1998-12-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-16 0:00 System Calls mabrouk BELHOUT @ 1998-12-16 0:00 ` dennison 1998-12-17 0:00 ` Gilles Sarnikowski 0 siblings, 1 reply; 21+ messages in thread From: dennison @ 1998-12-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-16 0:00 ` dennison @ 1998-12-17 0:00 ` Gilles Sarnikowski 1998-12-17 0:00 ` dennison 0 siblings, 1 reply; 21+ messages in thread From: Gilles Sarnikowski @ 1998-12-17 0:00 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-17 0:00 ` Gilles Sarnikowski @ 1998-12-17 0:00 ` dennison 1998-12-18 0:00 ` mabrouk BELHOUT 1998-12-24 0:00 ` Michael F Brenner 0 siblings, 2 replies; 21+ messages in thread From: dennison @ 1998-12-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-17 0:00 ` dennison @ 1998-12-18 0:00 ` mabrouk BELHOUT 1998-12-24 0:00 ` Michael F Brenner 1 sibling, 0 replies; 21+ messages in thread From: mabrouk BELHOUT @ 1998-12-18 0:00 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-17 0:00 ` dennison 1998-12-18 0:00 ` mabrouk BELHOUT @ 1998-12-24 0:00 ` Michael F Brenner 1998-12-24 0:00 ` dennison ` (2 more replies) 1 sibling, 3 replies; 21+ messages in thread From: Michael F Brenner @ 1998-12-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-24 0:00 ` Michael F Brenner @ 1998-12-24 0:00 ` dennison 1998-12-24 0:00 ` Larry Kilgallen 1998-12-29 0:00 ` Robert A Duff 1998-12-25 0:00 ` dewar 1998-12-25 0:00 ` dewar 2 siblings, 2 replies; 21+ messages in thread From: dennison @ 1998-12-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-24 0:00 ` dennison @ 1998-12-24 0:00 ` Larry Kilgallen 1998-12-25 0:00 ` dewarr 1998-12-29 0:00 ` Robert A Duff 1 sibling, 1 reply; 21+ messages in thread From: Larry Kilgallen @ 1998-12-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-24 0:00 ` Larry Kilgallen @ 1998-12-25 0:00 ` dewarr 1998-12-29 0:00 ` Tarjei Tj�stheim Jensen 0 siblings, 1 reply; 21+ messages in thread From: dewarr @ 1998-12-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-25 0:00 ` dewarr @ 1998-12-29 0:00 ` Tarjei Tj�stheim Jensen 1998-12-29 0:00 ` robert_dewar 1998-12-29 0:00 ` Larry Kilgallen 0 siblings, 2 replies; 21+ messages in thread From: Tarjei Tj�stheim Jensen @ 1998-12-29 0:00 UTC (permalink / raw) 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, ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-29 0:00 ` Tarjei Tj�stheim Jensen @ 1998-12-29 0:00 ` robert_dewar 1998-12-29 0:00 ` Larry Kilgallen 1 sibling, 0 replies; 21+ messages in thread From: robert_dewar @ 1998-12-29 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-29 0:00 ` Tarjei Tj�stheim Jensen 1998-12-29 0:00 ` robert_dewar @ 1998-12-29 0:00 ` Larry Kilgallen 1998-12-30 0:00 ` dennison 1 sibling, 1 reply; 21+ messages in thread From: Larry Kilgallen @ 1998-12-29 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-29 0:00 ` Larry Kilgallen @ 1998-12-30 0:00 ` dennison 0 siblings, 0 replies; 21+ messages in thread From: dennison @ 1998-12-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-24 0:00 ` dennison 1998-12-24 0:00 ` Larry Kilgallen @ 1998-12-29 0:00 ` Robert A Duff 1998-12-30 0:00 ` dennison 1 sibling, 1 reply; 21+ messages in thread From: Robert A Duff @ 1998-12-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-29 0:00 ` Robert A Duff @ 1998-12-30 0:00 ` dennison 1999-01-02 0:00 ` Chris Morgan 0 siblings, 1 reply; 21+ messages in thread From: dennison @ 1998-12-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-30 0:00 ` dennison @ 1999-01-02 0:00 ` Chris Morgan 0 siblings, 0 replies; 21+ messages in thread From: Chris Morgan @ 1999-01-02 0:00 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-24 0:00 ` Michael F Brenner 1998-12-24 0:00 ` dennison @ 1998-12-25 0:00 ` dewar 1998-12-25 0:00 ` dewar 2 siblings, 0 replies; 21+ messages in thread From: dewar @ 1998-12-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 1998-12-24 0:00 ` Michael F Brenner 1998-12-24 0:00 ` dennison 1998-12-25 0:00 ` dewar @ 1998-12-25 0:00 ` dewar 2 siblings, 0 replies; 21+ messages in thread From: dewar @ 1998-12-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls
@ 1998-12-23 0:00 mabrouk BELHOUT
0 siblings, 0 replies; 21+ messages in thread
From: mabrouk BELHOUT @ 1998-12-23 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* System Calls @ 2001-07-10 18:20 Matt Raikes 2001-07-10 21:55 ` Dale Stanbrough 0 siblings, 1 reply; 21+ messages in thread From: Matt Raikes @ 2001-07-10 18:20 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: System Calls 2001-07-10 18:20 Matt Raikes @ 2001-07-10 21:55 ` Dale Stanbrough 0 siblings, 0 replies; 21+ messages in thread From: Dale Stanbrough @ 2001-07-10 21:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2001-07-10 21:55 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-12-16 0:00 System Calls mabrouk BELHOUT 1998-12-16 0:00 ` dennison 1998-12-17 0:00 ` Gilles Sarnikowski 1998-12-17 0:00 ` dennison 1998-12-18 0:00 ` mabrouk BELHOUT 1998-12-24 0:00 ` Michael F Brenner 1998-12-24 0:00 ` dennison 1998-12-24 0:00 ` Larry Kilgallen 1998-12-25 0:00 ` dewarr 1998-12-29 0:00 ` Tarjei Tj�stheim Jensen 1998-12-29 0:00 ` robert_dewar 1998-12-29 0:00 ` Larry Kilgallen 1998-12-30 0:00 ` dennison 1998-12-29 0:00 ` Robert A Duff 1998-12-30 0:00 ` dennison 1999-01-02 0:00 ` Chris Morgan 1998-12-25 0:00 ` dewar 1998-12-25 0:00 ` dewar -- strict thread matches above, loose matches on Subject: below -- 1998-12-23 0:00 mabrouk BELHOUT 2001-07-10 18:20 Matt Raikes 2001-07-10 21:55 ` Dale Stanbrough
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox