Discussion:
OS, version, CPU
(too old to reply)
T. Joseph Carter
2013-10-27 05:01:19 UTC
Permalink
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… ;)

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
Alex Szpakowski
2013-10-27 05:08:41 UTC
Permalink
Check out SDL_platform.h for #1 and #3. SDL_cpuinfo.h covers #2 somewhat.
Post by T. Joseph Carter
- OS version (string, system dependent)
- CPU string, possibly also system dependent, but "standardized"?
- Platform enum: UNKNOWN, WINDOWS, DARWIN, LINUX, BSD, etc…
T. Joseph Carter
2013-10-27 05:56:28 UTC
Permalink
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. The notion of using #ifdef __WIN32__ on a
decidedly 64 bit or not even Intel-based version of Windows is
amusing, but whatever… :)

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

Very different systems. Very different kernels. Very different
architectures and feature sets. And while I don't know if SDL would
compile on a Windows CE system, it should be a minor thing to get it
to do so if someone is crazy enough to try it! It does "run" under
Windows 9x just fine. Heck, I bet it'll compile out of the tarball
on Windows NT 4.0.

Version tends to matter a lot more on Windows than it does on Linux,
but it also tends to matter on iOS where iOS 5 is still realistic for
SDL to encounter, Android which is all over the map in terms of
versions and features, and the Mac where 10.4 is still seen now and
again.

Joseph
Post by Alex Szpakowski
Check out SDL_platform.h for #1 and #3. SDL_cpuinfo.h covers #2 somewhat.
Post by T. Joseph Carter
- OS version (string, system dependent)
- CPU string, possibly also system dependent, but "standardized"?
- Platform enum: UNKNOWN, WINDOWS, DARWIN, LINUX, BSD, etc…
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Andre D
2013-10-27 06:45:55 UTC
Permalink
Do if an ifdef win32 with GetVersionEx

On Sun, Oct 27, 2013 at 1:56 AM, T. Joseph Carter
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.
The notion of using #ifdef __WIN32__ on a decidedly 64 bit or not even
Intel-based version of Windows is amusing, but whatever… :)
SDL_GetPlatform doesn't report an OS version at all. Let's take the output
- 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
Very different systems. Very different kernels. Very different
architectures and feature sets. And while I don't know if SDL would compile
on a Windows CE system, it should be a minor thing to get it to do so if
someone is crazy enough to try it! It does "run" under Windows 9x just
fine. Heck, I bet it'll compile out of the tarball on Windows NT 4.0.
Version tends to matter a lot more on Windows than it does on Linux, but it
also tends to matter on iOS where iOS 5 is still realistic for SDL to
encounter, Android which is all over the map in terms of versions and
features, and the Mac where 10.4 is still seen now and again.
Joseph
Post by Alex Szpakowski
Check out SDL_platform.h for #1 and #3. SDL_cpuinfo.h covers #2 somewhat.
On Oct 27, 2013, at 2:01 AM, T. Joseph Carter
Post by T. Joseph Carter
- OS version (string, system dependent)
- CPU string, possibly also system dependent, but "standardized"?
- Platform enum: UNKNOWN, WINDOWS, DARWIN, LINUX, BSD, etc…
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
T. Joseph Carter
2013-10-27 07:43:58 UTC
Permalink
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.

Obviously as of 2.0.1 that's the only way you're going to get an OS
version. But asking the OS how much memory is installed was just
added to SDL because someone thought it oughtta be supported. I tend
to need to know what a user is running a whole lot more often than
how much RAM they've got, personally.

