OS, version, CPU

That seems very contradictory to me. If SDL hides all these platform
differences, then why do I need to write lots of platform-specific
code just to get an essential bit of debugging information users
rarely bother to communicate in their bug reports?

And what possible justification is there for SDL_GetPlatform if it
returns a string that’s actually meaningless? By your argument, the
function shouldn’t exist because it’s the developer’s responsibility
to ifdef their code to determine the platform. If that’s not so,
then why is the system-dependent platform version different?

JosephOn Sun, Oct 27, 2013 at 02:40:08PM +0000, Tim Angus wrote:

On Sun, 27 Oct 2013 01:56:37 -0700 T. wrote:

Well, if I’m just going to #ifdef all of my code for different
platforms, what’s SDL for exactly?

The point is that you don’t #ifdef all your code for different
platforms. If you do need platform specific code though, why do you
think SDL should be involved? SDL is a layer theat hides platform
differences. Having it occupy the role of platform delegation seems
counter-intuitive.

Is there any other information you might want in a debug dump?On Oct 27, 2013 10:32 PM, “T. Joseph Carter” wrote:

On Sun, Oct 27, 2013 at 02:40:08PM +0000, Tim Angus wrote:

On Sun, 27 Oct 2013 01:56:37 -0700 T. wrote:

Well, if I’m just going to #ifdef all of my code for different
platforms, what’s SDL for exactly?

The point is that you don’t #ifdef all your code for different
platforms. If you do need platform specific code though, why do you
think SDL should be involved? SDL is a layer theat hides platform
differences. Having it occupy the role of platform delegation seems
counter-intuitive.

That seems very contradictory to me. If SDL hides all these platform
differences, then why do I need to write lots of platform-specific code
just to get an essential bit of debugging information users rarely bother
to communicate in their bug reports?

And what possible justification is there for SDL_GetPlatform if it returns
a string that’s actually meaningless? By your argument, the function
shouldn’t exist because it’s the developer’s responsibility to ifdef their
code to determine the platform. If that’s not so, then why is the
system-dependent platform version different?

Joseph

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Aside from memory and more specific os info I mean. If someone were to
write a debug info module.On Oct 27, 2013 10:53 PM, “Andre D” <@Andre_D> wrote:

Is there any other information you might want in a debug dump?
On Oct 27, 2013 10:32 PM, “T. Joseph Carter” wrote:

On Sun, Oct 27, 2013 at 02:40:08PM +0000, Tim Angus wrote:

On Sun, 27 Oct 2013 01:56:37 -0700 T. wrote:

Well, if I’m just going to #ifdef all of my code for different
platforms, what’s SDL for exactly?

The point is that you don’t #ifdef all your code for different
platforms. If you do need platform specific code though, why do you
think SDL should be involved? SDL is a layer theat hides platform
differences. Having it occupy the role of platform delegation seems
counter-intuitive.

That seems very contradictory to me. If SDL hides all these platform
differences, then why do I need to write lots of platform-specific code
just to get an essential bit of debugging information users rarely bother
to communicate in their bug reports?

And what possible justification is there for SDL_GetPlatform if it
returns a string that’s actually meaningless? By your argument, the
function shouldn’t exist because it’s the developer’s responsibility to
ifdef their code to determine the platform. If that’s not so, then why is
the system-dependent platform version different?

Joseph

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sure, patches welcome!On Sat, Oct 26, 2013 at 10:01 PM, T. Joseph Carter < tjcarter at spiritsubstance.com> wrote:

Hi everyone,

I’ve noticed that SDL doesn’t really have a means to determine the OS and
version. Largely that makes sense because SDL doesn’t care about that. It
wants to know about what backends are supported, and which ones you’re
using right now.

I’m not 100% convinced on this, but if SDL should actually know these
things, I imagine it should be able to tell you:

  • OS version (string, system dependent)
  • CPU string, possibly also system dependent, but “standardized”?
  • Platform enum: UNKNOWN, WINDOWS, DARWIN, LINUX, BSD, etc?

Is this something SDL should know at runtime, and should apps/games be
able to query it (or anything like it) for some reason? I think the first
two would be quite useful for debug logs and the like. I can’t imagine how
many times someone has come to #SDL with an issue and the first questions
you have to ask them are inevitably what OS are they running, what SDL
version, how did they install it, etc?

If you’ve gotta prompt developers to tell you this stuff, good luck with
end users? :wink:

The platform enum I admit is of limited use for most applications. Useful
for me as context for SDL’s Joystick GUIDs, but not too many uses otherwise.

Joseph

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Message-ID: <20131027055628.GD51845 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Well, SDL_platform.h covers what I intended to do with #3, but not
really what I intended for an enum. But I did say that I didn’t see
many uses for the enum beyond what I was doing, so I withdraw that
from consideration.

I don’t think that the idea of sortable platform info is all that
outlandish, but I certainly wouldn’t want to get it via return. I’d
look at it more like this:

void SDL_CheckPlatform( const char * const * attributes, int
*check_result, size_t count );

To understand why you might do this, consider: someone has a copy of
your game installed onto a USB drive. The game was compiled for
Windows, and normally they play it there, but today they’re at a
friend’s place and want to show it off. The friend has a Linux box
with Wine, but no Windows. Do you want to just assume that it’s a
Windows box, or do you want to adjust e.g. the search directories in
accordance with the current platform? If the later, then you want to
be able to do the following:

SDL_CheckPlatform
(
{
“Microsoft”,
“Apple”,
“Linux Foundation”,
“BSD”,

"Windows7", /* Because "Windows" should be true for Wine as well. */
"Wine",
"Ubuntu",

"x86-32",
"x64"

},
check_results,

7
);

