[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mingw alternatives
From: |
Bruno Haible |
Subject: |
Re: mingw alternatives |
Date: |
Mon, 26 Apr 2010 10:45:24 +0200 |
User-agent: |
KMail/1.9.9 |
Paolo Bonzini wrote:
> We're at the point where every other function in mingw is being hooked.
>
> Maybe it would be better to start fresh with ReactOS's msvcrt, add
> everything that gnulib provides and more (for example the *at functions
> could be added very easily), and link it statically with the application
> instead of using gnulib... kind of like the mingwex library but to the
> n-th power...
Note that this would not solve the open_memstream issue, because the same
hardwired FILE struct is also used in AIX, HP-UX, IRIX, OSF/1, Solaris.
If you want to create another runtime platform for Win32, you can certainly
do so. But:
- It would not replace the need for mingw. mingw is needed when people
want to be able to link with system-provided or third-party DLLs.
If the same process links to two different runtime libraries, each
containing a C standard library, it will be a big mess.
- What would be the advantage of your new platform compared to Cygwin?
Why would people want to use a Cygwin remake instead of the real
Cygwin?
Bruno
- Re: [PATCH 1/2] open_memstream-tests: new module, (continued)
- [PATCH 2/2] open_memstream: new module, Eric Blake, 2010/04/23
- Re: work in progress: [PATCH 0/2+] open_memstream, Jim Meyering, 2010/04/24
- Re: extended streams, Bruno Haible, 2010/04/24
- Re: work in progress: [PATCH 0/2+] open_memstream, Paolo Bonzini, 2010/04/26
- Re: mingw alternatives,
Bruno Haible <=
- [PATCH 3/2] open_memstream: port to more systems, Eric Blake, 2010/04/26