wxPlatform class ?

[Olly Betts]

On 2006-07-07, Francesco Montorsi wrote:
> 1) because while on Windows you have the GetVersionEx() API which makes 
> things easier (since returns documented values), AFAIK, there's no such 
> API in Unix world.

In general, you can't run a program compiled for one Unix on another,
whereas the different Windows versions are built to be mostly binary
compatible (at least upwardly so).  So for Unix, the OS you're compiling
for is the OS you'll be running on.

While some Unix-like systems have compatibility layers for foreign
binaries, these are analagous to running a Windows binary on Linux using
wine, and I wouldn't expect that case to report "Linux" as the current OS!
They're also not widely used - the main users seem to be companies who
want to migrate OS but have closed source software they need to keep
using.

> Of course there is `uname -o` and I guess that the strings it returns 
> should be quite reliable for OS detection...

Not really - "uname -o" isn't portable.  It seems to be Linux specific
in fact - none of Solaris, FreeBSD, NetBSD, OpenBSD support it at least.

A much cleaner and more efficient way to implement this on Unix would be
with compile time checks for preprocessor symbols.  E.g. GCC defines
__linux__ if you're compiling for Linux, and 

>          wxString str(wxGetOsDescription());
>          return str.Contains(wxT("AMD64")) ||
>                 str.Contains(wxT("IA64")) ||
>                 str.Contains(wxT("x64")) ||
>                 str.Contains(wxT("X64"));

Ick.  That misses several existing cases ("alpha", "hppa64", and "ppc64"
for example), and is inherently brittle for future systems.  Looking for
"64" in the output of 'uname -m' would be slightly better, but already
misses at least "alpha" and I suspect soon 64 bit processors will become
sufficiently standard that they'll stop having 64 in their names at all.

Using uname's output (as wxGetOsDescription does) doesn't really handle
the "64 bit system in 32 bit mode" case anyway:

$ uname -a
Linux ubuntu 2.6.15-23-amd64-k8 #1 SMP PREEMPT Tue May 23 13:51:32 UTC 2006 x86_64 GNU/Linux
$ linux32 uname -a
Linux ubuntu 2.6.15-23-amd64-k8 #1 SMP PREEMPT Tue May 23 13:51:32 UTC 2006 i686 GNU/Linux

> As you can see this function can be useful for a program to know on 
> which architecture it's running, regardless of the system where it was 
> compiled. This obviously because it's possible, in some cases, to run 
> 32bit programs in 64bit operating systems.

OK, but what's the motivation for this?  Why is this something a user of
the wx API would ever want to know?

I can see reasons why some people might want a way to record a value for
the current OS and toolkit in a file, but I'm failing to see exactly
what "is this a 64 bit system" is useful for.  Every reason I can think
of is better tested for in a more direct way.  So I don't really
understand how it should behave and so how best to implement it...

> sizeof(void*)==8 is a compile-time test; the whole sense of 
> wxToolkitInfo is to do these tests at run-time.

Although if the answer can't change from compile time to run time then
the two are the same, just the run-time test is more efficient!

Cheers,
    Olly