Am 09.03.2015 um 09:59 schrieb Aleksey Bragin:
> I suppose if the API "changes" (and it means, it improves, and usually
> without breaking backward compatibility), then there is no reason to
> provide old, broken or incomplete implementation. I doubt there is any
> popular app which relies on some bugs in old API implementation which
> can justify that.
My favourite for subtle changes inside Win32: SetTimer :)
MSDN has removed many of the details now, so I quote from the old
version of the page:
===================================================================
uElapse
[in] Specifies the time-out value, in milliseconds.
Windows NT/2000/XP: If uElapse is greater than USER_TIMER_MAXIMUM, the
timeout is set to 1.
Windows 2000/XP: If uElapse is less than USER_TIMER_MINIMUM, the timeout
is set to USER_TIMER_MINIMUM.
Windows Server 2003: If uElapse is greater than USER_TIMER_MAXIMUM, the
timeout is set to USER_TIMER_MAXIMUM.
Windows XP SP2/Windows Server 2003 SP1: If uElapse is less than
USER_TIMER_MINIMUM, the timeout is set to USER_TIMER_MINIMUM. If uElapse
is greater than USER_TIMER_MAXIMUM, the timeout is set to
USER_TIMER_MAXIMUM.
===================================================================
Reference e.g. http://www.jliforum.de/board/viewtopic.php?p=61375#61375
This has broken at least our third-party imported Matrix screensaver
(see fix in r28955). Due to the widespread usage of the SetTimer API,
there are probably more examples.
Of course, given that we're targetting Windows Server 2003 SP1 or newer,
the behaviour for us is clear. But if such changes occur in recent
Windows versions as well, I believe we need different implementations of
an API for each Windows version we try to emulate.
Maybe someone can give an example of such a change in more recent
Windows versions as well.
Cheers,
Colin
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev