bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mingw alternatives


From: Paolo Bonzini
Subject: Re: mingw alternatives
Date: Mon, 26 Apr 2010 11:20:00 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]