Macros and the WIN32 define

[Guy Rouillier]

As I previously reported, I've been getting Chris Antos's grep working
on TSE Linux, with success. One issue I encountered is the use of the
WIN32 define. The use of the WIN32 define affects more macros than just
this grep macro. So rather than just making changes on my own for the
grep macro, I want to initiate a discussion about a standardized
approach we can hopefully use for all affected macros.

With Carlo's insights, the WIN32 define was apparently introduced to
differentiate DOS TSE from Windows TSE, long before Linux TSE existed.
But it turns out that the changes made in the grep macro for WIN32 are
mostly applicable to Linux TSE as well. By compiling the grep macro
(and other macro packages used by grep) with "sc32 -dWIN32=0", I was
able to get the macro working on Linux with very few changes required.

From what I can find, WIN32 is defined under windows, and LINUX is
defined under Linux, but there is no define that covers them both. The
SAL language does not permit compound conditions with #ifdef, so we
can't say something like "#ifdef WINDOWS or #Ifdef LINUX)". Perhaps the
easiest solution if to just look for a minimum TSE version of 4.4? Or
maybe given the limited audience, people would be satisfied just using
the -dWIN32=0 parameter with sc32 as I did above.

Opinions and suggestions welcome.

--
Guy Rouillier

[Carlo Hogeveen]

> Opinions and suggestions welcome.

Mostly information from me, and one opinion at the end.

Rethinking this, the solution I use and mentioned earlier
#ifdef LINUX
#define WIN32 FALSE
#endif
has the advantage that it makes old macros work for TSE 2.6 upwards, often including Linux, and new macros can then use "#if WIN32" as a reader-friendlier alternative to "#ifndef LINUX" to test for Windows-only.

This solution does not support TSE 2.5 and older versions.
I often make this explicit by generating a compiler error for 16-bit TSE versions with something like
#ifndef WIN32
16-bit versions of TSE are not supported.
#endif

The grep macro you are working on does not support TSE 2.5 and older, as Chris' documentation mentions.

That said, suppose you do want to support TSE 2.5 too.
You can compound compiler directives this way:
#ifdef WIN32
#define IS_32BIT 1
#else
#ifdef LINUX
#define IS_32BIT 2
#else
#define IS_32BIT 0
#endif
#endif

This lets the rest of the macro use
#if IS_32BIT
Do TSE 2.6 upwards stuff for Windows and Linux
#else
Do TSE 2.5 stuff.
#endif

An example reference that heavily uses compiler directives:
https://ecarlo.nl/tse/index.html#Compatibility_downto_tse40

Since compiler directives work per macro, we need not worry about what other macros do with compiler directives.

In my opinion, requiring users to recompile your macros with "-dWIN32=0" is a bad for two reasons:
1. This is an extra hurdle for less technical users.
2. At the latest this wrecks your macros at the next TSE upgrade, which simply recompiles all macros without external compiler options.
If you are changing macros anyway, then do what works without hassle for its users.

Carlo

Aside: After a frustrating day of failing to reinstall Windows 98 in a VM, I ended up simply testing the TSE 2.5 stuff in DosBox, making DosBox full screen. This worked awesome! Happy end.

[Guy Rouillier]

>> Aside: After a frustrating day of failing to reinstall Windows 98 in
a VM, I ended up simply testing the TSE 2.5 stuff in DosBox, making
DosBox full screen. This worked awesome! >> Happy end.

Since you already had a VirtualBox environment running, you could have
run FreeDOS in a VM. I set it up in VB in about 5 minutes, works great.

https://www.freedos.org/

--
Guy Rouillier

[Guy Rouillier]

See comments inline.

--
Guy Rouillier

On 9/25/2022 3:20:31 PM, "Carlo Hogeveen" <t...@ecarlo.nl> wrote:

>Rethinking this, the solution I use and mentioned earlier
> #ifdef LINUX
> #define WIN32 FALSE
> #endif
>has the advantage that it makes old macros work for TSE 2.6 upwards, often including Linux, and new macros can then use "#if WIN32" as a reader-friendlier alternative to "#ifndef LINUX" to test for Windows-only.
>

I don't think this is a good idea. I just grep'd all the .s* files in
the mac directory, and *all* of them test WIN32 only with #ifdef or
#ifndef. By introducing a boolean value to WIN32 that has unique
meaning (i.e., beyond the fact that it either does or does not exist),
you introduce a new avenue for logic errors. Given how long the OS
defines have been in use, the safer approach would be to restrict
testing of them only to whether they are defined or not.

>The grep macro you are working on does not support TSE 2.5 and older, as Chris' documentation mentions.
>
>That said, suppose you do want to support TSE 2.5 too.
>You can compound compiler directives this way:
> #ifdef WIN32
> #define IS_32BIT 1
> #else
> #ifdef LINUX
> #define IS_32BIT 2
> #else
> #define IS_32BIT 0
> #endif
> #endif
>
>This lets the rest of the macro use
> #if IS_32BIT
> Do TSE 2.6 upwards stuff for Windows and Linux
> #else
> Do TSE 2.5 stuff.
> #endif

Again, I think we should restrict IS_32BIT to only #ifdef or #isndef.

>
>Since compiler directives work per macro, we need not worry about what other macros do with compiler directives.

Well, here I am trying to maintain a macro I didn't write. So, some
consistent rules for writing macros would help people in a similar
situation. That's why major languages having coding styles. If, for
example, WIN32 can mean different things in different macros, that makes
keeping the entire set of macros working correctly much more difficult.

>In my opinion, requiring users to recompile your macros with "-dWIN32=0" is a bad for two reasons:
>

I agree completely. That was just a quick way for me to get the macro
working without rewriting it entirely. I would not submit that as an
official revision to that macro. I have forwarded the summary of my
work to Chris; we'll see how he would like to proceed.

Thanks for taking the time to reply. I appreciate your help.

[Carlo Hogeveen]

Guy,
I guess we disagree about the need for a different way to go forward and the need to discuss it.
For what it is worth, I do not remember seeing anyone other than Semware, Dieter Kössl (aka Dieter Koessl aka "dik"), Chris, and myself use compiler directives.
In TSE releases, Sammy's solution going forward seems to be to remove them.
Carlo