Joseph
Post by Andre D
Do if an ifdef win32 with GetVersionEx
On Sun, Oct 27, 2013 at 1:56 AM, T. Joseph Carter
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.
The notion of using #ifdef __WIN32__ on a decidedly 64 bit or not even
Intel-based version of Windows is amusing, but whatever… :)
SDL_GetPlatform doesn't report an OS version at all. Let's take the output
- 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
Very different systems. Very different kernels. Very different
architectures and feature sets. And while I don't know if SDL would compile
on a Windows CE system, it should be a minor thing to get it to do so if
someone is crazy enough to try it! It does "run" under Windows 9x just
fine. Heck, I bet it'll compile out of the tarball on Windows NT 4.0.
Version tends to matter a lot more on Windows than it does on Linux, but it
also tends to matter on iOS where iOS 5 is still realistic for SDL to
encounter, Android which is all over the map in terms of versions and
features, and the Mac where 10.4 is still seen now and again.
Joseph
Post by Alex Szpakowski
Check out SDL_platform.h for #1 and #3. SDL_cpuinfo.h covers #2 somewhat.
On Oct 27, 2013, at 2:01 AM, T. Joseph Carter
Post by T. Joseph Carter
- OS version (string, system dependent)
- CPU string, possibly also system dependent, but "standardized"?
- Platform enum: UNKNOWN, WINDOWS, DARWIN, LINUX, BSD, etc…
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Andre D
2013-10-27 07:46:04 UTC
Permalink
I only mentioned windows because I assumed you had no reason to detect
a BSD or Linux kernel (or what, are you going to detect every distro?)
for an SDL application.

On Sun, Oct 27, 2013 at 3:43 AM, T. Joseph Carter
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.
Obviously as of 2.0.1 that's the only way you're going to get an OS version.
But asking the OS how much memory is installed was just added to SDL because
someone thought it oughtta be supported. I tend to need to know what a user
is running a whole lot more often than how much RAM they've got, personally.
Joseph
Post by Andre D
Do if an ifdef win32 with GetVersionEx
On Sun, Oct 27, 2013 at 1:56 AM, T. Joseph Carter
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.
The notion of using #ifdef __WIN32__ on a decidedly 64 bit or not even
Intel-based version of Windows is amusing, but whatever… :)
SDL_GetPlatform doesn't report an OS version at all. Let's take the output
- 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
Very different systems. Very different kernels. Very different
architectures and feature sets. And while I don't know if SDL would compile
on a Windows CE system, it should be a minor thing to get it to do so if
someone is crazy enough to try it! It does "run" under Windows 9x just
fine. Heck, I bet it'll compile out of the tarball on Windows NT 4.0.
Version tends to matter a lot more on Windows than it does on Linux, but it
also tends to matter on iOS where iOS 5 is still realistic for SDL to
encounter, Android which is all over the map in terms of versions and
features, and the Mac where 10.4 is still seen now and again.
Joseph
Post by Alex Szpakowski
Check out SDL_platform.h for #1 and #3. SDL_cpuinfo.h covers #2 somewhat.
On Oct 27, 2013, at 2:01 AM, T. Joseph Carter
Post by T. Joseph Carter
- OS version (string, system dependent)
- CPU string, possibly also system dependent, but "standardized"?
- Platform enum: UNKNOWN, WINDOWS, DARWIN, LINUX, BSD, etc…
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Andre D
2013-10-27 07:47:12 UTC
Permalink
Sorry, kernel version.
Post by Andre D
I only mentioned windows because I assumed you had no reason to detect
a BSD or Linux kernel (or what, are you going to detect every distro?)
for an SDL application.
On Sun, Oct 27, 2013 at 3:43 AM, T. Joseph Carter
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.
Obviously as of 2.0.1 that's the only way you're going to get an OS version.
But asking the OS how much memory is installed was just added to SDL because
someone thought it oughtta be supported. I tend to need to know what a user
is running a whole lot more often than how much RAM they've got, personally.
Joseph
Post by Andre D
Do if an ifdef win32 with GetVersionEx
On Sun, Oct 27, 2013 at 1:56 AM, T. Joseph Carter
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.
The notion of using #ifdef __WIN32__ on a decidedly 64 bit or not even
Intel-based version of Windows is amusing, but whatever… :)
SDL_GetPlatform doesn't report an OS version at all. Let's take the output
- 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
Very different systems. Very different kernels. Very different
architectures and feature sets. And while I don't know if SDL would compile
on a Windows CE system, it should be a minor thing to get it to do so if
someone is crazy enough to try it! It does "run" under Windows 9x just
fine. Heck, I bet it'll compile out of the tarball on Windows NT 4.0.
Version tends to matter a lot more on Windows than it does on Linux, but it
also tends to matter on iOS where iOS 5 is still realistic for SDL to
encounter, Android which is all over the map in terms of versions and
features, and the Mac where 10.4 is still seen now and again.
Joseph
Post by Alex Szpakowski
Check out SDL_platform.h for #1 and #3. SDL_cpuinfo.h covers #2 somewhat.
On Oct 27, 2013, at 2:01 AM, T. Joseph Carter
Post by T. Joseph Carter
- OS version (string, system dependent)
- CPU string, possibly also system dependent, but "standardized"?
- Platform enum: UNKNOWN, WINDOWS, DARWIN, LINUX, BSD, etc…
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Andre D
2013-10-27 07:56:15 UTC
Permalink
The fact of the matter is, there is no portable way to do so. Thus,
why are you scoffing at ifdeffing various platform implementations.
Post by Andre D
Sorry, kernel version.
Post by Andre D
I only mentioned windows because I assumed you had no reason to detect
a BSD or Linux kernel (or what, are you going to detect every distro?)
for an SDL application.
On Sun, Oct 27, 2013 at 3:43 AM, T. Joseph Carter
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.
Obviously as of 2.0.1 that's the only way you're going to get an OS version.
But asking the OS how much memory is installed was just added to SDL because
someone thought it oughtta be supported. I tend to need to know what a user
is running a whole lot more often than how much RAM they've got, personally.
Joseph
Post by Andre D
Do if an ifdef win32 with GetVersionEx
On Sun, Oct 27, 2013 at 1:56 AM, T. Joseph Carter
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.
The notion of using #ifdef __WIN32__ on a decidedly 64 bit or not even
Intel-based version of Windows is amusing, but whatever… :)
SDL_GetPlatform doesn't report an OS version at all. Let's take the output
- 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
Very different systems. Very different kernels. Very different
architectures and feature sets. And while I don't know if SDL would compile
on a Windows CE system, it should be a minor thing to get it to do so if
someone is crazy enough to try it! It does "run" under Windows 9x just
fine. Heck, I bet it'll compile out of the tarball on Windows NT 4.0.
Version tends to matter a lot more on Windows than it does on Linux, but it
also tends to matter on iOS where iOS 5 is still realistic for SDL to
encounter, Android which is all over the map in terms of versions and
features, and the Mac where 10.4 is still seen now and again.
Joseph
Post by Alex Szpakowski
Check out SDL_platform.h for #1 and #3. SDL_cpuinfo.h covers #2 somewhat.
On Oct 27, 2013, at 2:01 AM, T. Joseph Carter
Post by T. Joseph Carter
- OS version (string, system dependent)
- CPU string, possibly also system dependent, but "standardized"?
- Platform enum: UNKNOWN, WINDOWS, DARWIN, LINUX, BSD, etc…
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
T. Joseph Carter
2013-10-27 08:56:37 UTC
Permalink
Well, if I'm just going to #ifdef all of my code for different
platforms, what's SDL for exactly?

