On 08/02/2010 07:53 AM, Dmitry Timoshkov wrote:
Max TenEyck Woodburymax@mtew.isa-geek.net wrote:
You have chosen not very good name. There is no such a thing as Wine API, Wine implements Win32 API, and doesn't specify/add anything custom to it. The name "WineAPI" implies that Wine defines its own API which is not true, and is confusing.
This has been discussed elsewhere on this mailing list.
There is a lot of information specific to Wine, particularly its internal structure, that is not shared with Microsoft's product.
Then "Wine internals" or "Wine architecture" would be more appropriate.
But it is NOT just the internals. I believe that good API documentations should include a 'Theory of Operation' section which describes how it is actually implemented. There should also be a section that documents regression and other tests. In other words, I hope this will become a *really* good set of API documentation. So 'Wine internals' would have been a bad name for the project. Similarly 'Wine architecture' is inappropriate.
This is not particularly a name I chose. The other discussions of this have also used 'WineAPI'. I did consider your objections that you have voiced previously. I understand that the target API is in fact the Win32API, but the Win32API is not something we control. We do control the actual API Wine uses. There will be differences between the WineAPI and the Win32API. When those differences are pointed out, I expect the WineAPI will be changed to match the Win32API. We are free to do that. We are *not* free to change the Win32API.
I think 'WineAPI' is an appropriate name and better than either of the names you suggested. If anyone comes up with a better name, I will try to get the Sourceforge project name changed, but the project is currently called 'wineapi'. So, for the moment, it is what it is.
Further, there is a little confusing and incorrect information in the Microsoft documentation. Bluntly, the Microsoft documentation is what they want it to be. We need to document what it really is.
Regardless of the quality of Microsoft documentation it's still Win32 API, not a Wine API.
And it is Microsoft's documentation and nominally documents their code. We have to document *our* code. There will be differences. Differences that I expect will be removed when found unless we can show that the Microsoft documentation is, in fact, incorrect.
You are setting up a 'straw man' argument. You are assuming that we can and *have* implemented the Win32 API correctly and that Microsoft's published documentation is completely correct. We have not and Microsoft has not. Our documentation will help us fix our code. We can not and should not even try to get try to get Microsoft fix their problems. From that your argument fails.
- Max