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