DOS ain't dead

> > I do know that OpenWatcom's Win32/PE output seems to run fine under HX.
> So
> > I'd suggest to prefer that.
>
> Just out of curiosity, in which ways would a win32 build be preferable to a
> DJGPP build?

I don't think it is better. I would almost always prefer DJGPP. I meant "if you must use HX, stick to OpenWatcom".

In theory, having only one binary that runs on two (incompatible) OSes would be nice (even if relying on external API emulation).

In 2008, Japheth recompiled the FTE text editor with HX. There he implied a "true flat memory model" was better somehow. (For DJGPP, I think for stability they restricted access to low DOS memory.) He also (rightly) said DJGPP was a bit bloated, having never been optimized for size, so his way gave a slimmer binary. (UPX helps but DJGPP UPX'd stuff runs much slower under NTVDM. Not sure whether specific DPMI hosts would be better overall with demand paging for speed or lower memory usage.)

HX also supports .DLLs. (DJGPP has DXE3, which has had a lot of work done, but I'm unsure if it's truly equal in robustness.)

> > The msvcrt.dll supplied with Windows XP seems to work - and I guess the
> > ones supplied with Win9x are also ok.
>
> Thanks! I tried the following MSVCRT.DLL and at first glance it appeared
> to work:

I didn't try them all, but I literally meant it when I said use old ReactOS's 0.3.14 version from 2012. I'm not sure others work as well.

I really should try some simple MAWK/Win32 tests under HX myself and report back. (Well, I don't use system() or popen() a lot there.)

BTW, you mentioned elsewhere some flaws (?) in DJGPP's build when you didn't explicitly close some files (i.e. FAT corruption). I believe the built-in GAWK lint (and/or debugger??) will hint at such things in advance.

N.B. I really don't see the point of using or preferring proprietary .DLLs from Win9x at all. In that case, just use DJGPP. However, most people already have several Windows licenses.

> C:\BEN\mawk\bin>mawk "BEGIN{print \"hi\"}"
> hi
>
> But on closer inspection, it appears to have trouble running itself.
>
> C:\BEN\mawk\bin>type test.awk
> function sys(str) {
> printf "test.awk: %s\n", str
> retval = system(str)
> print ""
> return retval
> }
>
> BEGIN {
> sys("cd")
>
> cmd = ARGV[0] " \"BEGIN{print \\\"hi\\\"}\""
> sys(cmd)
> exit 0
> }
> C:\BEN\mawk\bin>mawk -f test.awk
> test.awk: cd
> C:\BEN\MAWK\BIN
>
> test.awk: C:\ben\mawk\bin\mawk.exe "BEGIN{print \"hi\"}"
> C:\FreeDOS\BIN\COMMAND.COM: line 1: runaway regular expression /c
> ...
>
> I'm not sure what to blame: this win32 build of mawk.exe, HX, or something
> else.

It could be a RE library quirk. Realistically, I'd suspect HX, but it could be a Windows (which? XP? 10?) problem. Last I checked, MinGW stated an (untested??) minimum of Windows 10.

Specifically, DOS with all its different memory types and managers and environments makes things a bit confusing. There is less confusion on a modern OS where everything is all unified (a single memory API and default shell). You know, system() isn't really "portable". Alexei's SmallerC had some limitations and quirks trying to use system() in his compiler. By this I mean system() is maybe too simplistic and incomplete. Adding anything else (spawn? exec? fork?) makes a big mess for true portability.

If anything, I'd suggest to stick to simple file input and output with AWK, then use external tools with the shell to manipulate that data. Don't try to do it all mixed together.

Actually, REXX was specifically designed to do exactly what you want, pass data to and from environments without (much, if at all) use of the system shell. However, again, you have to be careful in DOS (enough free conventional memory? CWSDPMI support? needs different "extender" or DPMI host?). CWSDPMI (pure 32-bit DPMI) won't run DOS4GW binaries, for instance, and can clash with some OpenWatcom "extenders".

Seriously, I've played a lot with REXX lately, even in DOS, and it's easily as good as AWK. Howard Fosdick gives away his 2005 REXX book for free, too. I can point you to several builds of Regina (DJGPP, DOS4GW) and BRexx (BorlandC 386+ real mode, TurboC 8086, DJGPP / DPMI). Regina prefers ANSI REXX "ADDRESS SYSTEM 'dir' WITH INPUT STREAM 'in.txt' OUTPUT STEM dat." while BRexx (32-bit only, 16-bit's stack depth is too small) prefers "dir (stack" and "stack> sort". (Anything that isn't an internal REXX function or instruction is treated as an external command and shelled out.)

I just think some things on non-POSIX systems (like Windows) are never emulated properly, e.g. popen (hence the Win95 patches of that for AWK). In other words, dark corners exist, especially for Windows (non-*nix) builds. If some features don't work portably, don't rely on them.

> I'm not sure what to blame: this win32 build of mawk.exe, HX, or something
> else.

Here's the output that I got in MS-DOS 7.1 when I run your test program ( with msvcrt.dll from XP SP3 ):


test.awk: cd
C:\TEMP\bin

test.awk: c:\temp\bin\mawk.exe "BEGIN{print \"hi\"}"
hi


haven't tried the dll of your link yet...

EDIT: tried "your" dll, same result as above.

---
MS-DOS forever!