www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thoughts on std.system.OS

reply Jonathan M Davis <jmdavisProg gmx.com> writes:
I made a few changes to std.system to clean it up a bit and make it more 
thorough:

https://github.com/D-Programming-Language/phobos/pull/186

However, on reflection, I'm not convinced that the OS enum and its 
corresponding os variable along with the os_major and os_minor variables serve 
any real purpose. Their purpose appears to be to tell you at runtime which OS 
you're actually running on - as in version, not just family of OS. I don't see 
how this is actually possible outside of perhaps Windows (it's just defaulted 
to WindowsXP thus far). And if it can't really do its job, I'd just as soon 
remove it. And since it hasn't been in the documentation, it's not likely to 
break any code.

Thoughts on std.system.OS? Is there a good reason to leave it? In principle, 
it's a nice idea, but I just don't see how it can deliver. And if it can't 
deliver, it should be removed IMHO. What do you think?

- Jonathan M Davis
Aug 12 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 13 Aug 2011 08:08:09 +0300, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 Thoughts on std.system.OS? Is there a good reason to leave it? In  
 principle, it's a nice idea, but I just don't see how it can deliver.  
 And if it can't deliver, it should be removed IMHO. What do you think?


Why not use uname on non-Windows systems, and report the kernel version?

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Aug 13 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 13, 2011 13:18:29 Vladimir Panteleev wrote:

 On Sat, 13 Aug 2011 08:08:09 +0300, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:

 Thoughts on std.system.OS? Is there a good reason to leave it? In
 principle, it's a nice idea, but I just don't see how it can deliver.
 And if it can't deliver, it should be removed IMHO. What do you think?


 
 Why not use uname on non-Windows systems, and report the kernel version?


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.

- Jonathan M Davis
Aug 13 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 13 Aug 2011 13:23:08 +0300, Jonathan M Davis <jmdavisProg 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?)

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Aug 13 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 13, 2011 13:38:00 Vladimir Panteleev wrote:

 On Sat, 13 Aug 2011 13:23:08 +0300, Jonathan M Davis <jmdavisProg 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.


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.


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.
 



- Jonathan M Davis
Aug 13 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 13 Aug 2011 13:51:47 +0300, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 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.


Really? I've *never* seen the `uname -a` shell command (which I assume is  
just a thin syscall wrapper) print out the distro name.



 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.

 which



While perhaps abstract version numbers don't make much sense to programs,  
they can be useful information for the program's users. For example,  
adding OS version numbers to log files may help troubleshooting.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Aug 13 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 13, 2011 14:12:07 Vladimir Panteleev wrote:

 On Sat, 13 Aug 2011 13:51:47 +0300, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:

 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.


 
 Really? I've *never* seen the `uname -a` shell command (which I assume is
 just a thin syscall wrapper) print out the distro name.


It does on at least some distros. The distro name is frequently part of the 
version number. For instance, on my Arch box right now, it's 3.0-ARCH. But if 
not all distros that we'd want to list do that, then that's not going to work. 
And if that doesn't work, then I have no idea how you'd get your hands on the 
distro name programmatically.



 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.

 which



 
 While perhaps abstract version numbers don't make much sense to programs,
 they can be useful information for the program's users. For example,
 adding OS version numbers to log files may help troubleshooting.


Except that you need useful, understandable version numbers to make sense. 2.6 
and 3.0 are virtually meaningless on Linux (which would be the major and minor 
number). Maybe the minor number will mean something with the 3 series, but 
we've had 2.6 for years now, and there's an enormous difference between 2.6.3 
and 2.6.33.

Even worse, major and minor numbers don't mean _anything_ on Windows. What are 
you going to give? The NT kernel version? That's pretty much meaningless. As 
far as Windows versioning goes, having XP, Vista, etc. are about all that's 

too, but that doesn't exactly fit in with major/minor numbers.

And I have no clue what Mac OS X and FreeBSD do.

Overall, I just don't see how the major and minor version could be of any real 
value to anyone.

- Jonathan M Davis
Aug 13 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 13 Aug 2011 14:23:35 +0300, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 It does on at least some distros.


