process.h patch

[Jon Griffiths]

Hi,

> Hmm, glad to see everyone is alive and well again.

:-) Its been a slow week, no?

Firstup, on copyright, I think I was misunderstood. When I say they are not 
copyrighted, I mean the author(s) have _given up_ their copyright explicitly. 
Each original header file carries the following banner:

 *  THIS SOFTWARE IS NOT COPYRIGHTED
 *
 *  This source code is offered for use in the public domain. You may
 *  use, modify or distribute it freely.
 *
 *  This code is distributed in the hope that it will be useful but
 *  WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY
 *  DISCLAMED. This includes but is not limited to warranties of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

You can't get more clear than that, I think. Of course it would be good to 
acklowdge their contribution and let them know their modified code is being 
used.

> Thus the references are set during compile time and not link time and also
> would allow you to essentially link to an MSVCRT and a libc within the same
> program if desired.

I believe in most cases you can do this by appending an _ to the name, 
although not for all cases obviously. The only thing I don't like about this 
is requiring another library, particularly because the apps code that uses 
MSVCRT_is then non-portable.

With the @ignore directive in your .spec, it is now possible to link with 
msvcrt and optionally have individual functions resolved to libc, so it 
shouldn't be required to have a prefix, although it wouldn't hurt to be 
available.

One thing I _don't_ think we need to do is to try to use the headers when 
building msvcrt and Francois suggested. I think its extra work for no real 
benefit, bugs show themselves soon enough, and winapi_check catches several 
kinds of parameter bugs already. I alos dont like having to use a different 
build command for one dll (ie include he msvcrt header dir).

> Part of the reason for rewriting the include files was also for licensing. 
> If we rewrite the header files ourselves then it's pretty much guaranteed
> that they can be licensed exactly the same as Wine.  If we "borrow" them
> then who knows.  Most Windows compilers I have seen have some sort of
> license on what you can do with their header files that might not make them
> fit for inclusion into Wine.

I don't think this is an issue given the notice above, which Is why I started 
from the rsxnt headers as a base. 

> An idea that just popped into my head is maybe seeing if we can get a
> windows compiler maker (e.g. Borland) to donate a full set of headers under
> the Wine license.  However they may have licensed them with certain terms
> and be unable to do that.

I'm sure the rsxnt guys would be happy to provide an email exlicitly giving 
permission, even though we don't need to ask for it since they have no 
copyright on their code. I like their headers because they are MS compatable 
and very lightweight (even more so since I stripped them right back before 
submitting).

> This is just the stuff off the top of my head.  I am gonna hit the sack
> now, long day tomorrow (tues.) and the next day.

Good luck for the weeding!

Cheers,
Jon

-- 
"Don't wait for the seas to part, or messiahs to come,
  Dont you sit around and waste this chance ..." -Live

tntjpgriff at tsnxt.co.uk , jon_p_griffiths at yahoo.com