DOS ain't dead

T.K. Chia (and others) did a nice job reassembling the published GW-BASIC sources for us. His last binary release seems to be from Dec. 16, 2022.

* https://gitlab.com/tkchia/GW-BASIC

I wrote a very quick line-numbered BASIC program just to play around. (It's only 68 lines but irrelevant here.)

However, the GWBASIC.EXE does not support INSTR() at all. Which was strange to me since it should. I tried looking at the sources, but nothing obvious came up.

But I did recall that he mentioned an incompatibility with MASM having its own INSTR reserved keyword. So what happened was he auto-translated everything to "INSTRC"! And yes, INSTRC() works fine!

I would classify this as a (very tiny) bug.

There's also a tiny other quirk that it seems to pad output text files with Ctrl-Z and junk at the end. If I manually delete that, the output text matches that of a run with QBASIC.

Just FYI.

> T.K. Chia (and others) did a nice job reassembling the published
> GW-BASIC sources for us. His last binary release seems to be from
> Dec. 16, 2022.
>
> There's also a tiny other quirk that it seems to pad output text files with
> Ctrl-Z and junk at the end.

I figured out a simple workaround for that (using FreeDOS edlin, not sure if dependent upon compiler):


echo e | edlin file.txt


> T.K. Chia (and others) did a nice job reassembling the published
> GW-BASIC sources for us. His last binary release seems to be from
> Dec. 16, 2022.
>
> * https://gitlab.com/tkchia/GW-BASIC
>
> I wrote a very quick line-numbered BASIC program just to play around. (It's
> only 68 lines but irrelevant here.)
>
> However, the GWBASIC.EXE does not support INSTR() at all. Which was strange
> to me since it should. I tried looking at the sources, but nothing obvious
> came up.
>
> But I did recall that he mentioned an incompatibility with MASM having its
> own INSTR reserved keyword. So what happened was he auto-translated
> everything to "INSTRC"! And yes, INSTRC() works fine!
>
> I would classify this as a (very tiny) bug.

I added a patch in https://codeberg.org/tkchia/GW-BASIC/issues/15

---
l

Hello all,

Thanks for the bug report! As I mentioned at Codeberg, I eventually opted to apply a different fix for the INSTR problem. I have uploaded a new binary release at https://codeberg.org/tkchia/GW-BASIC/releases/tag/20261005 .

The trailing ^Z + junk is because the GW-BASIC code as released by Microsoft does file I/O using ancient FCBs, which obligatorily pad files up to some record size (128?).

I had been thinking of updating the code to use file-descriptor-based I/O as supported in MS-DOS 2+ — obviously this is possible! — but I am not familiar enough with the code to know how to do that. Any help in this department will be welcome.

Thank you!

(edit: fixed link to release page)

---
https://codeberg.org/tkchia · https://git.disroot.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

Hi tkchia,

Your signature's link to https://disroot.org/tkchia seems to lead to an error 404.

---
l

ecm: oops, thanks! It should point into git.disroot.org.

---
https://codeberg.org/tkchia · https://git.disroot.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

Something else, what does "lfanew" mean?

---
l

> Something else, what does "lfanew" mean?

It is a reference to the field at offset 0x3c in the MZ header structure definition in the Windows API (edit: or, at least, which used to be part of the API):
typedef struct _IMAGE_DOS_HEADER {
  WORD e_magic;
  WORD e_cblp;
  WORD e_cp;
  ...
  WORD e_lfarlc;
  WORD e_ovno;
  ...
  LONG e_lfanew;
} IMAGE_DOS_HEADER,*PIMAGE_DOS_HEADER;
As for what it really means: not totally sure — I am guessing it is some form of Hungarian Notation.

Thank you!

---
https://codeberg.org/tkchia · https://git.disroot.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"