Dimitrie O. Paun wrote:
On Tue, Jun 01, 2004 at 11:16:06AM -0700, Alexandre Julliard wrote:
No I don't think we want that. The headers are not that stable, we are still making changes to them. We also need the MSVCRT definitions in multiple dlls so there would be a lot of duplication.
Yes, the headers are not stable, but the interface is. The probability of one of those functions to change signature is virtually none. And we don't need all the headers, just some functions and structures. It just seems to me we have way too many constraints to be able to do a decent job. We're already cutting corners on the MSVC compatibility because of this mixing.
When compiling with STLPort I saw a method that can eliminate the need for the MSVCRT macro and yet produce MSVCRT_xxx for those who need it and an xxx for those how don't. Basically you have your Regular cleanroom headers-set for wine-lib and external dlls. And you have another set of headers for msvcrt compilation. In The second set: - each header does some magic like #define stat_t MSVCRT_stat_t - than #include <original/header.h>
Now compilation units that need the MSVCRT_xxx use an extra -I "$wine_include/internal_msvcrt" switch in the make files.
should I random pick an header and demonstrate the Technique?
From what I understand, the need for these differences are so the msvcrt.dll.so could define it's own set of functions and in place use gcc-glibc for implementation. This way stirring a way from both duplicates in Linking and conflicts with gcc-glibc headers. [Q] Why don't we avoid glibc all together. Take what ever code we are missing and have a complete self contained implementation? Just like MinGW's -nocygwin
(Now if we where using C++ the problems would be solved in 2 seconds flat: "namespace". Was not "namespace" back ported to C )