Ghost Solution Suite

 View Only
  • 1.  Filter Greater/Less than restriction and version numbers

    Posted Sep 26, 2011 12:08 PM

       I'm trying to create a simple filter that searches for an installed application and checks the version number. I'd like to filter by versions greater than a certain point or less than a certain point. I've found that the actual >, or < filters do not properly handle typical version number conventions.

     

       For instance, if I'd like to search for versions greater than 5.12.6, a filter using > or >= will find that 5.12.15 is "less than" 5.12.6.

     

       Is there a way to create a filter to correctly search for version numbers using 'greater than' or 'less than' restrictions? Can the operation of these restrictions be modified in a future version to correctly handle version number conventions?



  • 2.  RE: Filter Greater/Less than restriction and version numbers

    Posted Sep 26, 2011 03:50 PM

    Can you confirm which Symantec product you are using as I am not convinced you are in the right forum.



  • 3.  RE: Filter Greater/Less than restriction and version numbers

    Posted Sep 26, 2011 05:45 PM

    Actually, the inventory query language in GSS uses polymorphic operators with a number of coercion behaviours to ensure that the right thing mostly happens for comparison. However, version numbers are usually just not represented suitably in the underlying WMI providers to make any type-driven comparison work, period.

    Essentially, there's no data type in COM (which follows the early-90's data types in early Visual Basic) specific to a version number, so providers have two representations to choose from. One is the internal representation in Windows used in executables, which is an encoding in which each of 4 16-bit components is concatenated to form a 64-bit number (as per VS_FIXEDFILEINFO). However, this isn't very human-readable, which is why there is also a string format in Windows file versions, and indeed multiple of them with different strings renderings of the version data for different cultures.

    Application developers typically do provide only one the "dotted" string form in the neutral culture, but in general version strings have to be considered localized data.

    So, which piece of version information is exposed by WMI providers? A 64-bit numeric encoding, that sorts properly with respect to integer comparisons, is what most code has to use but is largely unintelligible to human users. Or, it can choose a locale-specific string encoding, which cannot be reliably compared by any computer language's built-in operation.

    WMI providers generally provide only the string, and because the data is in string form the (polymorphic) operations used by Ghost Solution Suite's query processor are string compares, which have the obvious results - they correctly compare the strings, but this doesn't represent the semantics of the data and those implied semantics are not something that can be determined from the WMI schema.

    [ Note that as this problem is innate to WMI, you can find various things on the web where folks have encountered this exact problem and attempted to create baroque comparison functions in VBScript, mostly incorrectly. ]

    As a result, there only thing that might have been possible is for the inventory query language to have contained an explicit coercion which attempts (I say attempts because locale-specific version strings would defeat any attempt to do this - using the string forms instead of the numeric raw data is strictly the wrong thing to do) to convert from the most common neutral locale rendering (i.e. en-US conventions) to a 64-bit numeric.

    However, the parser for the inventory query language just isn't up to this. Although the GSS server and Ghost itself was being expanded for GSS 3.0 (before that was cancelled) to support a large subset of embedded Javascript, and this could have been retrofitted in as an expression processor for the query language, the query language as it exists now doesn't contain any form of expression evaluator, let alone one in which it's possible to augment it with a version-decoding builtin or plugin function.

    Therefore, your only option is to try and find (from the WMI schema) whether the provider being queried exposes a numeric property encoding that you can write a comparison for using numeric comparison semantics. If the WMI provider doesn't give you one, you're out of luck.