Windows XP support

and proud :-)> On 15 Aug 2016, at 11:08, Marvin Marvin wrote:

nerds

On Mon, Aug 15, 2016 at 8:54 AM, jeroen clarysse <@Jeroen_Clarysse> wrote:
I would like to add that performance-wise, SDL1.2 has serious issues from Vista upwards hen combining GDI with SDL.

On 15 Aug 2016, at 08:05, Bandock wrote:

BenoitRen wrote:
The great thing about SDL 1.2 is that it runs on Windows 95 all the way to Windows 8. I don’t know if it runs on Windows 10, but it wouldn’t surprise me. The graphics capabilities were limited, however, which is why SDL2 is a big deal. But if platform support is going to be limited to the latest versions of popular OSs, its usefulness is severely reduced.

It definitely runs on Windows 10 since DOSBox currently uses a version of SDL from the 1.x branch (though some have been working on builds that use the 2.x branch).


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


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


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

On the other hand, I know somebody who got it working on Windows 98 by
just using KernelEx and a few extra stub functions, so it looks like
SDL2 is barely even doing much with XP.

XP added a handful of nice features (like RAWINPUT), but Win32, so far,
hasn’t been the constant tension of dropping old platforms like macOS
has been. 90% of what we need has been in Win32 since Windows NT 3.51,
much of the rest was officially backported by Microsoft (like XInput) or
can be dynamically loaded with reasonable fallbacks for older systems
(like the Shell APIs).

The Win9x OSes got dropped partially because they were ancient and
largely abandoned (whereas WinXP, while old, was still popular), and
NT-based OSes like Windows XP had guaranteed Unicode support, which
meant we didn’t need two codepaths through everything or any
understanding of what a “codepage” is, which simplifies our work immensely.

We could drop XP at some point, but there’s not a lot of pressure to do
so, at least until (and if!) the UWP model gets wide, wide, wide
adoption. On Mac OS X, we were falling into this gross maze of #ifdefs
and version checks and evaporating compiler support and stuff, and that
forces our hand a lot, but Windows hasn’t been like that.

–ryan.

It would also be nice if the maintainers actually supported the OSes
they claim to! As I have pointed out before, and logged as a bug,
despite SDL 2.0.4 officially still supporting OS-X 10.6 (Snow Leopard),
which runs on 32-bit Macs, the current versions of the Mac binaries are
64-bit only. Sad

I think something changed on Sam’s system that did the builds; I don’t
think it was a deliberate change, and I think he’s probably too busy to
deal with it. My attitude has always been that we shouldn’t ship
binaries at all, for this sort of reason.

If you’re on an older Xcode because Apple abandoned you, you absolutely
have my sympathies, but my ability to help you is extremely limited. We
do still support 32-bit builds of SDL, but we have the same
forced-upgrade march that everyone else does. I don’t like that this is
Apple’s policy about everything, but that’s where we are,
unfortunately. :frowning:

–ryan.

Judging by the Steam Developer Survey, OS X users are 3.37% of Steam, and of that 3.37%, a large majority are running 10.9 or later, with over 60% running 10.11 or 10.5:

http://store.steampowered.com/hwsurvey?platform=mac http://store.steampowered.com/hwsurvey?platform=mac

Speaking to users of SDL2 (and not really the maintainers): If you are a true build masochist, you might want to maintain 32-bit and 64-bit OS X fat binaries just to verify your fat binary build pipeline is intact, but, realistically, you would be doing so against any commercial interests. You are targeting a fraction of a fraction.

Do you think 5-10% of the 3.37% of Steam?s users who don?t pay to upgrade their machines are the ones who are paying to buy your games?

As for XP support, there is the China argument. But if you?re going to the trouble of targeting XP with Mandarin glyphs, compiling your own SDL2 binary is going to be the least of your efforts.

As a user of SDL2, I am much more interested in reasonable FORWARDS compatibility with new platforms and OSes so I can rebuild my older projects with minimal source changes. Being early on new platforms helps capture real opportunities and I am really grateful for the work going into SDL2 that makes this possible.

