Re: Windows 9X compatibility

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Sun, 28 Mar 2010 16:59:54 +0200
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> Date: Sat, 27 Mar 2010 18:39:01 -0600
> >> From: Christoph <address@hidden>
> >>
> >> The need is in my opinion a growing pain in the rear-end to support this 
> >> backwards compatibility.
> >
> > This argument can only be persuasive if it comes from someone who
> > personally experienced this pain, which could only be true if they are
> > active maintainers of the MS-Windows port.
> 
> Maybe the fact that there are no more active maintainers of the
> MS-Windows port is somewhat related to the pain in the rear that W9X
> compatbility is?

Who said there are no more active maintainers?  Please take a look at
the ChangeLog files to have some reality check.

> First, I don't have a machine for testing.

Neither do I.  There's no requirement to test the code on Windows 9X,
only not to use code that we _know_in_advance_ will break W9X.

> Second, the W9X API is so broken and has some many quirks that,
> apart from the permanent browsing of the MSDN it requires, a trivial
> change can be easily turned into a long session of mailing list
> archive archeology.

There's no requirements to use W9X-specific APIs.  We use APIs that
are available on all Windows systems, as much as possible.  When
that's impossible, we use the advanced APIs, and the affected Emacs
features are simply not available on W9X or display an error message.
We have quite a few such features already.  Use of NT file security in
file ops is one example that comes to mind; the "load average" display
on the mode line is another.

The only requirement is to use such features in a way that doesn't
crash Emacs on Windows 9X.  For example, we load system libraries with
error checking, instead of blindly assuming they are always available.

> Third, W9X compatibility means that you either have
> to refrain to implement features based on modern APIs or #ifdef them

See above: this is false.  (And #ifdef is not a solution anyway,
because a run-time check is needed.)

> which greatly adds to the maintenance burden.

True, there is some maintenance burden, but I personally find it
insignificant.  The code to load a library safely and invoke functions
that may not exist is very simple, almost boilerplate, and each
additional API that needs this treatment just needs more-or-less
copy-pasted more of the same.

Once again, I'm bewildered by the intense reaction to this issue,
given the facts.