On 12/27/2013 07:48 PM, Giampaolo Rodola' wrote:

On Fri, Dec 27, 2013 at 7:38 PM, M.-A. Lemburg mailto:mal@egenix.com> wrote:

On 27.12.2013 19:18, Giampaolo Rodola' wrote: > Today I was looking for a way to determine whether I was on Windows >= > Vista and couldn't find anything so I came up with this [1]. > > That led me to think about platform module. > Honestly I can't see the usefulness of it as it doesn't give you any usable > API to figure out what platform version you're on.

Have you had a look at the documentation ?

http://docs.python.org/2.7/library/platform.html?highlight=platform#windows-...

Yes, on Windows XP I get a tuple like this:

('XP', '5.1.2600', 'SP3', 'Uniprocessor Free')

On Windows 7:

('7', '6.1.7600', '', 'Multiprocessor Free')

Neither of those are helpful to make assumptions such as "if I'm on Windows >= XP with SP3: do something". The real deal would be dealing with a tuple of integers in order to use comparison operators, similarly to sys.version_info:

if sys.version_info >= (3, 0): # py3-specific code

What about this?: if tuple(int(v) for v in platform.win32_ver[1].split(".")) >= (5,1,2600): ...

On Fri, Dec 27, 2013 at 3:09 PM, Andrew Barnert wrote:

So you want to write:

if platform.win_version_info >= (5, 1, 2600):

Is that really much better than:

if platform.win32_ver.version >= '5.1.2600':

Once either of the first two numbers rolls over to two digits, the first comparison will be correct, the second will not:

...

...

x = '5.9.2600' y = '5.10.2600' y > x False

Skip

On Dec 27, 2013, at 13:09, Andrew Barnert wrote:

Meanwhile, Microsoft's suggested solution is that you not check for version numbers at runtime, but instead check for features. And there are good reasons for that--for example, XPSP3 N has exactly the same version numbers as XPSP3 normal, but if you try to use the new Windows Media APIs, you'll crash.

Also, in forgot to mention that there are features added to Windows versions discontinuously. For example, there are features that are in XPSP3 (5.1.2600) and 2003R2SP2 (5.2.3790) but not original 2003 (5.2.3376). So, a check for >= 5, 1, 2600 would give you the wrong information anyway. And that's not even considering the fact that some kernels are used for multiple different Windows versions with different features (e.g., that 5.2.3790 is also the kernel for 64-bit XP). To make things even more fun, 2003SP2 originally had the same 3376 kernel as stock 2003, then got bumped to the same 3790 kernel as 2003R2SP2 in a non-service-pack update. These aren't anomalies; this is the way Windows versioning works. The kernel build number is useless as an indication of anything but kernel features that Python code isn't going to care about; the major.minor can be useful in a few cases, but usually even that doesn't tell you as much as you probably expect. Any change to make it easier to write misleadingly broken code is probably not a good change.

On Dec 28, 2013, at 8:12, "Giampaolo Rodola'" wrote:

...

Meanwhile, Microsoft's suggested solution is that you not check for version numbers at runtime, but instead check for features. And there are good reasons for that--for example, XPSP3 N has exactly the same version numbers as XPSP3 normal, but if you try to use the new Windows Media APIs, you'll crash.

Mmm. What's weird is that if you use MSDN as a reference every Windows API has a "minimum supported client" section near the bottom of the page. See for example: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684874(v=vs.85).as... To me that suggests that (most of the times at least) you are encouraged to use the windows version to decide whether to support a feature or not.

Those versions don't correspond to any unique kernel version number, so you _can't_ check for it that way. What you _can_ do with that information is write your app's version requirements, so your end users know not to buy your all if they have xpsp1. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724832(v=vs.85).as... is one of the places they recommend against using version numbers as a substitute for feature test. it says: way to determine whether a particular operating system feature is present. This is because the operating system may have had new features added in a redistributable DLL. Rather than using the Version API Helper functions to determine the operating system platform or version number, test for the presence of the feature itself. To determine the best way to test for a feature, refer to the documentation for the feature of interest. The following list discusses some common techniques for feature detection: You can test for the presence of the functions associated with a feature. To test for the presence of a function in a system DLL, call the LoadLibrary function to load the DLL. Then call the GetProcAddress function to determine whether the function of interest is present in the DLL. Use the pointer returned by GetProcAddress to call the function. Note that even if the function is present, it may be a stub that just returns an error code such as ERROR_CALL_NOT_IMPLEMENTED. You can determine the presence of some features by using the GetSystemMetrics function. For example, you can detect multiple display monitors by callingGetSystemMetrics(SM_CMONITORS). There are several versions of the redistributable DLLs that implement shell and common control features. For information about determining which versions are present on the system your application is running on, see the topicShell and Common Controls Versions. If you must require a particular operating system, be sure to use it as a minimum supported version, rather than design the test for the one operating system. This way, your detection code will continue to work on future versions of Windows. Note that a 32-bit application can detect whether it is running under WOW64 by calling the IsWow64Process function. It can obtain additional processor information by calling theGetNativeSystemInfo function.

--- Giampaolo https://code.google.com/p/psutil/ https://code.google.com/p/pyftpdlib/ https://code.google.com/p/pysendfile/