[Mono-winforms-list] Re: Fw: [Mono-list] System.Windows.Forms plans.

Jonathan Wilson jonwil@tpgi.com.au
Fri, 02 Jul 2004 22:48:57 +0800

Bascily, there should be 3 sorts of APIs exported in WINE.
1.windows apis. These dont change (some may be added or their 
implementation improved but the prototypes of an existing call wont change 
unless it was wrong in the first place)
2.internal WINE apis. These should be for WINE use only and free to be 
changed for whatever reason.
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).

For example, a function that one can call after loading WINE as a shared 
library to enable WINE to initalize itself.
And one to do whatever per-thread stuff WINE needs to do for an existing 
thread created outside WINE (or alternativly a way to create a WINE thread 
that can then be used outside the WINE code)
And some functionality to enable the loading of windows DLLs and calling 
code inside them properly. (this should be done so that it will work both 
for user dlls and also for system dlls so that you can e.g. do 
WineLoadLibrary("ole32.dll") and it would load the correct ole32.dll based 
on if the user has said they want native or builtin and then you could get 
the correct addresses)
And whatever else is needed to enable mono, linux winamp plugin loaders and 
whatever else might want to make windows API calls and/or load and use 
WIN32 code.

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).