Re: Windows 9X compatibility

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

>> 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?

"no more" in the sense "more than we have today". I was not saying that
there are no people working on the Windows port.

>> 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).

> 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.

There are certain areas where the problem is not serious enough to
notice (mostly GDI) but threading, networking and I/O in general is a
minefield.

[snip]

>> 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.

This is no solution at all for the general problem. A pure W32 API
application made for W95 will build fine with modern versions of the
SDK, and XP (or Windows7) will execute it without complaining. But
chances are that it will not behave as it did on W95.

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

If current Windows maintainers are fine with this scenario, they are the
people who keep the Emacs port on a great shape *now* so they have the
right to set the policy. OTOH, it would be a good thing for the Emacs
project to lower the entry barrier as much as possible, as I previously
said discussing other topics. Is future W9X support important enough to
risk the loss of just *one* prospective contributor?