From: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
Message-Id: <199902181830.NAA27585@mccoy2.ECE.McGill.CA>
Subject: Re: inetutils ?
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Thu, 18 Feb 1999 13:30:21 -0500 (EST)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.990218100609.3649F-100000@is> from "Eli Zaretskii" at Feb 18, 99 10:06:27 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Bonjour M. Eli Zaretskii

> Just to cover a few tidbits that Richard Dawe didn't:
> 
> > - how about chroot () ? supported ?
> 
> There's no `chroot' in DJGPP's library.  So, to support this
> functionality, I'd suggest to override the library version of `chdir'
> with a custom one that maintains the current root, prepends it to all
> absolute file names, and disallows changing directory above the
> current root.  `chroot' will then just set an internal variable.

Good idea, but not enough, chdir is not the only point of entry
for the filesystem, for example in ftp someone could do a
get D:/djgpp/etc/file

for djgpp :
char * _rootpath;
int chroot (const char *path)
{
	_rootpath = strdup(path);
	return 0;
}

and _rootpath prepend at any file access.

> > - the infamous fork (). For example inetd on a busy
> > day, with a good wind can for requests in 2 digits
> > per second. Can djgpp fork()'s handle it.
> 
> DJGPP's `fork' simply fails every call.  I suggest to replace it with
> something which does "start /m inetd", together with some trickery to
> implement inheritance of environment variables, file handles, and
> other information that `fork' passes.  "start" will only work on
> Windows, but current options for sockets are only for Windows anyway.

Well I thought spawn()'s familly functions was supported

something like :
pid_t spawn (const char *path, 
		const int fdlen, 
		const int fdarray[], 
		const char *argv, 
		const char **envp);

Node the fd*, so I can set the stdout/stdin for the child.
fdarray[STDIN_FILENO] = socket_fd;
fdarray[STDOUT_FILENO] = dup (socket_fd);
fdarray[STDERR_FILENO] = dup (socket_fd);
fdlen = 3;

Is this at all possible as an alternative ?

> Besides, running a Unix-style daemon on plain DOS would require either
> a dedicated machine or a lot of TSR (that's Terminate-and-Stay-Resident) 
> tricks that are profoundly hard in DPMI mode.  So limiting
> high-throughput daemons to Windows doesn't seem as a grave limitation
> to me.  On DOS, you can always say that the max throughput is limited.

This is beyond me. inetutils can not cover schizophrenic behaviour
of the OS. If somebody wants to run a busy ftpd server on a DOS box
Well ...

> > exec (), signal ().
> 
> Both of these are supported.  Hoever, note that signals cannot be
> delivered between programs (e.g., you cannot kill the child program by
> sending it SIGKILL), and delivery of signals is blocked while a
> program is inside a DOS call.  Since running a child program is done
> via a DOS call, this means no signals until the child returns.

ewwwwwwwww !
Now I'm beginning to understand why WIN/DOS users reboot
there machines so often.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!