Michael Labb?> On Aug 16, 2016, at 12:30 PM, Ryan C. Gordon wrote:

If you’re on an older Xcode because Apple abandoned you, you absolutely have my sympathies, but my ability to help you is extremely limited. We do still support 32-bit builds of SDL, but we have the same forced-upgrade march that everyone else does. I don’t like that this is Apple’s policy about everything, but that’s where we are, unfortunately. :frowning:

As far as I know, binaries built on 10.6 (with XCode from back then)
aren’t even guaranteed to work on newer OSX versions - I think to
support 10.6 to 10.11 one has to build with latest XCode and
-mmacosx-version-min=10.6 - can someone who has more experience with
that platform than me confirm that?

BTW, I heard newer OSX versions run okayish in VirtualBox (without
graphics acceleration though), so running OSX in VirtualBox on a proper
PC, building binaries there and testing them on your old real Mac might
be an option.

Cheers,
DanielOn 08/13/2016 12:22 PM, rtrussell wrote:

Dominus wrote:
You can quickly build those frameworks yourself, btw…

The only Mac I have is a 32-bit model running OS-X 10.6, and my
understanding is that whilst that is officially supported for running
SDL 2.0.4 it is not supported for building it. So if that’s right I have
no way of running the build and creating the frameworks. I’ve more than
once asked here for some kind person to do it for me, but there have
been no takers.

If you believe SDL 2.0.4 can be built on OS-X 10.6 can you point me to a
project file suitable for Xcode 3.2?

Richard.

Do you know why Apple breaks compatibility all the time?
Is there any good reason that remotely outweighs causing developers so
much pain?

Cheers,
DanielOn 08/16/2016 09:30 PM, Ryan C. Gordon wrote:

It would also be nice if the maintainers actually supported the OSes
they claim to! As I have pointed out before, and logged as a bug,
despite SDL 2.0.4 officially still supporting OS-X 10.6 (Snow Leopard),
which runs on 32-bit Macs, the current versions of the Mac binaries are
64-bit only. Sad

I think something changed on Sam’s system that did the builds; I don’t
think it was a deliberate change, and I think he’s probably too busy to
deal with it. My attitude has always been that we shouldn’t ship
binaries at all, for this sort of reason.

If you’re on an older Xcode because Apple abandoned you, you absolutely
have my sympathies, but my ability to help you is extremely limited. We
do still support 32-bit builds of SDL, but we have the same
forced-upgrade march that everyone else does. I don’t like that this is
Apple’s policy about everything, but that’s where we are,
unfortunately. :frowning:

–ryan.


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

Daniel Gibson wrote:

As far as I know, binaries built on 10.6 (with XCode from back then)
aren’t even guaranteed to work on newer OSX versions

I can’t answer as to whether they are “guaranteed” to work, but several people are running my app (built on 10.6 with Xcode 3.2) on recent versions of OS-X and nobody has reported any issues as yet. Feel free to try it yourself, albeit that it’s only an alpha release: http://www.rtr.myzen.co.uk/BBCBasic.dmg

Richard.

2016-08-16 16:25 GMT-03:00, Ryan C. Gordon :

XP added a handful of nice features (like RAWINPUT), but Win32, so far,
hasn’t been the constant tension of dropping old platforms like macOS
has been. 90% of what we need has been in Win32 since Windows NT 3.51,
much of the rest was officially backported by Microsoft (like XInput) or
can be dynamically loaded with reasonable fallbacks for older systems
(like the Shell APIs).

OK yeah I guess it isn’t seen as much of a maintenance problem unlike OSX :stuck_out_tongue:

We could drop XP at some point, but there’s not a lot of pressure to do
so, at least until (and if!) the UWP model gets wide, wide, wide
adoption.

That makes it sound like it’d get dropped only if Windows 7 did (since
as far as I’m aware UWP isn’t available on Windows 7 either), and
there’s still a good bunch of people using that.