if( check_results[ 5 ] > 0 && check_results[ 6 ] > 0 )
{
fprintf( logfile, “Running in Wine, on Ubuntu.\n” );
}

I personally don’t see myself using this, but if you can get at the
under-lying platform (e.g. RedHat) from within Wine, then someone will
eventually want to write some dlls to do that, albeit with most of
them targetting Microsoft Windows instead of Wine-hosts.

SDL_GetPlatform doesn’t report an OS version at all. Let’s take the
output of “Windows” again. How useful is that? “Windows”. That
could mean:

  • Windows 95 on an old 486
  • Windows Mobile 5 (Windows CE!) on an old cell phone
  • Windows RT on an ARM-based tablet
  • Windows 7 on an x86_64

And, as I mentioned, what about Wine?> Date: Sat, 26 Oct 2013 22:56:28 -0700

From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] OS, version, CPU

Date: Sun, 27 Oct 2013 00:43:58 -0700
From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] OS, version, CPU
Message-ID: <20131027074358.GE51845 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Shall I also have ifdefs for Darwin, for Linux, for BSD?? I can’t
imagine the number of times I’ve seen “portable” code assume that
there’s WIN32 or linux and if neither one?

#error “There are only 2 OSes in the universe, foolish human!”

I’d really rather not encourage people to write more of it.

Another convenience: if you’re using directory-access stuff, then you
can look in some particular directory for platform-customization
dynamic libraries, parse platform info out of their filenames, and use
matching comparisons to that to decide which you want to load (if
any), allowing you to add (or improve) support without releasing a
completely new base executable.

Date: Sun, 27 Oct 2013 03:56:15 -0400
From: Andre D
To: SDL Development List
Subject: Re: [SDL] OS, version, CPU
Message-ID:

Content-Type: text/plain; charset=windows-1252

The fact of the matter is, there is no portable way to do so. Thus,
why are you scoffing at ifdeffing various platform implementations.

“There is no portable way to do this” is a valid way to say “it might
be worthwhile for SDL to provide an API”. The question, of course,
being if it SHOULD.

Date: Sun, 27 Oct 2013 01:55:15 -0700
From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] OS, version, CPU
Message-ID: <20131027085515.GA62129 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed

A lot can be determined by the equivalent of uname -rs on systems
that have it.

Haiku 1 (x86)

That tells me very little. There might be more useful version
information on BeOS/Haiku available to a developer, but uname -rs on
the system just spits out “Haiku 1”. I did just about hit the floor
when I did a gcc --version on it: 2.95.3! O_O

Actually, you’ve got that slightly wrong: Haiku currently supports TWO
gcc versions. One is the primordial one that you noticed, the other is
a modern build. If you’re using a 2.., then you probably neede to
either update Haiku, or modify your build scripts for the modern
branch. Within a few (two? three?) major releases they’re apparently
planning to kill the 2.. compatibility (it only exists because BeOS
used C++ for it’s interfaces, and Haiku has been trying to give plenty
of migration and development time; THIS is why you should never build
OS APIs higher than the C level).

Date: Sun, 27 Oct 2013 11:43:41 +0100
From: Rainer Deyke
To: SDL Development List
Subject: Re: [SDL] OS, version, CPU
Message-ID: <526CEE5D.7000208 at eldwood.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 27.10.2013 10:16, Gerry JJ wrote:

You don’t have to infer these things on modern Linux distros. Parse
/etc/os-release =). It’s not on absolutely everything, but it’s pretty
standard.

/etc/os-release tells me I’m running Ubuntu, which is not entirely
accurate. (I’m running Linux Mint, which is Ubuntu-compatible and uses
Ubuntu packages, but which also adds its own packages on top of those
provided by Ubuntu.)

It should, however, be useful for programs wanting to know a
generalized subset of APIs that they can use…

Date: Sun, 27 Oct 2013 13:46:25 +0100
From: Rainer Deyke
To: sdl at libsdl.org
Subject: Re: [SDL] OS, version, CPU
Message-ID: <l4j1uo$mho$1 at ger.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 27.10.2013 12:18, Gerry JJ wrote:

Den 27. okt. 2013 11:43, skrev Rainer Deyke:

/etc/os-release tells me I’m running Ubuntu, which is not entirely
accurate. (I’m running Linux Mint, which is Ubuntu-compatible and uses
Ubuntu packages, but which also adds its own packages on top of those
provided by Ubuntu.)

Oh right, I forgot about that =/. Does Mint have some other file in
there with more correct info? lsb-release or something? I know there’s
some way to detect it (wish they’d fix their os-release though)

$ lsb_release -i
Distributor ID: LinuxMint

And this can be used to finish off the checking.

Date: Sun, 27 Oct 2013 22:53:18 -0400
From: Andre D
To: SDL Development List
Subject: Re: [SDL] OS, version, CPU
Message-ID:
<CAOOZ2gVzqFYfpxLQ9MrZekRgoUWKOet=8jAoGSyGSg6Ny9NZFg at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

Is there any other information you might want in a debug dump?

Date: Sun, 27 Oct 2013 22:54:06 -0400
From: Andre D
To: SDL Development List
Subject: Re: [SDL] OS, version, CPU
Message-ID:
<CAOOZ2gVjg-J+tFgKDai_niW3Ggw0jFNKwYh0J6e4HnE8WxKBEg at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

Aside from memory and more specific os info I mean. If someone were to
write a debug info module.

Just the ability to detect Wine as Windows (and similar such things),
and IF the host APIs can be accessed by the program, the ability to
detect the actual host, and distinguish between e.g. Wine, and what it
emulates.

It would also be good for any such thing to be in a dynamic library,
so that it can be updated as needed, instead of requiring a recompile
of the base executable.

Well, if I’m just going to #ifdef all of my code for different platforms,
what’s SDL for exactly?

Usually for speed and code size issues you want to resolve platform related
code differences at compile time.

There is no point in detecting that you are running on an android tablet or
a linux desktop runtime, this will add only complexity to your code.On Sun, Oct 27, 2013 at 9:56 AM, T. Joseph Carter < tjcarter at spiritsubstance.com> wrote:


Bye,
Gabry

I disagree, modern compilers are able to detect portions of code that
are not used and optimize them away.
Also I find that runtime checks help abstraction quite a bit and are
nicer to see than a cascade of #ifdef

jm2c
VittorioOn Mon, Oct 28, 2013 at 10:38 AM, Gabriele Greco <gabriele.greco at darts.it> wrote:

On Sun, Oct 27, 2013 at 9:56 AM, T. Joseph Carter wrote:

Well, if I’m just going to #ifdef all of my code for different platforms,
what’s SDL for exactly?

Usually for speed and code size issues you want to resolve platform related
code differences at compile time.

There is no point in detecting that you are running on an android tablet or
a linux desktop runtime, this will add only complexity to your code.

I don’t think that the idea of sortable platform info is all that
outlandish, but I certainly wouldn’t want to get it via return. I’d
look at it more like this:
[…]

I could see removing more than a string and letting the caller figure
out how to parse it. However I don’t plan on writing anything so
intricate as a check for “WINE on Ubuntu”. For Windows, I’m willing
to write code to grab SYSTEM_INFO and OSVERSIONINFOEX, but unless
WINE can be determined by processing those, I don’t intend to look
for it. I surely don’t intend to (and do not think I could anyway)
determine that WINE was running on Ubuntu.

MSDN doesn’t even pretend to know Windows 9x exists, which at this
point is probably a good thing, but I’d want to make sure it does.
Also, Microsoft is threatening to remove GetSystemVersion and
GetSystemVersionEx from Windows > 8.1, but there’s enough people
screaming that removing these is unwelcome and will break working
code.

What I’m willing to spend the time on for version is getting the
architecture (Windows 9x, Windows NT, and Windows CE if I can find
info), a version number (major, minor, build number), the overall
patch level, and perhaps a formatted string. Something perhaps like
"Windows XP Service Pack 3", because I can and it makes more sense
than “Windows NT 5.1.2600 3.0”. And because if you need to know
programmatically the windows patch level is major 3, minor 0, and
whether you have Home, Professional, Home Server, Real Server,
BackOffice, BackOrifice, FrontOffice, IIS, Home Basic, Super Home
Basic, Extreme Home Basic, Business Professional, Wannabe
Professional, Awesome Professional, Enterprise, BitTorrent Enterprise
Volume License, and Bill Gates Owes Me Money Edition, dude you really
are on your own. :slight_smile:

Windows will tell you in SYSTEM_INFO if you’re using x86, ia64,
x86_64, and ARM. Presumably it could also tell you PowerPC and
PA-RISC, but ? I don’t think SDL actually supports any version of
Windows that supports these, so I’m not going to accept that anything
but the currently documented CPUs are unknown unless or until someone
protests. :slight_smile:

I’m planning similar information for other platforms. I don’t
presently know how to get it on several others. Sam’s asked for a
patch to consider, so I’ll figure it out and submit one.

I personally don’t see myself using this, but if you can get at the
under-lying platform (e.g. RedHat) from within Wine, then someone will
eventually want to write some dlls to do that, albeit with most of
them targetting Microsoft Windows instead of Wine-hosts.

I don’t know of any means to determine that an application is running
under WINE and what version. Certainly WINE doesn’t expose its
underlying platform in any detail. Your best bet would be to start
poking around Z: and see what you find there. I don’t think that’s
guaranteed to work even if you determine that you’re running under
WINE, so I’m not going to do it. :slight_smile:

SDL_GetPlatform doesn’t report an OS version at all. Let’s take the
output of “Windows” again. How useful is that? “Windows”. That
could mean:

  • Windows 95 on an old 486
  • Windows Mobile 5 (Windows CE!) on an old cell phone
  • Windows RT on an ARM-based tablet
  • Windows 7 on an x86_64

And, as I mentioned, what about Wine?

If WINE does not expose its version, then it’s just not going to
happen.

Another convenience: if you’re using directory-access stuff, then you
can look in some particular directory for platform-customization
dynamic libraries, parse platform info out of their filenames, and use
matching comparisons to that to decide which you want to load (if
any), allowing you to add (or improve) support without releasing a
completely new base executable.

SDL already has some abstraction for this, actually.

The fact of the matter is, there is no portable way to do so. Thus,
why are you scoffing at ifdeffing various platform implementations.

“There is no portable way to do this” is a valid way to say “it might
be worthwhile for SDL to provide an API”. The question, of course,
being if it SHOULD.

That’s the question. And my thought was that if SDL already reports
your system memory and a very generic description of your platform,
might not a better description of the platform and at least a vague
description of the CPU be warranted, at least in the common cases?

Sam will consider a patch, at least, so I’ll add it to my todo list.

A lot can be determined by the equivalent of uname -rs on systems
that have it.

Haiku 1 (x86)

That tells me very little. There might be more useful version
information on BeOS/Haiku available to a developer, but uname -rs on
the system just spits out “Haiku 1”. I did just about hit the floor
when I did a gcc --version on it: 2.95.3! O_O

