Predefining __OS_DOS__

Predefining __OS_DOS__

[Peter Gerwinski]

Hi, folks!

It is important for GNU Pascal, but it might be useful for C
programmers, too.

What about adding "-D__OS_DOS__" to the `CPP_PREDEFINES' of all
MS-DOS-like operating systems?

This would result in this symbol being predefined when compiling
a program for an MS-DOS-like target system.  Programmers writing
intended-to-be-portable programs can use this to determine
whether a system supports drives etc.

This would combine the often-needed

    #if defined (MSDOS) || defined (_WIN32) || defined (__EMX__)

to

    #ifdef __OS_DOS__

This change would affect the following files:

    dsp16xx/dsp16xx.h    (MSDOS)
    i386/go32-rtems.h    (MSDOS)
    i386/go32.h          (MSDOS)
    alpha/win-nt.h       (_WIN32)
    i386/mingw32.h       (_WIN32)
    i386/win-nt.h        (_WIN32)
    rs6000/cygwin32.h    (_WIN32)
    rs6000/win-nt.h      (_WIN32)
    EMX sources: tm.h    (__EMX__)

Greetings,

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980830
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: Predefining __OS_DOS__

[Jeffrey A Law]

  In message < 19981205125824.C299@esmeralda.gerwinski.de >you write:
  > Hi, folks!
  > 
  > It is important for GNU Pascal, but it might be useful for C
  > programmers, too.
  > 
  > What about adding "-D__OS_DOS__" to the `CPP_PREDEFINES' of all
  > MS-DOS-like operating systems?
  > 
  > This would result in this symbol being predefined when compiling
  > a program for an MS-DOS-like target system.  Programmers writing
  > intended-to-be-portable programs can use this to determine
  > whether a system supports drives etc.
You say it is important to Pascal -- why?  Seems to me that is this purely
a target issue, why does Pascal about defining __OS_DOS__ for the target?

I'd actually recommend programmers use the specific case they care about.  If
they want a #define for generic dos-like stuff, they can always add

#if defined (MSDOS) || defined (_WIN32) || defined (__EMX__)
#define __OS_DOS__
#endif

To one of their common header files.




  > This change would affect the following files:
  > 
  >     dsp16xx/dsp16xx.h    (MSDOS)
Ick.  This file probably shouldn't have MSDOS in its CPP predefines anyway.

  >     i386/go32-rtems.h    (MSDOS)
Similarly.

jeff

Re: Predefining __OS_DOS__

[Peter Gerwinski]

Jeffrey A Law wrote:
> 
> You say it is important to Pascal -- why?  Seems to me that is this purely
> a target issue, why does Pascal about defining __OS_DOS__ for the target?
> 
> I'd actually recommend programmers use the specific case they care about.

Up to now, `MSDOS', `_WIN32' and `__EMX__' always occured in
this combination in the GPC project.  Sometimes someone forgot
one (or two) of them and caused unpleasant bugs.  I don't know,
but I can imagine that similar things have happened in the C
world, too.

> If they want a #define for generic dos-like stuff, they can always add
> 
> #if defined (MSDOS) || defined (_WIN32) || defined (__EMX__)
> #define __OS_DOS__
> #endif

This is confusing for Pascal programmers since there is no
symbol `||' in Pascal.

> To one of their common header files.

There are no header files in Pascal.  One would have to add this
to each source file.

    Peter

Re: Predefining __OS_DOS__

[Jeffrey A Law]

  In message < 19981206160259.J189@esmeralda.gerwinski.de >you write:
  > Jeffrey A Law wrote:
  > > 
  > > You say it is important to Pascal -- why?  Seems to me that is this purel
  > y
  > > a target issue, why does Pascal about defining __OS_DOS__ for the target?
  > > 
  > > I'd actually recommend programmers use the specific case they care about.
  > 
  > Up to now, `MSDOS', `_WIN32' and `__EMX__' always occured in
  > this combination in the GPC project.  Sometimes someone forgot
  > one (or two) of them and caused unpleasant bugs.  I don't know,
  > but I can imagine that similar things have happened in the C
  > world, too.
True.  This can be a problem.  But I'd prefer people to actually think about
the code they write instead of depending on this kind of crutch.

I'd think it is just as likely that someone will start using __OS_DOS__ for
code they think is common to dos-like systems, when in fact it is not common
to all the dos-like systems.

Additionally, less and less code in the compiler should be conditional on
host defines of this nature.  Instead we should be depending on autoconf
macros and defines which indicate the availability or non-availability of
specific features.  This is the general direction most FSF code is taking
and __OS_DOS__ seems to me like a step backwards.

  > This is confusing for Pascal programmers since there is no
  > symbol `||' in Pascal.
But there's also no #ifdef in Pascal.  If they can learn about #ifdef,
#define and friends, they can learn about ||. :-)

  > There are no header files in Pascal.  One would have to add this
  > to each source file.
Err, if you're using cpp, then you have #include capabilities.  How else are
you testing #ifdefs?

jeff

Re: Predefining __OS_DOS__

[Peter Gerwinski]