2016-08-16 16:56 GMT-03:00, Michael Labb? :

As for XP support, there is the China argument. But if you?re going to the
trouble of targeting XP with Mandarin glyphs, compiling your own SDL2 binary
is going to be the least of your efforts.

Eh, building the library for Windows is easy (again: worst case just
grab MinGW-w64 and let it do its job, you pretty much already have to
do it if you aren’t using Visual Studio anyway). The question was more
about whether XP would remain supported at all altogether (even if you
have to build yourself).

As far as I know, binaries built on 10.6 (with XCode from back then)
aren’t even guaranteed to work on newer OSX versions - I think to
support 10.6 to 10.11 one has to build with latest XCode and
-mmacosx-version-min=10.6 - can someone who has more experience with
that platform than me confirm that?

No, I have two OSX systems: A build system running 10.6 and another
system for testing which always runs the latest version of OSX. I can
confirm that builds done using 10.6 are running fine on the latest
10.11.

The 10.6 system is running XCode 3.2.6 with the last “good” SDK,
which contains all the things that have been removed from newer
SDKs, including really old (but still useful) stuff like QuickDraw
etc.

Apple’s API developer policy is really a pain the a**. In comparison
to Windows APIs all OSX APIs are pretty new and still they’re deprecating
them faster than you can say Jack Robinson. Anybody remember Carbon?
Many people painfully migrated their sources from classic Mac OS to
Carbon only to hear a few years later that Carbon would be killed off
completely and that there was no way to go 64-bit in Carbon. It’s
really a pain and it looks like the OSX dev management is a bunch of
amateurs with no clue of how to design long-lasting, stable APIs. Instead,
it’s like they’re following Greek philosopher Heraclit’s famous dictum
that “everything flows” … and that’s just annoying the heck out of me.

It is because of Apple that I first learned to appreciate the robustness
of Win32 APIs. Now who would’ve thought that!On 16.08.2016 at 23:14 Daniel Gibson wrote:


Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

Ryan C. Gordon wrote:

NT-based OSes like Windows XP had guaranteed Unicode support, which meant we didn’t need two codepaths through everything or any understanding of what a “codepage” is, which simplifies our work immensely

Every time Win9x support is dropped, this is one of the reasons mentioned. It’s as if open source developers are parroting it from each other. I don’t buy it, because SDL wouldn’t be the first project to need Unicode support across Win9x and WinNT. Mozilla has done it for ages in their software, a Unicode layer library by Microsoft exists, and an open-source variant of said library exists as well. That’s several compatibility layers you can reuse in one way or another. Yet people act like those don’t exist.

2016-08-17 15:50 GMT-03:00 BenoitRen :

Ryan C. Gordon wrote:

NT-based OSes like Windows XP had guaranteed Unicode support, which meant
we didn’t need two codepaths through everything or any understanding of
what a “codepage” is, which simplifies our work immensely

Every time Win9x support is dropped, this is one of the reasons mentioned.
It’s as if open source developers are parroting it from each other. I don’t
buy it, because SDL wouldn’t be the first project to need Unicode support
across Win9x and WinNT. Mozilla has done it for ages in their software, a
Unicode layer library by Microsoft exists, and an open-source variant of
said library exists as well. That’s several compatibility layers you can
reuse in one way or another. Yet people act like those don’t exist.

So what I hear is that you are volunteering to add support back for Win9x
using any these libraries and maintain it for free forever?

Gabriel.

Well that sounds a little harsh. What Ryan’s main point is that simpler
code is better. It’s easier to follow, and easier to maintain. I’m sure
if someone volunteered to implement and maintain Win9x/NT, and it was done
well, it wouldn’t be rejected.On Wed, Aug 17, 2016 at 2:50 PM, BenoitRen wrote:

Ryan C. Gordon wrote:

NT-based OSes like Windows XP had guaranteed Unicode support, which meant
we didn’t need two codepaths through everything or any understanding of
what a “codepage” is, which simplifies our work immensely

