Thoughts on std.system.OS

Jonathan M Davis jmdavisProg at gmx.com
Mon Aug 15 10:23:03 PDT 2011


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


More information about the Digitalmars-d mailing list