[MinGW-dvlpr] [Fwd: Adding a new target to newlib]

[Earnie B. <ear...@ya...>]

Hey Casper,

What's this about?  This guys chicken has already been Bourne in MSYS.

Earnie.

-------- Original Message --------
Subject: Adding a new target to newlib
Date: Tue, 18 Jun 2002 00:39:30 +0200
From: "KJK::Hyperion" <no...@li...>
To: ne...@so...

Hi all. I'm the main developer of POSIX+, a POSIX compatibility layer
for
Windows NT and ReactOS (<http://www.reactos.com/>). Under suggestions
from
other team members, I've decided to evaluate newlib to provide POSIX+
the
C runtime. Before investing time into the adaption, I need a general
understanding of a few concepts. I'll bother you this one time, then
rely
on the documentation. Feel free to RTFM the trivial questions. Let's
see:
  - do I need a POSIX-like shell to build newlib? because I'd have a
nasty
    chicken-egg problem then: I can't have a POSIX shell until POSIX+ is
    compiled, I can't compile POSIX+ until newlib is compiled, and I
can't
    compile newlib without a shell. Even a future self-hosted version is
    out of question, because the team has gone to great lengths to
minimize
    the requirements to build ReactOS. A possible advantage is that
POSIX+
    will (likely) have only one public, official version, and the only
    variants will be architecture-specific builds: does this help? will
    some old-fashioned makefiles do?
  - is newlib thread-safe by default, or only for multithread-aware
    programs? (e.g. *_r variants of standard functions) I'm trying to
    follow the Single Unix Specification, and it clearly states that all
    functions are meant to be reentrant and thread-safe, except when
    otherwise noted
  - POSIX+ defers simple runtime functions (e.g. memcpy, memcmp, strcpy,
    etc.) to a system-wide runtime library (NTDLL.DLL). Is it dangerous
to
    mix the two runtimes? does it lead to inconsistent behavior? e.g.
some
    of these functions are interdependent in newlib?
  - is it possible to compile newlib into a Windows DLL, or does it
depend
    on POSIX linking semantics? e.g. symbols need not be qualified with
a
    DLL name?
  - to what extent is newlib extensible? Specifically:
     - can the per-process and per-thread data be customized/extended?
     - does asynchronous I/O depend on POSIX threads, and can it be
       implemented otherwise without breaking something else?
     - NT has a very good heap manager, can it be used in place of the
       internal one used (I presume) by newlib?
     - to the NT Rtl, heaps are just another kind of data structures, so
a
       process can have as many heaps as it sees fit (Microsoft
suggests,
       for example, the use of throwaway per-thread heaps for
aggressively
       multi-threaded programs, like ISAPIs, to minimize the context
       switches under heavy load). Does some other target have similar
       semantics, whose API I can "recycle"? if not, are there
guidelines
       for new identifiers/prototypes?

Finally, a "political" question: what about licensing? POSIX+ must be
under the GPL, and I guess that the various newlib licenses don't
conflict
with it. But what about headers? to allow unlimited commercial use of
ReactOS system libraries, all of our public headers and DEF files
(source
code for import libraries) are under no license, we don't even claim
copyright. What about newlib's?

Thanks in advance