Joseph
Post by Andre D
The fact of the matter is, there is no portable way to do so. Thus,
why are you scoffing at ifdeffing various platform implementations.
Post by Andre D
Sorry, kernel version.
Post by Andre D
I only mentioned windows because I assumed you had no reason to detect
a BSD or Linux kernel (or what, are you going to detect every distro?)
for an SDL application.
Andre D
2013-10-27 09:02:15 UTC
Permalink
" to provide low level access to audio, keyboard, mouse, joystick, and
graphics hardware via OpenGL and Direct3D."

On Sun, Oct 27, 2013 at 4:56 AM, T. Joseph Carter
Well, if I'm just going to #ifdef all of my code for different platforms,
what's SDL for exactly?
Joseph
Post by Andre D
The fact of the matter is, there is no portable way to do so. Thus,
why are you scoffing at ifdeffing various platform implementations.
Post by Andre D
Sorry, kernel version.
Post by Andre D
I only mentioned windows because I assumed you had no reason to detect
a BSD or Linux kernel (or what, are you going to detect every distro?)
for an SDL application.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Tim Angus
2013-10-27 14:40:08 UTC
Permalink
Post by T. Joseph Carter
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.
T. Joseph Carter
2013-10-28 02:21:11 UTC
Permalink
Post by Tim Angus
Post by T. Joseph Carter
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
Andre D
2013-10-28 02:53:18 UTC
Permalink
Is there any other information you might want in a debug dump?
Post by T. Joseph Carter
Post by Tim Angus
Post by T. Joseph Carter
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
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
Andre D
2013-10-28 02:54:06 UTC
Permalink
Aside from memory and more specific os info I mean. If someone were to
write a debug info module.
Post by Andre D
Is there any other information you might want in a debug dump?
Post by T. Joseph Carter
Post by Tim Angus
Post by T. Joseph Carter
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
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
Gabriele Greco
2013-10-28 09:38:58 UTC
Permalink
On Sun, Oct 27, 2013 at 9:56 AM, T. Joseph Carter <
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.
--
Bye,
Gabry
Vittorio Giovara
2013-10-28 12:56:09 UTC
Permalink
On Mon, Oct 28, 2013 at 10:38 AM, Gabriele Greco
Post by Gabriele Greco
On Sun, Oct 27, 2013 at 9:56 AM, T. Joseph Carter
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 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
Vittorio
T. Joseph Carter
2013-10-27 08:55:15 UTC
Permalink
A lot can be determined by the equivalent of uname -rs on systems
that have it.

