On Tue, Apr 11, 2000 at 10:30:22AM -0700, Alexandre Julliard wrote:
> Huw D M Davies <[EMAIL PROTECTED]> writes:
>
> > Well for _fullpath I really don't see the problem of adding our own
> > stdlib.h with include_next <stdlib.h> and the additional declarations.
>
> Then there are 3 stdlib.h to choose from (the Windows one, the Unix
> one, and the include_next one). It seems to add a lot of confusion for
> very little gain.
Sorry, I was talking about creating the Windows one with an
include_next and the extra functions declarations.
> > I'm not sure what you mean here. Are you saying Winelib apps can't
> > use Unix fd_set or Windows fd_set? They clearly can't use both.
>
> They can't use both, and since Wine is using the Windows definitions
> they very likely cannot use the Unix ones; unless the app absolutely
> never uses a single Windows API that needs the corresponding type,
> which I think very unlikely for real apps. This may be viable for
> fd_set, but not for things like wchar_t, or file handles.
OK that's what I thought you meant. So we need to construct a
winsock.h from scratch? Since Wine itself still needs the Unix
definitions does something like this work?
winsock.h
----------
#include <windef.h>
typedef struct {
...
} WINSOCK_fd_set;
INT WINSOCK_getpeername(SOCKET *, struct WINSOCK_sockaddr *, INT *);
...
#ifndef __WINE__
#define fd_set WINSOCK_fd_set
#define getpeername WINSOCK_getpeername
...
#endif /* __WINE__ */
---------
The winelib app must not include Unix socket.h after this but then it
shouldn't want to. Unix stdlib.h also can't be included after this
since it declares fd_set.
What have I missed?
Huw.
--
Dr. Huw D M Davies | Clarendon Laboratory
[EMAIL PROTECTED] | Parks Road
Tel: +44 1865 272390 | Oxford OX1 3PU
Fax: +44 1865 272400 | UK