Jeffrey A Law wrote:
>   > Up to now, `MSDOS', `_WIN32' and `__EMX__' always occured in
>   > this combination in the GPC project.  Sometimes someone forgot
>   > one (or two) of them and caused unpleasant bugs.  I don't know,
>   > but I can imagine that similar things have happened in the C
>   > world, too.
> True.  This can be a problem.  But I'd prefer people to actually think about
> the code they write instead of depending on this kind of crutch.
> 
> I'd think it is just as likely that someone will start using __OS_DOS__ for
> code they think is common to dos-like systems, when in fact it is not common
> to all the dos-like systems.
> 
> Additionally, less and less code in the compiler should be conditional on
> host defines of this nature.  Instead we should be depending on autoconf
> macros and defines which indicate the availability or non-availability of
> specific features.  This is the general direction most FSF code is taking
> and __OS_DOS__ seems to me like a step backwards.

In most other cases I would agree, but ports of GNU software to
MS-DOS-like systems have always been somewhat special rather
than part of the main line.  These ports being all independent
resulted in independent, unsystematic predefinitions.  (There
are, for instance, also -D__MSDOS__, -D__WIN32__, -DWIN32, but
only the combination I mentioned has the intended effect of
identifying all MS-DOS-like systems.)  I think it's time to
clean them up, and a common predefinition for all MS-DOS-like
systems is a step forward in this direction.

BTW, does anyone know whether autoconf works on MS-DOS?

>   > This is confusing for Pascal programmers since there is no
>   > symbol `||' in Pascal.
> But there's also no #ifdef in Pascal.  If they can learn about #ifdef,
> #define and friends, they can learn about ||. :-)

There is (*$ifdef FOO *), (*$define FOO *), but no `||' in
Pascal.  (In fact GNU Pascal does support `||' because its
preprocessor is a modified `cpp', but I consider C expressions
in a Pascal preprocessor a bug, not a feature, and I am not
planning to encourage their use in Pascal programs.)

>   > There are no header files in Pascal.  One would have to add this
>   > to each source file.
> Err, if you're using cpp, then you have #include capabilities.  How else are
> you testing #ifdefs?

Okay, it seems to be necessary to go a little deeper into the
details.

Pascal has include capabilities - (*$i Foo *) means
#include "foo.pas" - but they are not used for communication
between different modules of the same project.  (Pascal provides
other mechanisms to achieve this.)  Thus, a Pascal project
usually does not have "header" files included by all source
files.

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980830
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: Predefining __OS_DOS__

[Jeffrey A Law]

  In message < 19981211014146.J166@esmeralda.gerwinski.de >you write:
  > In most other cases I would agree, but ports of GNU software to
  > MS-DOS-like systems have always been somewhat special rather
  > than part of the main line.
True.  And if you read GNU policy on being DOS friendly you'll find that
policy discourages catering to DOS braindamage.  I agree with that policy.
MS DOS is not a priority.


  > identifying all MS-DOS-like systems.)  I think it's time to
  > clean them up, and a common predefinition for all MS-DOS-like
  > systems is a step forward in this direction.
I disagree strongly that this is a step forward, it sounds much more
like a step backwards to me.  It is not the compiler's job to try and predefine
"commonizing" symbols, nor should it be.

Code that needs to be dos-aware should check for the specific systems that
are dos-like using the existing predefines for each system.

  > BTW, does anyone know whether autoconf works on MS-DOS?
Unsure, but we can (and should) have the dos configurations emulate what
autoconf does if autoconf can not run on DOS.  ie, there are a set of things
autoconf defines based on characteristics of the host.  A DOS host would
use the same defines, but would generate them statically (or by running some
batch script).

This allows DOS hosts to appear to work much more like other hosts, which
allows us to support them in a reasonable fashion.

We need to move away from thinking about specific host systems and toward
thinking about how to write code which deals with characteristics of host
systems.  It's a subtle, but important distinction.

Instead of writing 

#ifdef DOS
do dos-like stuff
#endif

You write

#ifdef HAVE_SOME_FEATURE
do code to handle that feature
#endif

  > >   > This is confusing for Pascal programmers since there is no
  > >   > symbol `||' in Pascal.
  > > But there's also no #ifdef in Pascal.  If they can learn about #ifdef,
  > > #define and friends, they can learn about ||. :-)
  > 
  > There is (*$ifdef FOO *), (*$define FOO *), but no `||' in
  > Pascal.  (In fact GNU Pascal does support `||' because its
  > preprocessor is a modified `cpp', but I consider C expressions
  > in a Pascal preprocessor a bug, not a feature, and I am not
  > planning to encourage their use in Pascal programs.)
So, write a set of nested #ifdefs.  ANything you do with "||" can be done
with a nest.  Though I would encourage "||" for use in cpp macros.

There's no reason to confine Pascal to an inferior preprocessor.


jeff

Re: Predefining __OS_DOS__

[Geert Bosch]

On Sat, 12 Dec 1998 14:59:59 +0100 (EET), Kamil Iskra wrote:

  Using DIR_SEPARATOR is *NOT* appropriate, strictly speaking. It implies
  that only one character can be used for dir separation. This is true under
  UNIX, but not under AmigaOS, for example, where ':' can be used in some
  cases (and, unlike under Dos, it is usually NOT followed by
  DIR_SEPARATOR).

