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:
- Is XInput not available on my Windows installation?
- Does my build system not actually support XInput despite headers
and libs all being there?
- Would XInput work if I took my SDL library and used it on Windows
Vista/7? (I don’t have either?)
- 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. 
JosephOn Thu, Oct 31, 2013 at 10:22:12AM +0100, Gerry JJ wrote:
Den 30. okt. 2013 17:41, skrev T. Joseph Carter:
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.
