At my day job I’m working with a database export from a LANrev system. If you don’t already know what LANrev is, you might as well stop reading now. I’m just putting this up on the web because I couldn’t find it there when I looked for it, and hopefully this will save someone the trouble of contacting LANrev support.
Still here? Okay then. Many fields in the database tables LANrev exports are numeric indexes to other tables, which are themselves short lists of values. For example, in the software_info table, there is a field named OSPlatform, but rather than actual platforms (e.g. “Mac OS X”, this field just contains a number, which can be used to lookup the actual platform in the table named enum_osplatform.
And that’s all well and good until you get to the OSVersion field, see it contains numbers (e.g. 4167), and look for the corresponding enum_osversion table. But there is no such table. So then you search through other tables, thinking maybe the table is just poorly named, but again, no dice. So then you search online. Previously, you would have found no explanation of this mystery online, but now hopefully such a search brought you here.
The secret? That number, 4167, is the actual version number; it’s just in an obscure format. Specifically, it’s a decimal representation of a hexadecimal representation of three decimal numbers. It’s all obvious now, right? Hopefully an example will clarify. The hexadecimal value of 4167 is 0×1047. The first two digits of that are the major version number, followed by the minor, and then the really minor or “bug” version. That is, put in some decimal points and 0×1047 becomes 10.4.7, the actual version number in it’s familiar format.
Why does LANrev do this crazy conversion? Apparently because Apple does this. Why does Apple do this? I have no idea. To save 2 bytes? And why doesn’t LANrev document this? Again, no idea. But it’s online now. Hopefully it will help someone.
Post a Comment