TIL...


 Except that you need useful, understandable version numbers to make  
 sense. 2.6
 and 3.0 are virtually meaningless on Linux (which would be the major and  
 minor
 number). Maybe the minor number will mean something with the 3 series,  
 but
 we've had 2.6 for years now, and there's an enormous difference between  
 2.6.3
 and 2.6.33.


Perhaps make the version number a dynamic array?


 Even worse, major and minor numbers don't mean _anything_ on Windows.  
 What are
 you going to give? The NT kernel version?


By the way, the Windows versions in the OS enum are very incomplete - only  
major client versions are listed.

A rather large variety of Windows versions and editions exists, see for  
example:

http://msdn.microsoft.com/en-us/library/ms724429(v=vs.85).aspx
http://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

Considering the large variety, I think it would be a mistake to try to  
keep track of all Windows versions in an enum. I would like to suggest to  
replace all Windows versions in the OS enum with a single "Windows"  
entity, and add some constants or enums for common Windows versions to  
allow comparisons. For example:

if (os_major >  OS_MAJOR_WINDOWS_XP ||
    (os_major == OS_MAJOR_WINDOWS_XP && os_minor >= OS_MINOR_WINDOWS_XP))
{
     // This is Windows XP or higher
}

Going even further, a version structure supporting comparison operators  
would make the above simpler. (Or are regular dynamic arrays suitable for  
this?)

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Aug 13 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 13, 2011 14:49:13 Vladimir Panteleev wrote:

 On Sat, 13 Aug 2011 14:23:35 +0300, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:

 It does on at least some distros.


 
 TIL...
 

 Except that you need useful, understandable version numbers to make
 sense. 2.6
 and 3.0 are virtually meaningless on Linux (which would be the major and
 minor
 number). Maybe the minor number will mean something with the 3 series,
 but
 we've had 2.6 for years now, and there's an enormous difference between
 2.6.3
 and 2.6.33.


 
 Perhaps make the version number a dynamic array?
 

 Even worse, major and minor numbers don't mean _anything_ on Windows.
 What are
 you going to give? The NT kernel version?


 
 By the way, the Windows versions in the OS enum are very incomplete - only
 major client versions are listed.
 
 A rather large variety of Windows versions and editions exists, see for
 example:
 
 http://msdn.microsoft.com/en-us/library/ms724429(v=vs.85).aspx
 http://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions
 
 Considering the large variety, I think it would be a mistake to try to
 keep track of all Windows versions in an enum. I would like to suggest to
 replace all Windows versions in the OS enum with a single "Windows"
 entity, and add some constants or enums for common Windows versions to
 allow comparisons. For example:
 
 if (os_major >  OS_MAJOR_WINDOWS_XP ||
     (os_major == OS_MAJOR_WINDOWS_XP && os_minor >= OS_MINOR_WINDOWS_XP))
 {
      // This is Windows XP or higher
 }
 
 Going even further, a version structure supporting comparison operators
 would make the above simpler. (Or are regular dynamic arrays suitable for
 this?)


There are a large variety of Linux distros as well, and we can't cover all of 
them, so I'm not sure that the fact that there are lots of stray versions of 
Windows depending on how you count them merits handling Windows like that. 
However, it _is_ a bit odd to treat each version of Windows as a separate OS 
in the enum when none of the other OSes have more than one version in the 
list.

As for doing something like you suggest with the os_major and os_minor 
numbers, it does seem kind of messy. If all you want is comparison, you can do 
that with the existing enum, and it covers all of the Windows versions that 
most people will care about.

The situation definitely requires some consideration though. And it should 
probably be redesigned a bit.

- Jonathan M Davis
Aug 13 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 13 Aug 2011 20:16:52 +0300, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 As for doing something like you suggest with the os_major and os_minor
 numbers, it does seem kind of messy. If all you want is comparison, you  
 can do
 that with the existing enum, and it covers all of the Windows versions  
 that
 most people will care about.


Please, no. Ignoring server Windows versions is a huge mistake, and their  
version numbers go in the same pace as the client ones.

Personally, I don't think that distro detection belongs in Phobos. It  
seems way too undocumented and unstandardized.


 As for doing something like you suggest with the os_major and os_minor
 numbers, it does seem kind of messy.


