Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 17 Mar 2013 22:14:00 -0500
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com
Cc: musl@...ts.openwall.com
Subject: Re: question: hard-coded file descriptors in
 stdin/stdout/stderr

On 03/14/2013 12:51:19 PM, Zvi Gilboa wrote:
> >> which ones?
> 
> ... since you are asking...  inspired by musl-libc, I am currently  
> writing a win32
> /win64 open-source library that implements/provides POSIX system  
> calls (see note
> below).  I believe that having a powerful libc with an MIT license  
> available on
> Windows would actually be of great value to the open source community  
> for all
> possible reasons, but that is of course irrelevant to my question:)

All possible reasons? I can't think of one.

I have actually thought about this sort of thing. For example, I did a  
talk at the recent emebedded Linux conference explaining _why_ toybox  
and musl are important to Android:

http://www.youtube.com/watch?v=SGmtP5Lg_t0

> The main issue here is that the standard file descriptors on Windows  
> are -10
> (STD_INPUT_HANDLE), -11 (STD_OUTPUT_HANDLE), and -12  
> (STD_ERROR_HANDLE).

In DOS, stdin, stdout, and stderr were 0, 1, and 2. What you just  
listed is an explicit violation of posix.

>  I could of course compensate for that in my code and "translate" the  
> POSIX special
> file descriptor numbers to the Windows ones, however it would be more  
> elegant if musl
> -libc used the descriptors defined in <unistd.h>  instead of  
> hard-coded numbers.

You want to introduce non-posix assumptions into musl to make windows  
code more elegant.

Really?

> 
> * as for psxcalls: this is a C library, that exclusively uses the  
> Native API.  It
> attaches to ntdll.dll during run-time, and can thus be compiled as a  
> "native" static
> library with no external dependencies.

Doesn't mingw already exist?

>  While it is currently in its very initial
> stage (and not yet online), the major "obstacle" features --  
> including fork()
> -- have already been implemented.  To remove all doubts,

Remove all doubts? Really? All of them?

> I am aware of Cygwin's existence,

But apparently not mingw.

> yet am looking for a high-performance solution that would be both  
> "clean" (psxcalls-->libc-->user-library-or-application), and flexibly  
> licensed.

How on earth does licensing on WINDOWS matter, since the base OS is  
proprietary?

So this is explicitly "provide free stuff to make paying money to  
Microsoft more appealing"?

Rob

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.