On Sunday, August 14, 2011 19:24:21 Vladimir Panteleev wrote: > On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis <[email protected]> > > 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
