Re: m4 files not unique in 8.3 environments

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Date: Mon, 28 Feb 2005 15:49:23 +0100
> Cc: address@hidden, address@hidden
> 
> > It happens if one disables name-numeric-tails.  Which is necessary if
> > one wants the same installation to work on both DOS and Windows.
> 
> When a GNU program, built as a DJGPP binary, is run on Windows, it suffers
> from the horrible hacks inside Windows that were made to support the
> long + short filenames at the same time. And from the limitations of the
> DOS API vs. the Win32 API.

Bruno, would you please stop telling other people that their projects
are dead, obsolete, etc. (as you probably won't want others tell you)?
You are being unkind and unfair, something I would not expect from you
(or any other active participant of the Free Software movement, for
that matter).

Regarding your analysis of the problems related to file names on
Windows: it is based on misconceptions, misunderstandings, and wrong
assumptions.  For starters, the ``horrible hacks'' of the 8+3 alias
names plague MinGW programs no less than they do DJGPP programs,
because they are inherent in the Windows filesystems.  Even Windows
shell builtins are plagued by that (try "del *.jav" some day and watch
in horror as all your Java *.java files are nuked).

> Therefore for running programs on Windows, nowadays mingw is the
> platform of choice.

I can only assume that your own personal experience with using MinGW
for serious development is close to nil, because MinGW has yet to
arrive at the level of integration, coherency, and Posix compliance
that DJGPP gives its users since 1996.  GNU Make is a good case in
point: the upcoming release 3.81 will be the first, ever, to have an
official support for MinGW; by contrast, the DJGPP port of Make went
mainstream years ago.  On the GNU Make mailing list we are discussing
how to make the test suite work with the MinGW port, while the DJGPP
port passes the tests with flying colors since Make 3.78, which was
released in 1999.

Don't misunderstand me: I use MinGW ports, and applaud those who work
on it.  But one cannot call MinGW ``a platform of choice'' on Windows,
not yet.  There are too many subtle misfeatures and incompatibilities
that need to be resolved before MinGW becomes a reliable production
platform.

> > why should it be such a big problem.  They aren't magic file names,
> > are they?
> 
> They aren't magic filenames. But there has to be a limit of extra effort
> spent on non-mainstream platforms.

What effort?  We are talking about renaming 2 (two) files, for crying
out loud!  If you want, I can even suggest alternative names.

> DJGPP was released in ca. 1990, and became obsolete in 1995. I'm making
> changes that are suboptimal for DJGPP in 2002/2005.

Again, your data is wrong.  The latest stable version of DJGPP was
released in 2001, and its minor patch was released in 2002.  New ports
of GNU software are constantly released (just today I saw an
announcement of the ported Bison 2.0).  So DJGPP is very much alive.
And I can only wonder what myth caused you to write that DJGPP became
obsolete in 1995, since 4 years later, in 1999, Japanese Emacs
developers were excited when I installed the DJGPP port of Emacs on
their laptops running Windows 9x.

>   - Writing foo.html instead of foo.htm (or foo.lisp instead of foo.lsp)
>     expresses more clearly the content type of the file.

Wrong again: foo.html is perfectly fine on DOS, as is foo.lisp.
There's no problem at all to use long file names, as long as they are
unique in the first 8 characters of the trunk or the first 3
characters of the extension.  That uniqueness is all I'm asking for;
long file names are okay.

>   - Assuming that pipes are really pipes and not temporary files allow
>     some kinds of inter-process communications.

Why should you care about the implementation of pipes?  Use Posix
facilities, like popen and posix_spawn, which I'm sure you know about,
and everyone will be happy.

>   - Assuming the machine has more than 4 MB of RAM (such as a Sun3) allows
>     libiconv's code to be written the way it is.

That's another myth: DJGPP programs run in a 32-bit protected-mode
environment, and support virtual memory up to 512MB.  There's a DJGPP
port of libiconv that is widely used, FWIW.

To summarize, I find your refusal to rename 2 files to be puzzling at
the very least, as there's no technically sound reasons for it.  I
urge you to please reconsider.