Actually, you’ve got that slightly wrong: Haiku currently supports TWO
gcc versions. One is the primordial one that you noticed, the other is
a modern build. If you’re using a 2.., then you probably neede to
either update Haiku, or modify your build scripts for the modern
branch. Within a few (two? three?) major releases they’re apparently
planning to kill the 2.. compatibility (it only exists because BeOS
used C++ for it’s interfaces, and Haiku has been trying to give plenty
of migration and development time; THIS is why you should never build
OS APIs higher than the C level).

Alpha 4. The only gcc I saw is gcc 2.95.3, but I admit I haven’t
looked real closely yet. REALLY wish someone would talk the VMware
guys into sharing enough info to allow for the beginnings of some
VMware Tools for Haiku, I might be inclined to play with it more.
Admittedly I know VERY little about it at present.

/etc/os-release tells me I’m running Ubuntu, which is not entirely
accurate. (I’m running Linux Mint, which is Ubuntu-compatible and uses
Ubuntu packages, but which also adds its own packages on top of those
provided by Ubuntu.)

It should, however, be useful for programs wanting to know a
generalized subset of APIs that they can use…

I dunno if I’ll bother to try and parse that for Linux. SDL isn’t a
system diagnostic library?it’s a multimedia/gaming library. Major
platform details (Windows NT vs. 9x, OS X vs. iOS, desktop Linux vs.
Android) matter because they impact how SDL works. CPU mostly
matters because of structure packing, byte order, and possibly vector
math instructions, since SDL doesn’t provide a vector math library
built-in. (It’s not generally needed for 2D, and SDL’s approach to
3D is generally hands-off.

$ lsb_release -i
Distributor ID: LinuxMint

And this can be used to finish off the checking.

I won’t be having SDL execute shell commands, that’s for sure!

Is there any other information you might want in a debug dump?

Aside from memory and more specific os info I mean. If someone were to
write a debug info module.

Just the ability to detect Wine as Windows (and similar such things),
and IF the host APIs can be accessed by the program, the ability to
detect the actual host, and distinguish between e.g. Wine, and what it
emulates.

WINE as Windows is easy. WINE as WINE may intentionally be not
practical, as noted.

JosephOn Mon, Oct 28, 2013 at 02:02:34AM -0500, Jared Maddox wrote:

Den 27. okt. 2013 14:41, skrev Rainer Deyke:

$ cat /etc/lsb-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=15
DISTRIB_CODENAME=olivia
DISTRIB_DESCRIPTION=“Linux Mint 15 Olivia”

Thank you =). So, we can use lsb-release if it exists and is in that
format, and fall back to os-release if not. I wrote some code to do just
that =). (see next mail)

-g

Den 29. okt. 2013 00:30, skrev T. Joseph Carter:

I dunno if I’ll bother to try and parse that for Linux. SDL isn’t a
system diagnostic library?it’s a multimedia/gaming library. Major
platform details (Windows NT vs. 9x, OS X vs. iOS, desktop Linux vs.
Android) matter because they impact how SDL works. CPU mostly matters
because of structure packing, byte order, and possibly vector math
instructions, since SDL doesn’t provide a vector math library built-in.
(It’s not generally needed for 2D, and SDL’s approach to 3D is generally
hands-off.

I wrote some code to parse those files. It’s not too bad… No
execution of arbitrary files needed, at least =). You get strings like
"Ubuntu 13.10 (x86_64)" or “Linux Mint 15 Olivia (i686)”. Feel free to
use this in SDL if you want.

Haven’t tested it much, but it should hopefully work on any distro with
either /etc/lsb-release or /etc/os-release.

Just the ability to detect Wine as Windows (and similar such things),
and IF the host APIs can be accessed by the program, the ability to
detect the actual host, and distinguish between e.g. Wine, and what it
emulates.

WINE as Windows is easy. WINE as WINE may intentionally be not
practical, as noted.

You can check if HKCU/Software/Wine exists in the registry. I don’t know
if you can detect the version though.

-g

Den 29. okt. 2013 00:30, skrev T. Joseph Carter:

I dunno if I’ll bother to try and parse that for Linux. SDL isn’t a
system diagnostic library?it’s a multimedia/gaming library. Major
platform details (Windows NT vs. 9x, OS X vs. iOS, desktop Linux vs.
Android) matter because they impact how SDL works. CPU mostly matters
because of structure packing, byte order, and possibly vector math
instructions, since SDL doesn’t provide a vector math library built-in.
(It’s not generally needed for 2D, and SDL’s approach to 3D is generally
hands-off.

I wrote some code to parse those files. It’s not too bad… No
execution of arbitrary files needed, at least =). You get strings
like “Ubuntu 13.10 (x86_64)” or “Linux Mint 15 Olivia (i686)”. Feel
free to use this in SDL if you want.

https://gist.github.com/kamjau/7213161

Haven’t tested it much, but it should hopefully work on any distro
with either /etc/lsb-release or /etc/os-release.

Compiler flags are probably more useful a judge than a file on the
system for whether you have x86_64 or x86. After all, there is such
a thing as running 32 bit code on a 64 bit system. And again, the
kernel is more important than the Linux distribution flavor of the
week. I’d rather get the version from /proc than some arbitrary file
that could be edited, erased, or non-existant.

This is about information, not vanity.

Generally speaking, I’d rather tell you it’s a Linux 3.11.0 system
and let you just dump /etc/lsb-release or /etc/os-release if they
exist. It’s easily done, and the code to do it isn’t unique or even
particularly platform-specific.

It fits with the same notion that it’s more important for me as a
developer to know I’m looking at Windows NT 5.2.2600 than Windows XP
Professional. That it happens to be WinXP Pro is irrelevant?it’s NT
5.2, and that tells me a lot about what might break on your system.

Just the ability to detect Wine as Windows (and similar such things),
and IF the host APIs can be accessed by the program, the ability to
detect the actual host, and distinguish between e.g. Wine, and what it
emulates.

WINE as Windows is easy. WINE as WINE may intentionally be not
practical, as noted.

You can check if HKCU/Software/Wine exists in the registry. I don’t
know if you can detect the version though.

And if you create HKCU/Software/Wine yourself on real Windows?

JosephOn Tue, Oct 29, 2013 at 12:45:15PM +0100, Gerry JJ wrote:

Den 29. okt. 2013 14:10, skrev T. Joseph Carter:

Compiler flags are probably more useful a judge than a file on the
system for whether you have x86_64 or x86. After all, there is such a
thing as running 32 bit code on a 64 bit system.

Yes, exactly. This is supposed to tell you what OS you’re running on.
Compiler flags can’t tell you that.

And again, the kernel
is more important than the Linux distribution flavor of the week. I’d
rather get the version from /proc than some arbitrary file that could be
edited, erased, or non-existant.

Those files in /etc aren’t editable unless you’re root. If someone
really wanted to, they could replace the kernel with something
completely nonstandard, but this isn’t about people trying to break the
system.

This is about information, not vanity.

Yes. In things like automated bug reports, it’s useful to tell what
distro someone has. It has nothing to do with vanity.

Generally speaking, I’d rather tell you it’s a Linux 3.11.0 system and
let you just dump /etc/lsb-release or /etc/os-release if they exist.
It’s easily done, and the code to do it isn’t unique or even
particularly platform-specific.

It fits with the same notion that it’s more important for me as a
developer to know I’m looking at Windows NT 5.2.2600 than Windows XP
Professional. That it happens to be WinXP Pro is irrelevant?it’s NT
5.2, and that tells me a lot about what might break on your system.

One of the primary differences between Linux distros is userland.

And if you create HKCU/Software/Wine yourself on real Windows?

Then you’re asking for trouble. Sorry for trying to help.

-g

If all this is for is automatic generation of bug reports, then OS
detection probably doesn’t belong in the SDL core. Furthermore, you may be
better to just ask the user, since there is no consistent way to grab this
information. Using #ifdef doesn’t cover all your runtime bases, and at
least in linux-land, there are a number of variations on where this
information is stored, and the format. Although it does appear possible to
go through a series of checks for the OS information, this is easily a user
issue, and if they want to exclude their OS version information, then they
obviously don’t want whatever bug to be fixed.On Tue, Oct 29, 2013 at 9:45 AM, Gerry JJ wrote:

Den 29. okt. 2013 14:10, skrev T. Joseph Carter:

Compiler flags are probably more useful a judge than a file on the

system for whether you have x86_64 or x86. After all, there is such a
thing as running 32 bit code on a 64 bit system.

Yes, exactly. This is supposed to tell you what OS you’re running on.
Compiler flags can’t tell you that.

And again, the kernel

is more important than the Linux distribution flavor of the week. I’d
rather get the version from /proc than some arbitrary file that could be
edited, erased, or non-existant.

Those files in /etc aren’t editable unless you’re root. If someone really
wanted to, they could replace the kernel with something completely
nonstandard, but this isn’t about people trying to break the system.

This is about information, not vanity.

Yes. In things like automated bug reports, it’s useful to tell what distro
someone has. It has nothing to do with vanity.

Generally speaking, I’d rather tell you it’s a Linux 3.11.0 system and

let you just dump /etc/lsb-release or /etc/os-release if they exist.
It’s easily done, and the code to do it isn’t unique or even
particularly platform-specific.

It fits with the same notion that it’s more important for me as a
developer to know I’m looking at Windows NT 5.2.2600 than Windows XP
Professional. That it happens to be WinXP Pro is irrelevant?it’s NT
5.2, and that tells me a lot about what might break on your system.

One of the primary differences between Linux distros is userland.

And if you create HKCU/Software/Wine yourself on real Windows?

Then you’re asking for trouble. Sorry for trying to help.

-g

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I imagine the idea is to collect the OS alongside other information
from the system. If you ask the user to tell the system specs you run
the risk that the user won’t provide all the information you need, or
worse, make a mistake on something that isn’t obvious.

2013/10/29, Alex Barry <alex.barry at gmail.com>:> If all this is for is automatic generation of bug reports, then OS

detection probably doesn’t belong in the SDL core. Furthermore, you may be
better to just ask the user, since there is no consistent way to grab this
information. Using #ifdef doesn’t cover all your runtime bases, and at
least in linux-land, there are a number of variations on where this
information is stored, and the format. Although it does appear possible to
go through a series of checks for the OS information, this is easily a user
issue, and if they want to exclude their OS version information, then they
obviously don’t want whatever bug to be fixed.

On Tue, Oct 29, 2013 at 9:45 AM, Gerry JJ wrote:

Den 29. okt. 2013 14:10, skrev T. Joseph Carter:

Compiler flags are probably more useful a judge than a file on the

system for whether you have x86_64 or x86. After all, there is such a
thing as running 32 bit code on a 64 bit system.

Yes, exactly. This is supposed to tell you what OS you’re running on.
Compiler flags can’t tell you that.

And again, the kernel

is more important than the Linux distribution flavor of the week. I’d
rather get the version from /proc than some arbitrary file that could be
edited, erased, or non-existant.

Those files in /etc aren’t editable unless you’re root. If someone really
wanted to, they could replace the kernel with something completely
nonstandard, but this isn’t about people trying to break the system.

This is about information, not vanity.

Yes. In things like automated bug reports, it’s useful to tell what
distro
someone has. It has nothing to do with vanity.

Generally speaking, I’d rather tell you it’s a Linux 3.11.0 system and

let you just dump /etc/lsb-release or /etc/os-release if they exist.
It’s easily done, and the code to do it isn’t unique or even
particularly platform-specific.

It fits with the same notion that it’s more important for me as a
developer to know I’m looking at Windows NT 5.2.2600 than Windows XP
Professional. That it happens to be WinXP Pro is irrelevant?it’s NT
5.2, and that tells me a lot about what might break on your system.

One of the primary differences between Linux distros is userland.

And if you create HKCU/Software/Wine yourself on real Windows?

Then you’re asking for trouble. Sorry for trying to help.

-g

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I imagine the idea is to collect the OS alongside other information
from the system. If you ask the user to tell the system specs you run
the risk that the user won’t provide all the information you need, or
worse, make a mistake on something that isn’t obvious.

On the flip side, however, if multiple people are reporting the same bug,
and they are all contributing information about their system, even if one
or two are inaccurate, as long as they all provide the steps necessary to
reproduce the bug, the bug should be able to be tracked down.

If the developer is only collecting distribution version information, what
happens when the user isn’t updating their packages? In most cases (in the
linux world), the problem is often not the operating system/distribution,
but the packages they provide, so if someone wants to go down that route,
they should be querying one of the many package managers to see what
version of each program-dependent package their distro is using. That’s
even more nightmare-ish than querying the OS, but ultimately that’s the
information the developer would need to debug/sort out.

This is all to say that asking the user is the most reliable method,
because when they/their app generates a report, the developer begins a
dialog with the user (which is good in terms of supporting your users), and
gives the developer access to that user to gather further information about
what steps are taken, and how to reproduce the problem on the developer’s
end.On Tue, Oct 29, 2013 at 11:20 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

Well, when you’re distributing binaries, you’ll want to make them as
independent of the distro as possible. Include all the dependencies you
need with your executable, if you can. Only leave out system level stuff
like glibc, opengl, etc.

Anyway, if someone were to use this for bug reports, I agree it should
probably just be a default. Less for the reporter to worry about, but
available for them to change if they want to. That said, I don’t think
bug reports is the only use case this string would have, but honestly
I just coded it up because I’d had that back-and-forth with Rainer Deyke
and felt something should come from it, and T. Joseph Carter seemed to
want something like this. Apparently I was wrong, but hey. Maybe someone
out there will find a use for it =) (didn’t put a license on the gist,
but let’s say it’s zlib license.)

In any case, I do think returning a distro string is more useful than
just the kernel version. Linux isn’t just one OS, it’s a family of
distros. (Not to mention that kernel version is trivial to get with
uname(2), anyway.)

-g

Den 29. okt. 2013 16:49, skrev Alex Barry:> On Tue, Oct 29, 2013 at 11:20 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com <mailto:sik.the.hedgehog at gmail.com>> wrote:

I imagine the idea is to collect the OS alongside other information
from the system. If you ask the user to tell the system specs you run
the risk that the user won't provide all the information you need, or
worse, make a mistake on something that isn't obvious.

On the flip side, however, if multiple people are reporting the same
bug, and they are all contributing information about their system, even
if one or two are inaccurate, as long as they all provide the steps
necessary to reproduce the bug, the bug should be able to be tracked down.

If the developer is only collecting distribution version information,
what happens when the user isn’t updating their packages? In most cases
(in the linux world), the problem is often not the operating
system/distribution, but the packages they provide, so if someone wants
to go down that route, they should be querying one of the many package
managers to see what version of each program-dependent package their
distro is using. That’s even more nightmare-ish than querying the OS,
but ultimately that’s the information the developer would need to
debug/sort out.

This is all to say that asking the user is the most reliable method,
because when they/their app generates a report, the developer begins a
dialog with the user (which is good in terms of supporting your users),
and gives the developer access to that user to gather further
information about what steps are taken, and how to reproduce the problem
on the developer’s end.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think it would make sense if it were just one big utf-8 (or
something?) string blob…that way if any info is not available, it can
just be left out, or if more info is…it can just be tossed in without
worrying about adding query functions and having users query those
vals as well.On Tue, Oct 29, 2013 at 12:17 PM, Gerry JJ wrote:

Well, when you’re distributing binaries, you’ll want to make them as
independent of the distro as possible. Include all the dependencies you need
with your executable, if you can. Only leave out system level stuff like
glibc, opengl, etc.

Anyway, if someone were to use this for bug reports, I agree it should
probably just be a default. Less for the reporter to worry about, but
available for them to change if they want to. That said, I don’t think bug
reports is the only use case this string would have, but honestly I just
coded it up because I’d had that back-and-forth with Rainer Deyke and felt
something should come from it, and T. Joseph Carter seemed to want something
like this. Apparently I was wrong, but hey. Maybe someone out there will
find a use for it =) (didn’t put a license on the gist, but let’s say it’s
zlib license.)

In any case, I do think returning a distro string is more useful than just
the kernel version. Linux isn’t just one OS, it’s a family of distros. (Not
to mention that kernel version is trivial to get with uname(2), anyway.)

-g

Den 29. okt. 2013 16:49, skrev Alex Barry:

On Tue, Oct 29, 2013 at 11:20 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com <mailto:sik.the.hedgehog at gmail.com>> wrote:

I imagine the idea is to collect the OS alongside other information
from the system. If you ask the user to tell the system specs you run
the risk that the user won't provide all the information you need, or
worse, make a mistake on something that isn't obvious.

On the flip side, however, if multiple people are reporting the same
bug, and they are all contributing information about their system, even
if one or two are inaccurate, as long as they all provide the steps
necessary to reproduce the bug, the bug should be able to be tracked down.

