bencollver

27.01.2026, 03:04 |
trip report: Duff AWK (Miscellaneous) |
I attempted to convert Duff AWK from Borland C & TASM to Watcom.
I ran into a road block with lex. I ported the file awklex.l to work with Plan9 lex. However, awklex.l depends on functions defined in yylex.c, and yylex.c grubs around in the internals of a different version of lex. I wasn't able to identify which lex it depends on. It's not flex and it's not AT&T lex.
This means that to extend Duff AWK i would need to modify the old machine-generated code rather than re-generate it from awklex.l. I don't have the patience for that.
p.s.
The original build uses a small memory model. I found another build that uses a compact memory model so that it can better utilize conventional memory.
Small:
ftp://ftp.oldskool.org/pub/simtelnet/msdos/txtutil/awk320.zip
ftp://ftp.oldskool.org/pub/simtelnet/msdos/txtutil/awk320sr.zip
Compact:
https://www.burtonsys.com/ftp/AWK320.ZIP
https://www.burtonsys.com/ftp/AWKSRC.ZIP |
tkchia

27.01.2026, 18:12
@ bencollver
|
trip report: Duff AWK |
Hello bencollver,
Truly, the code needs a rewrite to depend only on POSIX lex features! 
I will not worry too much about yylex.c... For flex (and presumably POSIX lex in general), the routines inside yylex.c should either be defined inside the generated scanner code, or in the libl.a library (via -ll).
And, I think your above-linked source code assumes semantics of input () which are different from POSIX lex.
Thank you! --- https://codeberg.org/tkchia · https://disroot.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI" |
bencollver

27.01.2026, 19:08
@ tkchia
|
trip report: Duff AWK |
> Truly, the code needs a rewrite to depend only on
> POSIX
> lex features! 
Thanks for the sympathy!
Just to be clear, the code generated from awklex.l is held in awklex.c. The file yylex.c is a completely different source: it does not refer to the POSIX default output lex.yy.c. Another detail is that Duff AWK pre-dates POSIX lex. |
Rugxulo

Usono, 07.02.2026, 01:21
@ bencollver
|
trip report: Duff AWK |
> I attempted to convert Duff AWK from Borland C & TASM to Watcom.
OpenWatcom used to have some small fascination with POSIX tools and bundled some sources, but I never looked too closely.
At the very least, Gunther K. (in 2010) built BWK's awk with OpenWatcom for 16-bit DOS. But I think it uses too small a stack, and it (rarely) runs out of memory on code where MAWK runs fine (and faster).
MAWK is faster and better, IMHO, but I test with both (and GAWK and maybe others). The 1996 DOS + OS/2 (MS C) build of MAWK was pretty bloated, so I rebuilt with TC++ and UPX'd it.
All of that should be on iBiblio for FreeDOS.
> The original build uses a small memory model. I found another build that
> uses a compact memory model so that it can better utilize conventional
> memory.
There was also an older (GNUish) build of MAWK that ran in small model. |
roytam
10.02.2026, 07:17
@ Rugxulo
|
trip report: Duff AWK |
I wonder if any AWK variant that can compile as TINY model. |
bencollver

11.02.2026, 00:32
@ roytam
|
trip report: Duff AWK |
> I wonder if any AWK variant that can compile as TINY model.
RetroBSD.org runs a Unix kernel and userland in 128 kb RAM total. I haven't had a chance to tinker with its AWK yet. |