Linux 3.11.0-12-generic (x86_64)

That tells me:
- You're using a packaged kernel, so I shouldn't need to ask you
about whether you compiled in a driver for something commonplace.
- You can't load a 32 bit plugin

It allows me to infer a lot of other things as well, because Debian,
Ubuntu, Red Hat, etc. tend to use different things in their extra
version. Probably more than a few people on this list could ID that
kernel, the distribution it came from, and what release, with a very
high degree of accuracy.


Darwin 13.0.0 (x86_64)

That tells me:
- You're a Mac user whose OS is less than a week from release ;)
- You're running this on the desktop, not an iPad or something


Windows 5.1.2600 (x86)

This tells me:
- You need an OS upgrade (you're running XP SP3)
- You have the common 32 bit version. That's good, because if you
had the 64 bit version there'd be a whole set of possible issues to
address, and we don't have to deal with any of them.


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


That's what I've got on hand at the moment.

Joseph
Post by Andre D
I only mentioned windows because I assumed you had no reason to detect
a BSD or Linux kernel (or what, are you going to detect every distro?)
for an SDL application.
On Sun, Oct 27, 2013 at 3:43 AM, T. Joseph Carter
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.
Obviously as of 2.0.1 that's the only way you're going to get an OS version.
But asking the OS how much memory is installed was just added to SDL because
someone thought it oughtta be supported. I tend to need to know what a user
is running a whole lot more often than how much RAM they've got, personally.
Joseph
Post by Andre D
Do if an ifdef win32 with GetVersionEx
On Sun, Oct 27, 2013 at 1:56 AM, T. Joseph Carter
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.
The notion of using #ifdef __WIN32__ on a decidedly 64 bit or not even
Intel-based version of Windows is amusing, but whatever… :)
SDL_GetPlatform doesn't report an OS version at all. Let's take the output
- 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
Very different systems. Very different kernels. Very different
architectures and feature sets. And while I don't know if SDL would compile
on a Windows CE system, it should be a minor thing to get it to do so if
someone is crazy enough to try it! It does "run" under Windows 9x just
fine. Heck, I bet it'll compile out of the tarball on Windows NT 4.0.
Version tends to matter a lot more on Windows than it does on Linux, but it
also tends to matter on iOS where iOS 5 is still realistic for SDL to
encounter, Android which is all over the map in terms of versions and
features, and the Mac where 10.4 is still seen now and again.
Joseph
Post by Alex Szpakowski
Check out SDL_platform.h for #1 and #3. SDL_cpuinfo.h covers #2 somewhat.
On Oct 27, 2013, at 2:01 AM, T. Joseph Carter
Post by T. Joseph Carter
- OS version (string, system dependent)
- CPU string, possibly also system dependent, but "standardized"?
- Platform enum: UNKNOWN, WINDOWS, DARWIN, LINUX, BSD, etc…
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Gerry JJ
2013-10-27 09:16:55 UTC
Permalink
Post by T. Joseph Carter
It allows me to infer a lot of other things as well, because Debian,
Ubuntu, Red Hat, etc. tend to use different things in their extra
version. Probably more than a few people on this list could ID that
kernel, the distribution it came from, and what release, with a very
high degree of accuracy.
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.