If the developer is only collecting distribution version information,
what happens when the user isn’t updating their packages? In most cases
(in the linux world), the problem is often not the operating
system/distribution, but the packages they provide, so if someone wants
to go down that route, they should be querying one of the many package
managers to see what version of each program-dependent package their
distro is using. That’s even more nightmare-ish than querying the OS,
but ultimately that’s the information the developer would need to
debug/sort out.

This is all to say that asking the user is the most reliable method,
because when they/their app generates a report, the developer begins a
dialog with the user (which is good in terms of supporting your users),
and gives the developer access to that user to gather further
information about what steps are taken, and how to reproduce the problem
on the developer’s end.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Message-ID: <20131029131045.GF56755 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed

I wrote some code to parse those files. It’s not too bad… No
execution of arbitrary files needed, at least =). You get strings
like “Ubuntu 13.10 (x86_64)” or “Linux Mint 15 Olivia (i686)”. Feel
free to use this in SDL if you want.

https://gist.github.com/kamjau/7213161

Haven’t tested it much, but it should hopefully work on any distro
with either /etc/lsb-release or /etc/os-release.

Compiler flags are probably more useful a judge than a file on the
system for whether you have x86_64 or x86. After all, there is such
a thing as running 32 bit code on a 64 bit system.

Point. I included them in my example purely because I was thinking
about the implementation coming down to plain boring string
comparisons, and little else.

And again, the
kernel is more important than the Linux distribution flavor of the
week. I’d rather get the version from /proc than some arbitrary file
that could be edited, erased, or non-existant.

Linux isn’t an OS, just a kernel, so getting the kernel version
doesn’t tell you much. If all that you genuinely care about is the
kernel version, then it means you don’t care if it’s a *nix
environment, for example. The real “meat and potatoes” of the Linux
world is distro-specific (e.g. Gnome vs KDE, RPM vs DPKG), so if you
want to do any interactions with the system beyond just the kernel,
you need to get the distro info. Last time that I checked, even
Android was just a Linux distro if you squinted hard enough.

It fits with the same notion that it’s more important for me as a
developer to know I’m looking at Windows NT 5.2.2600 than Windows XP
Professional. That it happens to be WinXP Pro is irrelevant?it’s NT
5.2, and that tells me a lot about what might break on your system.

I’ve never heard of a Windows kernel shipping without some
standardized components, so not especially relevant. Now, some sort of
add-on stuff, like MSOffice, or StarOffice, or whatever else? SDL
shouldn’t be expected to look for that stuff, because hey, telling you
the info that you need in order to figure out how to look it up
yourself should be enough.> Date: Tue, 29 Oct 2013 06:10:45 -0700

From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] OS, version, CPU
On Tue, Oct 29, 2013 at 12:45:15PM +0100, Gerry JJ wrote:

Compiler flags are probably more useful a judge than a file on the
system for whether you have x86_64 or x86. After all, there is such
a thing as running 32 bit code on a 64 bit system.

Point. I included them in my example purely because I was thinking
about the implementation coming down to plain boring string
comparisons, and little else.

Plain boring comparisons are what I’m after here. As I’ve said, I’m
not looking for a diagnostic tool or even a full OS identification.
The thing I feel is needed is a platform identification. Think
closer to the kind of stuff you get out of config.guess than you do
from examining something found in /etc to determine a distribution.

Only, config.guess triplets aren’t quite it either. At the moment, I
can obtain these:

x86_64-apple-darwin13.0.0
x86_64-unknown-linux-gnu
i686-pc-mingw32
i586-pc-haiku

Of course config.guess output is somewhat less than 100% useful for a
number of reasons.

  1. You don’t always have this information when building SDL, as it’s
    kind of a UNIXism, or more accurately a GNUism. It’s a de-facto
    standard only because gcc uses it, and gcc is the standard compiler
    on most every platform people care about aside from Windows.

  2. The triplet is not standardized in a meaningful way. Oh, the CPU
    generally is because of gcc, but the vendor is typically “pc” or
    "unknown" and completely irrelevant.[*mingw] The platform may or may
    not indicate a version, and the version’s not easily parsed in C
    anyway.

  3. The triplets sometimes lie[*mingw].

  4. The platform may not be enough as critical things SDL needs may
    not be supported depending on the platform version. Apple annoyingly
    changes stuff all the time. Certain features are totally (and
    silently) unavailable on old versions of Windows. A Linux kernel too
    new or too old may not play well with a binary-only video driver.

Linux isn’t an OS, just a kernel, so getting the kernel version
doesn’t tell you much. If all that you genuinely care about is the
kernel version, then it means you don’t care if it’s a *nix
environment, for example. The real “meat and potatoes” of the Linux
world is distro-specific (e.g. Gnome vs KDE, RPM vs DPKG), so if you
want to do any interactions with the system beyond just the kernel,
you need to get the distro info. Last time that I checked, even
Android was just a Linux distro if you squinted hard enough.

True, but Linux is usually a platform. You don’t have different
versions of Steam for Debian, for Red Hat, for Ubuntu, for Mint, etc.
No need, because although there are different OSes based around the
Linux platform, the platform generally considered to be “Linux” is
based around the kernel itself.

Probably 99 out of 100 apps that someone could write using SDL (and
I’m being generous) don’t care whether you have dpkg, rpm, KDE,
Gnome, Enlightenment, or twm. :slight_smile: Heck, probably 95 out of the 100
don’t even much care that you’re running all of this on Linux unless
something goes wrong. For when it does (and for those apps that care
about the platform version), I intend to give something that will
help answer questions about what’s not working and why.

