What's the latest with Intel's Management Engine / Minix that runs on every Intel chipset? Is that still a thing? Did they harden it? Or can you still get access?
That... Shouldn’t be terribly difficult? Though I don’t believe UEFI has sound drivers (you’ll have problems writing one yourself because even frickin’ sound-codec chips have NDA-only datasheets these days), and the stupidest thing is that the “graphics output protocol” doesn’t indicate vsync so you can’t do tear-free blitting, which is literally worse than VGA.
About 10 years ago, it became "common knowledge" about mainboards that onboard sound has become good enough for almost anybody. It has never been true for me, maybe because my recent mainboards have been lower middle class (AMD B350 / B650) largely chosen for good CPU power converters.
Because my two (PC) laptops since 2020 have both had really damn good headphone outputs, I can believe that some good / expensive mainboards have it, too. It's not exotic technology anymore. Meanwhile, my desktop PC has a 20+ years old M-Audio prosumer card that also sounds great. (Now rigged with a PCIe -> PCI converter card off AliExpress)
Bluetooth sucks against the raw codec of a soundcard. If you want lossy music, that's it.
But given autotune trends and how genz-ers grew up with shitty early smartphone loudspeakers and not much better BT ones they aren't used to proper music and their tastes are rot forever.
There are a lot of parallels: It has a janky set of buggy drivers. It has backslashes in paths. It has a shell that is "inspired" by COMMAND.COM. And it's basically a program loader where every program immediately replaces it and drives the hardware directly.
I basically had this setup back in the day. I don't really know how I ended up with it, I was 7 at the time and none of it was intentional - but my bootloader had two entries: I could boot into Windows 98, or I could boot into Worms.
As far as I know, Worms is a normal DOS game, so the only way for that to happen should be a DOS install configured to just auto-start Worms on boot. Which makes sense as a way to keep a kid away from anything that could cause trouble.
I very vaguely recall that there used to be a very few PC games that worked as boot floppies and possibly didn't use DOS at all, but it was a rarity and Worms definitely wasn't one.
No, I set it up. My parents were non-technical. I had a CD-ROM re-release of Worms for DOS from one gaming magazine or another. I guess the installer set it up somewhere somehow but I remember it wasn't easy to get it installed and there were further problems trying to launch it. It's possible the installer itself was a DOS program, not a Windows program.
BIOS can only manage VESA which is much much slower than the capabilities of a modern GPU, so they might have meant graphical performance in regards to that.
VESA BIOS Extensions support direct framebuffer access in protected mode, and I don't imagine the lack of accelerated 2D operations would be a practical bottleneck when implementing NES-style graphics on modern PCs.
UEFI GOP additionally supports accelerated bitblt, but again YAGNI for 2D game performance at reasonable framerates on a modern PC.
Welcome to Amiga games, in many cases the floppy would contain the boot loader that would directly jump into the game.
At least on the Amiga 500 you would not go through the trouble to start Workbench, only to load the game, unless you were a lucky owner of an external hard drive.
Your comment said "welcome to Amiga games", as if it were unique to Amiga. The context of the thread is PC, where they had their own booter/bare-metal games.
So you don't have to go to "Amiga games world", you're already in the proper world.
And yet, your little slice of the world doesn't represent the world at whole.
If you're ignorant of the situation, maybe don't come out with such a self-centered (and arguably, arrogant) statement; and especially don't double down on it when corrected.
I recall many IBM-PC games are bootable games. I inserted a floppy , resets the computer, and then it directly boots into the game. The disk must contain a boot sector and drivers and such.
As well, although I think in the Amiga this was more common, to buy games that were already prepared like this.
At least on my circle for doing the same with PC games, we built the floppies ourselves, then again, it could be a side effect that you could hardly buy any legal games in Portugal during those days, even regular shops would sell pirated games as originals.
For making DOS games, there is also an old port of Löve2D. Löve2D normally uses SDL, but the DOS port has its own little (mode 13h VGA) graphics/audio/input library instead. Guess with a proper SDL port it might be possible to make a more complete port of Löve 2D (and of a newer version).
Note this uses DJGPP, which switches processor to 32 bit mode via DPMI. You won't get old-school experience of segmented memory, near pointers and 64KB limits everywhere.
Very cool. I'd never heard of OHRRPGCE (Official Hamster Republic Role Playing Game Construction Engine) before. I was going to say it feels like an early predecessor to something like RPG Maker but I think RPG Maker originally came out in the early ’90s for the Japanese PC-98 computers.
From the wikipedia entry [1] for OHRRPGCE
> It runs at an 8-bit color depth, by default creates games that run at a 320 × 200 resolution.
It's funny but I bet anyone else in here who also grew up with the QBASIC interpreter as a kid instantly thinks SCREEN 13 when they read something like this.
:) SCREEN 13 (VGA Mode 13h) is almost correct, but actually it originally used a 320x200 VGA Mode X assembly graphics library. I believe 320x200 instead of 320x240 to be compatible with earlier pure-QB code for SCREEN 13 reused in the engine. (Mode X isn't a single mode, it has some adjustable parameters.)
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.
These obscure architectures are almost always one person with a dream, one hero willing to step up make it happen and maintain it. My favorite is the openbsd luna88k https://www.openbsd.org/luna88k.html
I don't have any real clue how many openbsd luna 88k users there are in the wild, it was an obscure machine released, I think, only in japan, so most users, if they exist, are probably japanese, that is, out of my normal view scope. So as far as I can tell there is one user, the porter. But every release a couple weeks after the standard release date he comes out of the woods and drops the luna88k files and packages. I suspect it takes that long to compile on an actual luna88k. But that is all it takes and luna88k is an official hardware platform of openbsd.
I don't have nor do I really want a luna88k but that guy is sort of my hero for keeping it going like this.
With the ease and speed of browser-based DOSBox (look at internet archive), DOS becomes a highly portable target for small games and even non-trivial games.
Anything up to the complexity of mid-90s AAA titles can run practically anywhere with a keyboard and mouse.
Games like Tomb Raider, Command & Conquer, Quake, etc. This is pretty compelling if you want a "it just works" platform.
>Timer: Native PIT-based timer using DJGPP's uclock()
I want to commend Dj Delorie for doing a great job. As a poor child at that time having access to a proper compiler which could ran on my old PC which only ran DOS, was awesome and amazing.
> 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!
Perhaps not serious, but I think people gravitate towards older systems these days because they are easier to conceptualize. It's not unrealistic for a single person to have a complete grasp of e.g. the C64 and it's programming environment. DOS is similarly constraint, but also easier for you to form a more or less complete mental model around.
Some people love computers and making them do weird stuff, older computers make certain tasks feel more manageable.
Most computers in Turkey come with FreeDOS preinstalled because there's a law that states all computers must be sold with an operating system. FreeDOS turns out to be the cheapest and easiest.
That's why you don't let people who have never touched a computer write tech laws. You get results like this.
The computer is not very usable without an operating system. I think it would be reasonable for the computer to have Forth or BASIC or something like that in ROM, like many older computers do, so that the computer is usable without an operating system (but that you could also install an operating system if you wanted it).
Linux drivers and certification is a whole lot of extra work and complexity compared to FreeDOS. Years ago, Nettops were sold with FreeDOS where the components didn't support Linux that well.
Russia has a similar law and yes computers with FreeDOS are also a thing. Alternatively, you're entitled to get a refund for the Windows license by having your hard drive wiped and license sticker removed.
(FWIW: I suspect there are more than a few old industrial control systems and such out there that are still running DOS, just because of an "if it ain't broke, don't fix it" attitude)
My brother is in manufacturing. DOS is everywhere. Older things too (PDP-11? DG Nova? Seen both, semi-recently). Not just because "ain't broke, don't fix", but because when you have a cloth dying machine or brick forming machine you spent >US$5M for, that is often a bespoke install for your plant, you don't replace it because some guy who prolly slings Javascript all day sez "DOS is oooold, boomer".
These DOS machines for industrial control could probably be replaced by an Arduino or a far more reliable MCU, whereas running an actual legacy PC as a business-critical component in manufacturing has to be a bit of a nightmare by now. AI could probably do a good enough job of working out how the legacy DOS executables were intended to work.
You might notice that I never once claimed that the replacement I described would be "easy" or, for that matter, even advisable given the broader real-world constraints involved; just technically feasible in the barest sense. I don't think many people would want to use DOS to design a greenfield system of that kind today, and there's a reason for that. Yes, you can buy newly made "DOS PCs" today, but can you really ensure that today's brand new DOS PC will behave in every way that matters like the actual 30 years old DOS PC that used to control the machinery? That's not a trivial question to answer.
If you design the system from the outset to work with an actual PLC/SCADA or similar (the typical solution for hooking up to big industrial machinery of that sort) that's a bit less likely to come up as an issue, and the hardware will actually be designed for that kind of environment.
Yes, if you ignore everything that was discussed, invent time travel do you can "design the system from the outset" as the prescient you are, and pretend anyone was talking about greenfield, you get to be right. Good for you...some people just need the 'win'.
Yeah...this is "if you screw around with it enough, you void the warranty and we will no longer support it" for a potentially multimillion dollar machine.
I think this PR is awesome, and I can totally see myself playing around with this at some point. Being able to create DOS executables of SDL projects is just ... cool!
But I do wonder about the practicality. This would, I presume (never done DOS development, never touched a memory extender) only run on 386+ CPUs, and maybe more importantly, probably require a newer CPU than that to run anything non-trivial at acceptable performance. So I wonder how many "real DOS machines" this can practically target.
> "real DOS machines" this can practically target.
Define "real DOS machine".
But I would give you my definition: something with ISA slot so you can hear that awful 2.0 stereo SB Pro-compatible with a hiss what could be almost parseltongue. Video card of choice.
So basically anything between 386sx to P3 Tualatin and some rare and weird cases even P4 and AMD Athlon.
I did testing on a K6-2 300Mhz, and yes it has 2 ISA slot, one of which is where I put the Sound Blaster 16.
Compiling an SDL port of Quake quake gives you 90% performance at 320x200 and 97% at 640x480 compared to the original. That's about 45fps which isn't bad I think.
SDL3 should now work with any i386+ with a VGA and 4MB of RAM which is roughly the requirements of Doom.
There's a lot of interesting projects and even innovation going on making new games for old PCs/consoles. James Lambert and Kaze are doing fantastic work in the N64 space as one example (watch their videos on Youtube)
It's a simple enough implementation that implicitly helps document how SDL is supposed to work (DOS being a well understood platform by now). Plenty of reasons to maintain it based on that alone.
SDL is written in C. So it can support it without too much trouble. And some people are compiling stuff to run on DOS. So it makes sense. And your objection doesn't hold any water.
I suppose it's an issue of ignorance; even IT veterans often don't know that DOS was, and still is, the driver of many highly specialized industry applications, or an OS running the software of individuals as well as small business owners around the world.
All that's left now is SDL for UEFI, and then all our games can run in a pre-OS environment.
What's the latest with Intel's Management Engine / Minix that runs on every Intel chipset? Is that still a thing? Did they harden it? Or can you still get access?
https://www.zdnet.com/article/minix-intels-hidden-in-chip-op...
You're missing the most important question: Can the Intel Management Engine run Doom?
That... Shouldn’t be terribly difficult? Though I don’t believe UEFI has sound drivers (you’ll have problems writing one yourself because even frickin’ sound-codec chips have NDA-only datasheets these days), and the stupidest thing is that the “graphics output protocol” doesn’t indicate vsync so you can’t do tear-free blitting, which is literally worse than VGA.
Most support Intel HDA.
The problem is that people don't use onboard audio anymore (because its incredibly and audibly noisy). They use USB or Bluetooth.
Bluetooth absolutely isn't standardized and is a mess, and USB miiiiiiight be okay if you limit to a subset of EHCI and USB Audio Class 1.0 devices.
At this point, its easier to just use Linux and run your game as pid 1.
Regarding onboard audio:
About 10 years ago, it became "common knowledge" about mainboards that onboard sound has become good enough for almost anybody. It has never been true for me, maybe because my recent mainboards have been lower middle class (AMD B350 / B650) largely chosen for good CPU power converters.
Because my two (PC) laptops since 2020 have both had really damn good headphone outputs, I can believe that some good / expensive mainboards have it, too. It's not exotic technology anymore. Meanwhile, my desktop PC has a 20+ years old M-Audio prosumer card that also sounds great. (Now rigged with a PCIe -> PCI converter card off AliExpress)
You can strip down Linux significantly as well: no multi-user, no extra syscalls, no FS support beyond initramfs/tmpfs, etc.
Bluetooth sucks against the raw codec of a soundcard. If you want lossy music, that's it.
But given autotune trends and how genz-ers grew up with shitty early smartphone loudspeakers and not much better BT ones they aren't used to proper music and their tastes are rot forever.
I refuse to use Bluetooth, too.
But, unfortunately, people keep buying that trash. We're kinda forced to support their mistakes.
Well… UEFI is kind of modern DOS.
More like modern BIOS++ IMO
It certainly is not.
There are a lot of parallels: It has a janky set of buggy drivers. It has backslashes in paths. It has a shell that is "inspired" by COMMAND.COM. And it's basically a program loader where every program immediately replaces it and drives the hardware directly.
That honestly sounds amazing. Imagine booting into something like a grub menu that's just a list of classic games.
I basically had this setup back in the day. I don't really know how I ended up with it, I was 7 at the time and none of it was intentional - but my bootloader had two entries: I could boot into Windows 98, or I could boot into Worms.
It's a similar idea, but that's a DOS menu. At the point when the menu appears, MS-DOS 7.1 has already been loaded.
Stupid question but... would bundling the binary with an ASM port of something that could run this technically make it possible to run without the OS?
I realize this is basically doing docker for DOS games and incredibly stupid, I'm just curious about the thought experiment
Well, the "ASM port of something that could run this" would be the OS...
Possibly stripped down to only support that game, but basically yeah
Right. I guess I mean like an app specific OS haha
Probably your parents setting it up?
As far as I know, Worms is a normal DOS game, so the only way for that to happen should be a DOS install configured to just auto-start Worms on boot. Which makes sense as a way to keep a kid away from anything that could cause trouble.
I very vaguely recall that there used to be a very few PC games that worked as boot floppies and possibly didn't use DOS at all, but it was a rarity and Worms definitely wasn't one.
I bet it wasn't actually the bootloader but something with autoexec.bat - you could setup choices in it and windows was just one launch option.
Well, if you treat DOS as a bootloader for Windows 98 - which it was actually - then modifying autoexec.bat would count as setting up the bootloader.
No, I set it up. My parents were non-technical. I had a CD-ROM re-release of Worms for DOS from one gaming magazine or another. I guess the installer set it up somewhere somehow but I remember it wasn't easy to get it installed and there were further problems trying to launch it. It's possible the installer itself was a DOS program, not a Windows program.
MS-DOS Shell was one popular option to do this.
https://en.wikipedia.org/wiki/DOS_Shell
Brown Bag PowerMenu was another.
https://forum.winworldpc.com/discussion/15739/software-spotl...
I would guess a modern BIOS chip is as powerful as an NES, right?
You can do substantially more in UEFI than NES-level games. (See https://uefi.org/specs/UEFI/2.9_A/12_Protocols_Console_Suppo...)
What do you mean by "BIOS chip"? Like, the flash memory that stores the motherboard's firmware? I don't think that contains any processing elements.
BIOS can only manage VESA which is much much slower than the capabilities of a modern GPU, so they might have meant graphical performance in regards to that.
VESA BIOS Extensions support direct framebuffer access in protected mode, and I don't imagine the lack of accelerated 2D operations would be a practical bottleneck when implementing NES-style graphics on modern PCs.
UEFI GOP additionally supports accelerated bitblt, but again YAGNI for 2D game performance at reasonable framerates on a modern PC.
SDL for bare metal.
Welcome to Amiga games, in many cases the floppy would contain the boot loader that would directly jump into the game.
At least on the Amiga 500 you would not go through the trouble to start Workbench, only to load the game, unless you were a lucky owner of an external hard drive.
PC had bare metal games too. They were called “booters” and you can find an entire category of them on mobygames:
https://www.mobygames.com/platform/pc-booter/
Yeah, but I never saw them, missed my reply on the other thread?
Whether I saw your other response or not is moot.
Your comment said "welcome to Amiga games", as if it were unique to Amiga. The context of the thread is PC, where they had their own booter/bare-metal games.
So you don't have to go to "Amiga games world", you're already in the proper world.
It was certainly unique to Amiga games on my little part of the world.
Not everyone was rich enough to know how the world looked elsewhere, connecting to all kinds of BBSs.
And yet, your little slice of the world doesn't represent the world at whole.
If you're ignorant of the situation, maybe don't come out with such a self-centered (and arguably, arrogant) statement; and especially don't double down on it when corrected.
I recall many IBM-PC games are bootable games. I inserted a floppy , resets the computer, and then it directly boots into the game. The disk must contain a boot sector and drivers and such.
As well, although I think in the Amiga this was more common, to buy games that were already prepared like this.
At least on my circle for doing the same with PC games, we built the floppies ourselves, then again, it could be a side effect that you could hardly buy any legal games in Portugal during those days, even regular shops would sell pirated games as originals.
For making DOS games, there is also an old port of Löve2D. Löve2D normally uses SDL, but the DOS port has its own little (mode 13h VGA) graphics/audio/input library instead. Guess with a proper SDL port it might be possible to make a more complete port of Löve 2D (and of a newer version).
https://github.com/SuperIlu/lovedos
The original upstream version is archived and has not been maintained in 9+ years. The link is to a fork that has fixes as recent as 2025.
This is an especially funny screenshot as DosBOX itself is built on SDL.
Hm, then we need dosbox running in dos!
DOSBox-X has DOS as one of its supported host platforms (using HX-DOS that a sibling comment mentioned):
https://github.com/joncampbell123/dosbox-x#dosbox-x-supporte...
Doable maybe with HXDOS.
even better, windows running in dos.
oh wait...
(https://en.wikipedia.org/wiki/Windows_3.0)
SDLception
Note this uses DJGPP, which switches processor to 32 bit mode via DPMI. You won't get old-school experience of segmented memory, near pointers and 64KB limits everywhere.
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
I'm going to find out. I've been meaning for years to port the OHRRPGCE back to DOS, where it came from.
I'm very surprised to see SDL3 re-gain DOS support, since they've aggressively dropped support for almost every port/OS they had in the SDL 1.2 days.
Very cool. I'd never heard of OHRRPGCE (Official Hamster Republic Role Playing Game Construction Engine) before. I was going to say it feels like an early predecessor to something like RPG Maker but I think RPG Maker originally came out in the early ’90s for the Japanese PC-98 computers.
From the wikipedia entry [1] for OHRRPGCE
> It runs at an 8-bit color depth, by default creates games that run at a 320 × 200 resolution.
It's funny but I bet anyone else in here who also grew up with the QBASIC interpreter as a kid instantly thinks SCREEN 13 when they read something like this.
[1] - https://en.wikipedia.org/wiki/Official_Hamster_Republic_Role...
:) SCREEN 13 (VGA Mode 13h) is almost correct, but actually it originally used a 320x200 VGA Mode X assembly graphics library. I believe 320x200 instead of 320x240 to be compatible with earlier pure-QB code for SCREEN 13 reused in the engine. (Mode X isn't a single mode, it has some adjustable parameters.)
Perfect! I was just doing some Turbo C development inside DOSBox-X inside Debian GNU/Linux inside VMware Fusion inside macOS this morning.
Was this a joke? I must know!
Is there a turboc variant for linux, I vaguely remember working on turboc decades ago
you may also enjoy watching Inception then :)
Almost but usually I watch live stream of people watching records of people talking about how they remember about it.
Technically this already worked with HXDOS, which emulated DirectDraw well enough that SDL could use it.
Wait what.
What SDL would you compile for? Win32 with exclusive fullscreen? With a VESA resolution like 640x480?
I remember way back when, there were ports of SDL 1.x to djgpp. Glad to see someone still cares.
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.
These obscure architectures are almost always one person with a dream, one hero willing to step up make it happen and maintain it. My favorite is the openbsd luna88k https://www.openbsd.org/luna88k.html
I don't have any real clue how many openbsd luna 88k users there are in the wild, it was an obscure machine released, I think, only in japan, so most users, if they exist, are probably japanese, that is, out of my normal view scope. So as far as I can tell there is one user, the porter. But every release a couple weeks after the standard release date he comes out of the woods and drops the luna88k files and packages. I suspect it takes that long to compile on an actual luna88k. But that is all it takes and luna88k is an official hardware platform of openbsd.
I don't have nor do I really want a luna88k but that guy is sort of my hero for keeping it going like this.
SDL getting back to its Loki roots
Awesome. Why? But awesome. There does not need to be a reason why
With the ease and speed of browser-based DOSBox (look at internet archive), DOS becomes a highly portable target for small games and even non-trivial games.
Anything up to the complexity of mid-90s AAA titles can run practically anywhere with a keyboard and mouse.
Games like Tomb Raider, Command & Conquer, Quake, etc. This is pretty compelling if you want a "it just works" platform.
Having SDL now makes that even easier.
FreeDOS is technically a modern, actively-supported DOS.
So I can play Dota 2 on DOS.
SDL is a cross-platform multimedia library, and DOS is a platform.
Awesome! This makes me really happy.
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.
Looks like one of the main contributors to the PR is one of the SDL maintainers. That probably helps!
>Timer: Native PIT-based timer using DJGPP's uclock()
I want to commend Dj Delorie for doing a great job. As a poor child at that time having access to a proper compiler which could ran on my old PC which only ran DOS, was awesome and amazing.
Wait, it didn’t already or am I confusing it with the VESA support on Linux?
SDL has never supported DOS.
You might be thinking of Allegro?
https://github.com/superjamie/allegro-4.2.3.1-xc
> 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:
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!
Love it! Now, let's port it to CP/M (via GSX, maybe?)
Good - now we can play more DOS games again!
Well I guess Allegra was a bit old already /s
I loved Allegra! Saved me a lot of time when I was writing code for our musicdisk. That was 29 years ago though. :)
Uhm... excuse me? Why? Is there anyone even using DOS for anything serious these days?
Perhaps not serious, but I think people gravitate towards older systems these days because they are easier to conceptualize. It's not unrealistic for a single person to have a complete grasp of e.g. the C64 and it's programming environment. DOS is similarly constraint, but also easier for you to form a more or less complete mental model around.
Some people love computers and making them do weird stuff, older computers make certain tasks feel more manageable.
Yea, it is like looking at the insides of a mechanical clock vs looking into an electronic one.
The former is mesmerizing, intriguing, inviting and inspiring. The later? you can't wait to put the lid back on...
Most computers in Turkey come with FreeDOS preinstalled because there's a law that states all computers must be sold with an operating system. FreeDOS turns out to be the cheapest and easiest.
That's why you don't let people who have never touched a computer write tech laws. You get results like this.
The really weird case is where the computer isn't actually compatible with DOS, so they put in a locked-down Linux distro that emulates FreeDOS.
Wasn't it Dell or HP that did this? IIRC it was FreeDOS-on-QEMU-on-X11-on-Linux.
HP: https://blog.tmm.cx/2022/05/15/the-very-weird-hewlett-packar...
149 comments: https://news.ycombinator.com/item?id=31389893
Those types of laws aren't all that bad.. they got us this: https://segaretro.org/Dottori_Kun
The computer is not very usable without an operating system. I think it would be reasonable for the computer to have Forth or BASIC or something like that in ROM, like many older computers do, so that the computer is usable without an operating system (but that you could also install an operating system if you wanted it).
Is there a reason they don't go with Ubuntu or something like that instead?
I guess they don't want to get support's call. DOS looks like firmware for non techies.
Linux drivers and certification is a whole lot of extra work and complexity compared to FreeDOS. Years ago, Nettops were sold with FreeDOS where the components didn't support Linux that well.
I wish that was the case where I live. I'm looking for a new laptop and the mainstream ones still come with the Windows Tax.
Russia has a similar law and yes computers with FreeDOS are also a thing. Alternatively, you're entitled to get a refund for the Windows license by having your hard drive wiped and license sticker removed.
Who said anything about "serious"?
(FWIW: I suspect there are more than a few old industrial control systems and such out there that are still running DOS, just because of an "if it ain't broke, don't fix it" attitude)
My brother is in manufacturing. DOS is everywhere. Older things too (PDP-11? DG Nova? Seen both, semi-recently). Not just because "ain't broke, don't fix", but because when you have a cloth dying machine or brick forming machine you spent >US$5M for, that is often a bespoke install for your plant, you don't replace it because some guy who prolly slings Javascript all day sez "DOS is oooold, boomer".
These DOS machines for industrial control could probably be replaced by an Arduino or a far more reliable MCU, whereas running an actual legacy PC as a business-critical component in manufacturing has to be a bit of a nightmare by now. AI could probably do a good enough job of working out how the legacy DOS executables were intended to work.
This isn't hackaday or adafruit. Everything is easy when you don't have to actually do it. You are wrong on every point.
You might notice that I never once claimed that the replacement I described would be "easy" or, for that matter, even advisable given the broader real-world constraints involved; just technically feasible in the barest sense. I don't think many people would want to use DOS to design a greenfield system of that kind today, and there's a reason for that. Yes, you can buy newly made "DOS PCs" today, but can you really ensure that today's brand new DOS PC will behave in every way that matters like the actual 30 years old DOS PC that used to control the machinery? That's not a trivial question to answer.
If you design the system from the outset to work with an actual PLC/SCADA or similar (the typical solution for hooking up to big industrial machinery of that sort) that's a bit less likely to come up as an issue, and the hardware will actually be designed for that kind of environment.
Yes, if you ignore everything that was discussed, invent time travel do you can "design the system from the outset" as the prescient you are, and pretend anyone was talking about greenfield, you get to be right. Good for you...some people just need the 'win'.
Given the implications, I guess nobody is going to touch those setups to put an SDL-based program on them, though...
Yeah...this is "if you screw around with it enough, you void the warranty and we will no longer support it" for a potentially multimillion dollar machine.
The real question is "why not?" :)
I think this PR is awesome, and I can totally see myself playing around with this at some point. Being able to create DOS executables of SDL projects is just ... cool!
But I do wonder about the practicality. This would, I presume (never done DOS development, never touched a memory extender) only run on 386+ CPUs, and maybe more importantly, probably require a newer CPU than that to run anything non-trivial at acceptable performance. So I wonder how many "real DOS machines" this can practically target.
Still, it is massively cool.
> "real DOS machines" this can practically target.
Define "real DOS machine".
But I would give you my definition: something with ISA slot so you can hear that awful 2.0 stereo SB Pro-compatible with a hiss what could be almost parseltongue. Video card of choice.
So basically anything between 386sx to P3 Tualatin and some rare and weird cases even P4 and AMD Athlon.
https://theretroweb.com/motherboards?page=1&itemsPerPage=24&...
I did testing on a K6-2 300Mhz, and yes it has 2 ISA slot, one of which is where I put the Sound Blaster 16.
Compiling an SDL port of Quake quake gives you 90% performance at 320x200 and 97% at 640x480 compared to the original. That's about 45fps which isn't bad I think.
SDL3 should now work with any i386+ with a VGA and 4MB of RAM which is roughly the requirements of Doom.
A real DOS machine is running on a 8086 (or 8088)
ISA is part of IBM-compatibility.
Hacker News
Because it's fun, at least for certain folks? Crazy, right?
There used to be stock exchanges running happily on DOS. Maybe there still are.
Worked at an exchange in 2007/2008 and... we had systems still running from the 80s. Mostly tape audit stuff.
Most use Linux now, and specifically RHEL. I did see some IBM z, but that was specifically for one old DB that handled oil pipeline stuff.
There's a lot of interesting projects and even innovation going on making new games for old PCs/consoles. James Lambert and Kaze are doing fantastic work in the N64 space as one example (watch their videos on Youtube)
It's a simple enough implementation that implicitly helps document how SDL is supposed to work (DOS being a well understood platform by now). Plenty of reasons to maintain it based on that alone.
There are several reasons. One possible reason is, if you do not need the functions of other operating systems, then DOS will be much simpler.
SDL is written in C. So it can support it without too much trouble. And some people are compiling stuff to run on DOS. So it makes sense. And your objection doesn't hold any water.
because you can
Uhm... excuse me? Why? Is there anyone even using DOS for anything serious these days?
Translation: "Stop liking things I don't like!"
I suppose it's an issue of ignorance; even IT veterans often don't know that DOS was, and still is, the driver of many highly specialized industry applications, or an OS running the software of individuals as well as small business owners around the world.
Because computers can be used to do things that are not...so serious?
More specifically it's part of my quest to get Diablo (DevilutionX) running on anything it can, using modern tools. Next up PS2 and PSP.
> it's part of my quest to get Diablo
Sorry, I didn't quite get what you refer to as "it" here. Nevertheless, I also have a similar quest going.
If you have to do Microslop, then DOS is a sane option. Windows 11 is just too bloated and too slow in addition to being malware.