some ntdll functions (2) - part 1: functions

[Mike Hearn]

> In general yes, but not in the context of Wine. Of course it's more
> satisfying to make the function behave better, and it's OK to do it as
> long as it doesn't break anything, but we can't have anybody depend on
> that; because if we someday find an app that depends on the garbage
> results we will have to put the bug back in. And that's why it makes
> no sense to export extensions, since nobody can use them.

Out of interest, might this apply to WineLib-specific extensions in
future? As a trivial example, the KDE/GNOME system trays can hold icons
have a larger size and bit depth to the one on Windows (so they look
better). If you're trying to increase integration by using WineLib,
would adding a new extension to allow better tray icons to be used
allowed (because conditional compilation can always turn it off on
windows). The alternative would be to say that you have to use the
native APIs, but for instance if it was for special window hints that
might not really be possible (because all your window handling code is
via WineLib).

Same I guess for wine-specific window styles and so on. Presumably if
such things were introduced Microsoft could bork them by introducing
their own styles with the same numbers, but I think there are schemes to
work around that.

-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center