[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Mar 2013 07:43:03 -0400
From: LM <lmemsm@...il.com>
To: musl@...ts.openwall.com
Subject: Re: question: hard-coded file descriptors in stdin/stdout/stderr
On Fri, Mar 15, 2013 at 4:33 AM, Rich Felker <dalias@...ifal.cx> wrote:
> Not only are
> the numbers 0/1/2 specified and widely hard-coded in applications; the
> Windows "file handle" values for stdin/out/err are not usable as file
> descriptors because they are negative.
Was just thinking about that this morning. I've been trying to port
msh to Windows and it uses hard-coded 0, 1 and 2 with pipes and
expects them to mean stdin, stdout and stderr. I'm guessing MinGW
does something in its code to deal with the situation, because it
works with these hard-coded numbers when I build msh. Would be nice
if it worked the same way with a replacement library such as musl if
used on Windows.
> Nice to hear. Incidentally, fork() was one of the interfaces I thought
> we could just sacrifice in doing such a libc (posix_spawn or the
> similar Windows function can replace most correct uses of fork()), so
> it's nice to hear you've solved the problem.
That's pretty much what I do when I port applications to Windows; I
substitute spawn. Seems easier to replace vfork than fork that way
though.
One other issue I hit when porting to Windows is the lack of certain
signal handling capabilities. For instance, when attempting to port
flrec, in place of kill(pid_sox,SIGSTOP);, I'm trying to use
NtSuspendProcess and in place of SIGCONT, I'm trying to use
NtResumeProcess. Some of the other signal information used in the
program, I'm not even sure if I can duplicate on Windows yet.
Would be nice if musl does get ported to Windows. It could do a lot
towards simplifying porting of other applications.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