Every time Win9x support is dropped, this is one of the reasons mentioned.
It’s as if open source developers are parroting it from each other. I don’t
buy it, because SDL wouldn’t be the first project to need Unicode support
across Win9x and WinNT. Mozilla has done it for ages in their software, a
Unicode layer library by Microsoft exists, and an open-source variant of
said library exists as well. That’s several compatibility layers you can
reuse in one way or another. Yet people act like those don’t exist.


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

BenoitRen wrote:

That’s several compatibility layers you can reuse in one way or another.

Uniscribe (USP10.DLL) is usable in Win9x, albeit with limited functionality compared with its later incarnations, and that’s how I achieve continuity of support for Unicode from Win9x (with IE 5.5) right through to Windows 10.

Richard.

Saying that Window XP is dead is fine. It’s arguably true, even. Stating
it as a contradiction to the running discussion and providing no
constructive information is how one trolls.

Jonny DOn Wed, Aug 17, 2016 at 3:00 PM, Jesse Palser < jessepalsermailinglists at gmail.com> wrote:

Windows XP is dead.

If saying the above makes me a Troll, then I am hiding in my cave cooking
frogs.

JeZxLee

On 08/17/2016 02:50 PM, BenoitRen wrote:

Ryan C. Gordon wrote:
NT-based OSes like Windows XP had guaranteed Unicode support, which meant
we didn’t need two codepaths through everything or any understanding of
what a “codepage” is, which simplifies our work immensely

Every time Win9x support is dropped, this is one of the reasons mentioned.
It’s as if open source developers are parroting it from each other. I don’t
buy it, because SDL wouldn’t be the first project to need Unicode support
across Win9x and WinNT. Mozilla has done it for ages in their software, a
Unicode layer library by Microsoft exists, and an open-source variant of
said library exists as well. That’s several compatibility layers you can
reuse in one way or another. Yet people act like those don’t exist.


SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


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

Also, in China 40% of the users still use WinXP.On 08/17/2016 09:32 PM, Jonathan Dearborn wrote:

Saying that Window XP is dead is fine. It’s arguably true, even.
Stating it as a contradiction to the running discussion and providing no
constructive information is how one trolls.

Jonny D

Every time Win9x support is dropped, this is one of the reasons

This was the commit that removed Win9x support from PhysicsFS…look at
that sea of red, as all sort of compatibility tapdancing became unnecessary:

 https://hg.icculus.org/icculus/physfs/rev/4cdb856021dd

SDL has a lot more Windows-specific code than PhysicsFS, too.

–ryan.

I think the suggestion was to just require installing the Unicode
support on Win9x. Somebody who didn’t already have it installed
probably is not going to bother doing it now though.

Sik wrote:

I think the suggestion was to just require installing the Unicode
support on Win9x. Somebody who didn’t already have it installed
probably is not going to bother doing it now though.

As I alluded to before, my approach is to support Win9x + IE5.5 (which provides Uniscribe). Customers who want to run my application on Win9x understand that they may need to install IE 5.5, which doesn’t require any ‘technical’ knowledge. There is virtually nothing in my app which is Windows version specific.

Richard.

As I alluded to before, my approach is to support Win9x + IE5.5 (which
provides Uniscribe). Customers who want to run my application on Win9x
understand that they may need to install IE 5.5, which doesn’t require
any ‘technical’ knowledge. There is virtually nothing in my app which is
Windows version specific.

Okay, I’m not against SDL2 supporting Win9x, if we’re just going to
link against the same things we do now and some magical thing will make
it work right on Win9x systems without any effort on our part; foisting
this onto the user to solve with reasonable steps (if “install a 16 year
old web browser on your 21 year old OS” counts as reasonable) is better
than telling the user it just flatly doesn’t work…but that being said,
it’s not anything I plan to spend time on.

I will accept reasonable patches for this, but I dunno, the definition
of “reasonable” is pretty narrow right here.

–ryan.