Re: Windows 9X without KernelEx

[Po Lu via "Emacs development discussions." <emacs-devel@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> If you add usp10.dll (and unicows.dll) to Windows 98, does Emacs start
> then?  Or do any of the other missing APIs prevent it from starting?

I cannot test with USP10.DLL at the moment, but that aside, as I said,
all of the following prevent Emacs from starting on Windows 98:

  Shell_NotifyIconW
  ShellExecuteExW
  SHFileOperationW
  ReadDirectoryChangesW

and none of them are being defined by USP10.DLL, which as I understand
it is only concerned with multilingual text layout.

> We should have discussed this before your writing the code, to prevent
> the unnecessary efforts.  I'm sorry for your wasted time, but I have
> said many times before: this kind of issues should be discussed first.
> I will keep saying that, in the hope that at some point this will
> sink.

I re-read the following twice and considerably moderated its tone, but
it might continue to read as a flame to the sensitive, so, trigger
warning.  In nowise is it meant as a personal reflection on anyone in
this thread, though if anyone who passes by recognizes himself in the
same, he would do well to change his ways.

\f

Had I discussed this before writing the code, and if the same comment
prompted the arbitrary decision to be made of discontinuing support for
the system declared in the README, I would still be disappointed with
the preliminary investigation, initiated on account of several _express_
words in a document bearing every mark of authority and affirming
support for said system, having gone to waste on the back of an offhand
comment by someone uninvolved with the systems in question (which
investigation was decidedly not trivial: locating what appeared to be a
trustworthy symbol list, a system file from a 30-year-old operating
system against which to verify the list, and a host of other sundries
from three decades past, all late at night); and if it is said that I
ought to have asked this question before entering upon any sort of work
in that direction, then there is only one inference to be made, that our
READMEs and FAQs are not to be trusted, as their authors are liable to
change their minds the moment their attention returns to facts they have
previously written.

The truth is that these are matters which affect myself quite strongly,
because it is a recurring pattern in Free Software (and to a lesser
degree, proprietary software) development that has emerged and gained a
sorry amount of currency that when serious deliberations are raised on
any subject touching on support for computer systems, sometimes 3
decades of age, but as easily 5 or 10 years old, or any number of any
unit of time that meets with disapproval from certain quarters, along
come professional commentators from the peanut gallery who derail the
conversation in favor of simply repudiating past commitments that have
been matched both by words and by deeds, without regard for the
tremendous physical and mental investments that their fellow human
beings have put into meeting them, or attempting to intelligently
explore how best to fulfill them in future.  The losers in this game are
the users and the developers, of whom the one are compelled to choose
between the purchase of new hardware and being denied features and bug
fixes from new releases of such programs as they know and love, and the
other are subjected to unremitting abuse, till they relent to the
demands of the mob.  Having been on the receiving side in both roles, I
am naturally intensely motivated to guarantee that everything continues
to function to the only impartial specification, existing, written,
documentation, or otherwise I would have called it a day after restoring
lock files to working order on that one machine.

The latest episode being the Android port.  Any reasonable man would
expect supporting a broad selection of systems produced after 2010 to be
a public service, yet I am called a criminal, and my character is
questioned and assassinated by cowards secure behind the protection of a
SourceForge handle.  All for the cardinal sin of promoting the continued
use of computers featuring less censorship, sabotage, or disobedience
towards their owners, and where vulnerabilities in the OS enable
computer owners to assert their dominion over their own property.

And, though proceedings in this list has been remarkably civil by
comparison with the above, yet their essence dangerously approaches that
of the latter, which is deeply upsetting.