[SDL] OS, version, CPU

T. Joseph Carter tjcarter at spiritsubstance.com
Thu Oct 31 08:19:17 PDT 2013

On 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.

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


More information about the SDL mailing list