Thoughts on std.system.OS

[Jonathan M Davis]

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.

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