Re: Windows 9X compatibility

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 28 Mar 2010 21:57:02 +0200
> 
> >> 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.
> 
> ... and precisely gaining this information is difficult, because you
> must read the documentation for every API call and even then you can hit
> a bug, which is not rare in W9X (and before you say that any API has
> this problem, well, yes, but not to the extent of W9X).

You read too much into our reluctance to drop W9X support.  There's no
conscious effort to support W9X that would justify such a research.
We _try_ not to break W9X on purpose, but eventually testing and
reporting bugs (and sometimes, even debugging them) is up to the users
of those systems.  AFAIK, none of the active contributors to the
Windows port has access to a W9X system these days.

> > There's no requirements to use W9X-specific APIs.
> 
> Sorry, but do you have experience writing Windows raw API code on its
> successive incarnations since Windows 95? I'm starting to think you have
> not. Looking at the set of functions that makes the Windows API, those
> available on W95 are, for the most part, a proper subset of those
> available on XP. So, in theory, and unless you use certain obsoleted
> parts of the API (shell interaction, for instance, which is not part of
> the proper Windows OS API anyways) you are fine developing for W95. BUT
> there are two problems: quite a few W9X functions were extended on
> successive Windows versions with new features, so checking that the
> function is available on W9X is not enough, you must check that the way
> you intend to use the function is supported by W95. Often those
> differences are so fundamental that you must split the usage of the API
> call, one instance for W9X and another for NT (if you are
> lucky). Second, bugs are so frequent in the W9X API that, to all
> practical uses, quite a few functions have a non-documented behaviour
> that you must be aware of.

We are nowhere near such an investment.  Grep the sources for
is_windows_9x: you will see that it is used in some 2 dozen places to
return a failure indication where an advanced API is not available.
There are only two places in Emacs sources where W9X gets more than a
one-line code specific to it.  That's all there is to it.

> Is future W9X support important enough to risk the loss of just
> *one* prospective contributor?

No, it isn't.  But I saw no evidence of such a risk until now.  As I
tried to explain above, the bar is much lower than you seem to think,
because we do not promise any high-quality support for W9X that you
have in mind.  We just don't want to do anything that will surely
remove any possibility to run Emacs on these systems.