SDL Now Supports DOS
Jayschwa
243 points
99 comments
April 24, 2026
Related Discussions
Found 5 related stories in 65.7ms across 5,498 title embeddings via pgvector HNSW
- SDL bans AI-written commits davikr · 120 pts · April 16, 2026 · 60% similar
- Detecting DOSBox from Within the Box atan2 · 65 pts · April 17, 2026 · 51% similar
- The Official DR DOS Website Tomte · 46 pts · March 15, 2026 · 49% similar
- SteamOS now runs on every AMD handheld SockThief · 45 pts · April 23, 2026 · 45% similar
- DirectX: Bringing Console-Level Developer Tools to Windows haunter · 13 pts · March 12, 2026 · 44% similar
Discussion Highlights (16 comments)
ronsor
All that's left now is SDL for UEFI, and then all our games can run in a pre-OS environment.
raverbashing
Well I guess Allegra was a bit old already /s
jan_Sate
Uhm... excuse me? Why? Is there anyone even using DOS for anything serious these days?
alnwlsn
This is an especially funny screenshot as DosBOX itself is built on SDL.
Dwedit
Technically this already worked with HXDOS, which emulated DirectDraw well enough that SDL could use it.
vunderba
Awesome. I wonder how this would work with a 386+ targeted MS-DOS executable from FreeBASIC, which supports binding to SDL. [1] - https://github.com/freebasic/fbc
jlokier
Perfect! I was just doing some Turbo C development inside DOSBox-X inside Debian GNU/Linux inside VMware Fusion inside macOS this morning.
shevy-java
Good - now we can play more DOS games again!
looneysquash
For a open source project like SDL is, for something like this, it's usually a matter of how invasive it is, and how likely the contributors seem to stick around and maintain it. Different projects have different policies, and I don't know what SDLs is. But they already have a lot of ports, so I trust they know what they're getting themselves into.
vintermann
SDL getting back to its Loki roots
whobre
Love it! Now, let's port it to CP/M (via GSX, maybe?)
klik99
Awesome. Why? But awesome. There does not need to be a reason why
flykespice
I'm more impressed by the fact they accepted it upstream, specially for an OS target that is long gone from the market and has virtually no users. Usually upstream projects would reject such PRs under the reason they just increase maintenance cost with little to no benefit to the userbase.
TacticalCoder
> Input: ... gameport joystick via BIOS INT 15h with auto-calibration Joystick calibration: what a blast from the past! Blast from the past I encountered recently... Joysticks had to be "calibrated" and it was something you had to do for each game that supported joysticks. These would give back analog values and they'd depend on the phases of the moon or the room temperature or both. I'm not making this up: this was a serious pain point both for players and coders. FWIW in that DOS game of mine from 1991 or so for which I still had the .ASM source code files (about 30 000 lines of assembly code, 15 000 of which were auto-generated code to do very fast sprites drawing in the VGA 320x200 "tweaked" mode) and which I managed, at long last, to get to compile again a few days ago thanks to UASM (and quite some LLM help), I found lines like these: ul_corner_ch: db 63,"PUT YOUR JOYSTICK IN THE UPPER LEFT CORNER AND PRESS A BUTTON " lr_corner_ch: db 63,"PUT YOUR JOYSTICK IN THE LOWER RIGHT CORNER AND PRESS A BUTTON " p1_choose: dw 1 ;1 keyboard 2 joystick p2_choose: dw 0 ;0 none 1 keyboard 2 joystick And basically a 350 lines assembly file only for joystick calibration . So you can understand that "auto-calibration" as in TFA is quite a selling point!
cmxch
Wait, it didn’t already or am I confusing it with the VESA support on Linux?
qsera
Awesome! This makes me really happy.