I think it's less messy than pretending that all but certain popular  
Windows versions don't exist.

What about the dynamic array idea for version number representation and  
comparison? Would that work? It seems to me like a nice clean solution.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Aug 13 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 13, 2011 22:08:36 Vladimir Panteleev wrote:

 On Sat, 13 Aug 2011 20:16:52 +0300, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:

 As for doing something like you suggest with the os_major and os_minor
 numbers, it does seem kind of messy. If all you want is comparison, you
 can do
 that with the existing enum, and it covers all of the Windows versions
 that
 most people will care about.


 
 Please, no. Ignoring server Windows versions is a huge mistake, and their
 version numbers go in the same pace as the client ones.
 
 Personally, I don't think that distro detection belongs in Phobos. It
 seems way too undocumented and unstandardized.


Which is part of why I brought up the idea that perhas std.system shouldn't be 
doing what it's trying to do. If it can't do it right, it shouldn't do it all.


 As for doing something like you suggest with the os_major and os_minor
 numbers, it does seem kind of messy.


 
 I think it's less messy than pretending that all but certain popular
 Windows versions don't exist.
 
 What about the dynamic array idea for version number representation and
 comparison? Would that work? It seems to me like a nice clean solution.


If we can't do this for all of the OSes, I don't see much reason to have it in 
std.system. Something could be put in std.windows, but it seems to me that the 
only place that this functionality is of much value is in comparing versions 
of Windows (and maybe comparing the versons on the Mac) to determine some 
level of compatibility or somesuch.

In core.sys.windows.windows, you have the windows system call GetVersion. 
_That_ is probably what should be used to determine versions on Windows, and 
maybe it should be wrapped, but that would be a Windows thing. Personally, I'm 
inclined to drop the Os enum along with the os and os_major and os_minor 
variables, because I just don't think that we can get them to be correct 
enough of generally useful enough to be worth having. It's too OS-specific to 
be trying to handle it in an OS-generic manner like that.

- Jonathan M Davis
Aug 13 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 Personally, I'm
 inclined to drop the Os enum along with the os and os_major and os_minor
 variables, because I just don't think that we can get them to be correct
 enough of generally useful enough to be worth having. It's too  
 OS-specific to
 be trying to handle it in an OS-generic manner like that.


Looking at the code again, I noticed there's a Family enum, which seems to  
me closer to what the OS enum should really be. I think Family should just  
replace OS.

I don't agree that we should just drop version numbers. As I said before,  
they can be useful for users. They can also be useful for programs that  
care only about a certain OS family.

What do you think about this?

https://github.com/CyberShadow/phobos/blob/new-std-system/std/system.d

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Aug 14 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, August 14, 2011 19:24:21 Vladimir Panteleev wrote:

 On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:

 Personally, I'm
 inclined to drop the Os enum along with the os and os_major and os_minor
 variables, because I just don't think that we can get them to be correct
 enough of generally useful enough to be worth having. It's too
 OS-specific to
 be trying to handle it in an OS-generic manner like that.


 
 Looking at the code again, I noticed there's a Family enum, which seems to
 me closer to what the OS enum should really be. I think Family should just
 replace OS.
 
 I don't agree that we should just drop version numbers. As I said before,
 they can be useful for users. They can also be useful for programs that
 care only about a certain OS family.
 
 What do you think about this?
 
 https://github.com/CyberShadow/phobos/blob/new-std-system/std/system.d


I'm not at all convinced that it makes any sense to try and handle OS version 
numbers in a system-independent manner. You have to know what OS you're on for 
them to mean anything, in which case, why try and handle them in an OS-
independent manner?

On Linux, the version number is probably pointless. It's the version number 
for the kernel. Most programs won't care one whit about that. If they care 
about a version number, odds are that it's the version number of some program 
or library on the system that they're using, not the kernel. And in general, 
if you care, you care when you compile, not when you run the program. I would 
expect FreeBSD to be the same. I don't know about Mac OS X.

