On Sun, 9 Apr 2000, Patrik Stridvall wrote:
[...]
> However I think that we can be even more clever.
> Lets for a while concentrate how a binary distribution
> of winelib can look like.
>
> * /usr/include:
> Symbolic links from all windows specific headers
> to the windows directory. Like windows.h -> windows/windows.h.
You propose to modify the file contents of /usr/include?! I don't think
that's a good idea, even if it's just to add symbolic links. I don't
think any Linux distribution would allow it either.
Just let the people compiling Windows application put a
'-I/usr/include/windows' in their include path. They'll have to write
makefiles to compile with Winelib anyway.
> * /usr/include/windows:
> All windows header files including stdlib.h and friends.
> These files could if not for copyright reasons and GNU compabillity
> be exactly the ones from Microsoft Windows.
>
> * /usr/include/windows/mixed:
> Files that by being clever like below using #include_next and/or
> your header link trick tries to include both the Windows and Unix variants.
Let's see if I understood well:
- 'windows' would contain all the regular windows headers (windows.h,
etc) plus self-contained headers for a VC compatible C library.
- 'mixed' would contain headers that basically reuse the unix
platform's C library headers and add/subtract things as needed.
The 'windows' directory is the one which will provide the highest
compatibility because we control everything there. But it's also
going to require a lot of work to write.
On the other hand the contents of the 'mixed' directory can build on
the unix headers which are mostly comptatible already. We can just
add/remove stuff as needed. But of course the headers on each platform
are going to be slightly different hence lower compatibility/more
maintenance. I would tend to say that this should still be less work.
Do we really need both modes?
Could we go with 'mixed' headers as they get us started faster? Then
if we have lots of trouble with a particular header because there are
too many differences we can rewrite it from scratch. Hopefully this will
be rare.
> * /usr/include/windows/native:
> A link to the Unix headers. Defaults to /usr/include.
> Observe however that we can be even more clever by
> having files here instead that looks like this
>
> #if defined(__GNUC__)
> #include "/usr/include_gnuc/stdlib.h"
> #elif defined(__OTHER_COMPILER__)
> #include "/usr/include_other_compiler/stdlib.h"
> #else
> #include "/usr/include/stdlib.h"
> #endif
Yes but you cannot based yourself on the compiler to determine
whether you should include libc5 or glibc (2.0, 2.1, ...) (or can you?).
I think it's better to control this at the include path level (including
using symbolic links if necessary)
> --- /usr/include/windows/mixed ----
>
> #ifndef __WINE_WINDOWS_MIXED_CTYPE_H
> #define __WINE_WINDOWS_MIXED_CTYPE_H
>
> #ifdef __GNUC__
> #include_next <ctype.h>
> #else
> #include <native/ctype.h>
> #endif
>
> #undef isalnum
> #undef isalpha
> #undef iscntrl
> #undef isdigit
[...]
It's not relevant to the general principles but I'm not sure all these
undefs are really necessary. Most programs, more then 99%, don't care
whether these things are defined as macros or functions (they use the
parameter only once so there cannot even be problems with things like
isalnum(*p++)).
Currently we're only talking about the headers but then we'll have to
look at the link aspect.
The C library would end up in two parts, one in glib.so (or whatever)
and the other in winelibc which would contain things like _beginthread.
Would that cause any problem?
Should a Winelib application be able to do LoadLibrary on the C
library and then do GetProcAddress? I don't think it would be very
useful. Anyone thinks otherwise?
--
Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/
"Only wimps use tape backup: _real_ men just upload their important stuff on
ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds
