[Implemented] New OS version constants

[kenmo]

For 2014 and beyond, OSVersion() should probably have more constants:

Code: Select all

#PB_OS_Windows_10
#PB_OS_MacOSX_10_9
#PB_OS_MacOSX_10_10
and more...

Also, wouldn't it be nice if we could get the sub-version of the OS as well? Maybe a separate function?

For example, OS X 10.9.5 would return a string "10.9.5" or an integer 1095, or some other sort of value.

(I still like OSVersion() and the simple #PB_OS_ constants too!)

[PB]

> #PB_OS_Windows_10

Doesn't exist yet, but of course it will when 10 is released.

In the meantime, that's what #PB_OS_Windows_Future is for.

[c4s]

At least on Windows version checking won't be that easy anymore. More Information here:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
http://arstechnica.com/information-tech ... ably-work/

[davido]

@PB,
>In the meantime, that's what #PB_OS_Windows_Future is for.

I presume that when W10 arrives it will take the value of #PB_OS_Windows_Future and #PB_OS_Windows_Future will be replaced by a new value.
Do you think that is so?

[Shield]

No, #PB_OS_Windows_Future will not change the value and #PB_OS_Windows_10 will be some value that is larger than #PB_OS_Windows_8.
Check (debug) the values of the constants and make a good guess.

[PB]

Like Shield said:

Code: Select all

Debug #PB_OS_Windows_8      ; 90
Debug #PB_OS_Windows_Future ; 200

My guess is that #PB_OS_Windows_10 will be 100 when
Windows 10 actually get released to the public.

That future value is very low, IMO. It should be 900 or so,
because at this rate the value of 200 will be reached very
quickly.

[luis]

That future value is very low, IMO. It should be 900 or so,
because at this rate the value of 200 will be reached very
quickly.

It's irrelevant since you are supposed to use the constant in your tests and not the literal value currently associated to it.

#PB_OS_Windows_Future is 200 in PB 5.31, but could be 500 in PB 7.50 where 200 will be associated with #PB_OS_Windows_14.

[PB]

> It's irrelevant

Only if you upgrade PureBasic with each new release.

For people sticking with an older version for whatever reason,
like I need to for one app because I need Gnozal's libs, then
#PB_OS_Windows_Future will NOT represent a future Windows
at all, but will clash with #PB_OS_Windows_14 or something.

So it should've been a higher value to start with, like 900 or
even more, to truly future-proof it.

[luis]

For people sticking with an older version for whatever reason,
like I need to for one app because I need Gnozal's libs, then
#PB_OS_Windows_Future will NOT represent a future Windows
at all, but will clash with #PB_OS_Windows_14 or something.

What are you talking about ?

Let's say you stick with PB 5.31, #PB_OS_Windows_Future will be used for all future versions of Windows not known at the time 5.31 was written.
You have no knowledge about a #PB_OS_Windows_14 since PB 5.31 does not know about a constant from the future and never will. OsVersion() will report Windows 14 as "future version". Perfectly fine.

And what has all this to do with the number associated to #PB_OS_Windows_Future by the way ?
It can be 10, 100 or 1000 as long it is higher than the value associated to the last recognized OS version.

So it should've been a higher value to start with, like 900 or
even more, to truly future-proof it.

Why ? The value can grow in time as new version constants are added before it.

All the constant values could be completely changed from one PB version to the next for what you know. Why do you care ?
It's all irrelevant since you are using constants mnemonics.

[Rescator]

#PB_OS_Windows_Future is basically "I got no clue what windows this is".
The value may change with any PureBasic release so you should always use the constant and do not use hardcoded values.

If you do stuff like "If OSVersion() < #PB_OS_Windows_Future"
then on Windows 8.1 you get the result #PB_OS_Windows_8
but on future Windows 10 (and later Windows 11 and Windows 12)
the OSVersion() call will always return #PB_OS_Windows_Future.

As long as you use the constants it will work as intended, even if Fred should totally change the way OSVersion() works it will still work, as long as you use the constants (He'll make sure they are sequentially in the same order).

If you use values directly then you are asking for trouble.

Always reference the constants, and never re-define them and never store their value (in a file or similar) and read it back.

There is one constant missing though #PB_OS_Unknown this could probably be #PB_OS_Unknown=0 as that is not used.
That being said I've yet to see a situation where OSVersion() has failed, if it's designed to never fail then a Unknown value is useless.

Also note that OSVersion() may not tell you if it is Windows 8 (depends on how Fred fetches the info), it may just tell you the OS is Windows 8 compatible (which is really all that matters to you and program after all).

I do agree however that constants like #PB_OS_Windows_10, #PB_OS_MacOSX_10_9 and #PB_OS_MacOSX_10_10 should be added when appropriate.

There is also #PB_OS_Windows_8_1 missing which (if possible) I'd like to see added in the next release of PB.
8.1 is Windows NT 6.3 (and 8.0 is Windows NT 6.2) so there is a identifiable numerical difference there.

[es_91]

It should be 900 or so,
because at this rate the value of 200 will be reached very
quickly.

Just to throw some rumors in, Microsoft claimed, Windows 10 would be the last major release (at least for quite a long time.)

[StarBootics]

Hello everyone,

Just to mention that on Ubuntu 14.10 the OSVersion() return the #PB_OS_Linux_Future value.

Best regards
StarBootics