That’s going to wind up being more than just a platform/version query
before I’m done?but I’ll be submitting that as a separate patch.
I’ll make cases for other subsystems producing lower level driver
identification as I find the need (and the best implementation of a
solution to it?) Presently I’ve got too many things on my plate that
depend on one another, so cutting off bite-sized pieces is good.

It fits with the same notion that it’s more important for me as a
developer to know I’m looking at Windows NT 5.2.2600 than Windows XP
Professional. That it happens to be WinXP Pro is irrelevant?it’s NT
5.2, and that tells me a lot about what might break on your system.

I’ve never heard of a Windows kernel shipping without some
standardized components, so not especially relevant. Now, some sort of
add-on stuff, like MSOffice, or StarOffice, or whatever else? SDL
shouldn’t be expected to look for that stuff, because hey, telling you
the info that you need in order to figure out how to look it up
yourself should be enough.

Windows FLP was an XP that shipped without a few big ones. Couldn’t
easily install them either. There’s apparently similarly stripped
versions for Windows Vista and 7. Dunno about 8/8.1, but the trend
would be logical. You couldn’t easily re-add some of those missing
components either. Of course I don’t think any of those missing
components affected SDL.

I can imagine lots of things one could detect about a system if one
wanted to. I’m aiming for the basics, though, because that’s what
you’ll need to know if something that should work doesn’t.On Wed, Oct 30, 2013 at 01:49:25AM -0500, Jared Maddox wrote:


[*mingw]

Sigh.

This is one hell of an * for mingw32! For mingw-w64, the vendor
should be w64, not pc, and it matters a whole lot to SDL! A great
many API things exist under mingw-w64 that do not for mingw32.

There are many issues related to getting a “good” MSYS/mingw-w64
build system up and running for SDL. When I figure them out, I’ll be
sure to write some docs and post them. But I need to find someone
who can answer a few questions first.

There are three (four?) triplets for mingw systems:

  1. i686-pc-mingw32. Classic mingw32. Not recommended for SDL.
  2. i686-w64-mingw32. A mingw-w64 setup for 32 bit x86 Windows.
  3. x86_64-w64-mingw32. The mingw-w64 target for x86_64 systems.
    4? arm-w64-mingw32. Dunno if this exists. It should.

Issues with the above:

  • config.guess always reports #1 under MSYS because MSYS doesn’t even
    compile with modern gcc, let alone a non-i686 gcc! MSYS2 should
    support w64, but it’s not quite a polished release, and it’s totally
    undocumented. I dunno yet if MSYS2 is considered “usable” even.

  • The mingw-w64 wiki recommends TDM-GCC which comes as 32 bit and 64
    bit editions. The 32 bit edition is actually mingw32, so #1 is
    correct. I think mostly whoever wrote that on the wiki referenced it
    as an “easy mode” way to get the 64 bit version installed. It’s not
    what we want for SDL, though (except we need its binutils and if your
    host is a 32 bit windows, you also need its gdb!)

  • TDM-GCC’s 64 bit edition always reports itself as #3. But with the
    exception of the gdb binary, it is actually i686 host that by default
    produces x86_64. That means it should be host #2, but target #3 by
    default (or #2 with the -m32 flag!) It isn’t, though, and you’ll
    find its windres.exe only produces x86_64 code that cannot be linked
    with anything built with -m32. See, this is why it SHOULD be set up
    at least differently than it is.

Me, I’d provide both i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc
with binutils for each and use some equivalent of gcc_select. Of
course this is somewhat non-trivial since you don’t have traditional
UNIX symlinks. (Vista and above using NTFS do with escalated privs,
but those restrictions make them irrelevant to our purpose.)

Over on OFTC #mingw-w64, they’re telling me some of the documentation
is not as it should be. :slight_smile: I have gotten some help and found the
people there pretty friendly. We’ll see what I can do with the info
this weekend.

Joseph

Message-ID: <20131030164129.GA46741 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Linux isn’t an OS, just a kernel, so getting the kernel version
doesn’t tell you much. If all that you genuinely care about is the
kernel version, then it means you don’t care if it’s a *nix
environment, for example. The real “meat and potatoes” of the Linux
world is distro-specific (e.g. Gnome vs KDE, RPM vs DPKG), so if you
want to do any interactions with the system beyond just the kernel,
you need to get the distro info. Last time that I checked, even
Android was just a Linux distro if you squinted hard enough.

True, but Linux is usually a platform. You don’t have different
versions of Steam for Debian, for Red Hat, for Ubuntu, for Mint, etc.
No need, because although there are different OSes based around the
Linux platform, the platform generally considered to be “Linux” is
based around the kernel itself.

Probably 99 out of 100 apps that someone could write using SDL (and
I’m being generous) don’t care whether you have dpkg, rpm, KDE,
Gnome, Enlightenment, or twm. :slight_smile:

But for those that do, I figure that all that we need to give them is
enough info to interact with the package manager system. Still, it’s
not like I’m going to be the one implementing this.

That’s going to wind up being more than just a platform/version query
before I’m done?but I’ll be submitting that as a separate patch.
I’ll make cases for other subsystems producing lower level driver
identification as I find the need (and the best implementation of a
solution to it?) Presently I’ve got too many things on my plate that
depend on one another, so cutting off bite-sized pieces is good.

I’m going to suggest the function_name( const char **names, int
*matches, size_t elements ) signature again. I think it should serve
well for all simple queries, and everything that isn’t simple has a
risk of needing a custom per-subject interface.> Date: Wed, 30 Oct 2013 09:41:29 -0700

From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] OS, version, CPU
On Wed, Oct 30, 2013 at 01:49:25AM -0500, Jared Maddox wrote: