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