-g
Rainer Deyke
2013-10-27 10:43:41 UTC
Permalink
Post by Gerry JJ
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.)
--
Rainer Deyke (***@eldwood.com)
Gerry JJ
2013-10-27 11:18:09 UTC
Permalink
Post by 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)

-g
Rainer Deyke
2013-10-27 12:46:25 UTC
Permalink
Post by Gerry JJ
Post by 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
--
Rainer Deyke (***@eldwood.com)
Gerry JJ
2013-10-27 13:23:26 UTC
Permalink
Post by Rainer Deyke
$ lsb_release -i
Distributor ID: LinuxMint
That's the lsb_release *program*, though. It's a bit silly having to
launch a new process and capture output just to detect the OS version.

There is (or should be) a file called /etc/lsb-release, similar to
os-release, that may contain that information, but iirc it's not as well
defined, and info can be spread out over several files, etc. Meant to be
used by the lsb_release program, obviously.. nice for shell scripts, not
so much everything else..

-g
Rainer Deyke
2013-10-27 13:41:34 UTC
Permalink
Post by Gerry JJ
There is (or should be) a file called /etc/lsb-release, similar to
os-release, that may contain that information, but iirc it's not as well
defined, and info can be spread out over several files, etc. Meant to be
used by the lsb_release program, obviously.. nice for shell scripts, not
so much everything else..
$ cat /etc/lsb-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=15
DISTRIB_CODENAME=olivia
DISTRIB_DESCRIPTION="Linux Mint 15 Olivia"
--
Rainer Deyke (***@eldwood.com)
Gerry JJ
2013-10-29 11:42:36 UTC
Permalink
Post by 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
Sik the hedgehog
2013-10-27 09:26:40 UTC
Permalink
Post by T. Joseph Carter
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.
Sadly, I was kind of forced to write platform-specific code when I
needed to add file support to the level editor in my game, since I
needed access outside the PhysicsFS sandbox (to read user files).
While I did manage to trick PhysicsFS into giving me access to the
full filesystem when needed so I could reduce platform-specific code
to a minimum (in its own "sub-sandbox", for the record), I still need
to cope with the way paths are handled in each OS, so
platform-specific code was needed for that.

Also another place where I use platform-specific code is when I need
to work around SDL bugs and can't afford to wait for a fix :P But
ideally that kind of code should be gone whenever SDL updates with a
fix.
Post by T. Joseph Carter
Obviously as of 2.0.1 that's the only way you're going to get an OS
version. But asking the OS how much memory is installed was just
added to SDL because someone thought it oughtta be supported. I tend
to need to know what a user is running a whole lot more often than
how much RAM they've got, personally.
Actually, I imagine this could be useful if you want to cache stuff
and want to figure out what would be a good value for this system
(though in practice it tends to result in all programs doing that and
starving RAM like crazy... but whatever, for some stuff like games
that hog most resources for starters it may make sense).
Andre D
2013-10-27 05:10:14 UTC
Permalink
http://wiki.libsdl.org/SDL_GetPlatform returns the basic platform
(windows, osx, linux, etc) as a string. You can also ifdef some of
these platforms at compile time as your binary will not target OSX and
windows at the same time for an example.

On Sun, Oct 27, 2013 at 1:01 AM, T. Joseph Carter
Post by T. Joseph Carter
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
- 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… ;)
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
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Sam Lantinga
2013-10-28 03:15:33 UTC
Permalink
Sure, patches welcome!


On Sat, Oct 26, 2013 at 10:01 PM, T. Joseph Carter <
Post by T. Joseph Carter
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
- 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… ;)
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
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
Jared Maddox
2013-10-28 07:02:34 UTC
Permalink
Date: Sat, 26 Oct 2013 22:56:28 -0700
Subject: Re: [SDL] OS, version, CPU
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
- 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: Sun, 27 Oct 2013 00:43:58 -0700
Subject: Re: [SDL] OS, version, CPU
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
Subject: Re: [SDL] OS, version, CPU
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
Subject: Re: [SDL] OS, version, CPU
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
Subject: Re: [SDL] OS, version, CPU
Content-Type: text/plain; charset=UTF-8; format=flowed
Post by Gerry JJ
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
Subject: Re: [SDL] OS, version, CPU
Content-Type: text/plain; charset=UTF-8; format=flowed
Post by Gerry JJ
Post by 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
Subject: Re: [SDL] OS, version, CPU
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
Subject: Re: [SDL] OS, version, CPU
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.
T. Joseph Carter
2013-10-28 23:30:09 UTC
Permalink
Post by Jared Maddox
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
[..]

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. :)

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. :)

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.
Post by Jared Maddox
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. :)
Post by Jared Maddox
Post by T. Joseph Carter
SDL_GetPlatform doesn't report an OS version at all. Let's take the
output of "Windows" again. How useful is that? "Windows". That
- 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.
Post by Jared Maddox
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.
Post by Jared Maddox
Post by T. Joseph Carter
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.
Post by Jared Maddox
Post by T. Joseph Carter
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.
Post by Jared Maddox
Post by T. Joseph Carter
/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.
Post by Jared Maddox
Post by T. Joseph Carter
$ 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!
Post by Jared Maddox
Post by T. Joseph Carter
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.

Joseph
Gerry JJ
2013-10-29 11:45:15 UTC
Permalink
Post by 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.
Post by T. Joseph Carter
Post by Jared Maddox
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
T. Joseph Carter
2013-10-29 13:10:45 UTC
Permalink
Post by Gerry JJ
Post by 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.
Post by Gerry JJ
Post by T. Joseph Carter
Post by Jared Maddox
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?

Joseph
Gerry JJ
2013-10-29 13:45:29 UTC
Permalink
Post by 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.
Post by T. Joseph Carter
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.
Post by T. Joseph Carter
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.
Post by T. Joseph Carter
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.
Post by T. Joseph Carter
And if you create HKCU/Software/Wine yourself on real Windows?
Then you're asking for trouble. Sorry for trying to help.

-g
Alex Barry
2013-10-29 15:01:58 UTC
Permalink
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.
Post by T. Joseph Carter
Compiler flags are probably more useful a judge than a file on the
Post by T. Joseph Carter
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
Post by T. Joseph Carter
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
Post by T. Joseph Carter
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
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
Sik the hedgehog
2013-10-29 15:20:00 UTC
Permalink
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.
Post by Alex Barry
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.
Post by T. Joseph Carter
Compiler flags are probably more useful a judge than a file on the
Post by T. Joseph Carter
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
Post by T. Joseph Carter
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
Post by T. Joseph Carter
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
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
Alex Barry
2013-10-29 15:49:56 UTC
Permalink
On Tue, Oct 29, 2013 at 11:20 AM, Sik the hedgehog <
Post by Sik the hedgehog
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.
Gerry JJ
2013-10-29 16:17:18 UTC
Permalink
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
Post by Alex Barry
On Tue, Oct 29, 2013 at 11:20 AM, Sik the hedgehog
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
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Andre D
2013-10-29 16:20:56 UTC
Permalink
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.
Post by Gerry JJ
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
Post by Alex Barry
On Tue, Oct 29, 2013 at 11:20 AM, Sik the hedgehog
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
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Jared Maddox
2013-10-30 06:49:25 UTC
Permalink
Date: Tue, 29 Oct 2013 06:10:45 -0700
Subject: Re: [SDL] OS, version, CPU
Content-Type: text/plain; charset=utf-8; format=flowed
Post by Gerry JJ
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.
T. Joseph Carter
2013-10-30 16:41:29 UTC
Permalink
Post by Jared Maddox
Post by 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.
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.
Post by Jared Maddox
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. :) 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.
Post by Jared Maddox
Post by T. Joseph Carter
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.


---

[*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. :) 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
Gerry JJ
2013-10-31 09:22:12 UTC
Permalink
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.
Unless I misunderstand you (entirely possible), isn't that all
information that a program can easily tell at compile time with a few
#ifdefs? Why would you want to get it as a string from SDL?

