On Fri, Jul 02, 2004 at 10:48:57PM +0800, Jonathan Wilson wrote:
Bascily, there should be 3 sorts of APIs exported in WINE.
...
and 3.external WINE apis. There should be a limited set of special APIs which are made available to enable projects like mono and others wanting to interact with win32 code and/or the windows API implementation in WINE. These should be specificly documented and made stable (as in, we wont changer the prototype and we wont change the basic idea of what these functions do).
In other words, what Wine needs is not so much a stable API as a stable meta-API to determine what is actually supported.
For example, ...
If these were made stable, then apps that use them could be gauranteed that things wont break. Then, the only thing they need versioning for is to identify if a certain windows API is present or not. If it is, WineGetProcAddress (or whatever it is) will return an appropriate address. If its not, it would return an arror and you could work around it. (which may mean prompting the user to upgrade WINE).
The smaller said native-interaction API is, the easier it will be to keep stable.