Jon Griffiths tntjpgriff@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.
Alexandre Julliard wrote:
Jon Griffiths tntjpgriff@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.
Alexandre Julliard wrote:
Jon Griffiths tntjpgriff@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.
Hmm, glad to see everyone is alive and well again.
At this point my schedule is pretty full until Thursday. My parents are getting remarried this Wednesday (Valentine's Day) so I am busy preparing with them and working on some songs to sing at the wedding and reception.
My original plan was actually to write the headers along with the implementations to sort of break up the mundane task of writing headers with some actual coding and so that neither one would be too far behind the other. A lot has changed in Winelib since the original discussion on this. For one thing, DLLs work as expected now and imports can actually be resolved to native DLLs.
This is sort of a recap so that we are all on the same page:
There ought to be a full set of headers that is intended for linking with a real MSVCRT, possibly using a few macros sparingly but only for optimizations.
There also should be the ability to use normal UNIX headers and link with a normal UNIX libc if desired. (Which currently would be the only way to do things).
Francois had also talked about a mixed set of headers using mostly UNIX stuff but with a few MSVCRT things thrown in.
I had thrown in the idea of being able to prefix the msvcrt functions with something like MSVCRT_ and then linking against a library which forwarded the "MSVCRT_function" to "MSVCRT.function". Thus using MSVCRT_function in the program would use the MSVCRT implementation, and using just function in the program would use the normal libc function. The idea behind this was the some source files could include header files which #defined function MSVCRT_function, other source files could include normal libc headers. 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.
While the idea may not be great for use in Wine itself, it might be nice if the header files supported a prefix on all function names, somewhat like NEC's SOCKS headers (except actually working unlike the socks headers).
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.
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.
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.
Have a good one, -Dave
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
On Tue, 13 Feb 2001, Jon Griffiths wrote: [...]
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.
Yes, seems good.
[...]
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
But sooner is better :-)
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).
No need to change the build command, just include 'msvcrt/xxx.h'.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".
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
David Elliott wrote:
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.
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.
While Jon has addressed this issue in regards to the MSVCRT headers, this might be a good time to point out that the legality of enforcing copyright on header files through licensing restrictions is questionable.
I'll preface this with the usual mention of the fact that I am not a lawyer, nor do I play one on TV. Please consult a qualified professional before taking action on anything I've written.
Copyright law does not protect idea, just the expression of them. Several court decisions have been rendered which suggest that the 'purely functional' elements of a computer program are not copyrightable. There are several cases that explicitly deal with the issue of copyright and header files. The most relevant one for Wine development is probably the 1992 decision in Sega v. Accolade, where Accolade reverse engineered the headers for Sega's ROM libraries in order to develop games compatible with Sega's hardware without paying Sega's royalties. http://www.eff.org/pub/Legal/Cases/sega_v_accolade_977f2d1510_decision.html
The court in that case said:
Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles -- articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by external factors such as compatibility requirements and industry demands... In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for the purposes of copyright. When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement.
Since Wine absolutely requires the specific header file layout, strucutre and function names, etc to be the way the Windows headers express them, there is good cause to believe that the header files are unprotected by copyright.
In fact, development tool licenses that attempt to restrict usage of these headers may even constitute anti-trust copyright misuse. Early versions of MS Visual C++ contained a shrinkwrap license that forbade the use of the product to create software for platforms other than Windows. Later revisions (ie: SP3) removed that restriction, so perhaps MS realized that this was not protectable.
One fly in the legal ointment is that while the headers may not be copyrighable, the shrinkwrap license may still be legal as a contract. There's a case where a court suggested that someone who buys a copy of a product that contains a shrinkwrap license agreement and unwraps it is legally bound to follow it, while the person who later finds the unwrapped CD 'on the street' with no such license is allowed to copy the portions that are unprotected by copyright. It's unclear where the anti-trust issue fits in there.
Food for thought, anyhow...
-Gav
Gavriel State wrote:
David Elliott wrote:
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.
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.
While Jon has addressed this issue in regards to the MSVCRT headers, this might be a good time to point out that the legality of enforcing copyright on header files through licensing restrictions is questionable.
I'll preface this with the usual mention of the fact that I am not a lawyer, nor do I play one on TV. Please consult a qualified professional before taking action on anything I've written.
Copyright law does not protect idea, just the expression of them. Several court decisions have been rendered which suggest that the 'purely functional' elements of a computer program are not copyrightable. There are several cases that explicitly deal with the issue of copyright and header files. The most relevant one for Wine development is probably the 1992 decision in Sega v. Accolade, where Accolade reverse engineered the headers for Sega's ROM libraries in order to develop games compatible with Sega's hardware without paying Sega's royalties. http://www.eff.org/pub/Legal/Cases/sega_v_accolade_977f2d1510_decision.html
The court in that case said:
Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles -- articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by external factors such as compatibility requirements and industry demands... In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for the purposes of copyright. When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement.
Hmm, I am not so sure I like all of that. Program code serves two purposes. For one thing it is functional, and for another (and actually for the most part) it has a human readable structure.
I think it is actually very similar in nature to sheet music. The specific typesetting of a piece of sheet music can be copyrighted, so photocopying it is illegal. However, if the copyright has expired on the music itself then you can copy it by hand (or hell, even by machine) and as long as it is not an exact duplicate then you can make as many copies of that as you want.
Since Wine absolutely requires the specific header file layout, strucutre and function names, etc to be the way the Windows headers express them, there is good cause to believe that the header files are unprotected by copyright.
I would say the specific byte for byte header files are, especially the comments in the code which are most certainly copyrightable just like any text. However, you could easily make the point that you can define the same interface and do so "in your own words" and then it would be perfectly fine. The headers would of course look almost exactly the same as the originals given the nature of having to provide the same interface, but it is a new implementation of the same functionality.
In fact, development tool licenses that attempt to restrict usage of these headers may even constitute anti-trust copyright misuse. Early versions of MS Visual C++ contained a shrinkwrap license that forbade the use of the product to create software for platforms other than Windows. Later revisions (ie: SP3) removed that restriction, so perhaps MS realized that this was not protectable.
You'd think that would be a "Well, DUH!" But they always want to protect as many rights as they have, or don't have but could possibly have.
One fly in the legal ointment is that while the headers may not be copyrighable, the shrinkwrap license may still be legal as a contract. There's a case where a court suggested that someone who buys a copy of a product that contains a shrinkwrap license agreement and unwraps it is legally bound to follow it, while the person who later finds the unwrapped CD 'on the street' with no such license is allowed to copy the portions that are unprotected by copyright. It's unclear where the anti-trust issue fits in there.
Shrink-wrap licenses are shit. I can just see a team of hungry lawyers having a field day with these pretty soon. Eventually someone with lots 'o cash is gonna say that the shrink-wrap license is bull, get a lawyer to defend the argument and it'll be over and done with. Hell, businesses have gotten out of signed contracts because if one party says one thing, but contradicts it in the contract it really doesn't matter since the other party can then say they signed it based on the first parties word. Normally you want to let the lawyers handle reading and signing, that is their job after all.
Food for thought, anyhow...
Yeah, it's interesting. We are entering into some somewhat troubling times where everyone is trying to defend rights they don't even have and shouldn't have. And yet we are passing stupid laws taking away fundamental rights that we do have and should have. Just saw the appeal verdict from B&N vs. Amazon. That is a step in the right direction, but there are still many more steps to take.
-Gav
Cheers, -Dave
-
Alexandre Julliard -
David Elliott -
Francois Gouget -
François Gouget -
Gavriel State -
Jon Griffiths