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
next sibling parent 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
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 next sibling 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 Jacob Carlborg <doob me.com> writes:
On 2011-08-13 12:51, Jonathan M Davis wrote:
 #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.

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.
 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

-- /Jacob Carlborg
Aug 13 2011
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:
 #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.

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:
      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 next sibling parent "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
prev sibling next sibling 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. #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
Aug 13 2011
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 "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.
 #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.

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
prev sibling 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.
 #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.

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 useful, and that's in the OS enum. Maybe the service pack #1 would be useful 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 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 next sibling parent "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
prev sibling next 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
prev sibling next sibling parent "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.

# uname -r 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
prev sibling next sibling 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.

# uname -r 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 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:
 #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.

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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling 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
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 parent 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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling parent 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
prev sibling 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 "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:
I have current C/C++/C# code which obtains and uses the windows major  
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