On 2021-03-13 13:11:58, Michael Dukelsky (2:5020/1042) wrote to andrew clarke:

 ac>> Having a macro modify the variable passed to it just feels like bad
 ac>> code to me.

 MD> There's a lot of bad code here.

Yes.

Though somehow HPT works (mostly!) despite it all, so I don't like to be too harsh on any of the contributors.

None of the code I wrote 20 years ago is very good, in hindsight.

We are only human. :)

 ac>> Incidentally I think the "oldest" compiler still supported
 ac>> (properly) by HPT's build files is Open Watcom 2.0. The OW2.0 fork
 ac>> is an active project but its WCL386 compiler is still only C95
 ac>> compliant, as evident from the internal __STDC_VERSION__ macro
 ac>> being set to 199409.

 ac>> Though C95 is still newer than ISO/IEC 9899:1990, aka C89/C90.

 MD> Some persons emerge from time to time who want to build the sources for
 MD> DOS. Or maybe that was in BINKD echo...

Building for 32-bit DOS (DOS4GW) shouldn't be too difficult with OW2.0 now that the OW2.0 NT & OS/2 ports are building well. I've thought about a DOS4GW port but I'm not sure anyone would use it. At some point I may give it a try for a bit of fun and see how far I get, but I'd prefer to focus on fixing bugs and adding features.

Also it might already be possible to run the Win32 version of HPT under DOS using the HX DOS-Extender. HX is similar to PharLap/286 (one of the first DOS extenders) which provided emulation for a subset of 16-bit OS/2 functions. This allowed you to run a lot of text mode 16-bit OS/2 apps under regular DOS. HX does basically the same, but for a subset of Win32 programs (mostly text apps) on 386+ machines.

A 16-bit DOS port of HPT is theoretically possible but unrealistic, mostly due to the size of HPT and the DOS 640K limit, and even fewer people would use it compared to a potential DOS4GW version.

A 16-bit OS/2 port is also theoretically possible but would not be useful to anyone, except as a coding challenge.

--- GoldED+/BSD 1.1.5-b20180707