|
Message-ID: <CAFipMOFNe3gXvQyGdpxig4cgSu+rw9K17oAgOnSJcAB_GChmSw@mail.gmail.com> 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.