However, the case of Windows is _completely_ different from the others. Windows 
version numbers mean _nothing_ to most people. They want stuff like Windows XP 
and Windows 7. They'd probably expect an enum with the primary versions of 
Windows in it. But since there _are_ other stray versions of Windows, and the 
actual version number could matter for some stuff, finding a clean way to deal 
with Windows' GetVersion call and dealing with the full version number and at 
the same time dealing with the more commonly useful enum needs to happen (as 
part of that, the enum would probably use the version numbers for the values 
of its enum members similar to what you did with you constants). It's all 
_very_ different from Linux, FreeBSD, and Mac OS X. And I don't see _any_ 
reason to try and treat them the same.

If we're going to deal with operating system versions, it should be in a 
system-specific manner and _not_ in std.system.

Endian is effectively a runtime enum for the versions which deal with 
endianness. Family is effectively the runtime enum for the OS versions. As 
such, I think that both have some value. I do think that you have a valid 
point that OS would be a better name for Family, so I'll make that change in 
my pull request. However, I do _not_ think that it makes sense to try and do 
getOSVersion like you're doing.

We need to find a clean, simple and yet flexible way to deal with version 
numbers for Windows and put that in std.windows or core.windows somewhere - 
preferably in core IMHO (and actually I'd be kind of inclined to put 
std.system  in core rather than std given what it's doing). If something 
similar for the Mac makes sense, then we can add that somewhere. For Linux and 
FreeBSD, I expect that there's no point - particularly since I'm not sure that 
it's quite safe to trust uname to be consistent anyway. But I do not think 
that putting that in std.system in an OS-independent way makes sense.

- Jonathan M Davis
Aug 14 2011
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 14 Aug 2011 22:20:01 +0300, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 But I do not think that putting that in std.system in an OS-independent  
 way makes sense.


OK, I agree with your points. No objections.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Aug 14 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-14 21:20, Jonathan M Davis wrote:

 On Sunday, August 14, 2011 19:24:21 Vladimir Panteleev wrote:

 On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis<jmdavisProg gmx.com>

 wrote:

 Personally, I'm
 inclined to drop the Os enum along with the os and os_major and os_minor
 variables, because I just don't think that we can get them to be correct
 enough of generally useful enough to be worth having. It's too
 OS-specific to
 be trying to handle it in an OS-generic manner like that.


 Looking at the code again, I noticed there's a Family enum, which seems to
 me closer to what the OS enum should really be. I think Family should just
 replace OS.

 I don't agree that we should just drop version numbers. As I said before,
 they can be useful for users. They can also be useful for programs that
 care only about a certain OS family.

 What do you think about this?

 https://github.com/CyberShadow/phobos/blob/new-std-system/std/system.d


 I'm not at all convinced that it makes any sense to try and handle OS version
 numbers in a system-independent manner. You have to know what OS you're on for
 them to mean anything, in which case, why try and handle them in an OS-
 independent manner?

 On Linux, the version number is probably pointless. It's the version number
 for the kernel. Most programs won't care one whit about that. If they care
 about a version number, odds are that it's the version number of some program
 or library on the system that they're using, not the kernel. And in general,
 if you care, you care when you compile, not when you run the program. I would
 expect FreeBSD to be the same. I don't know about Mac OS X.


I think it makes sense to be able to get version information about Mac 
OS X. I would consider Windows XP, Vista and so on be similar to Mac OS 
X 10.5, 10.6.


-- 
/Jacob Carlborg
Aug 14 2011
prev sibling next sibling parent reply Kai Meyer <kai unixlords.com> writes:
On 08/14/2011 01:20 PM, Jonathan M Davis wrote:

 On Sunday, August 14, 2011 19:24:21 Vladimir Panteleev wrote:

 On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis<jmdavisProg gmx.com>

 wrote:

 Personally, I'm
 inclined to drop the Os enum along with the os and os_major and os_minor
 variables, because I just don't think that we can get them to be correct
 enough of generally useful enough to be worth having. It's too
 OS-specific to
 be trying to handle it in an OS-generic manner like that.


 Looking at the code again, I noticed there's a Family enum, which seems to
 me closer to what the OS enum should really be. I think Family should just
 replace OS.

 I don't agree that we should just drop version numbers. As I said before,
 they can be useful for users. They can also be useful for programs that
 care only about a certain OS family.

 What do you think about this?

 https://github.com/CyberShadow/phobos/blob/new-std-system/std/system.d


 I'm not at all convinced that it makes any sense to try and handle OS version
 numbers in a system-independent manner. You have to know what OS you're on for
 them to mean anything, in which case, why try and handle them in an OS-
 independent manner?

 On Linux, the version number is probably pointless. It's the version number
 for the kernel. Most programs won't care one whit about that. If they care
 about a version number, odds are that it's the version number of some program
 or library on the system that they're using, not the kernel. And in general,
 if you care, you care when you compile, not when you run the program. I would
 expect FreeBSD to be the same. I don't know about Mac OS X.


I would argue against using the kernel version as the "OS Version". It's 
as useless as the NTKernel version to most programmers. I would argue 
that there is a good case for determining if you are on a Debian or 
Redhat based system. I actually think this sort of system-independant OS 
version detection is very valuable. I'm on different linux systems all 
the time. Identifying which distro is running is both simple and 
necessary before doing any systems administration. I do and want to 
continue to use D for systems adminsitration. The most difficult 
programming tasks are making the same program work the same way on 
different platforms. The more tools D can provide that give the 
programmer this information in an easy to consume format, the more 
popular D will be for cross-platform programming.


 However, the case of Windows is _completely_ different from the others. Windows
 version numbers mean _nothing_ to most people. They want stuff like Windows XP
 and Windows 7. They'd probably expect an enum with the primary versions of
 Windows in it. But since there _are_ other stray versions of Windows, and the
 actual version number could matter for some stuff, finding a clean way to deal
 with Windows' GetVersion call and dealing with the full version number and at
 the same time dealing with the more commonly useful enum needs to happen (as
 part of that, the enum would probably use the version numbers for the values
 of its enum members similar to what you did with you constants). It's all
 _very_ different from Linux, FreeBSD, and Mac OS X. And I don't see _any_
 reason to try and treat them the same.

 If we're going to deal with operating system versions, it should be in a
 system-specific manner and _not_ in std.system.

 Endian is effectively a runtime enum for the versions which deal with
 endianness. Family is effectively the runtime enum for the OS versions. As
 such, I think that both have some value. I do think that you have a valid
 point that OS would be a better name for Family, so I'll make that change in
 my pull request. However, I do _not_ think that it makes sense to try and do
 getOSVersion like you're doing.

 We need to find a clean, simple and yet flexible way to deal with version
 numbers for Windows and put that in std.windows or core.windows somewhere -
 preferably in core IMHO (and actually I'd be kind of inclined to put
 std.system  in core rather than std given what it's doing). If something
 similar for the Mac makes sense, then we can add that somewhere. For Linux and
 FreeBSD, I expect that there's no point - particularly since I'm not sure that
 it's quite safe to trust uname to be consistent anyway. But I do not think
 that putting that in std.system in an OS-independent way makes sense.

 - Jonathan M Davis
Aug 15 2011
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, August 15, 2011 10:05 Kai Meyer wrote:

 On 08/14/2011 01:20 PM, Jonathan M Davis wrote:

 On Sunday, August 14, 2011 19:24:21 Vladimir Panteleev wrote:

 On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M
 Davis<jmdavisProg gmx.com>
 
 wrote:

 Personally, I'm
 inclined to drop the Os enum along with the os and os_major and
 os_minor variables, because I just don't think that we can get them to
 be correct enough of generally useful enough to be worth having. It's
 too OS-specific to
 be trying to handle it in an OS-generic manner like that.


 
 Looking at the code again, I noticed there's a Family enum, which seems
 to me closer to what the OS enum should really be. I think Family
 should just replace OS.
 
 I don't agree that we should just drop version numbers. As I said
 before, they can be useful for users. They can also be useful for
 programs that care only about a certain OS family.
 
 What do you think about this?
 
 https://github.com/CyberShadow/phobos/blob/new-std-system/std/system.d


 
 I'm not at all convinced that it makes any sense to try and handle OS
 version numbers in a system-independent manner. You have to know what OS
 you're on for them to mean anything, in which case, why try and handle
 them in an OS- independent manner?
 
 On Linux, the version number is probably pointless. It's the version
 number for the kernel. Most programs won't care one whit about that. If
 they care about a version number, odds are that it's the version number
 of some program or library on the system that they're using, not the
 kernel. And in general, if you care, you care when you compile, not when
 you run the program. I would expect FreeBSD to be the same. I don't know
 about Mac OS X.


 
 I would argue against using the kernel version as the "OS Version". It's
 as useless as the NTKernel version to most programmers. I would argue
 that there is a good case for determining if you are on a Debian or
 Redhat based system. I actually think this sort of system-independant OS
 version detection is very valuable. I'm on different linux systems all
 the time. Identifying which distro is running is both simple and
 necessary before doing any systems administration. I do and want to
 continue to use D for systems adminsitration. The most difficult
 programming tasks are making the same program work the same way on
 different platforms. The more tools D can provide that give the
 programmer this information in an easy to consume format, the more
 popular D will be for cross-platform programming.


It may very well be worth adding a way to detect which distro your on and 
possibly which version of which distro (though that _does_ risk being hard to 
maintain), but I'd argue that it doesn't make sense to do that in a system-
independent manner. Windows, Linux, FreeBSD, and Mac OS X all do versioning 
differently, and when you actually care about versioning, you're going to care 
which one of those you're dealing with. So, each of them might as well be 
dealt with separately rather than trying to have a generic OS version which 
you can't actually use generically anyway.

- Jonathan M Davis
Aug 15 2011
prev sibling parent "Regan Heath" <regan netmail.co.nz> writes:

version number.  In the most recent cases we use it to determine if UAC is  
a possibilty (major version >= 6, which includes Vista, 7, and Server  
2008).  In the past we have used it to determine whether a delay load dll  
should be present.  Having to use a compound IF with an ENUM for each and  
every windows platform would be less nice than using the major version  
number directly.  So, having a phobos function to get it would be nice,  
plus it saves people having to find and code the C function call  
themselves.  I don't have any preference for which module it might go in,  
nor do I understand the other OS versioning well enough to have an opinion  
on whether it makes sense to make this a cross platform feature, or just  
windows specific.
Aug 16 2011
prev sibling parent Kai Meyer <kai unixlords.com> writes:
On 08/13/2011 11:16 AM, Jonathan M Davis wrote:

 On Saturday, August 13, 2011 14:49:13 Vladimir Panteleev wrote:

 On Sat, 13 Aug 2011 14:23:35 +0300, Jonathan M Davis<jmdavisProg gmx.com>

 wrote:

 It does on at least some distros.


 TIL...


 Except that you need useful, understandable version numbers to make
 sense. 2.6
 and 3.0 are virtually meaningless on Linux (which would be the major and
 minor
 number). Maybe the minor number will mean something with the 3 series,
 but
 we've had 2.6 for years now, and there's an enormous difference between
 2.6.3
 and 2.6.33.


 Perhaps make the version number a dynamic array?


 Even worse, major and minor numbers don't mean _anything_ on Windows.
 What are
 you going to give? The NT kernel version?


 By the way, the Windows versions in the OS enum are very incomplete - only
 major client versions are listed.

 A rather large variety of Windows versions and editions exists, see for
 example:

 http://msdn.microsoft.com/en-us/library/ms724429(v=vs.85).aspx
 http://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

 Considering the large variety, I think it would be a mistake to try to
 keep track of all Windows versions in an enum. I would like to suggest to
 replace all Windows versions in the OS enum with a single "Windows"
 entity, and add some constants or enums for common Windows versions to
 allow comparisons. For example:

 if (os_major>   OS_MAJOR_WINDOWS_XP ||
      (os_major == OS_MAJOR_WINDOWS_XP&&  os_minor>= OS_MINOR_WINDOWS_XP))
 {
       // This is Windows XP or higher
 }

 Going even further, a version structure supporting comparison operators
 would make the above simpler. (Or are regular dynamic arrays suitable for
 this?)


 There are a large variety of Linux distros as well, and we can't cover all of
 them, so I'm not sure that the fact that there are lots of stray versions of
 Windows depending on how you count them merits handling Windows like that.
 However, it _is_ a bit odd to treat each version of Windows as a separate OS
 in the enum when none of the other OSes have more than one version in the
 list.


That's why you let the community keep the enum up to date. Offer support 
for the major distros (My list would include RedHat, Debian, SuSE, and 
their derivatives (Fedora, Ubuntu, openSuSE). Once you have those 6 
(that's not a big number), it's not hard to let the community add their 
favorite distro (like Arch).


 As for doing something like you suggest with the os_major and os_minor
 numbers, it does seem kind of messy. If all you want is comparison, you can do
 that with the existing enum, and it covers all of the Windows versions that
 most people will care about.

 The situation definitely requires some consideration though. And it should
 probably be redesigned a bit.

 - Jonathan M Davis
Aug 15 2011
prev sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 13.08.2011, 13:12 Uhr, schrieb Vladimir Panteleev  
<vladimir thecybershadow.net>:


 Really? I've *never* seen the `uname -a` shell command (which I assume  
 is just a thin syscall wrapper) print out the distro name.



2.6.39-gentoo-r3

It seems to work, and return the Kernel package version more or less. So  
here it is the Gentoo package in the 3rd revision.

Files to look for distributions / versions:
1) /etc/*-release
2) /etc/slackware-version
3) /proc/version

The release file seems to have become a pseudo standard. /proc/version  
gives the kernel version which I find more interesting than the  
distribution version. Both have their use of course. Some versions of  
distributions may come with a configuration that is incompatible to your  
program, so a way to figure that out would help. Also there are subtle  
differences for example in how the default Java installation is found, how  
the filesystem is laid out etc.
Aug 13 2011
parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 13.08.2011, 16:00 Uhr, schrieb Marco Leise <Marco.Leise gmx.de>:


 Am 13.08.2011, 13:12 Uhr, schrieb Vladimir Panteleev  
 <vladimir thecybershadow.net>:


 Really? I've *never* seen the `uname -a` shell command (which I assume  
 is just a thin syscall wrapper) print out the distro name.



 2.6.39-gentoo-r3

 It seems to work, and return the Kernel package version more or less. So  
 here it is the Gentoo package in the 3rd revision.

 Files to look for distributions / versions:
 1) /etc/*-release
 2) /etc/slackware-version
 3) /proc/version

 The release file seems to have become a pseudo standard. /proc/version  
 gives the kernel version which I find more interesting than the  
 distribution version. Both have their use of course. Some versions of  
 distributions may come with a configuration that is incompatible to your  
 program, so a way to figure that out would help. Also there are subtle  
 differences for example in how the default Java installation is found,  
 how the filesystem is laid out etc.


This script may help: http://www.unix.com/92528-post5.html
Aug 13 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-08-13 12:51, Jonathan M Davis wrote:


 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.


In Mac OS X you have three version numbers, for example: 10.6.8. Or at 
least two, don't know if I would call the first one a version number. I 
mean, Mac OS 9 and Mac OS 10 is two completely different operating systems.





 - Jonathan M Davis



-- 
/Jacob Carlborg
Aug 13 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 13, 2011 14:37:46 Jacob Carlborg wrote:

 On 2011-08-13 12:51, Jonathan M Davis wrote:


 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.


 
 In Mac OS X you have three version numbers, for example: 10.6.8. Or at
 least two, don't know if I would call the first one a version number. I
 mean, Mac OS 9 and Mac OS 10 is two completely different operating systems.


Well, since the OS is Mac OS X, not Mac OS (at least so far as versioning in D 
goes), then presumably 10.6.8 would have the major number 6 and the minor 
number 8.

- Jonathan M Davis
Aug 13 2011
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-08-13 16:58:41 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:


 Well, since the OS is Mac OS X, not Mac OS (at least so far as versioning in D
 goes), then presumably 10.6.8 would have the major number 6 and the minor
 number 8.


But that won't follow Apple nomenclature. The gestalt constants for 
getting those three numbers are: gestaltSystemVersionMajor, 
gestaltSystemVersionMinor, and gestaltSystemVersionBugFix. I don't 
think it'd be wise to shift the names just because Apple marketing has 
decided to stall the major number for a decade or more.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Aug 13 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 13, 2011 20:00:13 Michel Fortin wrote:

 On 2011-08-13 16:58:41 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:

 Well, since the OS is Mac OS X, not Mac OS (at least so far as
 versioning in D goes), then presumably 10.6.8 would have the major
 number 6 and the minor number 8.


 
 But that won't follow Apple nomenclature. The gestalt constants for
 getting those three numbers are: gestaltSystemVersionMajor,
 gestaltSystemVersionMinor, and gestaltSystemVersionBugFix. I don't
 think it'd be wise to shift the names just because Apple marketing has
 decided to stall the major number for a decade or more.


My conclusion to all of this is that trying to have os, os_major, and os_minor 
versions like this is a mistake. It just varies too much from OS to OS. We may 
want to provide functionality which is OS-specific to do this sort of thing, 
but handling it in an OS-generic manner doesn't seem reasonable to me given 
the differing situations between OSes.

- Jonathan M Davis
Aug 13 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-13 18:58, Jonathan M Davis wrote:

 On Saturday, August 13, 2011 14:37:46 Jacob Carlborg wrote:

 On 2011-08-13 12:51, Jonathan M Davis wrote:


 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.


 In Mac OS X you have three version numbers, for example: 10.6.8. Or at
 least two, don't know if I would call the first one a version number. I
 mean, Mac OS 9 and Mac OS 10 is two completely different operating systems.


 Well, since the OS is Mac OS X, not Mac OS (at least so far as versioning in D
 goes), then presumably 10.6.8 would have the major number 6 and the minor
 number 8.

 - Jonathan M Davis


Exactly.

-- 
/Jacob Carlborg
Aug 14 2011
prev sibling parent amanda <maamanda26 yahoo.com> writes:
hi,D:)When you have Herpes, HIV/AIDS, hpv,or any other STD, it can feel like
you are all alone in the world  DatingHerpesSingles.com is a place where you
didn't have to worry about being rejected   Just feel free to chat, share
stories, make friends in your local area.
Aug 14 2011
prev sibling next sibling parent amanda <maamanda26 yahoo.com> writes:
      when it comes to herpes,I hate how many people are using the word
"end".It's not the end,start your new life DatingHerpesSingles.com
Aug 14 2011
prev sibling parent Kai Meyer <kai unixlords.com> writes:
On 08/13/2011 04:23 AM, Jonathan M Davis wrote:

 On Saturday, August 13, 2011 13:18:29 Vladimir Panteleev wrote:

 On Sat, 13 Aug 2011 08:08:09 +0300, Jonathan M Davis<jmdavisProg gmx.com>

 wrote:

 Thoughts on std.system.OS? Is there a good reason to leave it? In
 principle, it's a nice idea, but I just don't see how it can deliver.
 And if it can't deliver, it should be removed IMHO. What do you think?


 Why not use uname on non-Windows systems, and report the kernel version?


 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.

 - Jonathan M Davis


Yup, it's easy:


http://mattiasgeniar.be/2008/10/05/how-to-find-out-your-current-distribution-version/

Between Debian and RedHat and their derivatives (ie Ubuntu and Fedora 
respectively), you should hit nearly all distributions.

I think /etc/issue is the most reliable place to look for distribution 
information, and then fall back to the other files.
Aug 15 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-13 07:08, Jonathan M Davis wrote:

 I made a few changes to std.system to clean it up a bit and make it more
 thorough:

 https://github.com/D-Programming-Language/phobos/pull/186

 However, on reflection, I'm not convinced that the OS enum and its
 corresponding os variable along with the os_major and os_minor variables serve
 any real purpose. Their purpose appears to be to tell you at runtime which OS
 you're actually running on - as in version, not just family of OS. I don't see
 how this is actually possible outside of perhaps Windows (it's just defaulted
 to WindowsXP thus far). And if it can't really do its job, I'd just as soon
 remove it. And since it hasn't been in the documentation, it's not likely to
 break any code.

 Thoughts on std.system.OS? Is there a good reason to leave it? In principle,
 it's a nice idea, but I just don't see how it can deliver. And if it can't
 deliver, it should be removed IMHO. What do you think?

 - Jonathan M Davis


It can be usefully to detect if you're running Mac OS X 10.5, 10.6 or 
10.7. The function "Gestalt" can be used for that found in the 
CoreServices framework.

-- 
/Jacob Carlborg
Aug 13 2011