process.h patch

[François Gouget]

Alexandre Julliard wrote:
> 
> Jon Griffiths <tntjpgriff at tsnxt.co.uk> writes:
> 
> > Until we have MS style headers, at least declare msvcrt functions extern "C"
> > so C++ Winelib programs will link.
> >
> > I didn't get any feedback to my headers patch. Alexandre, what do I need
> > to do to get some headers into CVS? Or is that not the plan?
> 
> Well, I don't know, I was hoping to get some feedback from the winelib
> experts out there on whether this is better than the approach with
> macros suggested by David.

   The headers look pretty good and as they are an important part of
Winelib I would really like to see them get into CVS. But there's one
thing to absolutely do first.

   In your email you say "I took the rsxnt headers as a base since they
are very uncluttered, and also released without copyright".
   Well, that's a big problem because if there's no copyright and no
license information then we cannot use them, at least under US law. So
you/we need to find the author(s) of these headers and get their
authorisation to use their headers and to release them under a license
compatible with the X11 license. I see that a google search on rsxnt
seems to give good results so at least contacting the authors should be
quite feasible.

   When that's cleared up we can tackle the issue of 'macros' mentioned
by Alexandre.
One annoying issue with the current headers is that they are not and
cannot be used for the implementation of the msvcrt (because of name
clashes with the regular C library). This means:
 - we'll have to duplicate the definition of some data-structures
 - inconsistencies can easily develop between the headers and the msvcrt
implementation
 - the headers will only get tested when someone uses them in a Winelib
application

   IIRC, David's solution to that was to define a macro to prepend the
'MSVCRT_' prefix depending on whether __WINE__ is defined or not. This
would look something like:

-- to put somewhere in a Wine specific shared header, maybe
'msvcrt/wine_msvcrt.h' --
#ifndef __WINE__
#define MSVCRT(x)   x
#else
#define MSVCRT(x)   MSVCRT_ ## x
#endif


-- then in other headers --
#include "wine_msvcrt.h"
...
int MSVCRT(isalnum)(int);
int MSVCRT(isalpha)(int);
int MSVCRT(iscntrl)(int);
...
#ifndef __WINE__
/* Comment out any macro that would clash, hopefully this will be ok */
#define isascii __isascii
#define toascii __toascii
#define iscsymf __iscsymf
#define iscsym  __iscsym
...
#endif
...

   It can be argued that it makes the headers a bit less readable but I
believe this is offset by them getting more systematic and regular
testing. 

   As far as completeness goes it's already a good start. We won't get
them complete and correct in one day anyway. If think they are a good
base on which to build and that's what's important.


-- 
François Gouget
fgouget at codeweavers.com