The WineAPI wiki.
Max TenEyck Woodbury
max at mtew.isa-geek.net
Mon Aug 2 10:03:59 CDT 2010
On 08/02/2010 07:53 AM, Dmitry Timoshkov wrote:
> Max TenEyck Woodbury<max at 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.
More information about the wine-devel