[ros-dev] ReactOS versioning

Timo Kreuzer timo.kreuzer at web.de
Tue Mar 10 00:56:45 UTC 2015


We neither need to write multiple implementatiins of the same thing, nor 
do we need to use magic python stuff. There is feature built into C and 
C++, that allows to do this in a pretty neat way: It's called "global 
variable". ;-)
Additionally Windows has the PEB, which already contains the Version number.

DllMain()
{
     g_VersionNumber = Peb->OSMajorVersion << 24 | Peb->OSMinorVersion 
<< 16 | Peb->OSBuildNumber;
}

SetTimer()
{
     if (g_VersionNumber >= NTDDI_WINXPSP2) foo() else bar();
}

Am 09.03.2015 um 11:46 schrieb Magnus Johnsson:
> A thought occurs to me. Is there a way to add descriptors to DLL 
> functions? It would be a neat way to handle having multiple versions. 
> In Python you can tag functions like @TargetVersionWindowsXP. If you 
> could transparently hide and rename symbols in the DLL's kernel-side 
> on load time, then you could have all the functions in the same file 
> without losing sanity points.
>
> 2015-03-09 11:27 GMT+01:00 Colin Finck <colin at reactos.org 
> <mailto:colin at reactos.org>>:
>
>     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 at reactos.org <mailto:Ros-dev at reactos.org>
>     http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.reactos.org/pipermail/ros-dev/attachments/20150310/76db8743/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3683 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.reactos.org/pipermail/ros-dev/attachments/20150310/76db8743/attachment-0001.bin>


More information about the Ros-dev mailing list