Proposal: Exploring ways to extend SDL3 compatibility for older systems

[JordanCpp]

Hello SDL3 team and community,

First of all, thank you for your incredible work on SDL. It's a cornerstone of the cross-platform development world.

I'm writing to you with a proposal and to open a discussion about supporting older operating systems and toolchains in SDL3.

I understand that maintaining support for legacy platforms can be a significant burden and often conflicts with adopting modern APIs and language features. However, there is a niche but passionate community (in retro-gaming, legacy system maintenance, and education) that greatly benefits from having a modern library like SDL on older systems.

To demonstrate both the need and the feasibility, I've been working on two projects:

1. SDL3Lite: A lightweight, API-compatible implementation of SDL3, written in C++98 for maximum portability. It targets Windows 95+ and old Linux distributions (Debian 3+).
2. LDL (Little Directmedia Layer): A broader cross-platform media library inspired by SDL's philosophy, supporting even more legacy graphics APIs like DirectDraw, Direct3D 5, and 3dfx Glide.

You can see the projects, build instructions, and screenshots here:
SDL3Lite
LDL

My work proves that it's technically possible. The screenshots show SDL_Renderer, OpenGL 1.2/3.3 contexts, and texture loading working on these old platforms.

My question to you is: Would you be open to the idea of finding a way to make SDL3 itself more friendly to such porting efforts?

I'm not suggesting to halt progress or compromise SDL3's modern features. Instead, perhaps we could explore:

• Conditional Compilation: Could key modern C++ features be hidden behind macros, allowing a "legacy mode"?
• Modularity: Could platform-specific code for ancient systems be moved into separate, optional modules?
• C Language Compatibility: To emphasize my commitment to portability, I want to state that I am fully ready to abandon C++ and develop a compatible layer purely in C. The language is not a principle for me; the goal of maximum portability is what matters most.
• Documentation of Dependencies: A clear map of which SDL modules require which modern OS/compiler features.

I am fully aware of the maintenance cost. I am not just asking "if you can do it"; I am offering my help and expertise gained from my LDL and SDL3Lite projects to assist in such an endeavor. I am ready to contribute code, testing, and long-term maintenance for these legacy paths.

Thank you for your time and consideration. I look forward to hearing your thoughts.

Sincerely,
Jordan.

[nightmareci]

I've already done a bit of what you're doing, getting SDL3 to work on Windows versions as far back as Windows XP, but there are some restrictions to deal with for new legacy support. New legacy support can get in, if done well within the existing structure.

SDL has always been first and foremost a C library, so you won't get to write functionality in C++ for Windows support. In the case of code that can be C, the project requires it be C, and SDL3 also requires some, but not all, C99 features, like declaration of variables not just at the start of scope. There's a lot of cross platform C99 code every port uses, so all of that has to work on the legacy targets as-is. That means legacy C89 compilers will never be supported, like very old MSVC versions, which leaves you unable to target Windows 95 with the Windows 95 supporting MSVC versions. One of the few places C++ is used is for Haiku support, as Haiku's system APIs are natively C++, not C, with those parts exporting C interfaces for the rest of the code.

The codebase is already modularized for different backends and platforms as needed, so new Windows 9x parts could be added, so long as a working C99 compiler is available. Maybe some old version of GCC could work.

[playmer]

Fwiw, I'm interested in Win95 support as well, but I'm stretched between a bunch of side projects at the moment.

A couple months ago I explored the toolchain problem nightmareci mentioned, and there should be a couple "simple" avenues to get modern language versions up and running, albeit, with outdated stdlibs. The main issue with mingw toolchains afaik is mostly just that the stdlib is compiled with higher requirements than 90s hardware, so you'd need to compile that yourself, some discussion on that here.

It should also be quite feasible to use clang with older MSVC stdlib/Windows SDKs for modern C and C++ language features. I've done some experiments there, and it seems to work, but I've not done anything as complex as SDL yet.

[playmer]

Also you should know there's already been some work to bring SDL to DOS. Here's a PR where someone wrote a port for SDL2, and icculus linked to his own branch working on bringing SDL3 to DOS: #13906 (comment)

So there's certainly interest here!

[icculus]

These things can live in the SDL tree too. We aren't against old and weird platforms if someone is supporting the code in small ways.

As was mentioned, there are forks for MS-DOS, we've had OS/2 and QNX, etc.

As for compatibility libraries: Emscripten offers an SDL-1.2 compatible library written from-scratch in JavaScript. We don't care if people do these as external things that don't involve us...a thing written in C++ that targets Windows 95 that is mostly like SDL3 would probably fit in this category.

[JordanCpp]

Thank you for the quick and insightful responses! @nightmareci, @playmer, @icculus

I understand the requirements for using C and C99, and this aligns perfectly with my goals for maximum portability. I am fully prepared to work within these constraints.

Taking your comments into account, I would like to start by making a practical contribution. My plan is to begin porting individual SDL3 modules using pure C, conforming to the C99 standard, starting with support for Windows 9x.

My proposed plan of action:

I will start with the most suitable modules – for instance, those related to event handling or basic window management, where work with legacy APIs can be relatively isolated.

I will create Pull Requests focused on:

Pure C code (C99)

Minimal changes to the existing codebase

Clear separation of code using #ifdef SDL_PLATFORM_WIN9X (or a similar define)

Preserving all existing functionality for modern platforms

I will first focus on the toolchain – as @playmer noted, I will use a combination like Clang with older Windows SDKs to ensure compatibility.

A few questions for the team:

Are there any specific modules you would recommend as a starting point?

