On 04/26/2010 10:45 AM, Bruno Haible wrote:
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.
True, I answered that separately.
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.
True. In particular, Microsoft lists exactly the following cases where
having two runtime libraries doesn't work:
* There are two separate heaps. You cannot allocate (explicitly with
new, malloc, or so on -- or implicitly with strdup, strstreambuf::str,
or so on), and then pass the pointer across a CRT-boundary to be freed.
* You cannot pass a FILE* or file handle across a CRT-boundary and
expect the "stdio low-level IO" to work.
* You cannot set the locale in one and expect the other's locale to be set.
However, all Windows DLLs are hookable, so maybe it's possible to hook
MSVCRT to death instead of writing a new one... It would work as long
as DLLs are not expecting anything about the shape of FILE* or the file
descriptor table.
- 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?
The idea was to not have a new platform, but just a different
implementation of some (possibly many) run-time library functions. It
would still use backslash-separated paths and 16-bit wchar_t, on the
other hand it could support things such as openat or open_memstream
without any overhead. (Note that for Cygwin it is much harder to
provide a non-racy openat due to the path-translation layer).
So, it would be similar to what gnulib provides, or a subset of it.
Sockets probably would be out of the scope of this project already.
Paolo