This is true in DOS-like systems and Unix as well:

 1.  C:\>DIR A:X
 2.  C:\>DIR A:\X
 3.  C:\>DIR \\SERVER\RESOURCE\X
 4.  dublin% ls /usr//bin

Here all ':', '/' and '\' are directory separators, and case 2, 3 and 4 are
rooted directories. In VMS multiple dir seps are used as well.

But actually I agree with you that using IS_DIR_SEPARATOR still is too low-level
to do in most cases, and more high level file handling functions would be
better. OTOH, better have something than nothing at all.

Regards,
   Geert

Re: Predefining __OS_DOS__

[Kamil Iskra]

On Fri, 11 Dec 1998, Jeffrey A Law wrote:

>   > What would be most helpful for those of us using non-Unix systems 
>   > (whether Win32, OS/2, DOS, VMS or other) is not to embed knowledge
>   > about things like filenames all over the place, but instead use functions
>   > or macros like IS_DIR_SEP(X), IS_ROOTED_PATH(X) to test for directory 
>   > separators or rooted paths.
[snip]
> Yes.  DIR_SEPARATOR shows up in cpp and other parts of gcc, but it's not
> used as often as it should be.   Using it more would allow for some cleanups
> of both the dos and vms support.

Using DIR_SEPARATOR is *NOT* appropriate, strictly speaking. It implies
that only one character can be used for dir separation. This is true under
UNIX, but not under AmigaOS, for example, where ':' can be used in some
cases (and, unlike under Dos, it is usually NOT followed by
DIR_SEPARATOR).

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

Re: Predefining __OS_DOS__

[Jeffrey A Law]

  In message < 87vhjiv9ms.fsf@cygnus.com >you write:
  > Jeff> Yes.  DIR_SEPARATOR shows up in cpp and other parts of gcc, but
  > Jeff> it's not used as often as it should be.  Using it more would
  > Jeff> allow for some cleanups of both the dos and vms support.
  > 
  > It would be nice if DIR_SEPARATOR and friends were put into a header
  > file somewhere.  As it is they are duplicated in various places (the
  > latest addition being java/jcf-path.c).
Yea.  This stuff really belongs in system.h.

jeff

Re: Predefining __OS_DOS__

[Tom Tromey]

Jeff> Yes.  DIR_SEPARATOR shows up in cpp and other parts of gcc, but
Jeff> it's not used as often as it should be.  Using it more would
Jeff> allow for some cleanups of both the dos and vms support.

It would be nice if DIR_SEPARATOR and friends were put into a header
file somewhere.  As it is they are duplicated in various places (the
latest addition being java/jcf-path.c).

Tom

Re: Predefining __OS_DOS__

[Jeffrey A Law]

  In message < 9812111040.AA25982@nile.gnat.com >you write:
  > What would be most helpful for those of us using non-Unix systems 
  > (whether Win32, OS/2, DOS, VMS or other) is not to embed knowledge
  > about things like filenames all over the place, but instead use functions
  > or macros like IS_DIR_SEP(X), IS_ROOTED_PATH(X) to test for directory 
  > separators or rooted paths.
  > 
  > Such definitions can be set in the appropriate configuration files
  > and then there is no need for #ifdef's in the actual code. 
Yes.  DIR_SEPARATOR shows up in cpp and other parts of gcc, but it's not
used as often as it should be.   Using it more would allow for some cleanups
of both the dos and vms support.

jeff

Re: Predefining __OS_DOS__

[Geert Bosch]

On Fri, 11 Dec 1998 00:51:55 -0700, Jeffrey A Law wrote:

  True.  And if you read GNU policy on being DOS friendly you'll find that
  policy discourages catering to DOS braindamage.
  [...]
  Instead of writing 
    #ifdef DOS
    do dos-like stuff
    #endif

  You write
    #ifdef HAVE_SOME_FEATURE
    do code to handle that feature
    #endif

What would be most helpful for those of us using non-Unix systems 
(whether Win32, OS/2, DOS, VMS or other) is not to embed knowledge
about things like filenames all over the place, but instead use functions
or macros like IS_DIR_SEP(X), IS_ROOTED_PATH(X) to test for directory 
separators or rooted paths.

Such definitions can be set in the appropriate configuration files
and then there is no need for #ifdef's in the actual code. 

Regards,
   Geert

Re: Predefining __OS_DOS__

[Mike Stump]

>   > What about adding "-D__OS_DOS__" to the `CPP_PREDEFINES' of all
>   > MS-DOS-like operating systems?

Let me comment further...  If we take all groups of two or three or
more defines and introduce a new define for each one and so on, we
have have all uses of defines only every have one define in them, now,
is this a win?

What is easier on mindshare, exponentially many defines all alike, or
exponentially fewer defines that purport to have some meaning?  I
submit that 10,000 defines are not better than 100, and for this
reason, we should _NOT_ do this.

This of a define a signaling, my code/implementation/OS is broken, and
here is why...  Better to have 0 of them.