Thoughts on std.system.OS

[Kai Meyer]

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.

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