I mean, you said you're not even interested in the OS architecture. I
don't see what you're after here.

-g
Alex Barry
2013-10-31 14:20:46 UTC
Permalink
Unless I misunderstand you (entirely possible), isn't that all information
that a program can easily tell at compile time with a few #ifdefs? Why
would you want to get it as a string from SDL?
I mean, you said you're not even interested in the OS architecture. I
don't see what you're after here.
-g
Yes, and no. That would only give you information on the computer that
build the executable/library, and not on the current computer. For
instance, I am running arch linux, and I could build my app, and run it on
ubuntu - if I used the preprocessor for this identification, it would only
know about my arch linux system.
T. Joseph Carter
2013-10-31 15:19:17 UTC
Permalink
Post by Gerry JJ
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.
Unless I misunderstand you (entirely possible), isn't that all
information that a program can easily tell at compile time with a few
#ifdefs? Why would you want to get it as a string from SDL?
I mean, you said you're not even interested in the OS architecture. I
don't see what you're after here.
Basically driver versions and supported features. But on Linux,
driver versions tend to be tied to the kernel version. On Android,
it's more of a question of the full OS release. On iOS it tends to
be based on the major version of the OS. On a Mac it's usually the
major and minor, though 3rd party drivers are possible for things
like joysticks. Windows is more complicated, but it can be greatly
narrowed down a lot by NT kernel and DirectX versions. If uname were
universal and consistent, there'd be little need for a patch. It's
not though, and on some systems uname's structure does not contain
the pertinent information anyway (if it even exists.)

Add to that a vague description of CPU architecture and you have what
I'm after. The major reason that tends to matter is that x86_64
platforms can usually handle i686 code, but the two cannot be quite
freely intermixed. Messes with plugins and the like.

I'll have a look at queryable driver info afterward. I think video
and sound are probably mostly covered to the extent those matter, but
when I'm done, if some part of SDL's hardware interaction doesn't
work as intended on some system, it should be real easy to figure out
what SDL is working with.

For example, recently someone protested that SDL's joystick code was
"broken". We were able to determine that on Windows, he was using an
XBox 360 controller using the DirectInput driver without XInput.
Consequently, on Windows XP 32 bit, I get the same result and I still
do not know why. As it stands, I still do not know:

1. Is XInput not available on my Windows installation?
2. Does my build system not actually support XInput despite headers
and libs all being there?
3. Would XInput work if I took my SDL library and used it on Windows
Vista/7? (I don't have either…)
4. Does the driver for the XBox 360 controller simply not do XInput
on my system to try and make me upgrade to Vista/7/8?

I could make SDL spew some debugging info itself in the joystick
driver to tell me what I need to know, and I probably will. But at
some point it should be possible for someone to say "My joystick
isn't working right in your game" and your game being able to,
through SDL, answer all three of those questions—right down to the
fact that you're running a WindowsNT platform (version 5, 1, "2600",
with patch level 3, 0) on an x86 architecture in case that
information is somehow relevant to figuring out the problem.

In fact, issues surrounding what driver SDL was using for joysticks
on Windows has now come up 3 times in the past two months in addition
to my own personal issue. It's come up under Linux once where the
solution was that SDL needed to be rebuilt with libudev. You
presently can't query the joystick driver info like you can display
or sound driver, and I honestly don't know what to say about the
possibility of knowing eg which joysticks are XInput and which are
DirectInput yet. I'm still thinking that one over—the querying of
the OS I have pretty well sorted out in my head.

Now I just need to finish working out the kinks in my Mavericks
upgrade so I can get back to work. :)

Joseph
Eric Wing
2013-10-31 20:45:25 UTC
Permalink
Post by T. Joseph Carter
Now I just need to finish working out the kinks in my Mavericks
upgrade so I can get back to work. :)
I hope by 'getting back to work on Mavericks' means adding a
GCController backend to SDL for Apple's new MFi based game controller
API for Mac & iOS. :P

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
T. Joseph Carter
2013-11-02 01:31:15 UTC
Permalink
It might first mean porting the tattiebogle driver to GCController.
Since I upgraded to Mavericks the driver doesn't work as-is, and
under VMWare Ubuntu's 3.11.0-generic-12 (I believe) is softlocking
when I connect the receiver device. I MAY see if I can pick up a
wired XBox 360 controller or clone whose sticks and DPad aren't
sucktastic to eliminate a variable in getting the driver to play nice
in its current form with xnu 13.x.x at all.

