Writing FreeDOS Programs in C
freedos.org
freedos.org
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.)
( * Also thanks for mentioning MIT. My comment said BSD, but I fixed that now.)
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).
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.
> 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.
In the context of this tutorial: They use their own "fed" editor.
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!
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.
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?
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 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.
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.
It seems a bit questionable but not an open-and-shut not-open-source license.
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 ?
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 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.
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.
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.
So, even if curses were available on DOS at the time, nobody would have preferred to use it.
Switching to 1080p@240Hz fixed it. The problem was that 60Hz was close to, but not the framerate the old game asked for.
CRT's were "strange" :)
Or if they were "high resolution" 800x600 56hz
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.
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.
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.
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.
There's mUEFIrcate for that.
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.