Thoughts on std.system.OS

Jonathan M Davis jmdavisProg at gmx.com
Sat Aug 13 03:51:47 PDT 2011


On Saturday, August 13, 2011 13:38:00 Vladimir Panteleev wrote:
> On Sat, 13 Aug 2011 13:23:08 +0300, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > That's certainly a thought, but that could get entertaining to get the
> > enum
> > values from that. As long as the various distros are consistent in their
> > naming schemes between their releases though, that _should_ be possible.
> > That
> > may be worth trying though.
> 
> Not sure what you mean when you mention distros. Getting the distro
> name/version is a separate, much more complicated problem. AFAIK, there is
> no identifiable standard which distros adhere to to allow programmatic
> identification.
> 
> Hence, just the kernel version. The uname() system call returns it as a
> string. A possible complication is that the size of the structure that
> system call uses differs between UNIX flavors, and if I read the docs
> right, it even changed once or twice between Linux versions. (I thought
> Linux was maintaining binary compatibility between versions?)

Whether Linux maintains binary compatible between versions depends on what 
you're talking about and which versions you talk about. _Every_ linux program 
risks breaking the ABI if you change the major version number. Whether other 
version changes break ABI depends on the program and their versioning scheme. 
_Posix_ calls may not change much between versions, and lots of other stuff 
stays pretty constant, but there's always a risk of an ABI change if the 
version number changed is big enough.

Regardless of that though, the issue here is that there are three pieces of 
information which std.system is trying to convey about the system that the 
program is running on.

1. The OS - as in the enum OS, which would be the version of Windows on 
Windows, and the particular distro on Linux (at present, FreeBSD and OS X 
don't try and distinguish between versions).

2. The major version of the OS.

3. The minor version of the OS.

#1 is possible to get on Windows IIUC. Also, if you parse the value from 
uname, it generally has the distro's name in it, and as long as a particular 
distro is consistent in how it puts its name in that string, it should be 
possible to parse out the name and determine what the correct OS enum value 
is.

#2 and #3 don't really make sense between OSes, and I'd argue that they don't 
make much sense period. I don't know what they'd mean on Windows in any 
meaningful way. On Linux, I suppose that they could be the major and minor 
numbers of the kernel (e.g. 2 and 6 or 3 and 0), but that's pretty useless on 
Linux, given that they don't change very often. At this point, there would 
only really be two options: 2.6 and 3.0. And I don't know how major and minor 
could be applied to OS X or FreeBSD.
 
So, with some work, it does seem like it could be possible to do #1, which 
might be useful, but I don't see much point in #2 or #3.

- Jonathan M Davis


More information about the Digitalmars-d mailing list