DOS ain't dead - Tiny C Compiler 0.9.27

bencollver

12.02.2026, 19:47

Tiny C Compiler 0.9.27 (Announce)

This is a DOS port of the Tiny C Compiler 0.9.27. It's actually a win32 binary, but is modified to run better in HXDOS.

This build requires an FPU (math coprocessor) to use floating point types.

It requires 16 MB RAM to bootstrap and rebuild itself.

It uses Watcom libc rather than MSVCRT.DLL.

It does not require LFN (long file name) support.

https://archive.org/details/tcc-0.9.27-for-dos

https://chiselapp.com/user/bencollver/repository/tcc4dos/timeline

gopher://tilde.pink/1/~bencollver/files/dos386/devel/tcc/

Oso2k 12.02.2026, 23:02 @ bencollver	Tiny C Compiler 0.9.27 Post reply
	What's the reason to produce a Win32 binary and force the use of HXDOS? I like HXDOS but the dependency makes this feel brittle. Why not use DJGPP or Watcom to produce a DPMI app?

bencollver 12.02.2026, 23:31 @ Oso2k	Tiny C Compiler 0.9.27 Post reply
	> Why not use DJGPP or Watcom to produce a DPMI app? Indeed. Feel free! As for myself, my motivation is to port "new" software to DOS just for fun.

Rugxulo Usono, 13.02.2026, 00:54 @ Oso2k	Tiny C Compiler 0.9.27 Post reply
	> What's the reason to produce a Win32 binary and force the use of HXDOS? I > like HXDOS but the dependency makes this feel brittle. > > Why not use DJGPP or Watcom to produce a DPMI app? I have not personally tried, but since OpenWatcom usually produces PE .EXEs with relocations, you could maybe try WDOSX "stubit tcc.exe" and see if that works.

Rugxulo Usono, 14.02.2026, 01:51 @ Rugxulo	Tiny C Compiler 0.9.27 Post reply
	> I have not personally tried, but since OpenWatcom usually produces PE .EXEs > with relocations, you could maybe try WDOSX "stubit tcc.exe" and see if > that works. Nope, doesn't work, no relocs found.

bencollver 14.02.2026, 02:12 @ Rugxulo	Tiny C Compiler 0.9.27 Post reply
	> Nope, doesn't work, no relocs found. Just out of curiosity, what would be the benefit of using WDOSX instead of HXRT? As a side note, i would like to point out that the Tiny C Compiler WITH SOURCE CODE will fit on a 1.44 MB floppy disk, and once extracted it can bootstrap itself. Neither DJGPP nor Watcom can do that.

Rugxulo Usono, 14.02.2026, 19:46 @ bencollver	Tiny C Compiler 0.9.27 Post reply
	> > Nope, doesn't work, no relocs found. > > Just out of curiosity, what would be the benefit of using WDOSX instead of > HXRT? Entirely self-contained (or at least mostly) and a native DOS app, even if run under Windows. Granted, even WinXP had bugs that DJGPP had to workaround. There is no perfect solution, everything has tradeoffs.

Rugxulo Usono, 14.02.2026, 19:47 @ bencollver	Tiny C Compiler 0.9.27 Post reply
	> As a side note, i would like to point out that the Tiny C Compiler WITH > SOURCE CODE will fit on a 1.44 MB floppy disk, and once extracted it can > bootstrap itself. Neither DJGPP nor Watcom can do that. Alexei's Smaller C can bootstrap itself.

bencollver 14.02.2026, 17:37 @ bencollver	Tiny C Compiler 0.9.27 Post reply
	Looks like i was not the first person to port TCC to DOS. In 2010 Detlef Reimers used HX-DOS to build TCC 0.9.25 on DOS, added a DPMI interface for DOS, and also added a VESA graphics library. https://detlefreimers.de/

bencollver

15.02.2026, 01:52

@ bencollver

Tiny C Compiler 0.9.27

Post reply

I reviewed Detlef Reimers changes in tcc4dos compared to the official 0.9.25 sources. The TCC source code directory tree was flattened and the files were renamed, but i was able to figure it out which files they corresponded to.

crt1.c
======

_start()

just before _controlfp() is the following TCC-specific inline ASM:

asm("int $0x1A" : "=d" (_RNUM) : "a" (0), "d" (0));

https://delorie.com/djgpp/doc/rbinter/id/80/22.html

If i read this correctly, this gets the system time in ticks into a global variable named _RNUM. This change is only made in crt1.c and is not present in wincrt1.c.

This _RNUM variable is used by a pseudo-random number generator in graphic.c.

delay.s
=======

This is a new file. It looks like a wrapper around the watcom delay() function. I don't really understand why it is there, and i don't believe this file is being used.

dllcrt.c
========

_dllstart()

just before the return statement is the following TCC-specific inline ASM:

asm("int $0x21" : : "a" ((short) 0xC06), "d" ((char) 0xFF));

https://delorie.com/djgpp/doc/rbinter/id/78/25.html
https://delorie.com/djgpp/doc/rbinter/id/70/25.html

Appears to be "flush buffer and read character from stdin"

My guess is that this is debugging code to add a pause at the end of DLL initialization?

dpmi.s
======

DPMI.S: Functions for accessing DOS interrupts and memory.
For TCC under the HXRT DOS extender (see hxdos.c).

https://downloads.openwatcom.org/ftp/devel/docs/dpmi10.pdf

hxdos.c
=======

// HXDOS.C: Functions for accessing DOS interrupts and memory.
// For TCC under the HXRT DOS extender (see dpmi.s).

To me it looks as though hxdos.c uses routines defined in dpmi.s.
The routines in hxdos.c are used in in grp/graphic.c and the examples under the xmp/ directory.

libtcc.c
========

include paths are changed from /include to /inc

tccelf.c
========

library name is changed from libtcc1.a to libt.a

tccpe.c
=======

library name is changed from tcc1 (tcc1.dll?) to t (t.dll?)

dll/vedasadll.c
===============

VESA graphics functions.

* * *

dpmi.s and parts of hxdos.c look potentially useful.

I don't plan to write graphical programs, but if i did, i might prefer to use sdl4dos and pull changes from DOSBox-X.

https://github.com/pdpdds/sdl4dos

"The SDL1 library distributed with DOSBox-X had been heavily modified from the original to support for example native OS menus."

https://personaljuan.github.io/dosbox-x/BUILD.html#to-compile-dosbox-x-for-dos-with-hx-dos-platform