process.h patch

David Elliott dfe at
Thu Feb 15 01:17:39 CST 2001

Jon Griffiths wrote:

> 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 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
>  *  DISCLAMED. This includes but is not limited to warranties of
> 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.

Cool, sounds good to me!

> > 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).

Actually, I also intended to use the headers when building MSVCRT, but that may
not be really necessary.

> > 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.

Very cool, so you were already taking this into consideration then.

> > 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).

I doubt it's necessary seeing that they put them into public domain.  We should
definitely give 'em some credit though.

> > 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!

Thanks.  It went great.  Everything went perfectly except the flowers were kind
of falling apart, but it actually worked out since it looked like the petals
were supposed to be dropping intentionally!

> Cheers,
> Jon

Good night,

More information about the wine-devel mailing list