Experiments with C in DOS

[timb]

There are a couple reasons for Turbo C. Probably the main one I guess is the low-level friendly additions Turbo C makes, like the register pseudos like _AH, _AL, _AX, etc. I do actually use a modern editor for Turbo C on most occasions. I write all my code in Notepad++ and then save it to a folder in DOSBox, then just run it in Turbo C. The other reason is just because I heard of it. It was probably the first thing I found, or already saw for a DOS C compiler.

You have to use Turbo C to compile this, because of the register pseudos, as they do not work in any other compilers that I know of (maybe TC++). There's no real reason it shouldn't work in FreeDOS, as it can almost run without DOS. The only thing it really uses from DOS are some delay functions, which could be replaced with either nothing, or the PIT.

Which version of TC did you use? There are some small, intrinsic differences between TC 2.0, TC 3.0, TC++ 1.01, Etc., though your code should compile and run fine in any of them. (TC++ is just a newer version of TC; they just added C++ support to the compiler.)

Actually, all of the popular DOS C compilers allow you to do inline ASM, directly access registers from C code, call interrupts and so on.

Manipulating registers from C code should be as easy as just calling “r->ax = whatever”. That should work with pretty much every compiler (TC, TC++, Borland C, Microsoft C and Watcom C).

Take the FreeDOS kernel for example. It’s written in a mix of C and ASM and will compile in any of above mentioned compilers (however the pure ASM Code is sprinkled with #ifdef statements adding and removing bits on a per compiler basis; that said, the high level C code is pretty clean).

I guess what I’m saying is the C/CPP compilers for DOS were pretty compatible. It’s the ASM products you have to watch out for. (TASM and MASM with all their modes!)

Anyway, I’ll try again with TC. Might be something with my patched version of TCPP.

[Ampera]

TC 3.0 afaik doesn't exist. I am using the final version of Turbo C (I think 2.01

I'm aware there's other stuff, and possibly even better stuff. I'm not entirely sure how I stumbled across this, but I've gotten used to it. For the same reason I use Netbeans for modern C programming, I've just gotten used to it.

This is all for entertainment purposes anyways. If I was serious about DOS programming, I would drop C and go with Assembly, as it's the somewhat more efficient option.

[timb]

TC 3.0 afaik doesn't exist. I am using the final version of Turbo C (I think 2.01

I'm aware there's other stuff, and possibly even better stuff. I'm not entirely sure how I stumbled across this, but I've gotten used to it. For the same reason I use Netbeans for modern C programming, I've just gotten used to it.

This is all for entertainment purposes anyways. If I was serious about DOS programming, I would drop C and go with Assembly, as it's the somewhat more efficient option.

Sorry, I meant TCPP 3.0. It went like this: TC1.x, TC2.x, TCPP1.x, TCPP3.x. (They skipped TCPP2.x.)

TCPP is 99% backwards compatible with TC, but produces much more optimized binaries (in both speed and size), so it’s well worth upgrading IMHO.

As for assembly and efficiency, unless you’re writing an OS kernel or something that touches the bare metal, a modern C compiler (like OpenWatcom) will generate highly efficient binaries. More so than you could do in assembly. You can also do inline ASM in your C program for the times you really need the extra performance.

DOS C programming is a lot like modern embedded programming, which is why I like it. (Compared to Windows and MSVCPP, where you need dozens of libraries and several hundred MB of runtimes installed just run a Hello World program.)

[Rick Law]

Microsoft C v6 which was a repackage of Green Leaf C was rather good.

I started with Demest C with soft ICE for debugging, then Greenleaf, then MS C.  The debugger with the last DOS version (for MS C or Greenleaf C, which was identical) was great for that time.  I tried Turbo C's briefly, but ran back to MS C V6 for the capabilities it offered.

[Ampera]

Microsoft C v6 which was a repackage of Green Leaf C was rather good.

I started with Demest C with soft ICE for debugging, then Greenleaf, then MS C.  The debugger with the last DOS version (for MS C or Greenleaf C, which was identical) was great for that time.  I tried Turbo C's briefly, but ran back to MS C V6 for the capabilities it offered.

I've currently moved to Turbo C++ after some weird compilation issues that I had with Turbo C, but I'm pretty much wrapping up my time with DOS for now. It's a fun hobby, but whatever I make I end up hitting a road block, and my mind isn't fully assembly ready, which is what I believe I would need in order to make any effective use of standard DOS. Watcom C was strange to me, and something I didn't touch much, despite it's native DOS extenders. I would honestly rather program all that myself, when and if I wish to do that. For now, I'm working on using C11 and the SDL2 libraries to make my programs. I will be coming back to DOS every so often, though.

[rdl]

I bought a copy of Borland Turbo C++ back in the mid nineties, but never had time to spend on it. Best I remember it was for Windows 3.1, and I'm pretty sure I still have all the manuals and floppy disks somewhere.

[Ampera]

That's neat. Indeed some versions of TC++ had Win16 support.

I believe I'm actually using Borland C++, not Turbo C++, as BC++ has some nicer features than TC++. Regardless, I'm moving my efforts towards other areas.

[rhb]

There is a *very* serious downside to C on a DOS machine.  If you have a pointer error you may be forced to reformat the disk and reinstall.

I had that happen one time and never tried programming on DOS again.  I stuck to Unix like God intended.

[helius]

That sounds pretty far-fetched. What an absence of permissions means on DOS is that you shouldn't run unverified batch scripts. The chance of a "pointer error" (like reading past the end of an array or something) actually writing garbage on to the disk is pretty minimal. It's not like the disk contents are memory mapped (as they can be in Unix!)

[Ampera]

That's what I thought. The program is loaded into memory, and unless you use disk I/O functions, it shouldn't do any of that.

[Ian.M]

It was *possible* back when MFM and RLL hard drives were the thing for rogue code using function pointers to cause a jump to the entry point in the hard drive controller card's ROM for its low level format routine, but even back then it was very unlikely.  Its also possible to do nasty things to system files if you are coding low level disk access routines. However if you are doing that sort of coding under DOS and not using a VM, you should probably use a test machine that's separate from your development machine, with nothing important on its hard drive.   Restoring MSDOS + MS NET (for ease of data transfer from your development machine) from a bootable USB stick or CDRW doesn't take very long and can easily be automated.

[alank2]

That sounds pretty far-fetched. What an absence of permissions means on DOS is that you shouldn't run unverified batch scripts. The chance of a "pointer error" (like reading past the end of an array or something) actually writing garbage on to the disk is pretty minimal. It's not like the disk contents are memory mapped (as they can be in Unix!)

I did a lot of DOS development in a DOS environment for years.  I fully knew that doing anything wrong in C can and will quickly lockup a system quickly, corrupt memory, etc.  Yes, it is possible that an out of control buggy program might accidentally corrupt the file system by calling a disk write to the wrong place by mistake.  I never had that happen [in many years of risking it!], though I knew it was possible and always had a backup of my system in case it did.

With all that said, I was pretty pleased to move to Windows NT 3.51 with its virtual dos machine.  No worry of it corrupting what it doesn't have access to!  I remember that NT window popping up very often telling me it was trying to execute an illegal instruction (when I did something wrong with a pointer usually!!!!).

[netdudeuk]

I started programming the PC (a Tandon 286) in 1989 / 1990.  I used the Microsoft C compiler and assembler to produce a graphical application which needed a VGA card, which was quite good for the time.

I had an extra monochrome (MDA) graphics card and monitor, which allowed me to run the CodeView debugger and see the graphics at the same time.

I could single step right through the C and assembly language on the mono display and watch the graphics application on the colour display.

Breakpoints, register display, etc, etc made it a great development environment for the time.