To the list of compiler listed I want to mention this one as well, that is my compiler of choice for 16-bit C in (Free)DOS these days (because it has a MIT license, it's very small, and it runs great inside of DOS itself so no need to mess with cross-compilation and I know if I have an environment like FreeDOS or DOSBox set up I can both compile and run my code, and I will never have to re-install or reconfigure anything when moving between different host systems):
(Not only Microsoft's C compiler in that directory, but also MASM, MAKE, and a bunch of other tools. 1-2 MB of files and you have an entire toolchain for 16-bit DOS.)
Interesting, "All files within this repo are released under the MIT License as per the LICENSE file stored in the root of this repo," but did they include the source for the toolchain? I may be looking in the wrong place...
Yeah, I didn't mean it was illegal, just that you might have an unnecessarily hard time fixing compiler bugs and understanding how the toolchain works.
Yes, of course. Source code would be nice, but I gamble on that there wasn't a terrible amount of bugs in that compiler. It is version 5.10, so not the first 5.x release, plus with the lack of good ways to distribute patches back then we all know software tended to be better tested. It also obviously works well enough to compile DOS 4.0 (and a bunch of user tools that are included) plus I have tried it already for some quite big code-bases without noticing anything being broken.
I feel like any bugs can probably be worked around and since it is C it is possible some things can be fixed by adding some macros in the include-files. I have thought of making some minor changes to the include-files to modify some of the few things I noticed that are missing from C89. I do not know if it is possible to make it 100% C89 compliant or if the binaries would have to be patched for that, but it seems like it already is 99% of the way.
* Since I can't comment on the comment to this post: Note I said C89. Definitely not going to go for anything more modern. Possibly add the standard integer size types from C99, as those can be useful for more portable code. There are other, bigger, compilers for more modern C versions that can cross-compile to DOS (and also Free Pascal that seems like a nice language for that).
Oh, yeah, you're definitely going to have a harder time adding C99 support to it than to OpenWatcom, not to mention C11, C17, and C23. Which matters if you're writing new code.
Is there really a difference between writing a DOS program and writing a FreeDOS program? You just need a period-accurate compiler that can target DOS. Maybe OpenWatcom, maybe DJGPP.
With HXDOS, you can also write a Win32 console-mode program and run it on DOS. 7-zip is an example of a program compatible with HXDOS.
I confess I don't know anything about FreeDOS, but are they trying to evolve DOS for the future, or just make a free bug-for-bug compatible version? Those are very different things.
FreeDOS is significantly different from "real" MS-DOS.
Back in the 20th century I used DR-DOS, written by Digital Research, the company behind the original OS of which DOS was an unauthorised re-implementation.
(DR CP/M-86 was years late, so SCP wrote 86-DOS as a replacement. MS licensed 86-DOS and later bought it. It's not a clone: CP/M was in a compiled high-level language, while 86-DOS was implemented in assembly language, implementing a version of the same API on a different CPU ISA, using a different filesystem drawn from a separate pre-existing product.)
Until MS discontinued MS-DOS and IBM kept on developing it for a few more versions, IBM PC DOS and MS-DOS were near identical.
DR-DOS was a little different from MS-DOS. It had extra commands, used different syntax in the config files, very slightly different output and things -- but then, it was from the original vendor, so that was excusable, and mostly, it understood MS syntax as well.
FreeDOS is not like that. It's quite unlike any other version of DOS. It has differently-named config files, it lives in a differently-named folder with an internal structure, and it has a number of external commands with different names and different syntax. For example, one that threw me is that there is no `SUBST` command, but a different `SWSUBST` which combines the functionality of SUBST and JOIN.
In 21st century DOS terms, at best, FreeDOS is as different from MS/PC/DR DOS as Red Hat is from Debian. In fact it may be more like it to say FreeDOS vs OG DOS is akin to FreeBSD vs Linux.
But the GCC, OpenWatcom, and DJGPP compilers the FreeDOS folks recommend are additionally free software, which is of real value to some of us. Zortech C had a reputation for producing better code IIRC, and it could run on an 80286, which I'm not sure the others can?
I don't remember when we transitioned to 32 bit DOS extenders for the DOS compilers, but we never got any pushback for that. Developers all used 386 computers.
I remember attending a compile panel at one of the SDWest conferences. The panel members were myself, representing Zortech, along with representatives from Borland, Watcom, and Microsoft.
The first question was "do you sell a version that will work on a floppy disk only computer?" One of the other panelists responded with yes, we do. He went on to describe how the various bits could be distributed among multiple floppies, and of course it involved a lot of shuffling floppies in and out.
I was next. I replied, "Yes, we have a version that does it! It costs $200 extra and comes with a hard disk drive!"
That got a huge laugh, and that was the end of that question. I never heard it again from anybody. Sometimes, it's just time to move on!
Historically there were 24-bit ("16 megs") DOS extenders that would work on a 286, though the 286's inability to seamlessly go back to real mode (which is needed for compatibility with BIOS routines) creates issues that make 286 protected mode a bit of a theoretical curiosity.
I was trying to come up with some advantage of Zortech C that might justify using it now instead of an open-source compiler like DJGPP under some circumstance. Any ideas?
Oh, the answer is that Zortech C is actually open-source, and I was just being an idiot? That's wonderful! And the license here doesn't seem to have any of the questionable bits in the OpenWatcom license.
And maybe people just haven't noticed? I assumed when you said "free of charge" that you implicitly meant "but not open source", and also didn't see anything on https://www.digitalmars.com/download/freecompiler.html about compiler source, and the only "license" link on that page goes to https://www.digitalmars.com/download/dmcpp.html which says, "The Software is copyrighted and comes with a single user license, and may not be redistributed. If you wish to obtain a redistribution license,...", so maybe you could see how I got the wrong idea!
I guess it made a lot of sense to implement compilers in 32-bit protected mode to get more space to work with easier? Free Pascal's compiler also requires 32-bit even if it can generate 16-bit DOS code as well (at least when cross-compiling from some other OS; I have not tried to cross-compile from DOS 32-bit compiler to DOS 16-bit executable).
Some people (and by that I mean Debian people; not sure about anyone else) disagree about OpenWatcom being free software. The license has some unusual requirement(s). There has been talk for a long time about possibly fixing that, but I do not know how on track that is (or how much it matters, in practice):
https://github.com/open-watcom/open-watcom-v2/discussions/27...
I developed on a 32 bit machine because of memory protection. Memory corruption resulted in seg faults, while in 16 bit real mode memory corruption would scramble your hard disk.
I ran all the test suites on protected machines. Only when everything was perfect did I run the programs in real mode DOS.
Protected mode memory is the greatest advance ever in computer hardware.
I wonder if it's obsolete now that we have things like Wasm. I mean, in some sense, it's nothing new—the UCSD p-System, EUMEL, and Dijkstra's THE offered the same safety much earlier, just at a punishing performance cost.
Also, though, you could imagine a system that protected the hard disk from corruption without having to be involved every time the CPU accessed RAM. For example, you could warm-boot into a trusted executive every time you wanted to flush the I/O queue to the hard disk. Rebooting would reload the executive code from the disk and set a "supervisor" bit on the disk interface, which the trusted executive would clear before yielding control back to the untrusted user program.
AFAIU it was just (some versions of?) DOS/4GW that had a 64MB limit. Some other DOS extenders, in particular the open source DOS/32A, allow using the full 4GB virtual address space.
I only remember conio at the time, but without internet you just used what Microsoft gave you. The BBSes I used may have had it, but it's hard to use something if you don't know it exists.
I'm guessing that PC-Hack 1.0, the ancestor of Nethack, contains a fair subset of curses, and pdcurses is from 01987 according to the bottom of https://github.com/wmcbrine/PDCurses/blob/master/docs/HISTOR.... But on the IBM, curses mostly solved the problem of porting Unix software to MS-DOS. The problems it solved on Unix, like minimizing characters transmitted to the terminal, papering over differences between terminal types, and setting cbreak mode, just didn't exist.
>in 1994? You wish. Turbo C++/Pascal was widely used under DOS, things truly began to
change with WIndows 95 and even until 1997 DOS wasn't fully dead because it had very
complex uses with DOS extenders. Windows 95 was an unstable piece of crap and
for tons of industrial cases tons of people booted it in DOS mode to launch really
advanced software.
By 1994 you would even get multimedia CD's made for DOS with ease.
AFAIK, curses worked with ANSI codes while conio directly accessed the screen buffer. ANSI support on DOS wasn’t enabled commonly as it needed a separate device driver, ANSI.SYS, to work, and it usually made DOS text output slower.
So, even if curses were available on DOS at the time, nobody would have preferred to use it.
Nope! 720x400 72hz was extremely common for games and apps. It's also why a lot of cheap Point of Sale LCD monitors around the turn of the millennium had 75Hz panels
Can you point to some source for that? I've never heard of a game using that resolution. The vast majority of them used the standard 320x200, either in CGA, EGA or VGA. The first two ran at 60Hz, VGA at 70Hz. A few games in the mid to late 90s started to use some non-standard tweaked VGA modes but by then Windows 95 started taking over gaming. You can check Wikipedia or Mobygames if you don't believe me.
I used FreeDOS once to run ancient software which controlled an industrial size oven. The client was having an ever increasing challenge of sourcing IDE disks (in 2008) so I was contracted to find a solution.
Eventually we settled on industrial PCs, solid state media and FreeDOS.
It was significantly cheaper than replacing the oven at £1M each.... in 50 of their factories worldwide.
I hobby-code for DOS, partly because of nostalgia, but much also because it (specifically DOSBox, or DOSBox-X) is such a fantastic and stable virtual machine. No one is going to deprecate even some minor part of the API. And some emulators give you fun features like allowing any screen resolution to be set up to run in fullscreen on a modern monitor (exposed using standard VESA API inside of DOS).
There are some other retro computer or consoles that could probably be just as useful for this. But DOSBox (as well as QEMU+FreeDOS, for those that prefer that) are nice because they have fully open source implementation from the CPU-level up to the user utilities, so there is no need to mess with dodgy ROM downloads or such to get things working.
I have it on my to-do list to install FreeDOS on bare metal to set up a retro gaming box. Tried once, but for some reason the installer failed writing to disk. Anyway, if anyone is making new FreeDOS games, I'll gladly pay for them, and it'll give me an excuse to go down that avenue again.
If enabling CSM in your BIOS isn't an option or isn't enough for FreeDOS, there is a translation layer that can get it to run on UEFI hardware: https://github.com/FlyGoat/CSMWrap
OK, I just posted a comment saying FreeDOS will no longer run on hardware because of lack of BIOS support, but that might change things I guess. Hope it can be made to work.
Another big problem for FreeDOS is the lack of sound card support. I do not know if anyone has solved that yet.
I've used FreeDOS for doing BIOS updates. In the pre-UEFI days it was common for manufacturers to provide BIOS updates as a DOS executable, apparently with the expectation that the customer would be able to dig up some old MS-DOS disk somewhere.
I suppose nowadays there isn't much use for that anymore thanks to doing FW updates via UEFI capsules. Though at least on the Linux side (LVFS/fwupd) it seems most PC clone vendors aren't on board yet.
Almost zero, the non-zero ones are about supporting legacy software/hardware. Also I would not touch C on any DOS platform, since the great Turbo Pascal exists for it. Nothing else even compares to it.
MS-DOS was a reasonable bootloader for Linux and Windows 95; I imagine FreeDOS might be a better one if you wanted to do hobby OSDev. Historically you could get hard real time performance for things like controlling steppers from your parallel port under MS-DOS, but nowadays you'd just use Freeduino or an iCE40. Also maybe brushless motors.
FreeDOS is no good at all for booting anymore, since BIOS support is increasingly rare. No way to boot FreeDOS (or MS-DOS) from UEFI. And of course also no point in trying to run it on ARM or any other non-x86 CPU. Looks like the future for FreeDOS will be to run in virtual machines only. A bit sad, since running FreeDOS on the bare metal of a 21st century computer (even one from 10-20 years ago) has been a nice way to experience just how fast modern hardware is.
I suppose there could be a use for programming for computers that would otherwise be ewaste, although I'm not sure how much ewaste is out there that can run DOS but not, say, Linux or a BSD. Lots has already been trashed or recycled, and my impression is that retrocomputing enthusiasts are thinning out the market as well.
We were recycling e-waste computers back in the 1990's for community groups and disadvantaged users running Linux with full X desktops, internet connectivity (sometimes via multiple dialup modems with EQL load balancing!)
https://www.computerbank.org.au/ <- charity my then partner and I started at the time. Still going strong after all these years, even though she passed away a few years ago.
You can do DOS target software with Rust... it's pretty limited and the tooling around it isn't nearly complete enough to make anything easy. That said, if you want to make something akin to a Zork text mode game or similar there's that... you can also use ANSI escape codes as another possibility for CP437 text mode interaction.
To the list of compiler listed I want to mention this one as well, that is my compiler of choice for 16-bit C in (Free)DOS these days (because it has a MIT license, it's very small, and it runs great inside of DOS itself so no need to mess with cross-compilation and I know if I have an environment like FreeDOS or DOSBox set up I can both compile and run my code, and I will never have to re-install or reconfigure anything when moving between different host systems):
https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/TOOLS
(Not only Microsoft's C compiler in that directory, but also MASM, MAKE, and a bunch of other tools. 1-2 MB of files and you have an entire toolchain for 16-bit DOS.)
Interesting, "All files within this repo are released under the MIT License as per the LICENSE file stored in the root of this repo," but did they include the source for the toolchain? I may be looking in the wrong place...
No, but that MIT license does not say anything about sharing the source code, so just sharing the binaries should be fine. (Not a lawyer.)
( * Also thanks for mentioning MIT. My comment said BSD, but I fixed that now.)
Yeah, I didn't mean it was illegal, just that you might have an unnecessarily hard time fixing compiler bugs and understanding how the toolchain works.
Yes, of course. Source code would be nice, but I gamble on that there wasn't a terrible amount of bugs in that compiler. It is version 5.10, so not the first 5.x release, plus with the lack of good ways to distribute patches back then we all know software tended to be better tested. It also obviously works well enough to compile DOS 4.0 (and a bunch of user tools that are included) plus I have tried it already for some quite big code-bases without noticing anything being broken.
I feel like any bugs can probably be worked around and since it is C it is possible some things can be fixed by adding some macros in the include-files. I have thought of making some minor changes to the include-files to modify some of the few things I noticed that are missing from C89. I do not know if it is possible to make it 100% C89 compliant or if the binaries would have to be patched for that, but it seems like it already is 99% of the way.
* Since I can't comment on the comment to this post: Note I said C89. Definitely not going to go for anything more modern. Possibly add the standard integer size types from C99, as those can be useful for more portable code. There are other, bigger, compilers for more modern C versions that can cross-compile to DOS (and also Free Pascal that seems like a nice language for that).
Oh, yeah, you're definitely going to have a harder time adding C99 support to it than to OpenWatcom, not to mention C11, C17, and C23. Which matters if you're writing new code.
Is there really a difference between writing a DOS program and writing a FreeDOS program? You just need a period-accurate compiler that can target DOS. Maybe OpenWatcom, maybe DJGPP.
With HXDOS, you can also write a Win32 console-mode program and run it on DOS. 7-zip is an example of a program compatible with HXDOS.
The "difference" is, that this is the FreeDOS project, thus they focus on that environment.
I confess I don't know anything about FreeDOS, but are they trying to evolve DOS for the future, or just make a free bug-for-bug compatible version? Those are very different things.
Neither. Because they are not aiming for:
> a free bug-for-bug compatible version
FreeDOS is significantly different from "real" MS-DOS.
Back in the 20th century I used DR-DOS, written by Digital Research, the company behind the original OS of which DOS was an unauthorised re-implementation.
(DR CP/M-86 was years late, so SCP wrote 86-DOS as a replacement. MS licensed 86-DOS and later bought it. It's not a clone: CP/M was in a compiled high-level language, while 86-DOS was implemented in assembly language, implementing a version of the same API on a different CPU ISA, using a different filesystem drawn from a separate pre-existing product.)
Until MS discontinued MS-DOS and IBM kept on developing it for a few more versions, IBM PC DOS and MS-DOS were near identical.
DR-DOS was a little different from MS-DOS. It had extra commands, used different syntax in the config files, very slightly different output and things -- but then, it was from the original vendor, so that was excusable, and mostly, it understood MS syntax as well.
FreeDOS is not like that. It's quite unlike any other version of DOS. It has differently-named config files, it lives in a differently-named folder with an internal structure, and it has a number of external commands with different names and different syntax. For example, one that threw me is that there is no `SUBST` command, but a different `SWSUBST` which combines the functionality of SUBST and JOIN.
In 21st century DOS terms, at best, FreeDOS is as different from MS/PC/DR DOS as Red Hat is from Debian. In fact it may be more like it to say FreeDOS vs OG DOS is akin to FreeBSD vs Linux.
I think the goal is compatibility, but not being afraid of extensions (like power management support and some other "modern" hardware features)
In the context of this tutorial: They use their own "fed" editor.
The Digital Mars compiler for DOS is available for free.
https://www.digitalmars.com/
But the GCC, OpenWatcom, and DJGPP compilers the FreeDOS folks recommend are additionally free software, which is of real value to some of us. Zortech C had a reputation for producing better code IIRC, and it could run on an 80286, which I'm not sure the others can?
I don't remember when we transitioned to 32 bit DOS extenders for the DOS compilers, but we never got any pushback for that. Developers all used 386 computers.
I remember attending a compile panel at one of the SDWest conferences. The panel members were myself, representing Zortech, along with representatives from Borland, Watcom, and Microsoft.
The first question was "do you sell a version that will work on a floppy disk only computer?" One of the other panelists responded with yes, we do. He went on to describe how the various bits could be distributed among multiple floppies, and of course it involved a lot of shuffling floppies in and out.
I was next. I replied, "Yes, we have a version that does it! It costs $200 extra and comes with a hard disk drive!"
That got a huge laugh, and that was the end of that question. I never heard it again from anybody. Sometimes, it's just time to move on!
Historically there were 24-bit ("16 megs") DOS extenders that would work on a 286, though the 286's inability to seamlessly go back to real mode (which is needed for compatibility with BIOS routines) creates issues that make 286 protected mode a bit of a theoretical curiosity.
I used the 286 in protected mode for developing the compiler, until the 386 became available.
They were really worth it.
OS/2 ran on the 286 in protected mode. Rational Systems had a 286 protected mode system that we shipped with Zortech. Pharlap had one, too.
That was a very intelligent answer.
I was trying to come up with some advantage of Zortech C that might justify using it now instead of an open-source compiler like DJGPP under some circumstance. Any ideas?
https://github.com/DigitalMars/Compiler
Oh, the answer is that Zortech C is actually open-source, and I was just being an idiot? That's wonderful! And the license here doesn't seem to have any of the questionable bits in the OpenWatcom license.
I wasn't able to make it fully open source until a few years ago.
And maybe people just haven't noticed? I assumed when you said "free of charge" that you implicitly meant "but not open source", and also didn't see anything on https://www.digitalmars.com/download/freecompiler.html about compiler source, and the only "license" link on that page goes to https://www.digitalmars.com/download/dmcpp.html which says, "The Software is copyrighted and comes with a single user license, and may not be redistributed. If you wish to obtain a redistribution license,...", so maybe you could see how I got the wrong idea!
Yeah I need to fix that. Thanks for poking at it.
I'm glad my comment was useful! I was worried it might annoy you.
I guess it made a lot of sense to implement compilers in 32-bit protected mode to get more space to work with easier? Free Pascal's compiler also requires 32-bit even if it can generate 16-bit DOS code as well (at least when cross-compiling from some other OS; I have not tried to cross-compile from DOS 32-bit compiler to DOS 16-bit executable).
Some people (and by that I mean Debian people; not sure about anyone else) disagree about OpenWatcom being free software. The license has some unusual requirement(s). There has been talk for a long time about possibly fixing that, but I do not know how on track that is (or how much it matters, in practice): https://github.com/open-watcom/open-watcom-v2/discussions/27...
I developed on a 32 bit machine because of memory protection. Memory corruption resulted in seg faults, while in 16 bit real mode memory corruption would scramble your hard disk.
I ran all the test suites on protected machines. Only when everything was perfect did I run the programs in real mode DOS.
Protected mode memory is the greatest advance ever in computer hardware.
I wonder if it's obsolete now that we have things like Wasm. I mean, in some sense, it's nothing new—the UCSD p-System, EUMEL, and Dijkstra's THE offered the same safety much earlier, just at a punishing performance cost.
Also, though, you could imagine a system that protected the hard disk from corruption without having to be involved every time the CPU accessed RAM. For example, you could warm-boot into a trusted executive every time you wanted to flush the I/O queue to the hard disk. Rebooting would reload the executive code from the disk and set a "supervisor" bit on the disk interface, which the trusted executive would clear before yielding control back to the untrusted user program.
Thanks for the pointer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376431
It seems a bit questionable but not an open-and-shut not-open-source license.
I don't know about OpenWatcom but I used the original Watcom on my old 286 just fine. Even the Windows 3.1 IDE ran fine on it IIRC.
https://www.digitalmars.com/download/freecompiler.html
Seems to require Win32 (Digital Mars C/C++ Compiler Version 8.57). Is there a version of the C compiler than can run on FreeDOS or MS-DOS ?
Not any more. The Win32 one functions as a cross compiler. The compiler is a little large for MS-DOS' memory.
AFAIU it was just (some versions of?) DOS/4GW that had a 64MB limit. Some other DOS extenders, in particular the open source DOS/32A, allow using the full 4GB virtual address space.
Not really, I was expecteding the tutorial to somehow dig out Turbo C, or Quick C.
On conio.h under GNU/Linux or Unix, it might be mimicked with trivial functions and escape codes.
I did similar stuff with TCL and some at-xy lookalike from Forth or 'print at' from the old Basic.
And rewritting these Basic games into C, TCL or whatever it's really fun (and you can defnitively kill the spaghetti code):
https://github.com/GReaperEx/bcg
You can just run BW Basic for FreeDOS, but that's no challenge...
I don't know the answer, just asking the question: Is/Was curses available at the time? https://en.wikipedia.org/wiki/Curses_%28programming_library%...
I only remember conio at the time, but without internet you just used what Microsoft gave you. The BBSes I used may have had it, but it's hard to use something if you don't know it exists.
It does look like there is a recent port: https://github.com/wmcbrine/PDCurses
So my guess is curses was not available to DOS at the time, only Unix systems.
I'm guessing that PC-Hack 1.0, the ancestor of Nethack, contains a fair subset of curses, and pdcurses is from 01987 according to the bottom of https://github.com/wmcbrine/PDCurses/blob/master/docs/HISTOR.... But on the IBM, curses mostly solved the problem of porting Unix software to MS-DOS. The problems it solved on Unix, like minimizing characters transmitted to the terminal, papering over differences between terminal types, and setting cbreak mode, just didn't exist.
Most of us coding at the time only cared about Turbo Vision, starting with Turbo Pascal 6. and Turbo C++ 3.0.
Or the other variant being TUI libraries for Clipper.
By 1994, most folks on PC were already doing Windows 3.x, and only using MS-DOS for games.
I only got to learn about curses years later.
>in 1994? You wish. Turbo C++/Pascal was widely used under DOS, things truly began to change with WIndows 95 and even until 1997 DOS wasn't fully dead because it had very complex uses with DOS extenders. Windows 95 was an unstable piece of crap and for tons of industrial cases tons of people booted it in DOS mode to launch really advanced software. By 1994 you would even get multimedia CD's made for DOS with ease.
Yes, I am a 70's child that started coding in 1986.
By 1994, most people already had Turbo Pascal and C++ on Windows 3.x, I happen to have such boxes.
Turbo Pascal for Windows 1.5 and Turbo Pascal 7 both supported Windows 3.x.
Turbo C++ 3.1 onwards also did Windows 3.x.
Industrial use cases used purpose built OSes, and unstable piece of crap applies to all 8 and 16 bit home computer OSes without MMUs.
AFAIK, curses worked with ANSI codes while conio directly accessed the screen buffer. ANSI support on DOS wasn’t enabled commonly as it needed a separate device driver, ANSI.SYS, to work, and it usually made DOS text output slower.
So, even if curses were available on DOS at the time, nobody would have preferred to use it.
Tangentially related: I was getting awful screen tearing in dosbox with a gl @ 4K@60hz rendering target.
Switching to 1080p@240Hz fixed it. The problem was that 60Hz was close to, but not the framerate the old game asked for.
The typical 320x200 mode that games used back then ran at 70Hz.
72Hz actually!
CRT's were "strange" :)
No, for VGA it was definitely 70Hz, or 60Hz for the 640x480 mode but few games used that.
Nope! 720x400 72hz was extremely common for games and apps. It's also why a lot of cheap Point of Sale LCD monitors around the turn of the millennium had 75Hz panels
Or if they were "high resolution" 800x600 56hz
Can you point to some source for that? I've never heard of a game using that resolution. The vast majority of them used the standard 320x200, either in CGA, EGA or VGA. The first two ran at 60Hz, VGA at 70Hz. A few games in the mid to late 90s started to use some non-standard tweaked VGA modes but by then Windows 95 started taking over gaming. You can check Wikipedia or Mobygames if you don't believe me.
Apparently the 720x400 mode is a text mode, according to: https://retrocomputing.stackexchange.com/questions/14806/why...
I would agree it's not a mode that was commonly used for vga dos games, which used lower resolutions around 300x200 and 8 bit color.
Narishma is right, mode 13h is 320x200 @ 70hz.
Curious as to whether there are any real-world use cases for doing this (other than curiosity) in DOS. If so, I'd love to hear about them.
I used FreeDOS once to run ancient software which controlled an industrial size oven. The client was having an ever increasing challenge of sourcing IDE disks (in 2008) so I was contracted to find a solution.
Eventually we settled on industrial PCs, solid state media and FreeDOS.
It was significantly cheaper than replacing the oven at £1M each.... in 50 of their factories worldwide.
Lots of solid state to IDE adapties out there too. But great example.
An IDE->CF one would have been cheap enough.
I hobby-code for DOS, partly because of nostalgia, but much also because it (specifically DOSBox, or DOSBox-X) is such a fantastic and stable virtual machine. No one is going to deprecate even some minor part of the API. And some emulators give you fun features like allowing any screen resolution to be set up to run in fullscreen on a modern monitor (exposed using standard VESA API inside of DOS).
There are some other retro computer or consoles that could probably be just as useful for this. But DOSBox (as well as QEMU+FreeDOS, for those that prefer that) are nice because they have fully open source implementation from the CPU-level up to the user utilities, so there is no need to mess with dodgy ROM downloads or such to get things working.
What do you hobby code? Can we have a glance at it?
I have it on my to-do list to install FreeDOS on bare metal to set up a retro gaming box. Tried once, but for some reason the installer failed writing to disk. Anyway, if anyone is making new FreeDOS games, I'll gladly pay for them, and it'll give me an excuse to go down that avenue again.
If enabling CSM in your BIOS isn't an option or isn't enough for FreeDOS, there is a translation layer that can get it to run on UEFI hardware: https://github.com/FlyGoat/CSMWrap
That had not occurred to me and I'm also not sure. FreeDOS was able to boot just fine into the live environment. It was the disk part that failed.
OK, I just posted a comment saying FreeDOS will no longer run on hardware because of lack of BIOS support, but that might change things I guess. Hope it can be made to work.
Another big problem for FreeDOS is the lack of sound card support. I do not know if anyone has solved that yet.
For old DOS games and programs, there is this: https://github.com/crazii/SBEMU
(Not development in C)
I've used FreeDOS for doing BIOS updates. In the pre-UEFI days it was common for manufacturers to provide BIOS updates as a DOS executable, apparently with the expectation that the customer would be able to dig up some old MS-DOS disk somewhere.
I suppose nowadays there isn't much use for that anymore thanks to doing FW updates via UEFI capsules. Though at least on the Linux side (LVFS/fwupd) it seems most PC clone vendors aren't on board yet.
Almost zero, the non-zero ones are about supporting legacy software/hardware. Also I would not touch C on any DOS platform, since the great Turbo Pascal exists for it. Nothing else even compares to it.
MS-DOS was a reasonable bootloader for Linux and Windows 95; I imagine FreeDOS might be a better one if you wanted to do hobby OSDev. Historically you could get hard real time performance for things like controlling steppers from your parallel port under MS-DOS, but nowadays you'd just use Freeduino or an iCE40. Also maybe brushless motors.
FreeDOS is no good at all for booting anymore, since BIOS support is increasingly rare. No way to boot FreeDOS (or MS-DOS) from UEFI. And of course also no point in trying to run it on ARM or any other non-x86 CPU. Looks like the future for FreeDOS will be to run in virtual machines only. A bit sad, since running FreeDOS on the bare metal of a 21st century computer (even one from 10-20 years ago) has been a nice way to experience just how fast modern hardware is.
https://sourceforge.net/p/freedos/mailman/message/59108825/
There's mUEFIrcate for that.
How usable is Muefircate?
I suppose there could be a use for programming for computers that would otherwise be ewaste, although I'm not sure how much ewaste is out there that can run DOS but not, say, Linux or a BSD. Lots has already been trashed or recycled, and my impression is that retrocomputing enthusiasts are thinning out the market as well.
We were recycling e-waste computers back in the 1990's for community groups and disadvantaged users running Linux with full X desktops, internet connectivity (sometimes via multiple dialup modems with EQL load balancing!)
https://www.computerbank.org.au/ <- charity my then partner and I started at the time. Still going strong after all these years, even though she passed away a few years ago.
Vibe coders are just going to be staring at this and go... where'd you get that blue mode in Cursor?
From the soydev extension.
Would be nice to have a Rust compiler as well
You can do DOS target software with Rust... it's pretty limited and the tooling around it isn't nearly complete enough to make anything easy. That said, if you want to make something akin to a Zork text mode game or similar there's that... you can also use ANSI escape codes as another possibility for CP437 text mode interaction.
Only if they invent a 64 bit DOS extender.
indeed there's something similar: https://github.com/dosemu2/fdpp
Because of the compiler's memory consumption?