Mail Archives: djgpp-workers/1999/02/18/13:31:55
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 !!!
- Raw text -