Windows XP sees the XBox 360 controller properly under VMWare, but I
still seem to be lacking the ability to use the thing as an XInput
device in SDL.

Mostly making Mavericks behave thus far has meant getting things like
MacPorts' cyrus-sasl2 working so I can actually send email. :)
Libtool may be a broken turd, but it tends to become more broken when
upstream is Doing It Wrong and nobody really wants to accept the
authority and responsibility of Doing It Right even if they don't.

Hopefully I'll get back to SDL-related stuff this weekend.

Joseph
Post by Eric Wing
Post by T. Joseph Carter
Now I just need to finish working out the kinks in my Mavericks
upgrade so I can get back to work. :)
I hope by 'getting back to work on Mavericks' means adding a
GCController backend to SDL for Apple's new MFi based game controller
API for Mac & iOS. :P
Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Vittorio Giovara
2013-11-02 13:04:16 UTC
Permalink
It might first mean porting the tattiebogle driver to GCController. Since
I upgraded to Mavericks the driver doesn't work as-is, and under VMWare
Ubuntu's 3.11.0-generic-12 (I believe) is softlocking when I connect the
receiver device. I MAY see if I can pick up a wired XBox 360 controller or
clone whose sticks and DPad aren't sucktastic to eliminate a variable in
getting the driver to play nice in its current form with xnu 13.x.x at all.
Probably off topic, but a working tattiebogle driver for Mavericks is here
https://github.com/d235j/360Controller
It even supports FEZ with rumble :)

Vittorio
Windows XP sees the XBox 360 controller properly under VMWare, but I still
seem to be lacking the ability to use the thing as an XInput device in SDL.
Mostly making Mavericks behave thus far has meant getting things like
MacPorts' cyrus-sasl2 working so I can actually send email. :) Libtool
may be a broken turd, but it tends to become more broken when upstream is
Doing It Wrong and nobody really wants to accept the authority and
responsibility of Doing It Right even if they don't.
Hopefully I'll get back to SDL-related stuff this weekend.
Joseph
Post by T. Joseph Carter
Now I just need to finish working out the kinks in my Mavericks
Post by T. Joseph Carter
upgrade so I can get back to work. :)
I hope by 'getting back to work on Mavericks' means adding a
GCController backend to SDL for Apple's new MFi based game controller
API for Mac & iOS. :P
Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Jared Maddox
2013-10-31 07:02:32 UTC
Permalink
Date: Wed, 30 Oct 2013 09:41:29 -0700
Subject: Re: [SDL] OS, version, CPU
Content-Type: text/plain; charset=utf-8; format=flowed
Post by Jared Maddox
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. :)
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.
T. Joseph Carter
2013-10-31 07:54:11 UTC
Permalink
Post by Jared Maddox
Post by T. Joseph Carter
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. :)
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.
Please tell me you're joking…

I will not be implementing package manager access in SDL. If for
some bat-crap crazy reason you need this, you're on your own.

Joseph
Jared Maddox
2013-11-02 09:14:26 UTC
Permalink
Date: Thu, 31 Oct 2013 00:54:11 -0700
Subject: Re: [SDL] OS, version, CPU
Content-Type: text/plain; charset=utf-8; format=flowed
Post by Jared Maddox
Post by T. Joseph Carter
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. :)
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.
Please tell me you're joking?
I will not be implementing package manager access in SDL. If for
some bat-crap crazy reason you need this, you're on your own.
I wasn't suggesting it, I was suggesting providing the information to
guess what package manager needs to be interacted with. If I actually
wasn't clear on this, then I apologize. My limited experience with
*nix has been "corner-case distros" where every bell & whistle from
A-Z isn't installed, but instead just a decent selection.
Continue reading on narkive:
Loading...