Re: How to detect OS type and version?

[Ray Blaak <rAYblaaK@STRIPCAPStelus.net>]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
> > Simply adding a new OS to some central definition should not impact all
> > existing code. In practical terms people should have had an "unknown OS"
> > handler anyway.
> 
> What is the directory separator character on "unknown OS"?  ;-)

I don't know, of course. The point is to have a plan for it. In the worst case
you exit with the appropriate error message "unknown OS!". In practice you
assume "Unix".

> The advantage of using an enumeration type, and _not_ having an
> Unknown_OS value, is that the compiler will tell you about all
> the places you might need to change when you add a new OS.
> That might or might not be what you want.

That is the inherent advantage of using an enumerated type, of course.

My point is that the nature of the information does not correspond to a known
fixed set.

> In my current project, I have two levels of distinction -- OS (Unix
> vs. Windows, for example) and OS_Flavor (Solaris vs. Linux, for
> example).  I've not needed to distinguish (for example) different
> versions of Linux, and it's probably a good idea to avoid that fine
> level of distinction if possible.

That you need only a few levels of distinction is a property of your current
project, not a property of the set of known OS types. That should be separated.

What I would do in your case is to make my own project-specific enumerated
type and decide the appropriate current literal value at startup based on the
the string-based values returned from querying the OS.

If the reported OS value cannot be correlated to one of your assumed OS types,
then you must decide what to do, which is likely to either assume it's a
default known one (e.g. some sort of "generic" Unix) or else bail out.

> > It's akin to having some app that processes first names as enumerated values
> > instead of strings. It's a mistake because the set of values are open ended
> > and are not known in advance, and can change depending on where you execute.
> 
> You probably don't port to a new OS quite as often as you add names to
> your database of telephone numbers or whatever.  And you probably don't
> use wildly different code based on first names, which needs updating
> every time you add a new first name.

That is essentially true in practice, I admit.

I guess what I care about is that the built in OS query that would live
somewhere under the System or Ada hierarchy would not return an enumerated
type, but rather a string.

That is, the enumeration should not be built into the language, since it is
not at all a stable enough set of values for the long term. Imagine being able
to code to an updated set only every 10 years, which seems to be Ada's upgrade
cycle.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.