What prefix or #define do you prefer for conditional compilation targeting such legacy systems?

Are there any specific coding style guidelines I should follow meticulously?

I will begin this work in my fork and create an initial PR for discussion as soon as I have a working proof-of-concept for a module.

Thank you for your openness to this discussion! I look forward to any further advice you may have.

[JordanCpp]

My implementation plan:

First phase - stubs only

Create minimal stubs for problematic APIs

Ensure successful compilation for Windows 95

Functionality will be limited, but the code will compile

Second phase - gradual implementation

After successful compilation, I'll start filling the stubs with actual code

I'll add functionality module by module

I'll start with basic input (keyboard/mouse) and window management

I'll start by creating a PR containing only the stub system and conditional compilation to demonstrate the approach.

I'm starting work on the stubs now.

[slouken]

I believe work on Win9x is already in progress. You should coordinate with @playmer and @nightmareci.

[playmer]

Not sure if it's okay to infodump here, but I'll start here and we can move elsewhere if slouken would prefer it go out of here until it's further along 😅

I didn't get wildly far, but I spent some time trying to get SDL to compile while targeting Win95, that work is here: playmer@465a2bd

It's likely I'm not going down a good path there, but I didn't spend too much time on it, I got it compiling (with a ton of stuff disabled, both in CMake and manually in code) with one of the toolchains I was playing with at the time, but it couldn't actually run any SDL applications. Since then I've been busy with other projects.

I've been cobbling together a bunch of scripts that try to assemble together a Clang/MSVC toolchain in this repo. It's not well documented, so I apologize for that. Basically InstallEverything.ps1 tries to go download and install VS2005 Express, the latest clang, the DX9 SDK, and the Windows2003 SDK. Regarding the Microsoft tooling, these were the lowest I could find available officially as download from Microsoft, ideally we'd go lower.

There's also some scripts and toolchain files that try to set up an environment that should allow usage of Clang alongside these SDKs with CMake. It's pretty hacky and certainly needs work. Feel free to grab this stuff and hack at it. The trickiest bit is getting lld-link to target Win95, but those bits in the toolchain files should be mostly correct.

[JordanCpp]

I propose the following experimental plan.

Windows 11: install MSVC 2022 and MSVC 2005 and mingw old versions.

Create manual .bat files to build a minimal sdl3.dll.

Include only the core, timer, and similar modules.

When building with MSVC 2022, verify that the build proceeds correctly.

When building with MSVC 2005, observe the errors and identify the necessary #defines for Windows 95/98.

Rewrite the modules to use the legacy WinAPI.

The first task should be to achieve a build with the header files from include/SDL3 and a single core module.

As an example, create the following directories:

• src/main/win9x
• src/core/win9x

Then add files and modules to the build one by one via the .bat files.

What do you think of this idea?

[playmer]

I don't know that I'd rewrite the subsystems from scratch for 95. My general process would be to get the toolchain working,
Make sure you can compile and run test applications utilizing the old SDKs and new compile for 95. Once there, try to build a minimal SDL and see where you run into issues. I'd think that the video subsystem could be reused for example, with hefty conditional compilation.

That said, maybe the maintenance burden is too high and it is just easier to have a different subsystem. You could at least start with the existing one and then trim down on unsupported things/rewrite pieces. Ultimately those decisions are way above my pay grade.

[edo9300]

For an appropriate toolchain, I've been using this gcc10 based one that targets the crtdll c runtime (available unchanged since windows nt 3.5) https://github.com/edo9300/mingw32-crtdll, for which I made a barebone docker image, it works good enough for my project using c++17 and lua (in this case lua is the only code doing the very few win32 calls). I actually tried compiling sdl3 with this toolchain once, but due to it using the original all mingw headers, there were plenty of missing functions and some other missing import libraries that require very crude patching on the sdl side. But the final library ended up working fine. The fact that the CRT DLL is very old shouldn't really impact sdl itself since sdl has its own c standard library implementation that should be used instead.

[icculus]

My suspicion is that for the most part, most of the existing code is close to usable.

The thing that will likely burn you worst is the lack of Unicode APIs on Win95, but we can either provide simple wrappers or require unicows.dll be included with the app.

Otherwise, most of it would follow the same tactics we use for Windows XP: newer system APIs are dynamically loaded and we add fallbacks where appropriate.

The only new modules we'd need would be for the renderer (no direct3d 9 support, I think? The software renderer and OpenGL likely works though, assuming GL drivers still exist) and maybe restore the winmm audio backend (but the directsound backend probably works, so maybe not worth it?).

(I haven't looked at playmer's code, he might have come to the same conclusions.)

[edo9300]

If SLD can work with opengl 1 it should work fine on those targets as well, as should always be available under windows (and apparently there's a wined3d port for 9x, giving you dx9 on w95 https://github.com/JHRobotics/wine9x). For Unicode APIs, yeah, unicows (or one of the Foss reimplementations) would be needed.
Another possible issue would be the gotchas with different behaviors in random win32 APIs that have different workings on those platforms.

[JordanCpp]

Thank you for your answers and your willingness to help.

There is a GCC 10 port for Windows 98. It runs on Windows 10 and produces binary code compatible with Windows 98.

I’ll try to integrate it with CMake on Windows.

https://github.com/fsb4000/gcc-for-Windows98?ysclid=mhj98mnd4y348015457

[JordanCpp]

Yes, OpenGL 1.2 works on Windows 95, including with 3dfx drivers. Also, opengl32.dll is already built into the operating system. It can operate using only the CPU.

I tested it in the 86Box emulator using Windows 95 OSR2.